И снова с вами Максим Бурцев, руководитель отдела мониторинга в Купере. Пусть название отдела не вводит вас в заблуждение: мы занимаемся не только мониторингом, но и остальными процессами, которые связаны с инцидентами. До, во время и даже после того, как проблемы решены. Сегодня хочу поделиться опытом внедрения нетривиальных инструментов и методов, которые сделали наши процессы удобными, понятными и эффективными.
В первой части — некоторые фишки инцидент-менеджмента, которыми мы гордимся.
Во второй части, которая начинается здесь, я расскажу о том, как мы апгрейднули методику приоритизации.
Контекст Купера
Отдел мониторинга в нашей компании состоит из четырех команд:
группа мониторинга;
группа управления инцидентами и проблемами;
группа разработки внутренних инструментов;
группа поддержки инфраструктуры.
До того как стать руководителем, я побывал в двух из них!
Инженеры мониторинга 24/7 следят за алертами и сопровождают 100% IT-инцидентов. Решенные инциденты попадают в руки инцидент-менеджеров, которые проводят разборы, оценивают финансовые потери, следят за выполнением задач по инцидентам, постоянно совершенствуют процессы и занимаются аналитикой. Разработчики, как ни странно, создают инструменты для всех наших процессов, а группа поддержки работает с заявками от внутренних пользователей.
Почему мы считаем свой подход классным и я даже пишу о нем большую статью? Существующая схема позволяет нам обрабатывать большое количество инцидентов с понятным, прогнозируемым результатом в сжатые сроки.
Ключевые фишки инцидент-менеджмента в Купере
Мониторинг 24/7
Мониторинг у нас работает круглосуточно, но все инженеры спят по ночам — как так? Магия часовых поясов нашей необъятной родины и модель, известная как Follow the Sun. Команда мониторинга геораспределенная: первая половина инженеров живет в европейской части страны и работает по московскому времени, вторая — живет за Уралом и закрывает московскую ночь.
Мы регистрируем инциденты по триггерам от трех основных источников. Во-первых, очевидно, это алерты. Во-вторых — к сожалению, обращения пользователей: в этих случаях контактный центр или продуктовая поддержка сообщает нам об аномальном росте жалоб по той или иной тематике.
Третий вариант — ad hoc мониторинг. Раз в два часа происходит автоматический Health-check: специальный бот собирает скриншоты основных графиков (преимущественно SLO критичных сервисов и функций). Если он видит просадки, то регистрирует инцидент, а мы идем разбираться, что пошло не так.
Не все проблемы приводят к срабатыванию алертов или заметны пользователям, поэтому нужна альтернатива, которая позволяет не упускать даже мелкие симптомы и предотвращать сбои, когда еще даже ничего не сломалось.
Автоматизация — наш милый Jarvis Bot
Во время острой фазы инцидента рук инженеров мониторинга на все не хватает — особенно если сбой каскадный или инцидентов несколько одновременно. Поэтому мы стараемся автоматизировать все, что можно автоматизировать. Для этого мы разработали бота, который участвует во всех наших инцидентах.
Jarvis Bot автоматически позвонит дежурным SRE и разработчикам, напомнит о необходимости дать апдейт по статусу решения инцидента и отправит этот статус во все нужные внутренние и внешние каналы информирования. Он даже помогает заполнять тикет — все отправленные апдейты сохраняются в таймлайне.
Важно, что Jarvis не отправляет оповещения по инцидентам во все каналы сразу. В зависимости от того, что сломалось, нужно оповещать разных людей. Мы разработали каталог наших сервисов и функций и привязали к ним каналы оповещения. Для самых критичных и страшных инцидентов есть большая красная кнопка «Позвать команду по спасению мира». Когда мы понимаем, что все пропало, не хочется тратить время на поиск дежурных от десятка команд.
Что за команда супергероев? Мы проанализировали самые крупные сбои и их причины, а потом составили список команд, которые могут помочь с подобными авариями. По сути, это команды эксплуатации и разработки некоторых сервисов. Кнопка экономит драгоценные минуты на эскалацию и сокращает время простоя бизнеса.
Оповещения об инцидентах и регулярные статус-апдейты Jarvis тоже полностью автоматизировал. Формат статуса по всем инцидентам у нас стандартизован, чтобы сразу отвечать на основные вопросы менеджмента, бизнеса, саппорта и всех, на кого влияет инцидент:
Какое влияние на пользователя оказывает инцидент?
Насколько проблема массовая? Она касается всех пользователей или только части (конкретной информационной системы / магазинов / ритейлеров / регионов и т. п.)?
Известна ли причина сбоя? Если да, описать.
Что делает команда для решения инцидента?
Каков ожидаемый результат этих действий и срок выполнения?
Известны ли сроки полного решения? Если да, указать.
Кого известить об инциденте?
Кажется, что последний вопрос чуть сложнее других. Нужно ли сообщать сборщикам, что у разработчиков не работают стейджинги? Нужно ли оповещать ритейлеров о проблеме с корпоративным мессенджером?
Определиться с ответом помогает поле «Компонент» в тикете инцидента. «Компонент» — это именно та функция или услуга, на которую влияет инцидент. К каждому компоненту в справоч��ике привязаны группы пользователей и каналы оповещения. Таким образом мы точно оповестим всех, на кого может повлиять инцидент, включая внешних партнеров и иногда даже вендоров. Информация обо всех инцидентах (кроме информационной безопасности, само собой) публикуется на нашем внутреннем ресурсе Status Page.
Умный Postmortem
Пожар потушили — что дальше? Правильно, идем разбираться. Но мы не ищем, кто виноват, — мы выясняем, что делать. Postmortem зачастую может быть даже важнее, чем процесс решения.
Команда инцидент-менеджеров насчитывает четыре человека, каждый из которых закреплен за одним или несколькими доменами нашего IT-подразделения (например, за доменом «Операции» или «Инфраструктура»). Помимо проведения Postmortem, инцидент-менеджер отвечает за аналитику и контролирует выполнение задач по проблемам в своем домене. Эта специализация сужает контекст и позволяет добиваться более качественных результатов разборов, упрощает коммуникации.
Все разборы проводятся по единому шаблону. Еще до созыва Postmortem-встречи этот шаблон отправляется команде, которая тушила инцидент. Шаблон позволяет не упустить важные тонкости при разборе и сформулировать правильные задачи.
К задачам по итогам инцидента мы тоже предъявляем стандартные требования. Базово — четкий срок исполнения и конкретный ответственный. Расширенные требования таковы:
Задача описывает действи��, а не процесс: «сделать X», а не «делать X», и тем более не «не делать Y».
Результат выполнения — конкретный и понятный. Не просто «нормально сделать», а подробное описание, что такое «нормально».
Задача имеет определенный критерий выполнения (Definition of Done). То есть — как мы понимаем, что задача реально закрыта.
У меня, кстати, есть отдельная статья: Blameless 2.0. Как поделиться результатами Postmortem и получить максимум ценности
Аналитика инцидентов: ищем тренды и «хвосты»
Postmortem это хорошо, а аналитику тоже надо делать. Не зря же мы постоянно собираем данные!
Мы научились категоризировать корневые причины и находить похожие инциденты. Например, если несколько разных инцидентов произошли из-за того, что тестовое окружение недостаточно похоже на прод, это приведет к созданию отдельной Problem и последующему детальному разбору с задачами.
Еще один интересный подход — анализ «хвостов» на графиках инцидент-метрик. Честно признаюсь: придумали не сами, подсмотрели у коллег :) Берем значения ключевых метрик (TTD, TTR и др.), строим график распределения. Наша цель — избавляться от длинных «хвостов» и двигать «горб» графика ближе к началу. Так можно находить неочевидные места в процессе решения инцидентов и улучшать процессы там, где зоны роста не бросаются в глаза.
Больше деталей о том, что у нас под капотом, ищите в статье моей коллеги Даши Поповой, тимлида инженеров мониторинга: Как работать с инцидентами, когда на кону большие деньги
А мы переходим к приоритизации.
Техдолг vs фичи
Инциденты случаются у всех — это, увы, данность. Иногда по вине технических спецов, иногда по стечению обстоятельств. Мы проводим постмортемы и выносим с каждого разбора задачи по улучшению надежности и наблюдаемости. Когда же этими задачами заниматься?
Как правило, команда скорее возьмет в ближайший спринт очередную фичу, потому что «Фичи приносят деньги, а техдолг — нет». Но это в корне неверный подход.
Инцидент — это, как минимум, деградация или простой сервиса, а следовательно — потеря прибыли. Сэкономил — значит заработал.
Я не настаиваю на том, что надо освобождать место в ближайшем спринте под задачу по митигации риска, который может реализоваться только через полгода. Возможно, не обязательно и срочно настраивать алерт на событие, которое уже привело к инциденту, если мы умеем решать такие проблемы за считаные минуты.
Но ведь может быть и наоборот: если ничего не сделать сегодня, завтра мы опять потратим часы на то, чтобы поднять продакшен с колен, сорвем джекпот из обращений недовольных клиентов и потеряем значительную сумму денег.
Как определить, берем задачу завтра или же она может еще пару недель подождать? И самый важный вопрос: как объяснить бизнесу, почему вместо перекрашивания самой важной кнопки на сайте мы должны исправить костыль на бэкенде?
Прежде чем взяться за расстановку приоритетов проблем (Problem Management), мы сделали шаг в сторону и навели порядок с приоритетами инцидентов. Здесь было несколько итераций.
Как менялась приоритизация инцидентов
Доисторический подход и приоритет по наитию. Логика здесь такая: чем громче вой на болотах, тем выше приоритет. Вспоминайте Олега Т. и «Я так чувствую». На заре развития процессов в Купере эта примитивная механика работала, но с ростом зрелости ее пришлось пересмотреть. Во многом потому, что вой на болотах стал слишком громким…
Эволюция: приоритет по критичности сервисов. Далее мы ввели более формальную схему, где приоритет инцидента прямо пропорционально зависит от Tier, то есть класса критичности сервиса. Четыре Tier = четыре уровня приоритета. Звучит логично, но на практике возникают вопросы.
Что делать, если сбой каскадный и затрагивает сразу несколько сервисов разной критичности? А если инцидент не приводит к полной недоступности? К примеру, в некоем сервисе класса Business Critical, обеспечивающем работу колл-центра, произошел инцидент. Проблема не является блокирующей и затрагивает лишь небольшую долю пользователей. Формальная критичность сервиса говорит, что инцидент требует немедленной реакции, а здравый смысл подсказывает обратное.
Спустя некоторое время тестирования мы поняли, что критичность инцидента нужно оценивать не по сервису, а по его функции.
Революция: матрица из двух прозрачных критериев. Наша актуальная схема приоритизации строится на двух объективных параметрах: критичности (Severity) и массовости (Scope).
Теряем деньги из-за инцидента здесь и сейчас — высокая критичность. Не теряем деньги, просто кому-то менее удобно работать — критичность ниже, решаем проблему менее спешно и точно не бросаемся на починку в ночь с пятницы на субботу.
С массовостью еще проще: какая доля пользователей страдает — такая и массовость. Мы выбрали четыре порога:
низкая массовость — каждый десятый пользователь (до 10%);
средняя — каждый третий пользователь (до 30%);
высокая — каждый второй (≥ 50%);
максимальная — страдают почти все пользователи, инцидент оценивается как критический.
Выбираем уровни критичности и массовости по четырехбалльной шкале, где единица — минимум, а четверка — максимум. Сопоставляем строку и столбец в таблице и получаем приоритет инцидента. Естественно, проблемы, которые заметны конечному клиенту, почти всегда получают высокий приоритет. Мы боремся с ними и ночью, и в выходной, и накануне Нового года. Схема надежная и простая, разберется даже ребенок.
Раньше мы выделяли четыре приоритета, но со временем устранили самый низкий (P4), потому что сами не смогли определить, чем он принципиально отличается от P3. Разница между вторым и третьим очевидна: P2 чиним срочно, P3 ждет рабочего времени. P1 от P2 отличает масштаб и моментальное влияние: инцидент критического приоритета (P1) прямо сейчас сжигает наш бюджет, а просто высокий приоритет (P2) может иметь отложенный, накопительный эффект.
А теперь мы подобрались к самой интересной части статьи, где я расскажу, как и зачем приоритизировать проблемы.
Приоритизация проблем: от приоритета инцидента к оценке риска
Когда мы в Купере только начали выстраивать процесс управления проблемами, то пошли по пути наименьшего сопротивления и присваивали проблемам тот же приоритет, что и инциденту, который ее вызвал. При критическом инциденте проблема автоматически становилась критической, ставились максимально жесткие дедлайны для связанных задач.
Понятий «блокирующая» и «неблокирующая задача» не существовало. Все задачи по критической проблеме сразу планировались на ближайший спринт. Никакой свободы врагам свободы! Угадайте, как часто мы укладывались в сроки? Правильно — ни-ко-гда. (Опять вспоминаем Олега Т.)
Вдохновившись успехом матрицы приоритетов для инцидентов, мы пошли внедрять аналогичный инструмент для приоритизации проблем. Поскольку проблема представляет собой не только корневую причину одного или нескольких инцидентов, но и уже реализованный риск, мы подсмотрели несколько идей в сфере управления рисками.
В основу легла логика методологии FMEA (Failure Mode and Effects Analysis) для выявления и анализа болевых точек в процессах с целью управления качеством. В оценке риска FMEA используются три критерия: тяжесть последствий, частота возникновения и возможность обнаружения проблемы до ее проявления.
Мы адаптировали схему под реалии Купера, приправили данными о наших инцидентах — и получили систему оценки проблем с двумя базовыми и тремя поправочными факторами.
Для проблемы выставляется два базовых параметра:
Степень ущерба, а точнее сумма финансовых потерь от произошедшего инцидента. Четыре уровня, больше потери — выше балл. Разделение по суммам не даю, потому что в разных компаниях и цифры разные.
Вероятность повторения, то есть как скоро, по нашим ожиданиям, может повториться подобный сбой. Так же четыре уровня: дни, недели, месяцы, кварталы.
Совмещаем строку и столбец и получаем приоритет проблемы в баллах:
0–3 балла — приоритет Minor (низкий);
4–10 баллов — Normal (стандартный);
11–13 баллов — Major (высокий);
14 баллов и выше — Critical (критический, наивысший).
Поправочные факторы могут повысить приоритет проблемы. Добавляем один уровень приоритета, если:
нарушен SLA (Service Level Agreement) связанного инцидента;
для ликвидации инцидента пришлось применить обходное решение, костыль;
о проблеме, инцидент для которой мы не обнаружили через мониторинг, сообщают пользователи.
Важное уточнение: «бонусы» не суммируются. Minor, который собрал три дополнительных балла, не может вырасти до Critical, его максимум — Normal.
Разберем методологию на реальных историях
Ситуация №1
Одним летним днем коллеги из департамента логистики обнаружили аномалию в бизнес-метриках на дашбордах. В ходе разбирательств выяснилось, что репликация в базе данных одного из наших микросервисов, недавно перенесенных в другое облако, не работает уже порядка 18 часов. 18 часов, Карл! Всему виной логи медленных запросов PostgreSQL, которые заполнили диск. В старом облаке такие логи были отключены по умолчанию, поэтому проблема не проявлялась.
Итоговая формулировка корневой причины инцидента звучит так: несовершенство архитектуры (нет отдельного диска/тома для медленных логов) + ошибка при внесении изменений (в ходе миграции не проверили кастомные настройки базы данных).
С наблюдательностью все, мягко говоря, не гладко — раз на обнаружение ушло 18 часов. Потери оценили в более чем 18 миллионов рублей. Вероятность повторения инцидента высокая: мы активно мигрируем в новое облако, поэтому на других сервисах может случиться то же самое. По нашей методологии это 16 баллов и наивысшая степень ущерба (Critical). Ожидаемое время решения — до пяти рабочих дней.
Задачи по предотвращению повторения взяли в текущий спринт:
проверили на всех перенесенных сервисах, что сбор медленных логов PostgreSQL отключен;
поправили алерты по репликации;
реализовали отдельный PVC для текстовых логов и настроили их экспорт в ELK.
Ситуация №2
Часть пользователей перестала видеть изображения на сайте. Выяснили, что сбой связан с недавним релизом: обновляли OpenResty, но канареечный деплой начал откатываться, и инженер, сопровождающий релиз, нажал роллбэк вручную. Часть подов с новой версией компонента остались в живых. «Плохие» поды прибили вручную, все изменения откатили, но проблема не исчезла — было необходимо сбросить кэши на CDN. Такие доступы есть далеко не у всех, поэтому потребовалась дополнительная эскалация.
Потери оценили примерно в три миллиона рублей — это средняя степень ущерба. Риск повторения высокий: мы вносим изменения в системы десятки раз в день, и откаты случаются нередко.
По матрице получаем восемь баллов — средний приоритет (Normal). Но инцидент решали долго — из-за необходимости сбросить кэши. Поэтому повысили приоритет проблемы до высокого (Major).
Задачи по предотвращению запланировали на следующий спринт:
исправление бага в CI/CD;
выдача прав на сброс кэша инженерам мониторинга.
Отклоненные критерии оценки
При разработке методики мы рассматривали и другие параметры. В нашу итоговую конфигурацию они не попали, но вам могут пригодиться, поэтому пройдусь и по ним.
Затраченный человеческий ресурс. Трудочасы инженеров и разработчиков — немалая статья расходов, но подсчитать их сложно. Мы не всегда фиксируем точное время, которое каждый сотрудник провел за разбором инцидента. Нет точной метрики — нет корректных порогов. Восемь часов — это много или мало? Нужно ли учитывать простой других сотрудников, если инцидент повлиял на внутренние сервисы? Посчитать количество сборщиков и курьеров, которые не смогли работать из-за сбоя, тоже почти нереально.
Бюджет ошибок. Если сервису присвоен наивысший класс критичности, мы ожидаем его доступность на уровне около 99,5%. Допустимый простой составляет около семи минут в день, или чуть меньше часа в неделю. Мы так и не решили, на каком интервале оценивать превышение бюджета: за день, за неделю, а может быть — за квартал. В итоге были вынуждены отказаться от критерия ради простоты.
Если докрутите эти идеи, расскажите в комментариях!
Результаты внедрения
Наша методика приоритизации позволяет оценить потери от повторения сбоя и обосновать необходимость срочного выполнения того или иного action item. Модель понятна всем: и разработчикам, и их руководителям, и проджект-менеджерам, и продактам, и инженерам, и стороне бизнеса. Критерии оценки простые и объективные.
Но прелесть не только в прозрачности — есть и объективные цифры. Если раньше мы переносили due date почти у каждой второй проблемы, то сейчас переносится около 20%. Средний срок закрытия проблем сократился почти на 30% — команды быстрее разбирают критичные задачи и не отправляют их пылиться в самый темный угол бэклога.
Для оценки эффективности управления проблемами у нас тоже есть метрики. Первая и ключевая — доля повторных инцидентов. Мы уже долго удерживаем эту метрику �� значении не выше 1%, и это еще одно доказательство, что новый подход к приоритизации более чем рабочий.
Говорите с бизнесом в терминах потерь и рисков. Когда все видят проблему в цифрах, гораздо легче поддержать работу над техническим долгом вместо разработки очередной фичи.
