Comments 8
Инструментами для сбора данных могут послужить: логи системы, алерты, данные мониторинга, скриншоты или сохраненная информация об ошибках.
А так же чат инцидента. Некоторые действия, производимые во время инцидента, как для анализа так и для исправления - ручные. Они не завернуты в скрипты и проверенные ранбуки. Поэтому документировать их в чат - жизненно необходимо (понятное дело что у сообщения "посмотрел логи сервиса А - проблем нет" ценность нулевая, поэтому участники инцидента должны четко понимать что важно а что нет)
Совершенно непонятно что имеется в виду под "приоритет" инцидента (вопрос не к автору поста, а чисто крик души). Что значит "Высокий"? и чем он отличается от "Критический", например? Событие инцидента - это когда, как минимум, одному человеку из команды пришлось бросить всё (сон, жену, детей, еду, работу) и сидеть ковыряться, восстанавливая сервис. В смысле приоритета для него это блокер, причем всегда. Возможно здесь стоит говорить о "серьезности" или "тяжести" (severity) инцидента, которая оценивается исходя из п.1 (степени влияния на пользователей)
Пропуски
Абсолютно бессмысленно оценивать время между событиями. Имеет смысл оценивать время имеющее отношение к реакции, эскалации и длительности всего события инцидента, имхо. Это, по крайней мере, часто показывает насколько хорошо описана система (или сервис) и насколько показательны данные мониторинга (влияет на принятие решения об эскалации или на восстановление сервиса, если диагностика быстро дала понять что исправлять, а описание - как). А то что длительное время может не быть никаких действий - если непонятно что делать то лучше сначала понять, а потом делать (или вообще эскалировать), инженер может укопался в логи чтобы понять что вообще происходит, а от него "действий" ждут
Root Cause
Использовал другой подход. Вообще, изначально при составлении таймлайна к митингу ретро подготавливаем драфт, содержащий события мониторинга, из чата, и т.п. - все что доступно инцидент менеджеру
- Первым этапом ретро митинга собираем "факты": все что имеет отношение к инциденту, но еще не зафиксировано в драфте. Участвует вся команда инцидента - о чем-то умолчали во время инцидента, что-то забыло написаться в чат, а что-то вообще произошло за сутки до с этой областью но может иметь отношение к инциденту. В том числе пишем и хорошее - хвалим команду (ну или команда хвалит себя, учитывая то что все активно участвуют в сборе "фактов". Что интересно, активным участникам ретроспетив это как раз и нравилось)
- Второй этап - сортировка "фактов": проблема или не проблема. Перефразирование и группировка проблем. Сортировка финального списка проблем на "потенциально вызвавших инцидент" и "возникших во время инцидента". Все они так или иначе попадут в бэклог, но у "возникших во время инцидента" приоритет на совести ответственного за область и им root cause analysis на данном митинге не светит
- Третий этап - каждая "потенциально вызвавшая инцидент" проходит Root Cause Analysis(любым методом). Находятся и группируются руткозы. Если их получилось много (проблема не в одной области а в нескольких) - команда митинга голосует за top-3 (опять же, проблемы не выбрасываются, просто им снижается приоритет и они остаются на совести ответственного за область). Составляется экшн план и назначаются ответственные за трекинг каждого действия (именно трекинг, поскольку решение проблемы может занять длительное время и, иногда, требуется отдельный проект). В идеале отчеты об исправлении должны быть на гильдии. В экшен плане всегда должно быть:
Если есть проблемы с анализом во время инцидента, первым пунктом идет доработка мониторинга
Если проблема требует длительного решения - в приоритете предоставить workaround для более быстрого завершения инцидента, если он возникнет еще раз, описать на странице сервиса, ранбуке, обучить команду дежурных
Про приоритет в точку. Грамотная организация дежурств подразумевает, что человек заступая на "вахту" будет готов подключиться и внезапный инцидент не поломает ему личные и семейные планы. Иначе может получится ситуация когда все инциденты решает один человек. Знаю компанию в которой этот самый один человек в какой-то момент просто выключил ночью телефон, так к нему домой приехали в 4 утра на такси и начили стучать в дверь. Адекватной работой с инцидент менеджментом (да и в целом) такое назвать нельзя.
Про оценку времени между событиями. Могу согласиться в том, что это может не быть первым приоритетом, но если время эскалации 5 дней (пять, дней!): в понедельник выстрелило, забили, а в пятницу вечером как мы любим очнулись и назвали критом, то время простоя здесь выходит на первые позиции, потому что ты попробуй в пятницу вечером собери трезвую команду.
время простоя здесь выходит на первые позиции
Здесь вопрос оценки тяжести инцидента -> вопрос опытности (обучения) дежурных.
Обучение или опыт дают возможность определить правильный уровень и необходимость эскалации. Ошибка в оценке тяжести проблемы - одна проблема. А вот оценка выше "критический" и откладывание решения до пятницы - это уже криминал.
Про Root Cause спасибо большое что поделился, если можешь - напиши пожалуйста про размер IT команды в которой этот процесс работал?
продукт был разделен по продуктовым областям - каждая область - это часть функционала. Область могла быть выражена в наборе сервисов или просто часть кода в монолите. Соответственно были команды - каждая ответственна за конкретную область(области) продукта
размер команды ретроспективы инцидента определялся в зависимости от задетых областей продукта
от команды почти всегда присутствовали разработчик участвовавший в инциденте (если была эскалация до девелоперов), и, как правило, тестировщик команды(но не всегда, тогда разработчик формулировал\передавал задачу тестировщику)
я, как ответственный за область SRE
дежурный во время инцидента
а так же все другие заинтересованные
как правило присутствовал самый опытный разработчик той команды, хоть его присутствие не было обязательным, благо эти ребята были, как правило, проактивны и понимали ценность подобных митингов
Иногда присутствовал представитель Support L2 (если был заинтересован)
и QA Lead (тоже опционально)
По проблемам процесса - чем больше собиралась команда ретроспективы ( задело несколько областей - придет больше народа , всплывет больше проблем, обсуждение затянется ) - тем строже приходилось контролировать длительность фаз, иначе не укладывались в запланированное время - самые сложные инциденты разбирали в два захода.
Постмортемы это хорошо. У нас в них участвуют команды поддержки и они приносят свою экспертизу в создании стабильности. Например для инцидента в примере, первая резолюция будет про алерты. Не пользователи должны жаловаться, а выстрелить алерты на 500/долгие ответы и система мониторинга должна сама звонить дежурному.
Руководство по проведению постмортемов. Как правильно разбирать инциденты для улучшения стабильности в будущем