О пройденном пути, полученных результатах и наших планах в мониторинге16.02.2024 12:15

Очередной сказ о мониторинге

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

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

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

О себе

Мы работаем в блоке, который разрабатывает основные витрины взаимодействия с клиентами (B2C). В них входят: сайт beeline.ru, интернет-магазин и мобильное приложение. Постоянное и бесперебойное обслуживание наших клиентов обеспечивают сотни систем, что кратно увеличивает возможность отказа. 

Наша команда была создана исключительно для повышения доступности наших систем. Мы — инженеры мониторинга. С помощью нашего корпоративного инструментария под кодовым названием «Платформа наблюдаемости» мы даём нашим командам уверенность в том, что в данный момент у клиента нет технических проблем, о которых мы, по крайней мере, не знаем :)

Проблемы на февраль 2023

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

Мы начали свой путь в феврале 2022 года. Это был месяц больших потрясений. Наши витрины были под постоянным прессом со стороны злоумышленников, которые пытались осуществить разного рода атаки, начиная от брутфорса и заканчивая SYN flood ddos. 

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

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

Определение метрик, по которым будем считать доступность/успешность

Начнем с главного, то есть с понимания, где мы находимся сейчас. 

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

В самом начале пути мы решили взять одну метрику успешности для подсчёта доступности ценности-услуги для клиента. 

Методика расчёта успешности системы была весьма простая: 1 - (количество 50х запросов/количество запросов) * 100. Также мы выявили для себя ТОП систем, успешность которых мы поставили во главу угла. 

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

Поскольку приложения и библиотеки логирования все разные, мы взяли логи наших балансировщиков для подсчёта. В основном это nginx. Затем обогатили их специальными хидерами для более корректного подсчёта. Например, уникальный идентификатор клиента для подсчёта уникальных пользователей per услуга. Помогает считать влияние аварии в количестве пользователей, которые не смогли воспользоваться услугой в момент деградации. Для этого мы использовали нашу платформу наблюдаемости (ELK). 

Далее мы взяли ТОП 20 по популярности методов/страниц, опубликовали агрегированные данные в QLIK для долгосрочного хранения, объяснили бизнесу, что у нас есть большие проблемы с доступностью наших услуг клиенту, получили карт-бланш и приступили к работе.

В процессе подсчёта успешности наших систем столкнулись с проблемой, когда команды используют 50х HTTP статус-код для отправки логических ошибок (недостаточно средств для смены тарифа, например). Такие ошибки портят статистику. 

На протяжении всей нашей работы мы боремся с такой реализацией в каждом отдельном случае, что переросло в документ под названием «Нефункциональные Требования к Системе», в которой мы описали этот нюанс как Quality Gate. 

Вообще, мониторинг требует большого количества общения. По итогу деградаций собираются дебрифы, на которых всегда встает вопрос мониторинга. Надо показать всё большему количеству людей наши борды, нашу статистику и т. д. 

Мы регулярно проводим демонстрации наших возможностей, наших успехов, разбираем F.A. Q. 

Также часто встречаемся с командами, рассказываем о нашем шаблоне. «Если сделать вот так, маршрутизация инцидента будет в N раз быстрее, нежели если использовать кастомный мониторинг».

Определение метрик, по которым будем судить о мониторинге

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

Перед нам встал выбор такой метрики. Так называемая «North Star Metric».

Доступность? Но мы ведь не можем напрямую влиять на эту метрику. Мы можем найти проблему, подсветить, но на скорость и качество исправления мы повлиять не можем. 

Количество заведенных/решенных инцидентов? Опять же не в нашей зоне ответственности. Команда эксплуатации — это смежное отдельное подразделение настоящих SRE-специалистов. 

