Мои разборы различных статей по инцидент-менеджменту, с моими комментариями или пояснениями. Тут будет довольно вольное их изложение. Я останавливаюсь только на тех моментах, которые кажаться мне важными или интерсными.
Рекомендации от команды PagerDuty по работе с инцидентами
Прежде чем бросаться делать инцидент-менеджмент, прежде всего нужно определитьс с тем, что является инцидентом. Это должна быть простая и понятная штука, с которой согласятся все участиники других команд.
Хороший пример:
- Мы считаем что инцидент - это когда кол-во ошибок больше 100/10%/т.д.
- Мы считаем что инцидент - это когда вот этот конкретный отчет/расчет/заргузка не завершилась до такого-то часа следующего дня/за столько-то часов.
- Мы считаем что инцидент - это когда не мы первые заметили проблему, а пользователь.
Не только автоматические метрики/алерты должны запускать процесс создания инцидента, но и просто обращения других людией (коллег, пользователей).
Лучше завести отдельный канал в мессенджере, в котором отделить вопросы по сервису от обращиний с проблемами/жалоб на работу сервиса. Так будет проще в дальнейшем контролировать процесс инцидент-менеджмента и приучить коллег следить за этим каналом более пристально.
Можно завести бота в вашем корпоративном мессенджере, и дать возможность всем сотрудникам сообщать о инциденте (даже если это не инциденте, но они в этом не уверены). Но очень важно что бы они получали обратную связть что их сообщение зарегистрировано и дежурный по инцидентам приступил к работе.
Для начала достаточно роли "Incident Commander" для больших обширных инцидентов.
Задача IC - координировать инцидент, принимать ключевые решения, помогать с коммуникацией, заводить и развешивать задачки. Это может быть выделенная роли или даже выделенный человек на запрлате с отдельной ставкой (в зависимости от размера компании). Если это отдельная роль - надо подумать как ее горизонтально масштабировать. Можно
От себя добавлю что часто это сложнореализуемо. Часто эта роль достается дежурному или проджект-менеджеру. Но чаще всего IC - это просто дежурный, в смену которого происходит инцидент. Обычно этого достаточно если процесс реагирования на инцидент достаточно прозрачен и отлажен.
Сложнее всего инженерам дается написание бюрократических штук или придумывания названий переменных. Так и с посмотртемом. Если не будет четкой понятной структуры как его писать - никто точно не будет его писать.
Обычно такой шаблон включает в себя таймлайн инцидента, описание инцидента, причины инцидента, если есть финансовые потери - описание их, и метода их расчета, а также размышление или готовые действия по предотвращению такого инцидента в будущем (ссылки на задачи (action-items, AI))
Шаблон постмортема от PagerDuty
Нужно проводить учения хотя бы каждый раз, когда у вас в команду приходит новый коллега, который прошел испытательный срок и готов начинать полноценно поддерживать работоспособность вашей инфраструктуры или сервиса
На алерты, особенно когда дежурный не один, надо ставить Acknowladge. Проснулся, поставил ack, пошел разбираться или эскалировать (или за кофе на кухню). В идеале таких ночных алертов не должно быть вообще. В противном случае необходимо заводить сразу задачу/инцидент. Это не должна быть рутинная задачу вроде чистки места на диске или ребута сервиса. Если это рутинная задача - сделай задачу на автоматизацию этого дествия что бы не приходилось просыпаться ночью или отрываться от более важной работы. На дежурстве твоя задача - актуализировать документацию. Было сложно, не мог долго понять что как где искать - обнови документацию! Сделайте процедуру передачи дежурства. Например на дейлике каждый понедельник заканчивает смену один дежурный, передает все текущие проблемы, и смену начинает другой дежурный, погруженный первым в контекст. Не стесняйся коммуницировать, просить помощи коллег и соседние команды. Никто не знает всего сразу. Дежурить должны все члены команды, особенно тимлиды. Иначе потом для них может быть очень много сюрпризов. Новых членов команды хорошо обучать и погружать в ваш бардак через дежурства вторым номером. Пусть новичек смотрит за алертами, задает "глупые" вопросы, смотрит что делаете вы. Не стоит бросаться сразу чинить алерт. Подождите 5 минут, возможно виновник быстрее среагирует и заберет его.
Алерт - это то, что требует действия человека. И не нужно присылать ночью алерт, если он терпит до утра - сделайте так, что бы он приходил только после ночи.
High - требует НЕМЕДЛЕННОГО действия от человека
Пример: "Production service is failing for 75% of requests, automation is unable to resolve."
Medium - требует действия человека в течении 24 часов
Пример: "Production server disk space is filling, expected to be full in 48 hours. Log rotation is insufficient to resolve."
Low - требует действия человека в рамках задачи, не срочно
Пример: "An SSL certificate is due to expire in one week."
Notification - просто информация, не требует действия человека
Пример: "A deployment was successful."
Тестируйте алерты, чтобы убедиться, что они работают правильно.
Тестируйте пороги. После создания алерта попробуйте поставить ему маленький порог и проверить.
Тестируйте "No Data" состояни. Должен он при этом переходить в ERROR или OK?
Тестируйте переход алерта в нормальное состояние.
От себя добавлю что удоюно все новые алерты помещать в отдельный тестовый канал в slack/mattermost. И переносить "в прод" через какое-то время что бы убедиться что отловили все flacky-состояния
Caution
Если вы не уверены какой выжности инфидент - выбирайтее более приоритетный уровень.
Наиболее критичные:
-
SEV-1: Критические проблемы. Нарушение SLA, утечка пользовательских данных, затронуто большое кол-во пользователей. Сообщаем топам, создаем инцидент, сообщаем публично
-
SEV-2: Критические системные проблемы. Деградация сервиса, затронута часть пользователей, и т.д. Создаем инцидент.
Менее критичные:
-
SEV-3: Что-то, что может перерости в более серьезную проблему, частичная потеря функциональности, потеря высокой доступности. Создаем инцидент если считаем нужным. Обрабатываем с высочайшим приоритетом, эскалируем другим командам как можно быстрее, откатываем релизы если они были причиной.
-
SEV-4: Минорные проблемы, не затрагивающие пользовательский функционал. Обрабатываем с высоким приоритетом, следим за состоянием системы
-
SEV-5: косметические баги и проблемы. Создаем задачу в трекере, вешаем на ответственного.
-
IC (Incident Commander): единая точка входа и правды о том, что происходит и в каком состоянии инцидент. Настраивает каналы коммуникации, находит и добавляет нужных людей, обучает других IC и коллег, подготавливает к другим инцидентам. Коммандер делигирует кому что делать во время/после инцидента и доводит инцидент до его закрытия. После закрытия создает шаблон постмортема как можно быстрее, что бы участники инцидента могли по горячим следам написать свои соображения.
-
Deputy (Заместитель): Помогает коммандеру. Документирует, ведет бюрократию в ходе инцидента, пока коммандер занят коммуникацией. Подменяет коммандера. Модерирует созвоны в ходе инцидента.
-
Scribe (летописец): Документирует timeline, записывает всю необходимую информацию пока остальные заняты коммуникацией.
-
Subject Matter Expert (SME - эксперт по предметной области): эксперт в нужной системе/домене, который занимается диагностикой и устранением инцидента.
-
Customer Liaison (контактирующие с клиентом): отвечает за публичную коммуникацию наружу, контактирует с клиентами.
-
Internal Liaison (внутренная коммуникация): ищет дежурных в других командах, отвечает внутренним клиентам компании и общается с другими отделами.
- пишите в мессенжер (канал инцидента в Slack/Mattermost), а не чат созвона. Так проще потом искать историю.
- найдите спокойное тихое место что бы своим фоновым шумом не раздражать других и мьютте микрофон когда не говорите
- представьтесь
- кратко и четко объясните, что происходит и что вы хотите
- уважайте других и чужое время
Помните что не все могут знать сокращения и аббревиатуры, который вы используете. Старайтесь говорить как можно понятнее для других.
Следйте инструкциям коммандера. Не делайте ничего, пока вас об этом не попросят и вы эти действия не согласуете. Если у вас есть сомнения о каких-то действиях - скажите об этом. Если не уверены в чем-то или не знаете - так и скажите "Я не знаю". Это намного лучше чем ввеси других в заблуждение. Если вас попросили что-то сделать, постарайтесь сделать этот вовремя. Иначе постарайтесь соорентировать других сколько это займет времени.
Если инцидент очень большой и задействовано очень много команд, то разделйте людей, задействованных в поиске и решении проблемы, на подкоманды. Назначайте лидеров этих комманд и ведите коммуникации с ними.
https://response.pagerduty.com/during/during_an_incident/
Обширная теме, ключевое тут: mitigation (смягчение последствий). Сначала тушим пожар и останавливаем кровотечение, потом уже наводим красоту и думаем как сделать теперь нашу систему лучше. Стараемся записывать что делаем, можно в чат копировать команды, которые вы делаете.
Не забывайте обновлять статус инцидента для внутренних пользователей.
https://response.pagerduty.com/during/external_communication_guidelines/
https://response.pagerduty.com/during/security_incident_response/
- IC (инцидент коммандер):
- обновляет инцидент (на спец. портале, wiki, jira - где вы его там заводите?), группирует инцидент с другими инцидентами, финализирует критичность (severity) ицидента, закрывает инцидент в случае если у вас инцидент и его постмортем - разные вещи.
- создает постмортем и назначаем ему ответсвенного/владельца
- отправляет всем нужным людям внутри компании информацию о инциденте и ссылку на постмортем
- переодически проверяет статус постмортема что бы убедится что по нему происходят какие-то движения
- Deputy (заместитель IC): нет особых действий, может помочь IC
- Scribe (летописец): еще раз проверяет историю чата, выносит оттуда ключевую информацию, собирает в посмотрем все обсуждения TODO
- Subject Matter Expert (SME - эксперт по предметной области): пишет в посмортем свои мысли и идеи по проблеме
- Customer Liaison (контактирующие с клиентом): отвечсет на вопросы внешних клиента о проблеме и обновляет статус посмотрема во внешних коммуникациях
- Internal Liaison (внутренная коммуникация): то же, что Customer Liaison, толко для внутренних клиентов/сотрудников
Для все SEV-1/2 инцидентов создаются постмортемы. Безобвинительные, детально описанные, с подробностями, обсуждением превентивных шагов, затрагиваем самого процесса реагирования на инцидент.
Первым делом IC назнавает владельца постмортема после окончания инцидента. Владелец обязан наполнить постмортем деталями, логами, графиками, обозначить в нем все интересные и спорные моменты
- Запланировать разбор постмотрема, пригласить всех релевантных и заинтересованных людей (в течении 3-х календарных дней для SEV-1 и 5 рабочих дней для SEV-2)
- Разобраться кто из других команд нужен для разбора
- Актуализировать страницу постмортема и сделать ее ревью до разбора
- Завезти нужные задачи в трекере/JIRA
- Вести разбор по темам постмортема
- Вести внутреннюю коммуникаци по постмортему
- Draft (черновик): содержание постмортема еще в работе
- In Reviewed: содержание постмортема актуализировано и он готов к разбору на встрече
- Reviewed: встреча по разбору завершена и содержимое постмортема согласовано
- Closed: все действия по постмортему (кроме JIRA-задач) завершены
Ваши действия если вы владелец постмортема:
- Завести новый постмортем по инциденту (если IC это еще не сделал)
- Запланировать разбор постмотрема, пригласить всех релевантных и заинтересованных людей (в течении 3-х календарных дней для SEV-1 и 5 рабочих дней для SEV-2)
- Завести встречу в отдельном календаре постмортемов
- Актуализировать страницу постмортема
- Timeline (последовательность действий): должен вклчать все ключевые действия и изминения, и их результат.
- Просмотреть историю в мессенджере, определить всех действующих лиц, добавить их в информацию
- Добавить детали
- Для каждого шага в timeline'е постараться добавить ссылки на графики, метрики, описание, коммиты и т.д.
- Добавить ссылку на голосовую запись, созданную в ходе разрешения инцидента
- Произвести анализ инцидента
- Собрать всю информацию: что и почему стало причиной, какие, как и сколько пользователей задето, кто какие команды запускал
- Написать сообщение, которое будет отправлено внешним пользователям по итогам постмортема, что бы утвердить его. Стараемся сгладить, вместо слов "outage" можно использовать "incident" или "service degradation". Можно подсмотреть такие сообщения в старых постмортемах.
- Минимум за 24 часа до разбора отправить ссылку на постмортем коллегам для того, что бы они поревьювили и дали советы. Что бы можно было поправить эти детали до разбора и не тратить на нем время.
- Прийти на разбор и провести его
- Завести задачи в треккере/JIRA
- пройтись по треду в мессенджере и найти все TODO
- навесить лейблы важности и тегировать задачи в трекере
- завести задачи на AI, которые направлены на предотвращение такого инцидента в будущем
- найти все экшены, который могли бы улучшить процесс реагирование на инциденты
- но не стоит увлекаться и создавать очень много задач
- рассказать коллегам о том, что мы выучили и узнали в ходе этого инцидента
Должен занимать 15-30 минут и направлен на подведение итогов постмортема. На нем можно обсудить что случолось, что можно улучшить и что мы собираемся делать в дальнейшем. Его основная цель состоит в том, что бы выяснить и обсудить разногласия по фактам, анализу, рекомендуемым действиям, а также получить более широкое представление о проблемах, которые вызывают у нас проблемы с надежностью.
Кого звать:
- Всегда
- IC
- Владельца, продакт-менеджера и техлидов сервиса, с которым была проблема
- Ключевых инжинеров, который были вовлечены в процесс починки
- Иногда
- Ответсвенного за взаимодействие с клиентом (для наиболее критичных инцидентов)
IC начинает митинг и следит за таймингом. Владелец постмортема рассказывает детали постмортема. Проходимся по постмортему, резюмируем таймлайн, основные моменты, сранные детали. Обсуждаем как проблема могла бы быть поймана заранее (канареечные деплои, тесты, dev-env) Обсуждаем влияние на клиентов и заказчиков. Обсуждаем action-items.
https://response.pagerduty.com/after/post_mortem_template/
https://response.pagerduty.com/after/effective_post_mortems/