Обрыв каналов связи, багованный релиз, мискоммуникация… Серия загадочных событий, авантюрный детектив из цикла «Следствие вели…» — нет, не с Леонидом Каневским, и даже не Колобки — а команда разбора инцидентов Ozon, или просто Post.
Хей-хей! Я Юля, специалист по сопровождению инцидентов в команде Post департамента SRE (Site Reliability Engineering). Когда я рассказываю своим друзьям, чем я занимаюсь, мне часто говорят, что я работаю в детективном агентстве.
Поэтому сегодня поговорим о том, как устроено управление инцидентами и проблемами в Ozon и чем оно схоже с работой детективов. Статья-расследование будет интересна всем, кто хоть раз задумывался о том, как большие компании не только справляются с форс-мажорами, но и учатся на своих ошибках. Расскажу о внутренней кухне и почему инцидент- и проблем-менеджмент не «бюрократия», а палочка-выручалочка на пути к стабильности.
Эпизод первый. Кажется, у нас проблемы
Глубоким вечером раздался звонок. «Это инцидент. Снизился уровень заказов на сайте Ozon…» — прозвучал в трубке загадочный голос незнакомца. Вечер переставал быть томным.
? Сначала давайте договоримся о том, что вообще считать инцидентом. Согласно ITIL 4 (Information Technology Infrastructure Library), инцидент — это любое незапланированное событие вне стандартных операций сервиса, из‑за которого прерывается обслуживание или снижается его качество.
Есть несколько способов выявления инцидентов:
автоматические алерты
мониторинг метрик дежурными
обращения пользователей
Самый надёжный источник информации — алерт, автоматическое оповещение о нештатном событии: отклонении метрики от нормы, сбое расчёта, накоплении лага и т. д.
Команды стремятся увеличить процент покрытия разных событий алертами, но есть кейсы, для которых настроить алерт — слишком сложно и затратно с точки зрения ресурсов разработки. Тогда о проблемах приходится узнавать в процессе мониторинга метрик дежурными, от бизнеса или от непосредственных пользователей продукта: покупателей, продавцов, курьеров, сотрудников склада и других.
Со всеми болями и бедами сотрудники Ozon обращаются в специальные каналы корпоративного мессенджера, которые мониторит команда 911 FireFighters (далее — 911).
При обнаружении проблемы дежурные:
Вникают в суть сбоя.
Фиксируют его влияние на репутационные, регуляторные и финансовые потери компании.
Определяют приоритет инцидента.
Инициируют оповещение команд, ответственных за деградирующий сервис, продукт или процесс, при наиболее критичных инцидентах.
? Немного деталей
Мы выделили несколько уровней приоритета инцидентов в зависимости от их влияния.
Наиболее критичные инциденты связаны со сбоем и полной недоступностью или со значительной деградацией услуги, сервиса или элемента инфраструктуры. Они оказывают негативное влияние на покупателей, продавцов и сотрудников Ozon. Несвоевременное устранение таких проблем может повлечь финансовые потери, нарушение законодательства или удар по репутации компании.
Для устранения всех технических сбоев в Ozon существует единый рабочий флоу для управления инцидентами и проблемами, несмотря на то, что предметная область весьма разнообразна:
И многое другое. Каждое направление устанавливает свои критерии приоритизации инцидентов, учитывая особенности внутренних процессов.
Эпизод второй. Без паники: управление инцидентами
Страшно, очень страшно. Мы не знаем, что это такое, если бы мы знали…
Инцидент поднят, эскалации прошли, все необходимые команды собрались на звонке. Но что делать дальше?
Снизился уровень заказов — команды начинают проверку:
— Какой сервис деградирует?
— Откуда идут ошибки?
— Были ли релизы? Да? Все откатить!
— Нет? Тоже откатить. На всякий случай.
Шутка. Но не всегда удаётся быстро найти корень проблемы, поэтому ответственные команды используют комплексный подход. В дело идут:
логи
трейсы
графики и другие инструменты мониторинга
запросы к базам данных
общение со свидетелями и пострадавшими, например с сотрудниками даркстора, у которых зависает складское оборудование, или с курьерами, у которых не работает приложение для доставки
любые, даже самые смелые, идеи об источнике проблемы и способах её решения
Среди участников разбора инцидентов выделяются следующие роли:
Координатор
Исполнители
Дежурный 911
Вольные слушатели
Устранение любого инцидента, за исключением инцидентов в сфере информационной безопасности, связанных с конфиденциальными данными, проходит в формате открытого звонка. К нему могут подключиться все заинтересованные лица.
Главная цель инцидент-менеджмента — как можно быстрее решить проблему самым простым и безболезненным способом.
После купирования сбоя и устранения его влияния необходимо удостовериться, что проблема не повторится и инцидент не будет иметь отложенный эффект. Обязательно дожидаемся положительной обратной связи от затронутых пользователей. Только после этого закрываем инцидент и расходимcя со звонка с чистой совестью. При сохранении некритичного влияния устранение проблемы можно продолжить в рабочее время после закрытия инцидента.
Также отмечу, что критичные инциденты — это не обязательно продовое окружение. В случае нестабильной работы тестовой среды блокируется работа QA-инженеров и разработчиков, что может привести к остановке деплоев в продакшене, а это уже не шутки. Поэтому для тестового контура у нас также предусмотрены критерии заведения инцидентов.
Эпизод третий. Разбор полётов: управление проблемами
Следствие вышло само на себя. Причиной снижения уровня заказов стало окончание распродажи. Вчера гречку продавали за 29 рублей, сегодня всё продали, акцию выключили — уровень заказов вернулся в норму. Снижение было, но, как оказалось, ожидаемое, все системы работали штатно, сбоев не было. Happy end!
Но это скорее исключение из правил. Чаще по всем случившимся критичным инцидентам необходимо проводить разбор полётов и работу над ошибками. Здесь на сцену выходит Postmortem. В IT так называется процесс разбора и последующего анализа случившихся сбоев. По инцидентам с самым высоким приоритетом критичности создаётся пост, главная цель которого — не наступить в будущем на те же грабли. Пост — это артефакт случившегося инцидента: поиск решения, а не виновных.
? На инциденте мы купируем проблему, в посте — ищем системное решение.
Пост создаёт и сопровождает команда Post, разбор проблемы проводят команды разработки, ответственные за сбоивший сервис. Для работы с постами мы используем тикеты и борды в таск-трекере. Также у нас есть специально разработанный портал — внутренняя система Ozon с необходимыми инструментами и аналитикой для инцидент- и проблем-менеджмента.
Процесс создания и ведения поста строго регламентирован: разбираем инциденты, согласно шаблону, стараемся придерживаться унифицированной формы.
В посте обязательно фиксируем следующие ключевые моменты:
Ход развития инцидента и хронологию основных событий. Для полноты картины мы также добавляем в пост таймлайн с саммари треда инцидента, созданный с помощью ML-суммаризации.
Сервис, в котором произошёл сбой.
Затронутые команды разработки.
Оценку влияния: время начала и окончания, какие процессы были нарушены, как это повлияло на бизнес, есть ли финансовые потери.
Корневую причину сбоя.
Превентивные меры для предотвращения проблемы в будущем.
Сроки выполнения необходимых работ.
Также фиксируем изменение статуса поста на всём жизненном цикле: поиск причины —> поиск решения —> разработка решения —> тестовый период —> пост закрыт.
Важный момент: пост должен быть понятен неподготовленному читателю. Разработчик из соседней команды, представитель бизнеса или руководства — любой человек, который не присутствовал на инциденте, должен иметь возможность прочитать пост и погрузиться в проблему. Для этого мы создаем в посте два саммари:
Общее краткое описание от владельцев процесса Postmortem. В нём стараемся описать инцидент доступным языком, избегаем профессионального сленга, расшифровываем аббревиатуры, соблюдаем стайлгайд и tone of voice Ozon, следуем регламенту команды Post.
Техническое описание от команды разработки — владельцев сбоившего сервиса. Здесь погружаемся в технические особенности проблемы, дополняем текстовое описание схемами и графиками.
? Единый стандартизированный подход к ведению постов повышает прозрачность, а следовательно, ценность и качество всего Postmortem.
Самое важное в Postmortem — докопаться до сути, вычленить корневую причину проблемы. Для этого мы используем технику пяти «почему».
? Разберём на примере:
— Остановилась выдача маршрутных листов курьерам. Почему?
— Сервис, отвечающий за формирование маршрутных листов, не мог вычитать необходимые события из Kafka. Почему?
— У сервиса был выкачен новый релиз, после чего чтение событий остановилось. Почему?
— Выяснили, что в релизе был баг, который не заметили на этапе тестирования. Почему?
— QA проводили в тестовом окружении, где сложно воспроизвести продовую нагрузку.
Найти корневую причину проблемы также помогают «вещдоки»: сохранённые логи и трейсы, графики, выгрузки из баз данных и многое другое, что осталось от инцидента. Все важные артефакты, ссылки на задачи, резолюции и т. д. сохраняем в пост — для аналитики, а также на случай повтора инцидента.
Если об инциденте узнали от сотрудников или внешних пользователей, отдельное внимание в списке превентивных мер необходимо уделить настройке алертов. Они помогут узнавать о сбоях незамедлительно, предупреждая их влияние на конечного пользователя.
Эпизод четвёртый. Систематизируем и анализируем
Когда все загадки разгаданы, а дела подшиты в папочки, наступает время анализа. Для удобства мы используем собственный внутренний сервис — портал, на котором в виде дашбордов представлена вся необходимая информация, касающаяся инцидент- и проблем-менеджмента. Каждый блок Ozon еженедельно проводит внутренние встречи для обсуждения и контроля разбора инцидентов.
На временном интервале в неделю, месяц, год оцениваем количество инцидентов и постов, причины их возникновения, направления, в которых происходили сбои, и многое другое.
Отдельно анализируем процесс обнаружения проблемы: как быстро узнали о сбое, оперативно ли отреагировали и приняли необходимые меры.
Особое внимание уделяем анализу влияния инцидентов: количеству упущенных заказов, аннулированных и просроченных отправлений, финансовым издержкам и компенсациям.
Также раз в квартал мы проводим открытую встречу внутри компании под названием «Инциденты для всех»: разбираем самые яркие и интересные инциденты за последнее время, обсуждаем вопросы и предложения, обмениваемся опытом и впечатлениями.
Для быстрого погружения в культуру инцидент- и проблем-менеджмента все новые сотрудники в рамках онбординга проходят обязательный курс по дежурствам и разрешению инцидентов.
Эпизод пятый. Подводим итоги
Итак, давайте обобщим и подытожим. Рабочий флоу управления проблемами и инцидентами в Ozon выглядит так:
Как уже было сказано, управление инцидентами объединяет множество специалистов из разных команд. Пройдёмся по главным действующим лицам нашего детектива. Участники рабочего флоу инцидент- и проблем-менеджмента:
Команды разработки сервисов.
Отдел сопровождения инцидентов: команды 911 и Post. Отвечает за управление инцидентами с технической стороны: фиксирует и приоритизирует инцидент, призывает ответственные команды для решения проблем, обеспечивает прозрачность процесса, ведёт процесс Postmortem. Погружён в проблему с технической точки зрения, работает в связке с командами разработки.
Отдел управления инцидентами со стороны клиентского опыта. Контролирует операционную часть сбоя: минимизирует влияние инцидента на клиентов, продавцов и бизнес в целом. В случае форс-мажора специалисты отдела могут менять способы и сроки доставки, аннулировать отправления, контролировать капаситеты сортировочных центров и информировать бизнес и кол-центры о проблеме.
Postmortem вместо послесловия
Каждый день выходит большое количество релизов, улучшаются старые процессы, рождаются новые проекты. Всё это неминуемо сопровождается нештатными ситуациями. Внимательное отношение к инцидент- и проблем-менеджменту позволяет не повторять ошибок прошлого: проще и выгоднее вложиться в качественный разбор случившихся сбоев и принять необходимые превентивные меры, чем решать одни и те же проблемы снова и снова. Грамотно выстроенный процесс управления инцидентами помогает эффективно использовать человеческие ресурсы и повышает прозрачность работы IT-блока для бизнеса.
Инциденты бывают разные: масштабные и локальные, с критичным влиянием или с потенциальными рисками. Но их объединяет одно — любой может повториться, если не уделить должное внимание Postmortem. Помимо мер, направленных на предотвращение проблемы, необходимо также смотреть в сторону оптимизации работы во время устранения инцидента. Можно ли было узнать о сбое раньше? А уменьшить время реагирования и локализации проблемы? Насколько слаженно работали команды? Что можно улучшить?
В нашей истории обыкновенная гречка сыграла роковую роль, собрав несколько команд разработки на звонок. А ведь этого можно было избежать при лучшей проработке коммуникации между командами и своевременных анонсах о выключении акций. При разборе поста это обязательно учтут, ведь не за горами распродажа сахара. Но это уже совсем другая история…