Какая-то бизнес-метрика? Тоже нет :(

Вот тут нам и попалась та самая пара, с которой нам предстоит идти бок о бок длительное время. Это MTBF и MTTR.

Итого в первый год работы у нашего отдела было несколько целей:

1 — MTBF/MTTR. 

Наша основная метрика. Наш NSM.

MTBF (средняя наработка на отказ) — это среднее время между исправляемыми сбоями технологического продукта.

MTTR (среднее время ремонта) — это среднее время, необходимое для ремонта системы (обычно технического или механического).

То есть, обычными словами, MTTR — это сколько чиним, MTBF — сколько работаем без ошибок.

В статье Atlassian можно почитать про эти метрики чуть детальнее. 

Хорошо, метрика нам подходит, а как её считать? У нас есть процессы инцидент-менеджмента, однако они не такие оптимальные, считать время решений или время безаварийной работы по ним нельзя. 

Поэтому мы разработали свою систему тегов и лейблов (например, отношение данной метрики к определённым системам или бизнес-сценариям) в Grafana, создали кастомный вебхук, который принимает все алерты из графаны, записывает их в БД, а дальше отправляет в целевой канал нотификаций. На основании этой информации в БД мы и считаем временные метрики per system, per пользовательский сценарий. 

Мы не знаем «нормальные значения», поэтому ставим себе в цель скорость положительной динамики. К концу года ждём от 30 до 50% изменения каждого из показателей.

2 — доступность

Напрямую на неё влиять мы не можем, но держать руку на пульсе обязаны. Это та метрика, ради которой мы здесь собрались. Она была так или иначе поставлена во главу угла. Задачи по её увеличению были в приоритете. Баги, влияющие на доступность, вывешивались на отдельный борд в Jira с отдельным компонентом, который был в 20+ командах, с обязательным заполненным полем «due date». 

3 — % предсказанных мониторингом аварий

Мы подумали, какая наша основная проблема на данный момент (март 2022 года)? И поняли, что меньше всего нам хочется, чтобы именно клиент рассказывал нам о наших проблемах. Никому же не нравится, когда кто-то вам подсвечивает ваши «зоны роста»? :)

Отсюда и выбор первой нашей метрики — это % деградаций, которые мы «предсказали» ДО клиента. 

Начали мы с небольшого значения в 86%, но уже за 4 месяца пришли к показателю, близкому к 100%. Конечно, часто новый функционал выходит на клиента раньше, чем реализована его наблюдаемость, что приводит к деградациям, которые мы не видим на мониторинге. 

Внедрение QulaityGate по мониторингу в производственном процессе, работа с командами по объяснению принципов мониторинга, создание шаблонных, простых и понятных решений приближает нас к светлому будущему, когда продуктовые команды задумываются о мониторинге раньше, чем случится первая авария на их продукте:)

4 — покрытие наших систем RED мониторингом

Этот мониторинг у нас называется «первичным». Мы исследовали каждую из используемых в нашем окружении технологий, определили для неё ключевые метрики, согласовали их с продуктовыми командами и командами эксплуатации. Создали некую библиотеку метрик, которая стала прозрачной для всех участников процесса.

Цель: удержать % покрытия таким мониторингом от 95% до 100% наших выпускаемых систем. 

5 — ОС от коллег

Тут всё просто. Раз в 3 месяца рассылаем опросник всем коллегам, с которыми мы работаем. Узнаём о себе много нового, проверяем гипотезы, работаем с ОС. 

Определение видов мониторинга

В своей работе мы определили несколько видов мониторинга. В этом разделе я хотел бы вас познакомить с ними:

1 — первичный мониторинг 

Ни один релиз не может встать без такого мониторинга. Мы с коллегами от релизных команд и SRE-команды следим за этим. 

Первичный мониторинг у нас состоит из 4-х частей.

Входящие запросы (от клиента к системе):

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

Pasted Graphic 1.png

Pasted Graphic 3.png

Pasted Graphic 4.png

Исходящие запросы (от нашей системы к другой системе). Тут по аналогии с входящими запросами:

• гармонический график прироста  

• абсолютный график количества  

• количество или % ошибок  

• среднее, медианное или 95 перцентиль от времени ответа 

— Инфраструктурные компоненты:

