Вступление: почему ваши «маленькие» инциденты совсем не маленькие

В большинстве компаний по‑настоящему разбирают только большие, громкие инциденты — те, что рвут SLA, бьют по выручке или поднимают по тревоге руководство. Но настоящая история вашей надежности спрятана в мелочах: в пяти‑минутном глюке API, некорректно настроенном feature flag, частичной деградации в одном регионе.

По отдельности это выглядит как мелочь. Вместе — это золотое дно.

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

• скрытые зависимости
• хрупкие стыки между командами
• коммуникационные разрывы
• слепые зоны в инструментах

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

Вам не нужна новая платформа. Вам нужен карандаш, простой шаблон и привычка превращать каждый инцидент в карту, из которой можно извлечь уроки.

1. Начните с картирования максимально маленького инцидента

Не ждите большого апокалипсиса. Начните со следующего же небольшого сбоя:

• шумный алерт, который в итоге оказался ложным;
• всплеск 502, который самоустранился;
• деплой, который пришлось быстро откатить.

Для каждого такого случая нарисуйте карту «до–во время–после»:

1. До – Каков был контекст системы и организации?

   • Какие сервисы были задействованы?
   • Кто был на онколле?
   • Какие были зависимости (внутренние и внешние)?

2. Во время – Как двигался инцидент?

   • Где симптомы проявились впервые (логи, метрики, сигнал от пользователя)?
   • Какие алерты сработали? Кто их увидел? В каком инструменте?
   • Какие решения принимались, кем и на основе какой информации?

3. После – Как всё завершилось?

   • Что изменилось (переключение конфигов, откаты, фейловеры)?
   • В какой момент все сочли инцидент «закрытым»?
   • Какие follow‑up’ы были заведены?

Представьте, что вы рисуете схему метро для инцидента: сбой стартует на станции A (например, всплеск метрик), проходит через станции B, C и D (пейджи, Slack, хенд‑оффы, дашборды) и в итоге доезжает до станции Z (разрешение + пост‑инцидентные заметки).

Цель не в художественности, а в структурной ясности.

2. Специально используйте простоту «карандаш и бумага»

Как только для картирования нужен особый софт или идеальная диаграмма, люди перестают это делать.

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

• Только базовые фигуры:

  • прямоугольники = системы/сервисы
  • кружки = люди/роли
  • стрелки = поток информации или работы
  • молнии = точки сбоя / моменты путаницы

• Стандартные, минималистичные подписи:

  • «Сработал алерт»
  • «Онколл подтвердил»
  • «Эскалировано в X»
  • «Ожидали одобрения Y»
  • «Клиент обновлён»

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

Низкая «точность» — это фича, а не баг. Когда схемы быстрые и неформальные, люди:

• фиксируют инциденты, пока всё ещё свежо в памяти;
• меньше переживают, что «должно быть идеально»;
• честнее отражают моменты неуверенности и непонимания.

Единственное требование: если вы участвовали в инциденте, вы должны уметь набросать его маршрут за 10–15 минут.

3. Считайте каждый инцидент «бумажным следом», а не местом преступления

Классические постмортемы часто ощущаются как расследование: кто что сделал, кто что упустил, чья это вина?

В «Нарисованном карандашом атласе отказов» нужна другая оптика: каждый инцидент — это возможность создать богатый бумажный след того, как:

• происходили хенд‑оффы (кто и когда передавал работу);
• принимались решения (что выбрали, от чего отказались);
• выглядел контекст (во что люди верили в тот момент).

Вместо вопроса «Кто это сломал?» задавайте:

• «Куда инцидент пошёл дальше?»
• «Что люди видели на каждом шаге?»
• «Какие, как им казалось, у них были варианты?»

На карте должны быть видны:

• Точки принятия решений – ромбы или заметки там, где делался выбор (например, «Откатывать или подождать?», «Пейджить команду базы данных?»).
• Пробелы в знании – места, где кому‑то не хватало видимости или понимания (например, «Не знали, что сервис A зависит от сервиса B»).
• Пустые круги – повторная работа вроде «Попробовали X, не помогло, откатили, попробовали Y».

Речь не о поиске виноватых, а о восстановлении пути, который инцидент прошёл через вашу социотехническую систему.

4. Комбинируйте количественные сигналы с человеческими историями

