Сложно недооценить роль того, как вообще построен процесс работы с инцидентами в компании. Если его нет, то дальше можно не читать 🌚
Здесь можно вдохновиться блогом Atlassian или опытом Skyeng и начать делать первые шаги в его построении. А для счастливчиков вроде меня продолжаем.
Перед инцидентом
1️⃣ Выясните SLA вашего сервиса: какой у него Tier (как повлияет на операции бизнеса его сбой), требования по доступности сервиса (сколько ему разрешено лежать), задержке (англ. latency).
Также важно знать таймауты ваших клиентов, чтобы понимать, в какой момент клиент уже дропает запросы не дожидаясь ответа от вас.
2️⃣ Узнайте, с какими сервисами интегрируется ваш и его зависимости:
- откуда сервис считывает данные (и кто их туда кладет 🙃), задержка обработки данных сервисом и как проверить, что новые обновления обработались.
- дергает ли он другие сервисы и какой результат возвращает пользователю, если те отвечают ошибками.
- кто дергает ваш сервис и какие ожидает ответы, и важно ⚠️ что клиенты делают в случае возврата ошибки.
Одно из заблуждений, с которым мы столкнулись - если у клиента есть fallback ("план Б", альтернативные значения чтобы вернуть пользователю), то все ок, можно не париться. А потом оказалось, что fallback не покрывает premium подписки и у нас 1000 жалоб менее чем за полчаса 😅
3️⃣ Как вы измеряете ущерб: это могут быть потерянные заказы, как у нас в доставке, жалобы от пользователей, или другие метрики специфичные для бизнеса.
Узнайте, по каким графикам вы можете оценить ущерб в real-time, или кого из операционной команды нужно подключить за этой инфой.
4️⃣ Как вы узнаете о проблеме, как с вами свяжутся? Обычно alert-ы генерируются либо автоматически (мониторинг обнаружил аномалию, например, latency летит в небеса), либо создаются вручную тех.поддержкой / операционной командой.
Каналы связи тех и других могут отличаться, но вот при ночном режиме на телефоне уже ничто не поможет. Не будьте мной, отключайте 🌝
5️⃣ Правила эскалации - кому, куда, как. Мы в Delivery Hero придерживаемся принципа, что лучше перебдеть и "позвать всех", чем пропустить бóльшую проблему. Отдельно узнайте, как связаться с инфраструктурной командой и security.
Любые вопросы по security обычно срочные и запускают отдельный процесс.
5️⃣+1️⃣ Откопайте любые мануалы и runbook-и по вашему приложению, где будет описано что делать в случае разных проблем.
В моей команде правило - под любой автоматический alert должна быть запись в runbook-e.
5️⃣+2️⃣ Проверьте доступы, об этом я уже писала здесь.
О том, как ловить то, что падает и действовать во время инцидента напишу в продолжении 😕
А у вас в компании выстроен процесс работы с инцидентами? Какие недостатки/сложности вы в нем видите?