■ набор метрик, которые мы определили как ключевые конкретно к данному решению. Postgresql, Redis, kafka, и т. д. Автоматический набор метрик подсасывается в зависимости от выбранной опции 

— Инфраструктура приложения:

■ набор критических для приложений метрик. Тут все просто: очередь, cpu, ram, диск, сеть и все остальное

Pasted Graphic 5.png

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

2 –– финансовый мониторинг

Периодически возникает потребность отразить финансовые показатели продукта — например, количество совершенных оплатных транзакций через определенную витрину, средний чек или сумму операций. Всегда очень полезно создавать мониторинг финансовых метрик. Во-первых, вероятно, это NSM продукта, а значит, аномалия в этой метрике должна влечь за собой тщательный разбор, в том числе технического аспекта. А во-вторых, всегда полезно посчитать, сколько стоила нам та или иная авария. 

Здесь особенно важно видеть метрику в динамике. Поэтому тут используем офсет в 7 дней для сравнения.

3 — e2e

Мы запросили у продактов критические сценарии, запросили аналитику для них, закупили устройства, симкарты и всё необходимое для реализации. Отдаем этот мониторинг в продуктовые команды и в подразделения, которые фиксируют обращения пользователей для проверки массовости деградации клиентского сценария — например, «Оплата с привязанной карты». 

В нашем контуре это решение Microfocus. На его базе, на реальных устройствах, мы гоняем это ТОП критических сценариев, включая оплатные транзакции. 

4 — безопасность

Мы очень крепко сотрудничаем с отделом информационной безопасности, так как немалая доля деградаций связана с рисками инфобеза (брут, синкфлуд, dos и т. д.) 

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

5 — бизнес-воронки

Об этом пункте я расскажу чуть подробнее в разделе «Планы». Наберитесь терпения :)

Определение инструментария

У нас довольно большой инструментарий в компании, львиная доля из него предоставляется нам коммунальным сервисом «Платформа Наблюдаемости», за что коллегам большое спасибо :)

Так вот, наши инструменты:

☑ Jira

Наш величайший таск-трекер. Живем двухнедельными спринтами со всеми вытекающими ритуалами: 3 раза в неделю планерки, 1 раз в 2 недели ретро, 1 раз в 2 недели планирование. 

Задачи попадают на нашу доску из своих проектов, но с определенным лейблом, после этого лидом распределяются внутри команды. В спринт планируем 60% времени, 40% оставляем на непредвиденные ситуации, которые, к нашему сожалению, все-таки возникают. 

☑ Confluence 

Тут лежит вся документация. Используем для демо-активностей, ссылаемся на неё при заведении задач на нас. Также используется для ретро-активностей. 

Информацию по алертам собираем, например, автоматически, из API Grafana, чтобы иметь всегда актуальный список алертов, порогов и действий. 

☑ ELK

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

У нас есть такой стандарт логирования. Он весьма свежий, разлит он далеко не на все продукты, но мы стараемся :)

Позволяет на основе этих данные строить качественную аналитику и быстро разбирать инциденты.

☑ Zabbix 

Используем для мониторинга инфраструктуры. 

Также у нас есть Zabbix Proxy в Яндекс Облаке, который позволяет с помощью selenium определять доступность простейших бизнес-сценариев. Это позволяет нам видеть доступность извне и считать время прогрузки необходимых элементов снаружи сети ВЫМПЕЛКОМ.

☑ Microfocus

Платформа для создания и запуска e2e-тестов, которые гоняются на реальном оборудовании, на мобильных устройствах. Имеет свою визуализацию и алертинг, однако основной единой платформой для этого является Grafana. 

Тут надо сказать, что данное ПО помогает нам в двух направлениях. 

• мониторинг E2E. В том числе и оплатные сценарии

• тестирование. На основе фермы устройств предоставляем нашим QA-специалистам прогнать тесткейсы на определенных устройствах 

☑ Prometheus/ victoria metrics

Системы для хранения и агрегации метрик. 

☑ Remedy

