RKN получает "root-доступ" к Рунету. Что это меняет для инженеров?

Новость, которая напрямую влияет на нашу работу. С 1 марта 2026 года Роскомнадзор получает беспрецедентные права на управление российским сегментом интернета.

Если коротко, РКН сможет:

Отдавать обязательные команды операторам связи.
Перенаправлять трафик через свои тех. средства (ТСPU).
Менять маршруты передачи данных.
В случае "угрозы" (критерии неясны) брать ручное управление всей сетью.

Формально это объясняется "устойчивостью и безопасностью". Фактически — это полная централизация управления сетью.

Взгляд архитектора: Что это значит для нас?

Это не политика. Это новые технические риски, которые мы обязаны учитывать при проектировании систем.

"Черный ящик" в маршрутизации: traceroute и mtr могут стать менее информативными. Мы получаем "черный ящик" (ТСPU) в середине маршрута, который может резать, фильтровать и замедлять трафик. Диагностика проблем с "тормозами" до AWS или Azure станет в разы сложнее.

Хрупкая избыточность: Ваша отказоустойчивая схема с двумя разными ISP (например, "Ростелеком" и "Билайн") теряет смысл, если РКН в "ручном режиме" направит трафик обоих провайдеров через один и тот же "бутылочное горлышко".

Риск изоляции: Доступ к критически важным внешним ресурсам (GitHub, Docker Hub, PyPI, apt-репозитории) может быть ограничен в любой момент по щелчку, если их сочтут "опасными".

Новый DR-план: В наших Disaster Recovery планах должен появиться новый сценарий: "Полная изоляция Рунета". Что будет делать ваш бизнес, если внешние API и SaaS-сервисы (включая ваш Cloud) просто исчезнут на N часов/дней?

Это новый вызов для каждого, кто отвечает за uptime и availability. Мы вступаем в эру, где сетевая связность перестает быть данностью и становится управляемым риском.

#security #networking #architect #sre #devops #russia

Linux: "Куда делся диск?" Скрипт для поиска "призрачных" файлов

Боль: Вы запускаете df -h и видите Use% 99% на разделе /var. Вы запускаете du -sh /var... и он показывает, что занято только 50%. Где остальные 49%?!

