Forwarded from Admin Future
🧠 Skills: On-call без выгорания — как построить дежурство, которое не съедает людей
Коллеги, давайте честно: у большинства из нас on-call — это "телефон всегда при тебе, и молись чтобы не позвонили". Никакого графика, никакой ротации, один человек тащит всё потому что "он лучше всех знает как это работает". Богдан снова не спал в эту пятницу.
Это не героизм. Это провал организации процесса.
Google SRE Workbook рекомендует максимум 2–3 actionable-инцидента за смену как устойчивую норму. Если у вашей команды стабильно 8–10 — у вас не проблема дежурства, у вас проблема с алертами. Сначала чиним шум, потом думаем о ротации.
Три кита нормального on-call:
Первое — ротация и границы. Идеально: не чаще одной недели дежурства раз в 6–8 недель. Всё чаще — ведёт к усталости. Всегда должны быть: primary (отвечает первым), secondary (бэкап если primary недоступен) и escalation path к руководителю — не для технических решений, а для принятия бизнес-решений.
Второе — алерты, которые требуют действия. Каждый алерт должен отвечать на один вопрос: "нужно ли действие прямо сейчас?" Усталость от алертов возникает из плохого соотношения сигнал/шум.
Аудит алертов раз в квартал — три категории:
Третье — blameless postmortem, который реально работает. Команды с blameless postmortem в 2.3 раза чаще имеют высокопроизводительные системы. Разница проста: blameless-культура фокусируется на обучении, blame-культура — на наказании. Когда инженеры боятся признавать ошибки, они скрывают проблемы, и мелкие инциденты разрастаются в крупные.
Шаблон постмортема за 30 минут:
Зачем это нужно:
Организации, которые делают это правильно, имеют не только меньше случаев выгорания — у них быстрее время реакции, лучше follow-through по постмортемам и on-call программы, которым инженеры доверяют, а не которых боятся.
Итог: On-call — это контракт между компанией и инженером. Компания получает надёжность 24/7. Инженер получает справедливую ротацию, понятные правила и восстановление после смены. Если одна из сторон не выполняет свою часть — это не дежурство. Это эксплуатация.
#skills #oncall #incident #postmortem #sysadmin #sre #admin_future
Коллеги, давайте честно: у большинства из нас 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
Forwarded from Admin Future
🧠 Skills: On-call без выгорания — как построить дежурство, которое не съедает людей
Коллеги, давайте честно: у большинства из нас on-call — это "телефон всегда при тебе, и молись чтобы не позвонили". Никакого графика, никакой ротации, один человек тащит всё потому что "он лучше всех знает как это работает". Богдан снова не спал в эту пятницу.
Это не героизм. Это провал организации процесса.
Google SRE Workbook рекомендует максимум 2–3 actionable-инцидента за смену как устойчивую норму. Если у вашей команды стабильно 8–10 — у вас не проблема дежурства, у вас проблема с алертами. Сначала чиним шум, потом думаем о ротации.
Три кита нормального on-call:
Первое — ротация и границы. Идеально: не чаще одной недели дежурства раз в 6–8 недель. Всё чаще — ведёт к усталости. Всегда должны быть: primary (отвечает первым), secondary (бэкап если primary недоступен) и escalation path к руководителю — не для технических решений, а для принятия бизнес-решений.
Второе — алерты, которые требуют действия. Каждый алерт должен отвечать на один вопрос: "нужно ли действие прямо сейчас?" Усталость от алертов возникает из плохого соотношения сигнал/шум.
Аудит алертов раз в квартал — три категории:
Третье — blameless postmortem, который реально работает. Команды с blameless postmortem в 2.3 раза чаще имеют высокопроизводительные системы. Разница проста: blameless-культура фокусируется на обучении, blame-культура — на наказании. Когда инженеры боятся признавать ошибки, они скрывают проблемы, и мелкие инциденты разрастаются в крупные.
Шаблон постмортема за 30 минут:
Зачем это нужно:
Организации, которые делают это правильно, имеют не только меньше случаев выгорания — у них быстрее время реакции, лучше follow-through по постмортемам и on-call программы, которым инженеры доверяют, а не которых боятся.
Итог: On-call — это контракт между компанией и инженером. Компания получает надёжность 24/7. Инженер получает справедливую ротацию, понятные правила и восстановление после смены. Если одна из сторон не выполняет свою часть — это не дежурство. Это эксплуатация.
#skills #oncall #incident #postmortem #sysadmin #sre #admin_future
Коллеги, давайте честно: у большинства из нас 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