Основной инструмент для инцидент-менеджмента. Используется всей компанией для создания и маршрутизации инцидентов. С ним довольно сложно интегрироваться, поэтому пишем сервисы-прослойки для упрощения.

☑ Rundeck

Система для построения вебхуков, используемых нами для автоматизации.

☑ Telegram

Используем специального бота с авторизацией для отправки алертов. Обязательно к любому алерту или инциденту иметь чеклист и порядок действий. Это сильно ускоряет разбор деградаций. Также стараемся ко всем алертам приложить схему работы функционала, который описывает данная метрика.

☑ Sentry

Используем для хранения ошибок по фронту. 

☑ Вебхук «Василёк»

Используется как мидлсервис, позволяющий считать статистику нашей работы. На основании сбора алертов per СJ или per System мы можем строить дашборды-светофоры. То есть он загорается красным при условии наличия критичного алерта с определенным label.

Пример такого дашборда, созданного для наших дежурных:

☑ Grafana

Основной инструмент визуализации. На данный момент также центр всех нотификаций и создания инцидентов. Для подсчёта статистики, определения более корректной маршрутизации инцидентов используем систему лейблов.

Забираем данные из разных источников: Zabbix, Prometheus, ElasticSearch, БД, Sentry, Hive.  

Определение требований к команде

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

Строились амбициозные планы, был определен роадмап, вехи проекта и его метрики. 

На данный момент нас 6 человек. Для наших десятки запущенных проектов и столько же планируемых –– это самое то.

Стоит напомнить, что помимо создания мониторинга, у нас стоит задача по его вечной модерации. Новый функционал запускается, старый отключается, находятся бутылочные горлышки в проектах. Всё это требует постоянного внимания со стороны нашей команды.

По факту, все мы devops-инженеры, часто с опытом эксплуатации высоконагруженных систем. Найти таких было очень сложно.

Определение процесса создания и модернизации (ретро)

Мониторинг — вещь бесконечная. Поскольку наши приложения стараются отвечать всем дуновениям рынка, наше ПО — штука весьма изменчивая. Отсюда смена сценариев, акцентов, нагрузки и т. д. Нам всегда нужно держать руку на пульсе, чтобы не допустить как чёрных дыр мониторинга, так и ложноположительных срабатываний, что влечёт за собой потерю доверия к мониторингу в целом. Если алерт / инцидент не вызывает желания что-то сделать, то смысл мониторинга уходит как песок сквозь пальцы :)

Pasted Graphic 12.png

Отдельно стоит сказать о процессе ретро. Перед нами стояла задача регулярного анализа нашего мониторинга. В рамках этого анализа нам предстояло ответить на несколько вопросов:

• Были ли аварии, на которые мы не среагировали?

• Были ли кризисные ситуации, по мнению нашего мониторинга, которых по факту не было?

• Реальна ли критичность ТОП 10 метрик по количеству инцидентов / алертов?

• Насколько улучшилась (ухудшилась) наша доступность / успешность? Почему так произошло?

• Как работали системы, с которыми интегрируются наши витрины?

• В каком направлении мы двигаемся по MTTR / MTBF?

• Каковы системы и пользовательские сценарии с наименее красивыми MTTR / MTBF?

• Есть ли ложноположительные срабатывания e2e-мониторинга?

• Есть ли алерты / инциденты, которые не переросли в задачи / баги?

• В каком статусе задачи / баги, созданные нашим мониторингом? Может быть, пора актуализировать?

Вот, например, как выглядит MTBF алерта, на который необходимо обратить внимание.

О последнем пункте хочется сказать отдельно пару слов. Есть инциденты / алерты, которые могут закрыться со словами «неактуально», «на данный момент ошибки ушли» и т. д. Очень важно работать с командами и не допускать такие ситуации. Причина любой деградации должна быть понятна команде. Она должна знать, почему она случилась, и когда произойдёт ряд мероприятий по недопущению этого в будущем. Все такие объекты в Jira мы опубликовали на отдельном борде, за которым следим регулярно, раз в неделю. При необходимости подключаем инструмент эскалации. 

