Почему мы захотели сделать «Школу мониторинга»
С 17 по 19 января Слёрм с друзьями проводит «Школу мониторинга» — бесплатную онлайн-конференцию для всех, кто душой, сердцем и деньгами вовлечен в процесс мониторинга. В водовороте новогодней суеты нам удалось поговорить с идейными вдохновителями стрима и несколькими спикерами
«Школа мониторинга» будет состоять из 3 секций:
17 января — философия мониторинга. Обсуждаем observability, архитектуру мониторинга и соответствующие процессы в компании.
18 января — техническая секция. Разбираем кейсы, инструменты и другие практические вопросы мониторинга.
19 января — бизнес-секция. Обсуждаем, как извлечь из мониторинга максимум ценности для бизнеса.
Узнать подробности и зарегистрироваться можно здесь.
Антон Скобин
Я люблю делать большие бесплатные проекты и просто соскучился по ним со времен «Вечерней Школы по Kubernetes для разработчиков», к которой приложил обе руки и еще немного мозгов.
Я много слышал, что мониторинг — история индивидуальная, нельзя собрать общие рекомендации и правила. Я подумал, что просто не нашлось подходящего фреймворка для обсуждения, и мне захотелось его поискать. Придумать формат, в котором из этой темы исчезнет мистический налет сложности.
Кроме Слёрма я работаю в компании Southbridge, мы занимаемся системным администрированием. Мы регулярно получаем от клиентов запросы: «Настройте мне мониторинг». Приходится объяснять, что мониторинг — это совместная работа, нельзя просто кинуть его во внешних девопсов и сказать «Сделайте мне всё красиво». Мы, конечно, замониторим свою часть, а потом на стороне клиента что-то сломается, и он придёт с претензией к нам. Чем больше людей понимает суть мониторинга, тем меньше таких ситуаций происходит в моей жизни.
В Слёрме есть курс по мониторингу, который не пользуется особой популярностью. Я бы хотел развить эту тему и доработать курс.
И меня дико прёт идея поговорить про то, как бизнес (продакт оунеры, директора) используют мониторинг для достижения своих целей. И вообще все диалоги исполнителя и бизнеса, на какой бы стороне в них я ни находился.
Илья Сабуров
Когда Слёрм решил сделать«Школу мониторинга», я с удовольствием отклинулся на приглашение продюсировать проект. Всю жизнь занимаюсь управлением разработкой интернет-проектов и поэтому не понаслышке знаю про важность мониторинга, причем мониторинга не только «железа», но и мониторинга на уровне логики приложения и уровне бизнес-процессов, использующих это приложение.
В моем предыдущем проекте — очень популярной онлайн-школе в Бразилии — у нас был двойной рабочий день: начинали мы в 9 по Москве, а заканчивали в 18, но по Сан-Пауло, а это полночь в Москве.
Однажды звезды сошлись таким образом, что один из наших микросервисов — веб-чат в вебинарах — перестал справляться с резко возросшей нагрузкой и подарил нам пару недель ночных бдений, пока команда искала причины аварий, спешно мигрировала сервис в Kubernetes и по пути рефакторила логику приложения. А пока происходила вся эта инженерная магия, по ночам приходилось оказывать психологическую поддержку пользователям, ведь вебинары шли с 19 до 21 по Сан-Пауло, то есть с 1 до 3 часов ночи по Москве.
Виктор Попов
Коротко я могу сказать так: чтобы спать ночью спокойно.
В своей работе набил немало шишек о плохой мониторинг: и пропускал важные события и просыпался из-за ерундовых алертов. Теперь хочу, поделиться опытом, чтобы мы все спали спокойнее.
Мониторинг — это недорого, его можно делать за вменяемые ресурсы. А ещё мониторинг — это про честность и открытость, про прозрачность инцидентов. Мой моральный ориентир — ребята из GitLab, которые выкладывают все метрики в публичный доступ. Я не верю сервисам, которые пишут, что у них «ничего никогда не падает» — явно же падает.
Виктор выступит в первый и второй день конференции. Темы его докладов:
«Горшочек, не вари! Сколько алертов вам нужно?» В докладе увидим жизненный цикл алерта, важность алертов и обсудим, как сделать так, чтобы алерты стали не раздражающим фактором, а рабочим инструментом.
«Как подготовить команду к инцидентам» Обсудим, как выстроить коммуникацию так, чтобы инциденты проходили максимально спокойно и ничто не отвлекало инженеров от спасения прода в кратчайшие сроки.
Андрей Менде
Мне хочется рассказать, как моей команде круто удалось срастить мониторинг и продуктовые метрики. Вместо того, чтобы воспринимать мониторинг как средство от аварий, мы воспринимаем его как инструмент для управления продуктом. Мы поняли, что самый лучший инструмент от аварий — это смириться с тем, что они будут происходить: в этом случае процесс становится куда более управляемым. Лучше заранее понимать сценарии развития проблем, предусмотреть их и протестировать пути решения, чем паниковать каждый раз по-новой.
Андрей выступит в третий день, тема его доклада — «Мониторинг и скорость развития продукта». Спикер расскажет, как за счет мониторинга и грамотных механизмов устойчивости можно значительно ускорить продуктовую разработку и выйти на новые финансовые показатели.
Алексей Леонтьев
Я захотел поучаствовать в «Школе мониторинга» Слёрма, чтобы рассказать коллегам о комфортном мониторинге и о том, как его реализовать.. Важно понимать, что метрики, алерты, хелсчеки — всё это делается для людей, а не для машин. Для грамотной настройки мониторинга нужно представлять сценарии использования собранных данных. Эргономичный мониторинг позволяет не страдать при расследовании проблем пользователей, так как сокращает время на поиск причин проблемы и позволяет проще её локализовать. Но ещё важнее это становится при расследовании инцидентов.
Алексей выступит во второй день «Школы». Тема его доклада — «Эргономичный мониторинг на практике». В этом докладе пойдет речь о том, как подойти к реализации мониторинга со стороны разработки так, чтобы он был полезен и удобен в использовании.
Будем рады видеть вас на нашем стриме.
Посмотреть программу
Программа 1 дня — философия мониторинга, 17 января
– Владимир Федорков. Открытие секции
Овервью спецпроекта: уровни мониторинга. Что будет на конференции. Почему мы вообще говорим о мониторинге.
– Сергей Спорышев, IT Summa. Добро пожаловать в мир observability
Архитектуры веб-приложений становятся все сложнее, инструментов для работы с ними все больше. Не так-то просто это все мониторить. Здесь на помощь приходит observability.
– Сергей Спорышев, IT Summa. Начинаем внедрять мониторинг, без боли, регистрации и смс
Вы когда-нибудь слышали от разработчиков фразу: «Товарищи девопсы, мы задеплоили новый сервис, замониторьте нам его. Желательно срочно!». Как начать выполнение этой задачи? В докладе мы рассмотрим, насколько комплексной является задача «замониторить что-то», из каких частей она состоит, какие инструменты используются в её реализации, какие команды проекта ответственны за каждую из её частей.
– Виктор Попов, НЛМК-ИТ. Горшочек, не вари! Сколько алертов вам нужно?
Вашей команде приходят 100500 алертов в минуту, при этом все привыкли их игнорировать? Обычный сценарий. В докладе покажем жизненный цикл алерта, важность алертов и обсудим, как сделать так, чтобы алерты стали не раздражающим фактором, а рабочим инструментом.
– Дмитрий Чумак, IT Summa. Организация мониторинга со стороны команды и процессов
Все знают анекдот про тестировщиков, бар и реального пользователя?
Как бы хорошо ни была организована ваша система мониторинга, как бы ни был покрыт метриками и алертами ваш проект, все равно произойдет инцидент, с которым никто не будет знать, как работать, а первоначальная ответственность за его устранение будет лежать на так называемой «команде дежурных». Как организовать работу этой команды? Как сократить время на решение инцидента? Как предотвратить его повторение в дальнейшем?
– Владимир Федорков. Закрытие секции
Outro + AMA-сессия
Программа 2 дня — техническая секция, 18 января
– Владимир Федорков. Открытие секции
Интродакшен секции: Что поставить? Что такое экспортеры? Путь алертов. Инструменты, что за что отвечает.
– Кирилл Малеванов, CTO Selectel. Опыт Selectel: что мы мониторим, почему и зачем?
Доклад о целях и задачах, слоях и видах мониторинга, о тех, кто реагирует на мониторинг.
О чем будем говорить:
идеальная цель мониторинга — знать, что случится завтра;
объекты мониторинга: от здания до приложения;
как мониторить деньги: Qlik, BI и BA;
кто и когда реагирует на мониторинг: дежурного «инженера по всему» до распределённых команд.
– Кирилл Малеванов, CTO Selectel. Подходы к мониторингу в Selectel — что собирать и чем показывать
Как работает система мониторинга в Selectel.О чем будем говорить:
распределение слоев мониторинга между командами;
инструментарий мониторинга: SCADA, Zabbix, Prometheus, Grafana, Netbox, Qlik;
протоколы сбора данных: RS485, Modbus, SNMP, REST, Telemetry (gRPC/Native), свои методы сбора метрик;
куда собирать данные: Timescale DB, ClickHouse, Redis, Mongo, Victoria Metrics;
разные дашборды из одинаковых данных.
– Иван Кондратьев, Core247. Удобная работа с алертами, организация дежурных ротаций с помощью Grafana Oncall
Доклад о том, как в Core247 уменьшили количествово алертов в 2–3 раза, как организовали работу с ними и почему выбрали Grafana Oncall.
Обсудим:
как их правильно агрегировать алерты;
как выстроить ротацию дежурных;
как настроить эскалацию алертов.
– Игорь Латкин, KTS. Grafana Loki как инструмент для сбора логов с вашей инфраструктуры
Grafana Loki становится все более популярным инструментом для сбора логов с инфраструктуры. Сбор логов — один из важнейших элементов мониторинга или, если быть точнее, observability. И так как мало логов, как говорится, не бывает, желательно иметь такую систему, которая сможет хранить их как можно больше и иметь быстрый доступ к ним.
В докладе рассмотрим внутренности Loki, его архитектуру, обсудим какие параметры конфигурации следует «крутить», чтобы масштабировать Loki под вашу нагрузку. А также рассмотрим, как можно на основе логов с помощью Loki строить систему мониторинга.
– Иван Сизых, Southbridge. Мультитенанси мониторинг
Расскажем, как перешли от сетапа, где у каждой команды в кластере K8s есть собственные Grafana+Loki в своём неймспейсе, к общим Grafana+Loki+VictoriaMetrics с разделением доступа к логам и метрикам на основе неймспейсов. Для этого дополнительно разработали прокси авторизации и оператор для подгрузки организаций в Grafana.
– Виктор Попов, НЛМК-ИТ. Как подготовить команду к инцидентам
Обсуждаем, как выстроить коммуникацию так, чтобы инциденты проходили максимально спокойно и ничто не отвлекало инженеров от спасения прода в кратчайшие сроки.
– Алексей Леонтьев, KTS. Эргономичный мониторинг на практике
Мониторинг проекта — это комплексная задача. В неё входит не только передача метрик, но и сбор логов, трейсов, health-чеки, правила для алертов и система их доставки до ответственных разработчиков.
Важно, чтобы мониторинг развивался планомерно в процессе разработки бизнес-логики. В этом докладе расскажем о том, как подойти к реализации мониторинга со стороны разработки так, чтобы он был полезен и удобен в использовании.
– Евгений Бутырин, COBU. Кастомизация шаблонов для Zabbix
В докладе рассмотрим кастомизацию шаблонов Zabbix на примере конкретного кейса по мониторингу десятка баз PostgreSQL на одном хосте и внедрению собственных метрик. Кратко вникнем как работает Zabbix, что такое шаблоны, с какими подводными камнями можно столкнуться: генерация UUID, составление name parameter, соответствие name template в expression trigger.
– Изабелла Меркулова, Selectel. Как мы мониторим ваши бекапы
В рамках доклада ответим на вопросы:
Что такое сервис бэкапов в реалиях облака Selectel?
Базовый мониторинг: error-срабатывания бэкапирования и фейлы при восстановлении из бэкапа.
Мониторинг инфраструктуры: алерты на использование сетевого оборудования и методы реагирования.
Мониторинг других параметров инфраструктуры.
Мониторинг свободного места в пуле бэкапов 1.0.
Мониторинг места в пуле 2.0 или мониторинг «тенденций»: прогнозирование заполнения пула бэкапов.
Бизнес-мониторинг: а точно ли всё хорошо работает?
– Сергей Маленко, KTS. Построение распределенного мониторинга
В докладе мы рассмотрим, как в KTS подходят к построению систем мониторинга многих контуров инфраструктуры и объединению в едином хранилище. Как при этом не прийти к проблеме единой точки отказа и сохранить независимость инфраструктуры контуров.
Посмотрим на применение таких инструментов как Kubernetes, Terraform, ArgoCD, Prometheus, VictoriaMetrics, Grafana Loki.
– Владимир Федорков. Закрытие секции
Outro + AMA-сессия
Программа 3 дня — бизнес-секция, 19 января
– Владимир Федорков. Открытие секции
Как бизнесу комбинировать оперативный и ретроспективный мониторинги.
– Andrew Mende, Sr. Product at Booking.com. Мониторинг и скорость развития продукта
Как продакт мененеджер я всегда относился к вложениям в устойчивость и мониторинг как к досадным накладным расходам. Как к страховке, которую надо купить, чтобы оградить себя от действительно серьезных факапов.Так было, пока я не попал в очень гибкую и быструю ML-команду, где тимлид наглядно показал мне, как за счет мониторинга и грамотных механизмов устойчивости можно значительно ускорить продуктовую разработку. А для ML-команды – больше скорость > больше протестированных моделей > больше бизнес-результат.
– Сергей Каменев, Head of SRE. Оценка финансового ущерба инцидента
В рамках доклада обсудим:
Зачем оценивать инциденты в деньгах?
Финансовые составляющие ущерба.
Как отследить метрики и сделать выводы.
– Эльдар Забитов, EBAC Online. Мониторинг маркетинговых показателей
Будем говорить о мониторинге в маркетинге. Обсудим:
Какие бывают данные и как их готовить и объединять?
Как работает маркетинговая/управленческая аналитика?
Какие отчеты нужно собирать в первую очередь для разных бизнесов/отделов компании?
Кейсы.
– Сергей Колосков. Важность мониторинга продукта для бизнеса
Обсуждаем, как мониторинг продукта связан с бизнес-метриками. Разберём вопросы:
Какие метрики важны для бизнеса?
Как настроить пирамиду метрик от мониторинга к North Star Metric?
Как работать с метриками мониторинга, если ты продакт?
Как находить инсайты для развития продукта из мониторинга?
Какой должен быть capacity на мониторинг?
– Елена Серегина. Пирамида продуктовых метрик
Пирамида продуктовых метрик, как распутать узел «бизнес метрики <> продуктовые метрики».
– Алена Артемьева, РАБОТА.РУ. Мониторинг удовлетворенности пользователей
Существует путаница между метриками клиентского сервиса: многие путают NPS и CSI, не знают, чем принципиально отличаются CSI и CSAT, что такое CES и как его измерять, какая правильная шкала для расчета NPS и CSI и многое другое.
В результате мы говорим NPS и подразумеваем «индекс удовлетворенности», не обращаем внимание на выборку, по которой проводятся опросы, получаем смещенные данные и делаем неверные выводы о том, насколько клиентам нравится наш продукт, или просто пытаемся подогнать результаты под KPI или какое-то среднее по рынку. Часто компании измеряют NPS и CSI, чтобы измерить, но не понимают, что дальше с этим делать и как интерпретировать результаты и какую пользу продукту они могут принести. Обо всем этом и поговорим.