Чисто data‑driven таймлайн не показывает, как инциденты разворачиваются в реальности.

Ваш атлас должен объединять:

Количественные данные

• логи
• метрики (латентность, ошибка‑рейты, насыщение ресурсов)
• трейсы
• таймлайны алертов и подтверждений

Качественный ввод

• рассказы онколлов: «Вот что я видел», «Вот почему решил сделать именно так»;
• фрагменты из Slack/Teams, показывающие путаницу или согласованность;
• экспертные комментарии: «Мы заподозрили балансировщик, потому что в прошлом квартале был похожий инцидент».

На вашей карте аннотируйте стрелки и узлы и тем, и другим:

• «14:05 – error rate > 5%» (метрика)
• «Инженер эксплуатации: “Похоже на прошлую проблему с кэшем”» (история)

Это двойное представление мощно, потому что:

• метрики показывают, что случилось и когда;
• истории показывают, почему люди действовали так, как действовали.

Задача атласа — свести эти две перспективы воедино.

5. Стандартизируйте пост‑инцидентную документацию вокруг карты

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

Создайте лёгкий, стандартный шаблон, который всегда включает:

1. Карту

   • Снимок или экспорт вашей нарисованной схемы.

2. Root cause (во множественном числе)

   • Технические факторы (например, дрейф конфига, необработанный edge‑case).
   • Организационные факторы (например, неясный ownership, медленный путь эскалации).

3. Ключевые уроки

   • Что вас удивило?
   • Что стоит обновить в вашем ментальном образе системы?

4. Превентивные / улучшительные действия

   • Краткосрочные фиксы.
   • Долгосрочные вложения.

5. Разбор коммуникаций

   • Кому и что нужно было знать, когда — и произошло ли это.

Простое правило: если человек прочитает только карту + одну страницу заметок, он должен понять, что произошло, чему вы научились и что собираетесь изменить.

Храните всё это в общем, доступном хранилище (Confluence, Notion, Git‑репозиторий и т.п.) и помечайте тегами по системам, командам и темам (например, «alerting», «deploy», «dependencies»).

Со временем это превратится в вашу библиотеку Атласа отказов.

6. Картируйте человеческую сеть: стейкхолдеры и потоки коммуникаций

Технический инцидент — это всегда ещё и коммуникационный инцидент.

На карте инцидента явно покажите:

• Кого информировали – только онколл? тимлидов? саппорт? топ‑менеджмент?
• Как информировали – канал в Slack, email, статус‑страница, incident‑tool.
• Когда информировали – рано, поздно или вообще нет.

Рисуйте стейкхолдеров кружками или группами и используйте стрелки, чтобы показать поток информации:

• Engineering ↔ SRE
• Engineering → Customer Support
• SRE → Status Page
• Engineering → Vendor

Отмечайте сбои:

• пунктирная стрелка — «должны были проинформировать, но не сделали»;
• молния — «непонятное или противоречивое обновление».

Так быстро проявляются паттерны:

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

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

7. Превратите атлас в супер‑инструмент онбординга и обучения

Большинство онбордингов рассказывает, как системы должны работать в идеале.

Ваша библиотека атласа отказов показывает, как они реально ведут себя под нагрузкой.

Используйте её активно:

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

Так проявляются паттерны:

• одна и та же зависимость ломает нас снова и снова;
• одно и то же недопонимание повторяется у разных ролей;
• один и тот же коммуникационный bottleneck возникает в разных инцидентах.

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

8. Как закрепить практику: лёгкий ритуал

Чтобы «Нарисованный карандашом атлас отказов» стал частью культуры, сделайте его маленьким и повторяемым ритуалом:

• Триггер: любой инцидент выше минимального порога (например, любой пейдж, который разбудил человека, или любой пользовательский импакт) получает карту.
• Ответственный: основной респондер делает первый грубый набросок в течение 24 часов.
• Уточнение: на пост‑инцидентном разборе группа проходит по карте и корректирует её.
• Хранилище: финальная карта + короткое описание попадают в общую библиотеку.

Со временем вы:

• обнаружите скрытые зависимости между системами и командами;
• увидите фрикцию в процессах, которой не видно по оргструктуре;
• улучшите и технический дизайн, и человеческую координацию.

И всё это — без покупки ещё одного инструмента.

Заключение: сначала нарисуйте, потом оптимизируйте

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

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

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

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