Ответ: Это "файлы-призраки". Процесс (например, nginx или java`) держит лог-файл открытым, а `logrotate в это время его rm (удалил). Файл исчез с диска, но пространство не освободится, пока процесс держит его "в памяти".

Реакция админа: reboot сервера.
Реакция архитектора: Найти "призрака" с lsof и освободить место без перезагрузки.

Этот Bash-скрипт использует lsof для поиска всех файлов, которые помечены как (deleted) , но все еще удерживаются процессами.

Код скрипта:
Bash

#!/bin/bash
# --- Поиск "призрачных" файлов (deleted but held open) ---

echo "--- Начинаю поиск файлов, удаленных, но удерживаемых процессами... ---"
echo "PID    USER     COMMAND     SIZE(MB)   FILE"
echo "----------------------------------------------------------------------"

# 1. lsof +L1: Найти файлы с link count < 1 (классический "призрак")
# 2. awk: Форматируем вывод, чтобы показать PID, User, Command, Size
# 3. sort: Сортируем по размеру (7-е поле, numeric-reverse)
# 4. head: Показываем топ-15

lsof +L1 -n | \
    awk '
    { 
        size_mb = $7 / (1024*1024); 
        if (size_mb > 1) { 
            printf "%-7s %-10s %-15s %-10.2f %s\n", $2, $3, $1, size_mb, $9 
        } 
    }' | \
    sort -k4 -nr | \
    head -n 15

Как использовать:
1. Сохраните как find_ghosts.sh и chmod +x find_ghosts.sh.
2. sudo ./find_ghosts.sh
3. Результат: Вы увидите, что PID 1234 (java) держит файл app.log (deleted) размером 10240 MB.
4. Решение: systemctl restart java-app.service. (Перезапуск процесса, а не всего сервера).

Взгляд архитектора: Вы не "гадаете", вы диагностируете. Вы понимаете, как VFS (Virtual File System) в Linux работает с inode и file descriptors . Это глубокое знание системы, которое отличает инженера от "эникейщика".

#linux #bash #sre #diagnostics #lsof #storage #скрипты #гайд

Linux: `systemd-nspawn` — контейнеры без Docker

Боль: Вам нужно быстро протестировать скрипт или сервис на "чистой" Ubuntu 24.04, но у вас RHEL. Вы не хотите ставить Docker, настраивать daemon.json или разворачивать тяжелую VM.

Решение: systemd-nspawn Это "секретное оружие" systemd . По сути, это chroot на стероидах, который встроен в вашу ОС. Он запускает легковесные контейнеры, используя то же ядро, но с полной изоляцией процессов и файловой системы.

Как это работает (на пальцах):

1. Создаем образ ОС (например, Ubuntu):
Bash

# (Нужен `debootstrap`)
sudo debootstrap jammy /srv/ubuntu-jammy

2. Запускаем контейнер:
Bash

# -D = директория
# -b = загрузиться в контейнер (boot)
sudo systemd-nspawn -D /srv/ubuntu-jammy -b

Готово. Вы в полноценной Ubuntu, которая запущена как сервис systemd .

Взгляд архитектора: Это идеальная "песочница" для отладки. Вы получаете полную, загружаемую ОС-контейнер без оверхеда Docker-демона. systemd-nspawn — лучший инструмент для тестирования systemd -юнитов и проверки скриптов в чистой среде перед "раскаткой" в прод.

#linux #systemd #container #devops #sre #гайд

Windows: `Perfmon` — это не 'топ'. `ETW` — вот настоящий 'eBPF'

Боль: `Perfmon` (Системный монитор) показывает 100% I/O на диске, но не говорит, КАКОЙ процесс и КАКОЙ файл это вызвал. Вы "слепы".

Решение: ETW (Event Tracing for Windows) ETW — это "черный ящик" ядра Windows. Это самый низкоуровневый и производительный (почти 0% оверхеда) механизм трассировки всего: I/O, Registry, Network, CPU...

PerfView — это бесплатный инструмент от Microsoft для "чтения" ETW.

Как найти "пожирателя" I/O (на пальцах):

1. Скачайте PerfView.exe (один файл, не требует установки).

2. Запустите сбор:
* PerfView.exe collect
* Оставьте на 30-60 секунд, пока идет "торможение".
* Нажмите "Stop Collection".

3.Анализируйте *.etl.zip файл:
* Откройте файл.
* Найдите "File I/O".
* БИНГО: Вы видите таблицу, где Process Name (sqlservr.exe), File Name (C:\DB\data.mdf) и IO_Time (ms) (90% всего времени).

Взгляд архитектора: Sysmon — это "что случилось". Perfmon — это "как сильно". ETW / PerfView — это "ПОЧЕМУ". Это ваш "микроскоп" для SRE-диагностики, который дает неопровержимые данные о том, какая функция в каком процессе "убивает" вашу систему.

#windows #sre #performance #diagnostics #etw #perfview #architect #гайд

Linux: htop — это прошлое. Встречаем btop++ — ваш SRE-дашборд

Боль: `htop` — это легенда, но он показывает только CPU и RAM . Чтобы увидеть диски, нужен iotop . Чтобы увидеть сеть — nethogs . Чтобы увидеть сенсоры — sensors .

Решение: btop++ . Это современный, написанный на C++ "комбайн", который показывает ВСЁ в одном, красивом, интерактивном окне.

Почему это "убийца" htop :
* Всё-в-одном: CPU, Память, Диски (I/O, iowait!), Сеть и Процессы — на одном экране.
* Интерактивность: Полная поддержка мыши, удобная фильтрация (F), дерево процессов.
* Визуализация: Встроенные ASCII-графики загрузки в реальном времени.

Установка (проще простого):
Bash

# Ubuntu/Debian
sudo apt install btop

# RHEL/CentOS (EPEL)
sudo yum install btop

# macOS
brew install btop

Взгляд архитектора: Это High-Resolution Observability (наблюдаемость высокого разрешения). Вы переходите от гадания "что тормозит?" к корреляции. Вы мгновенно видите: "Ага, CPU в норме, но Disk I/O уперся в 100%, и это процесс java (PID 1234)". Это сокращает MTTR (Mean Time to Resolution) с часов до секунд.

#linux #monitoring #sre #btop #sysadmin #tools #гайд

Kubernetes (Security): Аудит «привилегированных» Pod’ов и опасных контекстов

Боль: Кластер «зелёный», но в проде внезапно есть Pod’ы с privileged, hostNetwork и контейнеры, которые по факту бегут от root.
Реакция админа: «Они же работают».
Реакция архитектора: «Любая эскалация — это вопрос времени. Я хочу сигнал в моменте.»

Скрипт (Bash + kubectl + jq), выводит только рискованные контейнеры:

#!/usr/bin/env bash
# --- Kubernetes Risky Pods Audit ---
set -euo pipefail

command -v kubectl >/dev/null || { echo "[!!!] Требуется kubectl"; exit 2; }
command -v jq >/dev/null || { echo "[!!!] Требуется jq"; exit 2; }

echo "--- Начинаю аудит Pod'ов с опасными настройками ---"

data=$(kubectl get pods -A -o json)
echo "$data" | jq -r '
  [.items[] as $p
   | ($p.spec.containers + ($p.spec.initContainers // []))[]? as $c
   | {
       ns: $p.metadata.namespace,
       pod: $p.metadata.name,
       cont: $c.name,
       img: $c.image,
       privileged: ($c.securityContext.privileged // false),
       hostNetwork: ($p.spec.hostNetwork // false),
       hostPID: ($p.spec.hostPID // false),
       runAsRoot:
         ((( $c.securityContext.runAsUser
           // $p.spec.securityContext.runAsUser // null) == 0)
          or ( ($c.securityContext.runAsNonRoot
                // $p.spec.securityContext.runAsNonRoot // false) == false)),
       capAdd: ($c.securityContext.capabilities.add // [])
     }
  ]
  | map(select(.privileged or .hostNetwork or .hostPID or .runAsRoot
               or (.capAdd | index("SYS_ADMIN") or index("NET_ADMIN"))))
  | if length==0
      then "OK\tБезопасные настройки: нарушений не найдено"
    else
      (["NAMESPACE","POD","CONT","REASON","IMAGE"],
       (.[] | [
         .ns, .pod, .cont,
         ([
            (if .privileged then "privileged" else empty end),
            (if .hostNetwork then "hostNetwork" else empty end),
            (if .hostPID then "hostPID" else empty end),
            (if .runAsRoot then "runAsRoot" else empty end),
            (if (.capAdd|index("SYS_ADMIN")) then "SYS_ADMIN" else empty end),
            (if (.capAdd|index("NET_ADMIN")) then "NET_ADMIN" else empty end)
          ] | join(",")),
         .img
       ]))
      | @tsv
    end
' | column -t

echo "--- Аудит завершен ---"
echo "Рекомендация: навесьте PSP/PSa, OPA/Gatekeeper/Kyverno и зафиксируйте политику по умолчанию (runAsNonRoot=true, drop ALL)."

Взгляд архитектора: Вы не охотитесь на последствия, вы контролируете «плоскость допуска» (admission). Скрипт — датчик, политика — предохранитель.

#kubernetes #security #sre #devops #bash #jq #скрипты

Linux: htop врёт. Куда на самом деле уходит память? Вскрываем pmap

Боль: Вы запускаете htop. Он показывает: VIRT: 25.0G, RES: 500M. Вопрос: Куда "делись" 24.5 ГБ? Почему VIRT (виртуальная) такой огромный, а RES (физическая) — маленький?

Реакция админа: "Наверное, это кэш. Перезагружу".
Реакция SRE: "Я посмотрю карту памяти процесса".

pmap (Process Memory Map) — это "рентген" для процесса. Он показывает каждый регион памяти, который процесс "попросил" у ядра.

Как это читать:
1. Найдите PID (например, pidof java -> 1234).
2. Запустите pmap с флагом -x (расширенный):
Bash

pmap -x 1234

Что вы увидите:
*Сотни строк с .so файлами (это shared libraries — общие библиотеки).
* [ anon ]: Это "анонимная" память — то, что malloc() выделил в "куче" (heap). Если эта цифра растет — у вас 100% утечка памяти (memory leak).
* [ stack ]: Стек процесса.

"Убийца"-команда (показать итог):
Bash

# Показать только ИТОГО (Total)
pmap -x 1234 | tail -n 1
# Вывод: total ---- 25165824K

Бинго! Вот ваши 25 ГБ. Это не "утечка", а 1000+ .so-библиотек, которые "раздули" виртуальное адресное пространство.

Взгляд архитектора: Вы перестаете "гадать" по htop. Вы видите корень проблемы. pmap — это ваш микроскоп для диагностики утечек памяти и "раздутых" приложений.

#linux #sre #performance #diagnostics #pmap #команды #гайд #architect

🚀 Linux: "Убить" все процессы. kill — это скальпель, pkill — это "ковровая бомбардировка"

Боль: У вас "зависло" Java-приложение, которое расплодило 50 дочерних процессов java.
Реакция админа: ps aux | grep java, скопировать 50 PID'ов, kill -9 ... (потерять 10 минут).
Реакция архитектора: pkill.

pkill (process kill) и pgrep (process grep) — это ваш пульт управления процессами. Они ищут не по PID, а по атрибутам.

Как это работает:

1. Найти (pgrep):

# Найти все процессы, принадлежащие пользователю 'www-data'
pgrep -u www-data

# Найти все процессы, в команде которых есть 'nginx'
pgrep -f nginx

2. Убить (pkill): Это то же самое, но вместо "найти" — "убить".

# Мягко "попросить" все процессы 'java' завершиться
pkill java

# Жестко "убить" все, что принадлежит 'www-data'
pkill -9 -u www-data

# Убить все процессы, в команде которых есть "my_hung_script.py"
pkill -f "my_hung_script.py"

(Будьте очень осторожны с pkill -9 -u root)

Взгляд архитектора: Вы не управляете PID'ами (которые меняются). Вы управляете сущностями (пользователями, именами). Это быстрее, надежнее и идеально подходит для скриптов автоматизации (SRE).

#linux #cli #pkill #sysadmin #sre #команды #гайд

🔬 Linux (SRE): `htop` не видит диски. Находим "пожирателя" I/O с `iotop`

Боль: Сервер "тормозит". ssh "залипает". Вы открываете htop — CPU 5% , RAM 20% . Но iowait (wa) — 50% . Кто-то "убивает" дисковую систему.

Реакция админа: Перезагрузить сервер, надеясь, что "отпустит".
Реакция SRE: Запустить iotop.

iotop — это top для Disk I/O. Он в реальном времени показывает, какой ПРОЦЕСС и сколько читает (READ) и пишет (WRITE) на диск.

Как использовать (нужен root):

# 1. Установка
sudo apt install iotop
sudo yum install iotop

# 2. Запуск
sudo iotop

Ключевые флаги (чтобы видеть суть):

# -o: Показать ТОЛЬКО процессы, которые РЕАЛЬНО что-то пишут/читают
# -P: Показать Процессы, а не Потоки (намного чище вывод)
sudo iotop -oP

Результат: Вы мгновенно увидите, что PID 1234 (mysqld) пишет 200M/s (вероятно, "упал" индекс) или PID 5678 (jbd2/sda1-8) (журнал) сошел с ума.

Взгляд архитектора: Это SRE-диагностика. Вы не "гадаете", вы видите корень зла. Вы переходите от "наверное, диски" к "процесс mysqld (PID 1234) насыщает I/O, нужно смотреть его slow_query_log".

#linux #sre #performance #iotop #diagnostics #команды #гайд

🔬 Linux: Скрипт "Аудит открытых портов" (Сравнение с "Эталоном")

Боль: Вы думаете, что на вашем веб-сервере открыты только порты 22, 80, 443. Но разработчик "для теста" запустил python -m http.server 8000 на 0.0.0.0 и забыл.

Реакция админа: "Я проверю ss -tuln вручную, когда будет инцидент".
Реакция архитектора: "У меня есть cron-скрипт, который автоматически сверяет 'что есть' с 'что должно быть'".

Этот Bash-скрипт — ваш аудитор безопасности.

Код скрипта:

#!/bin/bash
# --- Скрипт аудита "лишних" TCP-портов ---

# 1. ЭТАЛОН: Порты, которые ДОЛЖНЫ быть открыты (на 0.0.0.0)
# (Используйте 'ssh' или номер '22')
ALLOWED_PORTS=(
    "ssh"
    "http"
    "httpsA"
)

# 2. ФАКТ: Получаем все, что слушает на 0.0.0.0 (IPv4)
# `ss -tuln`: TCP, UDP, Listening, Numeric
# `awk ...`: Вытаскиваем только номер порта
CURRENT_PORTS=$(ss -tuln | grep 'LISTEN.*0.0.0.0:' | awk '{print $5}' | sed 's/.*://' | sort -u)

# 3. СРАВНЕНИЕ:
# `comm -13`: Показывает строки, которые есть только во втором файле (CURRENT_PORTS)
# (т.е. "лишние" порты)
UNAUTHORIZED_PORTS=$(comm -13 <(printf "%s\n" "${ALLOWED_PORTS[@]}" | sort -u) <(echo "$CURRENT_PORTS"))

if [ -n "$UNAUTHORIZED_PORTS" ]; then
    echo "[!!!] ОБНАРУЖЕНЫ НЕСАНКЦИОНИРОВАННЫЕ ОТКРЫТЫЕ ПОРТЫ:"
    echo "$UNAUTHORIZED_PORTS"
    exit 1
else
    echo "[OK] Все порты соответствуют эталону."
    exit 0
fi

Взгляд архитектора: Это "Compliance as Code". Вы не "проверяете", вы валидируете вашу политику безопасности. Этот скрипт — основа для автоматического алерта в Zabbix или Prometheus (Alertmanager).

#linux #bash #security #networking #audit #скрипты #sre

🔬 Linux: Скрипт "Аудит dmesg". Ищем аппаратные ошибки
Боль: Сервер "тормозит", но htop и iotop — "зеленые". Приложение "вылетает" с Segfault.

Причина: Вы не видите аппаратных проблем. Отказ диска, "битая" RAM, проблемы с CPU — всё это логируется ядром в dmesg.

Реакция админа: "Проблемы с софтом, буду чинить приложение".
Реакция SRE: "Сначала проверю dmesg".

Этот Bash-скрипт — ваш "аппаратный аудитор". Он парсит dmesg и ищет "красные флаги".

Код скрипта:

#!/bin/bash
# --- Скрипт-аудитор 'dmesg' на ошибки ---

echo "--- Ищу 'красные флаги' в логах ядра (dmesg)... ---"

# -T: (Timestamps) Показать человеческое время
# --level=err,warn: Показать ТОЛЬКО ошибки и предупреждения
# (segfault, EDAC, I/O error, memory error...)
CRITICAL_ERRORS=$(dmesg -T --level=err,warn)

if [ -n "$CRITICAL_ERRORS" ]; then
    echo "[!!!] ОБНАРУЖЕНЫ КРИТИЧЕСКИЕ СОБЫТИЯ ЯДРА:"
    echo "$CRITICAL_ERRORS" | tail -n 20
    echo "--- Рекомендация: Немедленно проверьте I/O, EDAC (RAM) и CPU. ---"
else
    echo "[OK] Критических ошибок в dmesg не найдено."
fi

Взгляд архитектора: Это проактивный мониторинг "железа". Вы не ждете, пока smartd (диск) или EDAC (RAM) "покраснеют". Вы валидируете здоровье сервера на уровне ядра.

#linux #sre #diagnostics #bash #dmesg #скрипты #sysadmin

✅ AI-Промпт (Чек-лист): "Напиши мне systemd unit-файл"

Боль: Вы написали крутой скрипт на Python (app.py), но запускаете его в screen или через nohup ... &. Он "падает" — и всё.

Решение: Превратить его в настоящую Linux-службу (systemd). Но писать unit-файлы вручную — это "боль" (забыть [Install], User= и т.д.).

AI — идеальный генератор "болванок".

Промпт (для ChatGPT/Gemini/Copilot):

Выступи в роли Senior Linux SRE.
Напиши "production-ready" systemd unit-файл (`my-app.service`) для моего Python-приложения.

Чек-лист требований для AI:
1.  [ ] [Unit]: Добавить `Description=` и `After=network.target` (чтобы запускался *после* сети).
2.  [ ] [Service]:
    * `Type=simple`
    * `ExecStart=/usr/bin/python3 /opt/my-app/app.py` (путь к приложению).
    * `User=www-data` (Критично! Не запускать от root!).
    * `Restart=on-failure` (Критично! Авто-перезапуск при сбое).
    * `RestartSec=5`
    * `WorkingDirectory=/opt/my-app`
3.  [ ] [Install]:
    * `WantedBy=multi-user.target` (чтобы включался через `systemctl enable`).
4.  [ ] Объясни каждую секцию.

Взгляд архитектора: AI генерирует идемпотентный, безопасный (User=) и отказоустойчивый (Restart=) unit. Вы не тратите время на "бойлерплейт", а сразу получаете best-practice.

#ai4admin #linux #systemd #sre #automation #промпты #чеклисты

🚀 Linux (CLI): cd — это прошлое. Встречаем zoxide — "умный" cd

Боль: Ваш pwd — /srv/docker/containers/prod/nginx/config/sites-available/. Вам нужно "прыгнуть" в /var/log/nginx.

Реакция админа: cd /var/log/nginx (набирает 20+ символов).
Реакция архитектора: z log

zoxide — это "мозг" для вашей cd. Он запоминает каталоги, в которые вы чаще всего ходите, и "ранжирует" их.

Как это работает:

1. Установка: sudo apt install zoxide / brew install zoxide

2. Добавление в .bashrc / .zshrc: eval "$(zoxide init bash)"

3. Использование:

* z nginx -> "прыгнет" в /var/log/nginx (если вы там часто бываете)

* z sites -> "прыгнет" в /srv/docker/containers/prod/nginx/config/sites-available/

* zoxide query -l -> покажет все "запомненные" пути и их "рейтинг".

Взгляд архитектора: Это оптимизация рабочего процесса. Архитектор убирает "трение" (friction) из своей ежедневной работы. zoxide (как fzf или bat) — это инструмент, который экономит вам тысячи нажатий клавиш в день.

#linux #cli #zoxide #automation #devops #sre #гайд

🔬 Linux (SRE): Ваш Prometheus — "слепой". Встречаем Parca

Боль: Ваш Prometheus + Grafana показывают: "CPU spike at 14:30". И что? Вы знаете, что был всплеск, но вы не знаете, ПОЧЕМУ. Какая функция в вашем Python/Go/Rust-коде "съела" CPU?

Реакция админа: "Перезапущу pod, наверное, 'глюк'".
Реакция SRE: "Мне нужен непрерывный профилировщик".

Parca — это "Prometheus для профилирования". Он построен на eBPF и непрерывно (с почти нулевым оверхедом) сканирует CPU и память всех ваших процессов в системе.

Киллер-фича: Вы можете выбрать "спайк" CPU на Grafana, а затем "провалиться" в Parca и увидеть "Flame Graph" (огненный граф) — точную карту, показывающую, что function: process_payment() заняла 45% CPU в этот момент.

Взгляд архитектора: Вы переходите от "Мониторинга" (знать, что сломалось) к "Observability" (понимать, почему сломалось). Parca — это ваш "микроскоп", который находит "раковую опухоль" в коде, а не просто измеряет "температуру".

#linux #sre #ebpf #parca #observability #performance #architect #гайд

⚡ Linux: nice — для слабаков. Управляем Real-Time приоритетами с chrt

Боль: У вас есть критически важный процесс (например, VoIP-шлюз, база данных или процесс сбора метрик), который "заикается" или тормозит, когда сервер нагружен архивацией логов.

Реакция админа: renice -n -20 <PID>. (Это не поможет, если CPU загружен на 100%. Планировщик всё равно будет "честно" делить время).

Реакция архитектора: Использовать Real-Time Scheduler (SCHED_FIFO или SCHED_RR).

chrt — это утилита для управления планировщиком процессов.

Как это работает: Обычные процессы работают в классе SCHED_OTHER. Real-Time процессы (RT) имеют абсолютный приоритет. Если RT-процесс хочет CPU, ядро останавливает всё остальное, чтобы дать ему ресурсы.

Команды:

1. Посмотреть текущую политику процесса:

chrt -p 1234
# pid 1234's current scheduling policy: SCHED_OTHER
# pid 1234's current scheduling priority: 0

2. Сделать процесс "Бессмертным" (SCHED_FIFO): Внимание! Если этот процесс "зависнет" и съест 100% CPU, ваша система намертво зависнет.

# -f: FIFO (First In, First Out)
# -p 10: Приоритет 10 (от 1 до 99)
sudo chrt -f -p 10 1234

Взгляд архитектора: Это инструмент для Low Latency систем. Но с великой силой приходит великая ответственность. Архитектор использует chrt только тогда, когда понимает риски и изолирует такие процессы (например, через isolcpus в параметрах ядра).

#linux #performance #kernel #realtime #sre #chrt #гайд

metrics: SLA, SLO, SLI — Хватит путать эти аббревиатуры

На собеседовании на позицию Lead/Architect этот вопрос валит 50% кандидатов. Все говорят: «Ну, это про аптайм». Давайте разберем раз и навсегда.

1. SLI (Indicator) — Что мы меряем? Это конкретная метрика в графике.
Пример: Количество 500-х ошибок HTTP или Latency (задержка) ответа.
Факт: «Сейчас 99.5% запросов успешны».

2. SLO (Objective) — Какая у нас цель? Это внутренняя планка качества, к которой стремится команда.
Пример: «Мы хотим, чтобы 99.9% запросов были успешны».
Зачем: Если мы нарушаем SLO, мы останавливаем релизы новых фич и чиним стабильность (Error Budget).

3. SLA (Agreement) — За что нас накажут? Это внешний контракт с клиентом (юридический документ).
Пример: «Если аптайм упадет ниже 99.0%, мы вернем вам 30% оплаты».
Важно: SLA всегда ниже, чем SLO. У вас должен быть буфер безопасности.

Памятка архитектора: Не обещайте бизнесу 100% SLA. Это технически невозможно и бесконечно дорого. Обещайте «три девятки» (99.9%) и спите спокойно.

#sre #devops #metrics #sla #architecture #learning

🔥 Blameless Post-Mortem: Почему нельзя искать виноватых

Когда падает прод, инстинкт руководителя (и неопытного лида) — найти виновного. «Кто запушил конфиг? Петя? Лишить премии!»

Это путь в никуда. Архитектор строит культуру Blameless Post-Mortem (Разбор полетов без обвинений).

Почему это выгодно:

1. Честность: Если Петя знает, что его накажут, он будет скрывать ошибку до последнего, пока сервер не сгорит. Если знает, что не накажут — он придет и скажет: «Я сломал, давайте чинить». Время реакции сокращается в разы.

2. Системный подход: Ошибка человека — это всегда ошибка системы.

Плохой вопрос: «Почему Петя удалил базу?»

Вопрос архитектора: «Почему система позволила Пете удалить базу одной командой без подтверждения и бэкапа?»

Правило: Мы не чиним людей (увольнением). Мы чиним процессы (автоматизацией и защитой от дурака). В следующий раз, когда что-то сломается, начните разбор с фразы: «Мы не ищем виновных, мы ищем причину сбоя».

#softskills #management #sre #postmortem #culture #devops

🕵️‍♂️ Пятничный лонгрид: Анатомия сбоя. Почему мы чиним следствия, а не причины (и как перестать это делать)

Пятница. 16:45.
Прилетает алерт: «Прод лежит».
У тебя подскакивает пульс.
Руки сами тянутся к консоли, чтобы написать systemctl restart nginx или ребутнуть виртуалку.

🛑 Остановись.Убери руки от клавиатуры.

В 2026 году перезагрузка сервера без понимания причины — это не решение, а уничтожение улик.
Сегодня поговорим о том, что отличает «эникейщика» от Site Reliability Engineer (SRE): искусстве расследования.

1. Правило «Пяти почему» (The 5 Whys)
Мы часто лечим симптомы.
«Упал сервис — подняли сервис».
Это путь к выгоранию, потому что сервис упадет снова, когда ты будешь спать.

Применяй метод Toyota:
Проблема: Упал интернет-магазин (502 Bad Gateway).

1. Почему? PHP-FPM перестал отвечать.

2. Почему? Закончилась оперативная память, пришел OOM Killer.

3. Почему? Один процесс съел 4 ГБ RAM.

4. Почему? Пользователь загрузил картинку размером 50 МБ, а библиотека обработки изображений попыталась разжать её в память.

5. Почему? (Корневая причина): На фронтенде нет валидации размера загружаемого файла, а на бэкенде нет лимитов памяти на воркер.

Решение: Не «добавить памяти серверу», а «поставить лимит на загрузку».

2. Не путай совпадение с причиной (Correlation vs Causation)

«Я обновил ядро, и через час упала база. Наверное, ядро кривое». Возможно. А возможно, именно в этот час запустился «тяжелый» отчет бухгалтерии, который запускается раз в месяц.

Инструмент: В 2026 году мы смотрим на eBPF и трассировку. Не гадай. Используй perf, sysdig или biosnoop. Если ты не видишь, почему процесс встал (ждет диска? сети? мьютекса?), ты просто играешь в лотерею.

3. Теория «Черного ящика» и гигиена логов
Если твой лог выглядит как стена текста INFO: processed item, он бесполезен. В момент аварии тебе нужно знать, что случилось ДО падения.

Правило: Логи должны быть структурированы (JSON). Грепать текст в 2026-м — моветон.

Совет: Настрой ротацию так, чтобы при краше сохранялся coredump или хотя бы последние 1000 строк лога в отдельный файл crash_report_date.log.

🚀 Пятничный ритуал «Закрытия гештальтов»:

Чтобы уйти на выходные и реально отдохнуть, сделай эти 3 действия прямо сейчас:

* Browser Bankruptcy: Закрой эти 50 вкладок с документацией, которые ты «потом почитаешь». Если это важно — добавь в закладки/Obsidian. Если нет — закрой. Освободи RAM своего мозга.

* Clean Desktop: Удали с рабочего стола (и из папки Загрузки) временные скрипты test.sh, sql_dump_new_final.sql и скриншоты ошибок. Цифровой мусор создает тревожность.

* Silence is Golden: Проверь расписание дежурств (On-Call). Если в эти выходные ты не дежурный — выключи уведомления рабочего чата. Совсем. Мир не рухнет, а твоя нервная система скажет спасибо.

Помни: Хороший инженер — это не тот, кто быстро чинит, а тот, кто знает, почему оно сломалось, и делает так, чтобы это не повторилось.

Выдыхаем, коллеги. Эта неделя была долгой, но мы справились. 🍺🔌

#friday #longread #troubleshooting #sre #sysadmin #psychology #admin_future #debug

🧠 Skills: Культура Blameless Post-Mortem — как чинить системы, а не людей

Все падают. Даже инфраструктура технологических гигантов периодически ложится отдыхать. Отличие сильной IT-команды от слабой заключается не в количестве инцидентов, а в том, что происходит на следующий день. В 2026 году метод поиска крайнего инженера — это прямой путь к деградации инфраструктуры. Встречайте концепцию Blameless Post-Mortem (Безобвинительный разбор инцидентов) из практик SRE.

Что это такое:

Это документ и встреча, цель которых — понять ПОЧЕМУ произошел сбой, а не КТО его устроил. Главный принцип: мы исходим из того, что каждый сотрудник в момент инцидента действовал с хорошими намерениями и принимал оптимальные решения на основе той информации и инструментов, которые у него были.

Как провести правильный Post-Mortem:

— Запрет на слово КТО: Вместо «Кто удалил боевую базу данных?» мы спрашиваем «Какая последовательность действий привела к удалению?» и «Почему система позволила это сделать без подтверждения?».
— Хронология — это база: Соберите точный таймлайн. Во сколько пришел алерт, когда начали чинить, когда восстановили. Только сухие факты из систем мониторинга и рабочих чатов без эмоциональных окрасов.
— План действий: Итогом должен стать список системных задач в трекере. Например: «Настроить права доступа так, чтобы деструктивные команды не работали на проде без апрува второго администратора».

Если за ошибку наказывают, инженеры начинают скрывать проблемы и не зовут на помощь до последнего. В культуре Blameless люди сами приходят и говорят: «Я нашел уязвимый процесс в наших регламентах, давайте закроем дыру, пока не рвануло».

Ваша задача как сисадмина и архитектора — строить отказоустойчивые системы. А самая ненадежная деталь системы — это уставший человек с правами высшего уровня. Защищайте людей от систем, а системы от людей.

#skills #sre #postmortem #management #devops #admin_future

🧠 Skills: On-call без выгорания — как построить дежурство, которое не съедает людей

Коллеги, давайте честно: у большинства из нас on-call — это "телефон всегда при тебе, и молись чтобы не позвонили". Никакого графика, никакой ротации, один человек тащит всё потому что "он лучше всех знает как это работает". Богдан снова не спал в эту пятницу.

Это не героизм. Это провал организации процесса.

Google SRE Workbook рекомендует максимум 2–3 actionable-инцидента за смену как устойчивую норму. Если у вашей команды стабильно 8–10 — у вас не проблема дежурства, у вас проблема с алертами. Сначала чиним шум, потом думаем о ротации.

Три кита нормального on-call:

Первое — ротация и границы. Идеально: не чаще одной недели дежурства раз в 6–8 недель. Всё чаще — ведёт к усталости. Всегда должны быть: primary (отвечает первым), secondary (бэкап если primary недоступен) и escalation path к руководителю — не для технических решений, а для принятия бизнес-решений.

ШАБЛОН МАТРИЦЫ ЭСКАЛАЦИИ

Уровень 1 (0–15 мин):  Дежурный инженер (primary)
  -> Автоматический runbook, первичная диагностика

Уровень 2 (15–30 мин): Дежурный инженер (secondary)
  -> Подключается если primary не отвечает или нужна помощь

Уровень 3 (30–60 мин): Тимлид / старший инженер
  -> Техническое решение нестандартной ситуации

Уровень 4 (60+ мин):   Руководитель
  -> Только для бизнес-решений: откат релиза,
     уведомление клиентов, привлечение вендора

ПРАВИЛО: каждый уровень получает уведомление автоматически.
Никакого "позвони сам если не справляешься" — это перекладывание
ответственности на усталого человека в 3 ночи.

Второе — алерты, которые требуют действия. Каждый алерт должен отвечать на один вопрос: "нужно ли действие прямо сейчас?" Усталость от алертов возникает из плохого соотношения сигнал/шум.

Аудит алертов раз в квартал — три категории:

[ACTIONABLE]  Алерт требует действия в течение 15 минут.
              Будит людей. Должен быть в PagerDuty/Grafana OnCall.

[WATCHFUL]    Алерт требует внимания в рабочее время.
              Тикет в очередь, не звонок ночью.

[NOISE]       Алерт не требует никаких действий.
              Отключить немедленно.

Реальная статистика большинства команд при честном аудите:
- 20% алертов — ACTIONABLE
- 30% — WATCHFUL
- 50% — NOISE (которые будят людей ночью годами)

Третье — blameless postmortem, который реально работает. Команды с blameless postmortem в 2.3 раза чаще имеют высокопроизводительные системы. Разница проста: blameless-культура фокусируется на обучении, blame-культура — на наказании. Когда инженеры боятся признавать ошибки, они скрывают проблемы, и мелкие инциденты разрастаются в крупные.

Шаблон постмортема за 30 минут:

## Постмортем: [Название инцидента] | [Дата] | Severity: P[1-3]

### Что случилось (2-3 предложения)
### Timeline (с точными временными метками)
### Влияние на пользователей и бизнес
### Root Cause (система/процесс, не человек)
### Что сработало хорошо
### Что нужно улучшить
### Action items:
  | Задача | Владелец | Дедлайн |
  |--------|----------|---------|
  | ...    | ...      | ...     |

ЗАПРЕЩЁННЫЕ ФОРМУЛИРОВКИ:
  ❌ "Инженер не заметил алерт"
  ✅ "Алерт не имел достаточного приоритета в системе"
  ❌ "админ забыл обновить конфиг"
  ✅ "Процедура деплоя не включала проверку конфигурации"

Зачем это нужно:
Организации, которые делают это правильно, имеют не только меньше случаев выгорания — у них быстрее время реакции, лучше follow-through по постмортемам и on-call программы, которым инженеры доверяют, а не которых боятся.

Итог: On-call — это контракт между компанией и инженером. Компания получает надёжность 24/7. Инженер получает справедливую ротацию, понятные правила и восстановление после смены. Если одна из сторон не выполняет свою часть — это не дежурство. Это эксплуатация.

#skills #oncall #incident #postmortem #sysadmin #sre #admin_future