Овервью спецпроекта: уровни мониторинга. Что будет на конференции. Почему важно говорить о мониторинге.

Архитектуры веб-приложений становятся все сложнее, инструментов для работы с ними все больше. Не так-то просто это все мониторить. Здесь на помощь приходит observability.

В докладе обсудим идеологически аспекты подхода observability, а именно:

• что такое observability и из каких компонентов состоит;
• какие современные методологии для сбора метрик существуют;
• на чём строится система алертинга;
• какие есть инструменты для организации observability;
• как при внедрении всего этого не утонуть и не разорваться.

Вы когда-нибудь слышали от разработчиков фразу: «Товарищи девопсы, мы задеплоили новый сервис, замониторьте нам его. Желательно срочно!». Как начать выполнение этой задачи?

В докладе мы рассмотрим, насколько комплексной является задача «замониторить что-то», из каких частей она состоит, какие инструменты используются в её реализации, какие команды проекта ответственны за каждую из её частей. А также:

• уровни мониторинга проекта: от железа до сервиса-как-бизнес-единицы;
• мониторинг проекта как один из элементов деплоя в CI/CD-процессах;
• полезные практики по сокращению коллективной боли команды при организации мониторинга.

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

Что ему надо контролировать? Да ровно всё, что касается выполнения планов, и это огромная проблема, так как если сам он через какое-то время пятой точкой начнёт понимать, где подгорает, то многочисленные заказчики из бизнес-команды будут регулярно капать ему на мозг и уточнять состояние дел не только по стратегическим вехам, но и по промежуточным вехам, по которым можно определить, — не рассыпалась ли веха.... Кроме того они постоянно будут заказывать всё новые и новые отчёты, разработка которых независимо от сложности будет прожигать огромные дыры в беклоге, начиная от сбора данных, который сам по себе непрост.

Доклад будет про философию мониторинга и общения с бизнесом на позиции технического директора.

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

О чем будем говорить:

• alert fatigue – что это такое?
• виды алертов;
• work-life balance и алерты;
• каналы оповещения;
• честная важность алертов;
• отчёты по warning;
• жизненный цикл алерта;
• как писать алерты?

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

В докладе мы рассмотрим аспекты внедрения мониторинга на проект:

• организация работы команды, эскалации, ротации, HR-особенности при работе с «командой дежурных»;
• онбординг нового человека в команду: что может пойти не так;
• формирование и своевременная актуализация базы знаний;
• техдолг vs беклог;
• топ-3 популярных рекомендации при аварии.

Outro + AMA-сессия

Интродакшен секции: Что поставить? Что такое экспортеры? Путь алертов. Инструменты, что за что отвечает.

Доклад о целях и задачах, слоях и видах мониторинга, о тех, кто реагирует на мониторинг.

О чем будем говорить:

• идеальная цель мониторинга — знать, что случится завтра;
• объекты мониторинга: от здания до приложения;
• как мониторить деньги: Qlik, BI и BA;
• кто и когда реагирует на мониторинг: от дежурного «инженера по всему» до распределённых команд.

Как работает система мониторинга в Selectel.
О чем будем говорить:

• распределение слоев мониторинга между командами;
• инструментарий мониторинга: SCADA, Zabbix, Prometheus, Grafana, Netbox, Qlik;
• протоколы сбора данных: RS485, Modbus, SNMP, REST, Telemetry (gRPC/Native), свои методы сбора метрик;
• куда собирать данные: Timescale DB, ClickHouse, Redis, Mongo, Victoria Metrics;
• разные дашборды из одинаковых данных.

Доклад о том, как в Core24/7 уменьшили количество алертов в 2–3 раза, как организовали работу с ними и почему выбрали Grafana Oncall.

Обсудим:

• как их правильно агрегировать алерты;
• как выстроить ротацию дежурных;
• как настроить эскалацию алертов.

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

