Вступление: День, когда история перестала сходиться

Разбор инцидента был закончен, документ с корневой причиной аккуратно оформлен, шаблон постмортема заполнен. На бумаге всё выглядело нормально — пока кто‑то тихо не произнёс:

«Почему Прия была во всех этих звонках?»

Мы открыли список инцидентов за квартал. Одни и те же имена снова и снова. Одни и те же команды, одни и те же часы ночи. Кто‑то взял маркер, нарисовал на доске горизонтальную шкалу времени и начал отмечать каждый крупный инцидент как «поезд», идущий через дни и недели.

Через несколько минут картина стала очевидна: у нас проблема была не столько с инцидентами, сколько с усталостью от онколла.

В этом посте мы разберём идею «Бумажного ящика с расписанием поездов инцидентов» — намеренно низкотехнологичный способ вручную наносить на схему инциденты, участников и онколл‑смены, чтобы выявить человеческий риск, прежде чем он пустит под откос ваш следующий аутедж. По пути мы свяжем это с:

• человеческими факторами в реагировании на инциденты (стресс, когниция, групповая динамика)
• реакцией «бей или беги» в кризисных условиях
• проектированием гуманных онколл‑ротаций (primary/secondary/shadow)
• визуальными инструментами для обнаружения выгорания и неравенства нагрузки
• ранними признаками перегрузки
• более умным роутингом алертов
• инструментами для инцидентов, ориентированными на коллаборацию и наблюдаемость по умолчанию

Сначала ломаются человеческие системы, потом технические

Эффективность реагирования на инциденты — это не только плейбуки и ранбуки. Она тесно связана с человеческими факторами:

• Стресс‑реакции: повышенный стресс сужает внимание, уменьшает объём рабочей памяти и толкает людей к привычным, а не осознанным действиям.
• Когнитивная нагрузка: постоянное переключение между Slack, дашбордами и тикетами ухудшает мышление и замедляет диагностику.
• Групповая динамика: доминирующие голоса, неясное лидерство и отсутствие психологической безопасности искажают принятие решений.

Под давлением реального аутеджа включается биология. Срабатывает реакция «бей или беги»:

• учащается пульс
• снижаются тонкая моторика и способность к сложным рассуждениям
• люди зацикливаются на одной гипотезе
• коммуникация сворачивается до коротких, иногда резких сообщений

Если одни и те же люди снова и снова оказываются в этих условиях — особенно ночью, — их эффективность и суждения ухудшаются. Это ухудшение само по себе становится риском для надёжности, просто его сложнее отрисовать на графике, чем загрузку CPU.

Вывод прост: нельзя спроектировать устойчивую систему реагирования на инциденты, не спроектировав всё вокруг людей, которые в ней работают.

Почему дизайн онколла — это дизайн инцидентов

Онколл — это не просто табличка со сменами; это механизм распределения риска. Плохо спроектированные ротации создают «скрытые точки отказа» в виде выгоревших экспертов.

Продуманный дизайн обычно включает:

• Primary: активно реагирует на алерты и ведёт технический триаж
• Secondary: подстраховывает primary, берёт на себя часть задач, вмешивается, если primary перегружен или недоступен
• Shadow: учится, наблюдая и иногда помогая; создаёт дополнительную ёмкость в крупных инцидентах

Хорошие онколл‑расписания стремятся сбалансировать:

• Покрытие – есть ли у нас люди в те моменты, когда инциденты происходят чаще всего?
• Справедливость – равномерно ли распределены ночи/выходные и высокосеръёзные инциденты?
• Отдых – гарантировано ли людям реальное восстановление между периодами стресса?

Если хотя бы один из этих трёх элементов «провисает», ваш инцидентный постур уже нарушен — даже если вы ещё не увидели соответствующий режим отказа.

Бумажное расписание поездов: увидеть невидимое

У большинства команд данные об инцидентах спрятаны в инструментах: PagerDuty, Jira, Slack, платформах наблюдаемости. Это делает тренд‑анализ возможным, но и слишком легко игнорируемым.

«Ящик с расписанием поездов историй инцидентов» — это намеренно низкотехнологичное упражнение:

1. Нарисуйте шкалу времени на большом листе бумаги или на доске. Отметьте дни и часы за прошедший период (например, последние 3–6 месяцев).
2. Нанесите каждый значимый инцидент как горизонтальную полосу ("поезд") от времени начала до времени решения.
3. Аннотируйте каждый поезд:
   • серьёзность (цветом или толщиной линии)
   • основной (primary) ответственный
   • secondary и shadow (если были)
   • ключевые хендоверы или эскалации
4. Добавьте онколл‑смены отдельными строками под инцидентами, показывая, кто официально был на primary/secondary в какие окна.

Вы только что создали карту историй ваших аутеджей и ваших людей. Теперь задайте вопросы:

• Чьё имя появляется чаще всего?
• Кто просыпался по алертам много ночей подряд?
• Где инциденты накладывались друг на друга, заставляя людей постоянно переключаться?
• Где фактический primary отличался от формального онколл‑графика, намекая на стихийный героизм?

Чаще всего вы обнаружите:

• одного‑двух «неформальных владельцев», на которых ложится самая болезненная работа
• команды, которые получают все ночные страницы, пока другие имеют инциденты в рабочие часы
• периоды, когда у людей не было реального времени восстановиться между инцидентами

Преимущество бумаги в том, что по ней невозможно «проскроллить мимо». Люди её видят, реагируют и рассказывают истории, которые в одних только инструментах не проявляются.

Как заметить ранние признаки перегрузки

Как только вы начинаете прицельно смотреть, перегрузка инженеров оставляет множество следов.

Поведенческие сигналы

• Резкие, раздражённые ответы на созвонах или в чате
• Избегание сложных задач во время инцидентов («Давайте просто перезагрузим»)
• Растущая неохота брать новые зоны ответственности или участвовать в онколл‑ротации

Операционные сигналы

• Увеличение времени до подтверждения алерта (TTA) у конкретных людей или команд
• Повторяющиеся инциденты с одним и тем же сервисом и теми же респондентами
• Больше «быстрых фиксов» и меньше постоянных ремедиаций

Сигналы в расписании

• Инженеры набирают несколько недель онколла подряд, чтобы «быстрее отмучиться»
• Люди постоянно пытаются отдать свои смены из‑за выгорания или личных обстоятельств
• Одни и те же имена закрывают все форс‑мажорные дыры в покрытии

Вид «расписания поездов» делает эти паттерны очень заметными. Как только вы их видите, можно раньше вмешаться:

• подправить ротации, чтобы распределить высокую серьёзность шире
• добавить shadow‑роли, чтобы вырастить больше респондентов
• предложить временные «каникулы от онколла» после тяжёлых кварталов
• выделить явное время для разборов инцидентов и улучшения процессов

Помните: уставшие респондеры делают ошибки — и эти ошибки могут создавать или удлинять аутеджи.

Доставить правильный сигнал правильному человеку

Никакое онколл‑расписание не спасёт вас от шумной, плохо настроенной системы алертинга. Если людей будят из‑за ложных срабатываний, они начнут:

• игнорировать алерты
• выключать шумные проверки
• пропускать тот единственный алерт, который действительно важен

Эффективный роутинг алертов подразумевает:

1. Многоуровневые алерты и роли

   • Низкая серьёзность, не срочно: уводим в тикеты или каналы для работы в рабочее время
   • Действительно важные, чувствительные к времени проблемы: пейджим primary
   • Пересекающиеся или неясные проблемы: пейджим primary и уведомляем secondary

2. Карту владения сервисами

   • У каждого алерта есть понятный владелец — команда или сервис
   • У каждого сервиса есть явная ротация primary/secondary

3. Снижение шума как приоритет

   • Алерты, основанные на SLO, а не только на низкоуровневых метриках
   • Регулярная чистка алертов, которые редко полезны
   • Плейбуки, в которых явно прописано, когда не нужно пейджить

Цель: правильный сигнал, правильному человеку, в правильное время. Вы защищаете не только сон, но и когнитивный ресурс, который так нужен при инцидентах.

Инструменты для инцидентов: сначала коллаборация, по умолчанию наблюдаемость

Даже с хорошими расписаниями и чистым алертингом важно, как вы координируетесь во время инцидента.

Инструменты должны быть ориентированными на совместную работу и наблюдаемыми по дизайну:

• Понятные роли и зоны ответственности в инцидентном канале (incident commander, communications lead, scribe, технические лиды)
• Общий контекст – дашборды и таймлайны, доступные всем
• Структурированные обновления – сообщения о статусе с отметкой времени, журналы решений и гипотез
• Видимость постфактум – простой реплей: что произошло, кто что делал и когда

Это минимизирует:

• повторяющиеся вопросы («Какой сейчас статус?»)
• противоречивые команды и дублирование работы
• гиперзависимость от одного самого громкого эксперта

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

Сделать расписание поездов привычкой, а не разовой акцией

Ценность бумажного расписания поездов раскрывается, когда оно становится регулярным диагностическим инструментом, а не одноразовым упражнением после особенно тяжёлого квартала.

Подумайте о:

• Квартальных обзорах: перерисовывайте расписание каждые 3 месяца и обсуждайте его на советах по надёжности или SRE‑комитетах.
• Командных ретроспективах: пусть каждая команда аннотирует расписание со своей точки зрения — что было самым тяжёлым, что удивило.
• Сигналах для найма и обучения: если снова и снова одни и те же эксперты несут основную нагрузку, это аргумент в пользу найма и кросс‑обучения.
• Компенсации и признании: используйте эти данные (осторожно), чтобы отметить невидимый toil и скорректировать мотивацию.

Низкотехнологично — не значит примитивно. Это значит намеренно заметно.

Заключение: либо вы проектируете под людей, либо люди перепроектируют всё за вас

Ваши системы создаются людьми, эксплуатируются людьми и чинятся людьми под стрессом. Делать вид, что инциденты — чисто технические события, — это сознательное игнорирование реальности.

Бумажный ящик с расписанием поездов историй инцидентов — простой, но мощный способ:

• превратить разрозненные логи инцидентов в общую историю
• выявить усталость от онколла и неравномерное распределение нагрузки
• поймать ранние сигналы перегрузки
• улучшить расписания, инструменты и роутинг алертов

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

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