Вступление
Всем привет, меня зовут Марат, и я работаю с процессами в стартапах. Последние 2,5 года я работал с KYC (Know Your Customer)-финтех стартапе для Латинской Америки, где мне пришлось строить Инцидент-менеджмент с нуля (при росте количества сотрудников с 50 до 500) и закрывать дыры в мониторинге NOC-командой.
В работе с Incident Management-фреймворком мы преследовали две основные цели:
Достичь и поддерживать аптайм системы на уровне 99,99% (для наших API и SDK).
Обеспечить тем, чтобы инженеры (а не пользователи или саппорт) всегда были первоисточником информации о любом потенциальном сбое, который может привести к простою.
В наши первые дни у нас не было всеобъемлющей системы оповещения и мониторинга. А если и была, то с кучей false-positive алертов и буквально одним-двумя графами в Kibana. Поэтому начать мы решили с создания команды Network Operations Center (NOC) - как стратегического базиса для работы с предотвращением и управлением инцидентами. Мы не только достигли показателя времени безотказной работы в 99,98%, но и стали знать об инцидентах первыми: с 60% до 95% и выше. А все благодаря не только активному участию в улучшении платформы со стороны инженерки, но еще и благодаря метрикам First Time to Respond, Time to Acknowledge, Time to Assemble, Proactive Engineering Detection Rate, Number of Critical False Positives. В этом посте я расскажу про каждую из них, какие бывают антипаттерны, как измерять и как улучшать.
Да кто такой этот ваш NOC?
Давайте для начала погрузимся в не совсем распространенный термин NOC на пост-советском. Network Operations Center в самом простом понимании - команда, которая занимается 24/7 мониторингом системы и алертинга, и их первой линией поддержки. Команда понимает как делать базовый дебаг алертов и варнингов, у нее для этого есть специальный источник со всей необходимой информацией. Кроме того, команда отвечает за полный цикл инцидент-менеджмента: то есть оркестрацией процесса фикса этого инцидента, и артефактами после того как все случилось.
Как обычно с любым процессом, у нас есть роли, артефакты и события.
В данном случае, наши роли
NOC-команда, которая мониторит;
Incident Commander - это Engineering Manager, который ответственен за валидацию дебага и исправлением нашего инцидента;
Incident Team - в текущий момент дежурящие инженеры.
Артефакты
Root Cause Analysis (RCA) - наш с вами пост-мортем;
Runbook - источник знаний по каждой метрике и алерту, как они могут влиять на пользователей и систему, а также как их дебажить и эскалировать;
События
Post-Mortem - в котором вы анализируете и пишете Root Cause Analysis документ;
Incident - когда все горит, или не все, или не горит. Но опасно.
К примеру, у вас есть у вас дашборд с критическими системными метриками SaaS-платформы в Grafana - команда мониторит этот дашборд. На каждый чарт в этом дашборде есть некие показатели и паттерны поведения, которые команда отслеживает. Все эти правила лежат в Runbook (справочнике с Standard Operation Procedures). В случае KYC - у тебя на вход поток верификаций, причем с разных платформ. И вот если он у тебя упал - значит надо смотреть что это значит, и определять можно ли это NOC-команде подебажить (мало ли, вдруг просто пиковая нагрузка упала потому что у клиентов ночь), пофиксить (дернуть кнопку рестарт сервера), или эскалировать саппорту (что что-то не так) и инженерке.
Метрики
First Response Time (Время на реакцию)
Почему важно измерять: Быстрое время реакции может обеспечить или подорвать надежность продукта.
Ориентир: SLA в 1 минуту.
Антипаттерны: Попытки ответить на все Алерты одновременно в рамках SLA чреваты ухудшением качества. Лучше нарушить SLA и подумать как справляться / оптимизировать поток в будущем.
Потенциальное влияние на систему: Задержка в ответе ухудшает надежность платформы, так как сразу растет время между до принятия решений как чинить инцидент.
Как улучшить метрику: Человеческий мозг может одновременно держать в контексте не больше 3-5 источников, поэтому наша задача - постоянное уменьшение и оптимизация источников мониторинга и алертинга. Для этого нужно выявлять узкие места системы, мониторить типичные паттерны графиков при ложных и настоящих инцидентах, и улучшать механизм оповещения (для повышения точности и уменьшения ложных срабатывали). Еще здорово консолидировать разные важные графики на одном дашборде, или использовать такие инструменты как alerta, чтобы агрегировать в одном месте все важные ошибки.
Time to Acknowledge (Время на Подтверждение Инцидента)
Почему важно измерять: Чем раньше вы подтверждаете что это потенциальный инцидент, тем быстрее вы определяете путь для оценки проблемы и стратегий решения.
Ориентир: SLA 3 минуты.
Антипаттерны: аналогичны предыдущему пункту.
Потенциальное влияние на систему: Скорость подтверждения напрямую связана с доверием пользователей. Чем раньше платформа вывесила проблему на status page (в идеале до репортов пользователей о проблемах) - тем больше уверенность у пользователей что все у вас под контролем.
Как улучшить метрику: Аналогично First Response Time метрике, нужно сконцентрироваться на оптимизации количества и качества источников алертинга и мониторинга, чтобы NOC-команда не была перегружена.
Time to Assemble (Время на Сбор Команды)
Почему важно измерять: Быстрое и правильное формирование команды означает более быстрое решение проблем.
Ориентир: SLA 15 минут.
Антипаттерны: Часто команды фокусируются на замере скорости выхода в онлайн для починки любого инженера, а сам инцидент может быть решен только во второй или третьей итерации поиска нужного инженера. Замерять нужно только когда правильный человек выйдет чинить проблему.
Потенциальное влияние на систему: Быстрое и корректное формирование команды приводит к эффективному (и в плане скорости, и в плане качества) решению проблем.
Меры по улучшению: Выработайте четкие правила эскалации и компонентные признаки для каждого алерта. Как только любой Алерт имеет четкого владельца, а ложные срабатывания свелись к минимуму - сразу автоматизируйте оповещения об инцидентах (например Jira + PagerDuty); Частые, регулярные прогоны и обучение изменениям в процессе помогают команде быть готовой и реагировать быстрее. Включите дежурные команды и инженеров в работу над улучшениями Incident Management процесса - так вы получите больше мотивации к этим улучшениям.
Proactive Engineering Detection Rate (Как часто мы узнаем о проблемах первыми, а не клиенты)
Почему важно измерять: Понимание проблем еще до того, как они проявляются в виде инцидентов, обеспечивает надежность платформы.
Ориентир: Процент случаев, когда инженеры выявляли потенциальные проблемы до того, как они становились инцидентами, по сравнению с теми, которые были сообщены извне.
Паттерны и влияние на систему: Низкий процент (<80% для инцидентов с отвалившимся сервисом) указывает на реактивный подход. Высокая проактивность наоборот, как показывает опыт, обеспечивает надежность платформы. В идеале не должно быть ниже 95%.
Меры по улучшению: Работайте с постоянной настройкой и улучшением алертов и мониторинга. Улучшайте прозрачность между в местах, где работают инженеры и support / csm-отделы (которые общаются с клиентами). Например, убедитесь что ваш саппорт регулярно в конкретном месте получает апдейты про состояние системы и следующие шаги. Анализируйте не только где инжиниринг пропустил потенциальную проблему, но еще и как саппорт узнал о ней раньше - вместе вы можете создать улучшения, чтобы предотвратить подобное в будущем. Без грамотного менеджера, который может состыковать NOC-команду с инженерными целями по улучшения дашбордов и алертов - улучшить эту метрику будет сложно.
Number of Critical False Positives (Количество критических ложных срабатываний)
Почему важно измерять: Ложные срабатывания выкачивают ресурсы из разработки, являются причиной темных кругов под глазами разработчиков и, наконец, выливаются в выгорание. Они отвлекают от реальных проблем и всегда делают команду хуже подготовленной к предстоящим инцидентам.
Ориентир: Не больше 5%. Иначе слишком много шума.
Антипаттерны: Когда ложно-положительных алертов много (больше 5%) - ваша команда начинает пропускать действительно критичные сигналы о начале инцидента.
Воздействие: Эффективная работа над снижением ложно-положительных срабатываний ведет к масштабируемости и автоматизации. А чем больше ложно-положительных срабатывали, тем соответственно меньше можно наворотить автоматизации, не говоря уже о том, что качество ответов на инциденты сильно снижается. Это, в свою очередь, стоит огромных денег любому SaaS-продукту, и увеличивает отток хороших специалистов в другие (более комфортные для работы) места. Ну и это все ведет к развалу вашей системы реагирования. Для того чтобы исправить ситуацию, нужно основываясь на данных работать над повышением качества и количества оповещений.
Меры по улучшению: Сделайте каденцию еженедельного тщательного анализа всех оповещений и эскалаций. Составьте воронку каждого срабатывания, прям как в маркетинге или рекрутинге. Каждый этап воронки оповещений нужно тщательно изучить, чтобы каждое оповещение было правдивым, и предотвращало потенциальный инцидент. Если разработчики просят игнорировать этот алерт, просто отключите его пока не будет нормального фикса. На практике такая постоянная работа с анализом пути каждого критичного алерта не только снижает ложные срабатывания, но и значительно улучшает всю стратегию работы с инцидентами.
Заключение
Метрик много, но в моем опыте именно эти помогли значительно поднять аптайм, если их вешать как KPI на NOC-команду и обвязку из Incident Management процесса вокруг неё. Команда инженеров в мониторинге особенно хорошо проявляет себя, когда у вас быстрый рост стартапа после инвестиций, а мониторинг и алертинг в роли догоняющих. Это никак не отменяет обязательных для понимая здоровья системы Time to Mitigate, Time to Resolve, DORA Metrics (но их я тут не расписываю просто потому что за них уже не NOC-команда напрямую влияет - мы не можем предсказывать и прямо влиять на длительность инцидента, как мониторинговая команда).
Если возвращаться к первым двум целям постройки всего этого процесса, то аптайм мы подтянули до 99.98%, а знали про инциденты раньше всех в 95% случаев. И помог нам в этом пристальный взгляд в Tableau, где мы трекали эти метрики.