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

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

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

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

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

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

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

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

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

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

💀 Искусство Post-Mortem: Как писать отчеты об авариях, чтобы тебя повысили, а не уволили

В Google это называют Blameless Post-Mortem (разбор полетов без поиска виноватых). В российских реалиях это часто называют «объяснительная». Разница в том, что объяснительную пишут, чтобы прикрыть свою спину, а Post-Mortem пишут, чтобы прикрыть спину компании.
Вот структура идеального отчета, после которого директор скажет:
«Да, нам нужно купить это железо», а не «Вы уволены».

1️⃣ Правило «Без вины» (No Blame Policy)

Первая строчка любого отчета. Мы ищем причину в системе, а не человека.
❌ Плохо:
«Администратор Иванов случайно удалил таблицу в базе данных».
✅ Хорошо:
«Отсутствие защиты от случайного удаления (подтверждения команды) и наличие прав на DROP TABLE у дежурного инженера в продуктивной среде привело к потере данных».
Почему это работает:
если обвинить Иванова — в следующий раз Иванов скроет ошибку.
Если обвинить процесс — становится понятно, что увольнение одного человека проблему не решит.

2️⃣ Хронология — это твой щит

Менеджеры всегда спрашивают: «Почему так долго чинили?»
В отчете должна быть поминутная хронология:
• 14:00 — мониторинг Zabbix зафиксировал рост latency
• 14:05 — дежурный инженер получил алерт и начал диагностику
• 14:15 — выявлена проблема с дисковым массивом
• 14:20 — принято решение переключить трафик на резервный ЦОД
Зачем это нужно:
показывает, что команда работала, а время уходило, например, на согласования с бизнесом. Часто именно здесь рождаются аргументы для пересмотра SLA.

3️⃣ Метод «5 Почему» (5 Whys) — путь к бюджету

Главная цель — найти Root Cause.
Пример: упал сайт.
Почему? — закончилось место на диске.
Почему? — логи заняли всё пространство.
Почему? — ротация логов не сработала.
Почему? — конфиг изменили вручную с ошибкой.
Почему? — нет CI/CD для конфигов и автоматической проверки.
Вывод:
нужно не «чистить диск», а внедрять Ansible, GitLab CI и закладывать ресурсы на DevOps и тестовую инфраструктуру.

4️⃣ Переводи с «эльфийского» на деньги

Директору не важны OOM-killer и race condition.
Ему важны потери бизнеса.
Раздел Impact:
• Downtime: сервис недоступен 45 минут
• Losses: потеряно ~1500 транзакций
• Risks: высокие репутационные риски (жалобы VIP-клиентов)
Когда появляется цифра потерь, просьба купить сервер уже выглядит как инвестиция, а не расход.

5️⃣ Action Items: как мы потратим ваши деньги

Что делаем, чтобы это не повторилось.
Сейчас (без затрат):
• исправлен конфиг
• добавлен алерт
Среднесрочно:
• переработка скриптов деплоя
Долгосрочно (бюджет):
Проблема: текущий сервер БД не справляется с пиками нагрузки.
Риск: повтор аварии в ближайшие 2 месяца.
Решение: кластер из двух серверов + лицензия Enterprise-backup.

Итог
Никогда не упускай хороший кризис.
Пока всё работает — IT выглядит как статья расходов.
Когда всё ломается — ты становишься человеком, которому дают ресурсы.
Пиши Post-Mortem честно, сухо и с цифрами — и вместо увольнения получишь доверие, уважение и бюджет на апгрейд.
Стабильного прода и мудрых руководителей 🤝

#лонгрид #карьера #postmortem #management #money #sysadmin #admin_future

🚀 Skills: Постмортем — Как перестать наступать на те же грабли

Сервер упал, ты его поднял за 5 минут — молодец. Но если ты не написал «постмортем» (разбор полетов), через месяц ты снова будешь поднимать его в 3 часа ночи по той же самой причине. В 2026-м цена ошибки в инфраструктуре на ARM-кластерах слишком высока.

Золотые правила хорошего постмортема:

1. Никаких имен: Цель — найти слабое место в системе, а не «наказать Ваню».
2. Хронология: Запиши по минутам: что случилось, когда заметили, когда исправили.
3. Root Cause: Найди корень проблемы. «Забился диск» — это не корень. «Логротейт не отработал из-за ошибки в конфиге» — вот это оно.

Шаблон простого отчета в Markdown:

Инцидент #42: Падение API
Дата: 17.03.2026
Что случилось: Ошибка 502 на фронтенде в течение 15 минут.
Причина: Утечка памяти в новом контейнере, OOM Killer прибил процесс.
Как исправили: Увеличили лимиты RAM, откатили версию образа.
Что сделать, чтобы не повторилось: Настроить алерт на потребление 80% RAM контейнером.

Админ, который пишет такие отчеты, автоматически переходит в категорию инженеров, которым доверяют ключи от самого дорогого продакшена.

#skills #management #postmortem #reliability #career

🧠 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