В докладе рассмотрим внутренности Loki, его архитектуру, обсудим какие параметры конфигурации следует «крутить», чтобы масштабировать Loki под вашу нагрузку. А также рассмотрим, как можно на основе логов с помощью Loki строить систему мониторинга.

Расскажем, как перешли от сетапа, где у каждой команды в кластере K8s есть собственные Grafana+Loki в своём неймспейсе, к общим Grafana+Loki+VictoriaMetrics с разделением доступа к логам и метрикам на основе неймспейсов. Для этого дополнительно разработали прокси авторизации и оператор для подгрузки организаций в Grafana.

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

Обсудим в докладе:

• Как превратить пользователей в наших друзей и почему это очень полезно?
• Как распределяем роли во время инцидента?
• Что мы говорим руководству компании, если диалог перестает быть конструктивным?
• Как общаемся внутри команды во время инцидентов?
• Как пишем постмортем?

Мониторинг проекта — это комплексная задача. В неё входит не только передача метрик, но и сбор логов, трейсов, health-чеки, правила для алертов и система их доставки до ответственных разработчиков.

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

В докладе рассмотрим кастомизацию шаблонов Zabbix на примере конкретного кейса по мониторингу десятка баз PostgreSQL на одном хосте и внедрению собственных метрик. Кратко вникнем как работает Zabbix, что такое шаблоны, с какими подводными камнями можно столкнуться: генерация UUID, составление name parameter, соответствие name template в expression trigger.

В рамках доклада ответим на вопросы:

• Что такое сервис бэкапов в реалиях облака Selectel?
• Базовый мониторинг: error-срабатывания бэкапирования и фейлы при восстановлении из бэкапа.
• Мониторинг инфраструктуры: алерты на использование сетевого оборудования и методы реагирования.
• Мониторинг других параметров инфраструктуры.
• Мониторинг свободного места в пуле бэкапов 1.0.
• Мониторинг места в пуле 2.0 или мониторинг «тенденций»: прогнозирование заполнения пула бэкапов.
• Бизнес-мониторинг: а точно ли всё хорошо работает?

Outro + AMA-сессия

Как бизнесу комбинировать оперативный и ретроспективный мониторинги.

Как продакт мененеджер я всегда относился к вложениям в устойчивость и мониторинг как к досадным накладным расходам. Как к страховке, которую надо купить, чтобы оградить себя от действительно серьезных факапов.
Так было, пока я не попал в очень гибкую и быструю ML-команду, где тимлид наглядно показал мне, как за счет мониторинга и грамотных механизмов устойчивости можно значительно ускорить продуктовую разработку. А для ML-команды – больше скорость > больше протестированных моделей > больше бизнес-результат.

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

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

В рамках доклада обсудим:

• Зачем оценивать инциденты в деньгах?
• Финансовые составляющие ущерба.
• Как отследить метрики и сделать выводы.

Пирамида продуктовых метрик, как распутать узел «бизнес метрики <> продуктовые метрики».

Обсуждаем, как мониторинг продукта связан с бизнес-метриками. Разберём вопросы:

• Какие метрики важны для бизнеса?
• Как настроить пирамиду метрик от мониторинга к North Star Metric?
• Как работать с метриками мониторинга, если ты продакт?
• Как находить инсайты для развития продукта из мониторинга?
• Какой должен быть capacity на мониторинг?

Существует путаница между метриками клиентского сервиса: многие путают NPS и CSI, не знают, чем принципиально отличаются CSI и CSAT, что такое CES и как его измерять, какая правильная шкала для расчета NPS и CSI и многое другое.

В результате мы говорим NPS и подразумеваем «индекс удовлетворенности», не обращаем внимание на выборку, по которой проводятся опросы, получаем смещенные данные и делаем неверные выводы о том, насколько клиентам нравится наш продукт, или просто пытаемся подогнать результаты под KPI или какое-то среднее по рынку. Часто компании измеряют NPS и CSI, чтобы измерить, но не понимают, что дальше с этим делать и как интерпретировать результаты и какую пользу продукту они могут принести. Обо всем этом и поговорим.