Всем привет! Меня зовут Максим Бурцев, и я руководитель отдела мониторинга в Купере. Мы отвечаем за управление инцидентами и проблемами: следим за стабильностью продакшена, сопровождаем и разбираем все технологические инциденты, развиваем и контролируем процессы. В этой статье я поделюсь практикой, которая помогает нам выжимать из Postmortem максимальные результаты и масштабировать Action Items.

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

Проводя Postmortem, вы понимаете, что конкретно прошло неправильно, чего не хватило для хорошего результата и как можно было бы предотвратить аварию.

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

Но что, если периодически выносить сор из избы проводить разборы публично (в рамках компании)?

Как мы пришли к открытым разборам

Многие знают, что один из главных принципов Postmortem — blameless. Но трактовать это можно по-разному.

Традиционный перевод в контексте Postmortem: blameless = без поиска виновных. Мы не ищем «нарушителя» — мы ищем зоны роста в процессах и подходах. Виноват не исполнитель, а процесс, который позволяет совершать ошибки.

Существует и другой вариант перевода: blameless = без изъяна. Это уже не про подход к самому Postmortem, а про то, каким должны стать процессы в результате.

В высокий сезон 2022 года количество инцидентов в (тогда еще) СберМаркете стало пугающе расти. У бизнеса возникла выраженная потребность в том, чтобы инцидент-менеджмент был более прозрачным, а его качество росло. Это стало для нас стимулом подумать о blameless-принципе во второй трактовке.

Именно для того, чтобы наши процессы были совершенными, не имели изъянов, мы запустили регулярные «открытые» разборы — Комитет надежности. Практику частично подсмотрели у Amazon — там тоже есть публичные (внутри периметра) разборы инцидентов.

Что делает Комитет надежности

Конечно, Комитет не собирается ради любого Postmortem. Так мы бы съедали огромную часть рабочего времени. Есть три основных запроса, с которыми можно (и нужно) приходить.

Первый — поделиться своим горьким, обидным опытом. Самый простой пример инцидента — несовершенство тестовой модели, когда не хватило каких-то нетривиальных тестов. Даже если на закрытом Postmortem уже вывели решение, у команды может быть потребность выговориться и предостеречь остальных: «Вот наши грабли, мы на них наступили, и нам очень не понравилось, будьте осторожны».

Второй запрос — «Нам нужна помощь». Иногда команда видит проблему, но не понимает, как ее решить. Тоже приведу пример. Сервис в качестве своеобразной базы данных использовал S3. Поды приложения при редеплое не успевали выкачать все необходимое из объектного хранилища и не проходили Startup-пробу. Владельцы сервиса не могли предложить адекватного решения проблемы, поэтому вынесли обсуждение на более широкую публику.

Третий запрос — масштабирование задач. «Мы решили вот такую проблему вот таким образом и вам советуем». В Купере многие масштабные проекты по улучшению надежности запускались именно после таких встреч: массовое обновление консумеров Karafka до версии 2.0, внедрение бизнес-метрик в SLI сервисов, развитие концепции канареечных релизов и т. д.

Кого звать в Комитет надежности

Самое важное, что есть в концепте Комитета, — это люди. Их можно разделить на постоянных и приглашенных участников.

Постоянных участников мы называем комитетом Комитета. Это главные душнилы, которые задают самые правильные вопросы или обладают необходимым административным ресурсом, чтобы задачи, сгенерированные на встрече, однозначно нашли исполнителей и получили понятные сроки выполнения.

• Инцидент-менеджеры. Они «варятся» в инцидентах и имеют максимальный контекст, помогают спикерам готовиться к выступлениям и непосредственно проводят встречи Комитета.

• SRE-инженеры. Идеологи и руки надежности, эксперты в практиках и методологиях. В Купере несколько команд SRE, каждая их которых отвечает за надежность сервисов в определенном домене ИТ-ландшафта. В состав Комитета входят лиды этих команд и их общий руководитель.

• Engineering-менеджеры (EM). Тяжелая артиллерия административного ресурса, руководители доменов, эксперты широкого профиля. На каждую встречу мы приглашаем одного ЕМ из продуктовых доменов разработки и одного ЕМ из core-доменов вроде эксплуатации или платформы. Собрать всех руководителей уровня «CTO минус один» на одной встрече невозможно, поэтому мы согласовали такой формат «дежурств».

• Команды платформы. Платформа объединяет практически все наши сервисы. Платформенные инструменты позволяют с минимальными затратами внедрять доработки в максимально широких масштабах. PaaS на Комитете представлен сотрудниками Go- и Ruby-платформы.

• Тестировщики. А точнее, их методологический предводитель — руководитель обеспечения качества тестирования.

Стафф-инженеры. В каждом домене, core- или продуктовом, есть «супер-сеньоры» — эксперты высочайшей квалификации, способные предложить, спланировать и реализовать задачу любой сложности в короткие сроки.

Приглашенные участники — это спикер и его «группа поддержки».

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

Также на встречу приглашается административная вертикаль спикера: тимлид, юнит-лид, EM.

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

Формула открытого разбора