Поскольку мы тут говорим про команду, надо определить, как же мы будем эту команду оценивать. Мы определили наших пользователей. Это сотрудники от разработки, команды SRE, бизнес-подразделения, дежурной команды, команды обслуживания клиентов. Нам необходимо понимать, что они от нас хотели и смогли ли мы им помочь своим трудом. Вместе с командой составили опросник, который раз в 3 месяца анонимно отправляли всем нашим пользователям. Одним из вопросов была оценка нашего труда по шкале из 5 баллов. Быстро и просто узнать ОС о себе. 

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

Подсчёт итогов и успехов

Я очень люблю цифры, поэтому покажу их вам :)

За 2023 год уменьшили на 32% время решения наших алертов / инцидентов

За 2023 год в 2 раза увеличили срок безаварийной работы наших приложений 

За 2022 год мы получили +1,5% доступности по самой нагруженной нашей системе 

За 2023 год это число колеблется в районе 1,5

Под нашим мониторингом более 70 систем и более 750 серверов / неймспейсов

На данный момент у нас замониторено 28% критических сценариев путём прохождения синтетикой на реальном оборудовании

>3000

В начале работы было 3,95, в августе 2023 года стало 4,4

Планы на следующий год

• Monitoring as a Code. Тут все просто: максимальная шаблонизация ради ускорения производственного процесса.

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

• Уход от мониторинга систем в сторону мониторинга CJ полностью. На данный момент основной объект мониторинга это система. В нашем будущем мы планируем полностью уйти от этой иерархии в сторону построения мониторинга CJ, что привяжет все метрики именно к бизнес-сценарию, что вовлечет в работу над доступностью бизнес-подразделение команды. По каждому бизнес-сценарию мы будем считать доступность, конверсию, количество инцидентов, багов, обращений и дефектов. На данный момент технические метрики весьма абстрактны и нужны больше технической команде. После перехода на CJ мы всегда сможем сказать, сколько пользователей не дошли до экрана успеха по причине деградации.

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

• Разработка матрицы «бизнес-сценарий –критические метрики», который позволит проверять работу сценариев после релиза. Мы хотим, чтобы при установке релиза были указаны сценарии, на которые он влияет, а команда SRE могла сразу понять, на какие метрики смотреть после релиза. 

• Реализовать мониторинг сборочной инфраструктуры. Определять и реагировать на долгие сборки, повторные ошибки, недоступность репозиториев, отсутствие пакетов и т. д.

• Разработка системы критичности. Сейчас у нас только 2 приоритета. Хотелось бы цифры в 5 приоритетов.

Пример воронки по одному из сценариев.

• E2E на основе автоматического регресса. Коллеги от автоматизации тестирования создают скрипты параллельно с нами. Это создаёт избыточность работы. Мы параллельно описываем сценарии, создаём код проверки и визуализируем результат. Вопрос только в стенде, на котором происходит запуск. Они делают это на тесте, мы делаем это на продуктиве. В будущем мы хотим объединить усилия и сделать одну библиотеку тестов, которая сможет запускаться и на тесте, и на проде, в зависимости от переданных данных. Всё это будет интегрировано в производственный процесс. В этом году мы прошли стадию MvP. В следующем планируем запустить конвейер по созданию таких воронок. 

• Внешние встречи. С такими же командами из других компаний. Давайте обмениваться опытом?

Спасибо

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

Спасибо коллегам из IT за классный сервис PaaS, который позволяет за минуты разворачивать высоконагруженные сервисы.

Спасибо коллегам из Платформы Наблюдаемости за, без преувеличения, лучший и современный инструментарий, который позволяет реализовывать самые сложные и тяжёлые задачи наблюдения за созданным ПО.

Спасибо SRE-специалистам за их корректную обратную связь, особенно связанную с ложноположительными срабатываниями в 3 часа ночи. Вы самые крутые спецы!

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

© Habrahabr.ru