Люди любят цифры. Встречи Комитета проводятся регулярно, один-два раза в месяц, поэтому мы в начале каждой из них рассказываем об основных метриках процессов инцидент- и проблем-менеджмента: сколько инцидентов произошло, MTTA, MTTD, MTTR. Подбираем интересные факты. Это помогает погрузить участников в контекст. Вводный блок занимает до пяти минут.

На каждую встречу мы отбираем до трех инцидентов. Спикер выступает по подготовленному слайду: что произошло, как повлияло на качество услуги, какой ущерб принесло, в чем причина, как решали. Дальше идут результаты разбора, то есть задачи на улучшения, или Action Items.

Мы делим Action Items на два блока:

Actions — основные задачи, направленные на митигацию корневой причины инцидента и улучшение реакции на инцидент (например, доработку наблюдаемости). Их необходимо решить в максимально короткие сроки, чтобы максимально сократить риск повторения инцидента. Эти задачи блокируют решение проблемы.

Improvements — задачи на улучшение процессов. Это чуть менее важные задачи с относительно мягкими сроками выполнения. Они не блокируют решение проблемы, но выполнение все равно контролируется инцидент-менеджерами.

В некоторых случаях мы выделяем Mitigations Tools — специфические задачи на разработку и внедрение тулинга для решения типовых инцидентов. Скажем, инструмент для массовой отмены заказов или скрипт для остановки долгих запросов к БД. Они могут быть как блокерами, так и несрочными задачами.

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

Все поручения, созданные на Комитете, связываются с проблемой, как и те задачи, которые были созданы в ходе классического Postmortem. Дальнейший процесс в целом не отличается от стандартного: инцидент-менеджер контролирует статусы и сроки выполнения задач, проводит проблему по этапам жизненного цикла, валидирует неповторение инцидента с той же корневой причиной в течение грейс-периода. Единственное, что отличает задачи с Комитета от других, — специальный лейбл, который помогает фильтровать таски для сбора метрик и аналитики.

Какими должны быть Action Items

Небезызвестная компания Atlassian в своем хендбуке выделяет три основных параметра для оценки качества формулировки задачи. Спорить не буду :)

Action Item должен быть:

1. Actionable — отражающим результат, а не процесс. Задаем вопрос «Что сделать?», а не «Что делать?». «Не делай плохо, делай хорошо» — тоже антипример. Не получится перестать писать баги, чтобы инцидентов не случалось. Лучше подумать о том, как отлавливать баги на тестировании.

2. Specific — конкретным. Предполагаемый результат нужно описывать максимально точно.
   
   Сделай Rate Limiter на эту ручку → Установи Rate Limiter на столько-то RPS.

3. Bounded — ограниченным. Иначе задача с вами навсегда.
   
   Добавить тестов в пайплайн → Дополнить пайплайн автоматической проверкой изменений роутинга.

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

Как оценить эффективность

При закрытии всех блокирующих поручений проблема переводится в статус Resolved и обретает грейс-период. Если в течение установленного срока не было инцидентов с той же корневой причиной, проблема наделяется финальным статусом Closed. В противном случае она возвращается на исследование и дополнительные доработки, а параметр Reopen Count увеличивается на единицу.

Целевая метрика проблем-менеджмента — неповторяемость инцидентов. Соответственно, мы не должны допускать переоткрытия проблемы; это будет означать, что разбор был проведен недостаточно качественно. Для оценки эффективности Комитета можно посчитать долю переоткрытых проблем от общей массы, которая прошла через публичное обсуждение.

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

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

Почему у нас не получилось с первого раза и что мы поменяли

Первые несколько встреч Комитета произвели фурор в компании: нас поддержал VP по технологиям, было довольно много участников, активные дискуссии, масштабные задачи.

Со временем руководство перестало посещать Комитет, и интерес публики поутих за отсутствием мотивации сверху. Когда на одну из встреч не пришел никто, кроме организатора и спикеров, мы решили взять паузу и сделать работу над ошибками. Использовали метод «Пять почему» — как специалисты по поиску корневых причин неудач.

Что мы выяснили?

Во-первых, люди видели, что у нашего Комитета не было достаточно административного ресурса. Это не редкость в ITSM: за построение процессов и реализацию практик управления инцидентами зачастую отвечают команды, которые находятся далеко от верхушки организационной пирамиды.

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

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

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

Во-вторых, встречи Комитета несли низкую информативность для широких масс. Большая часть аудитории скучала на встречах. Вовлеченность была далеко не такой высокой, как мы ожидали.

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

В-третьих, кнут — это, конечно, здорово, но не стоит забывать о пряниках. Дайте человеку мерча, и он будет счастлив (хотя бы какое-то время). Мы ввели номинацию «Лучший вопрос или предложение по улучшению», чтобы оживить аудиторию.

Манифест умных Postmortem

1. Postmortem позволит вам не наступить на свои же грабли. Не стоит недооценивать важность разбора инцидента.

2. Blameless — это не только про то, что виноват не человек, а процесс, но и про стремление выстраивать безупречные процессы всеми доступными способами.

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

4. Когда вы думаете о том, с кем делиться результатами Postmortem, не забывайте об экспертах и административном ресурсе.

5. Формулируйте задачи четко. Только так вы получите требуемый результат.

6. Не недооценивайте силу позитивного подкрепления. Поддерживайте тех, кто поддерживает вас.

Что вы бы добавили в этот манифест?