Почему мониторинг и алертинг — это основа надежной системы
“Мониторинг и алертинг являются ключевыми элементами обеспечения надежности IT-систем!”
Такой яркий заголовок часто можно встретить в начале любой статьи. Но почему это действительно так важно для любой системы и любого бизнеса?
Такой яркий заголовок часто можно встретить в начале любой статьи. Но почему это действительно так важно для любой системы и любого бизнеса?
Почему это важно?
В теории DevOps и SRE команды зачастую описываются как слаженный организм, который призван работать на благо компании, и совместными усилиями бороться за все хорошее против всего плохого. Но на практике оказывается, что коммуникация между командами DevOps и SRE далеко не всегда является слаженной и эффективной
Бывают ситуации, когда команды неосознанно или специально вставляют друг другу палки в колеса из-за различий в целях, процессах и подходах
DevOps ориентируются на скорость доставки изменений и автоматизацию,
тогда как SRE сосредоточены на надежности и выполнении SLO
Такое различие в базовых целях может вызывать конфликты, особенно если быстрые релизы от DevOps подрывают стабильность, за которую отвечают SRE
Полезная привычка собирать данные о метриках системы и анализировать их позволит понимать, как эта самая система работает в реальных условиях, и своевременно выявлять узкие места. Например, анализ трендов с помощью данных мониторинга, помогает предсказать возможные проблемы, такие как нехватка ресурсов или деградация производительности
Мониторинг и алертинг выступают надежными товарищами в планировании и соблюдении бюджета ошибок. Получается, что мониторинг и алертинг действительно являются must have-ом для любой компании. Звучит круто, но как это выглядит на практике?
Нужно понимать, что мониторинг не так прост, как кажется. У мониторинга есть разные уровни, каждый из которых вносит свой вклад в создание общей картины системы:
Мониторинг и алертинг выступают надежными товарищами в планировании и соблюдении бюджета ошибок. Получается, что мониторинг и алертинг действительно являются must have-ом для любой компании. Звучит круто, но как это выглядит на практике?
Нужно понимать, что мониторинг не так прост, как кажется. У мониторинга есть разные уровни, каждый из которых вносит свой вклад в создание общей картины системы:
Что мониторится:
Цель: убедиться, что все базовые компоненты системы работают корректно
- Серверы (CPU, RAM, диск)
- Сети (пропускная способность, потери пакетов, задержки)
- Базы данных (доступность, время выполнения запросов, место на диске)
- Аппаратные компоненты (температура процессоров, состояние жестких дисков)
Цель: убедиться, что все базовые компоненты системы работают корректно
Что мониторится:
Цель: следить за состоянием работы приложений и сервисов и выявлять проблемы, которые влияют на бизнес-логику
- Внутренние метрики сервисов и приложений
- Логи (ошибки, исключения)
- Производительность (время отклика API, успешные/ошибочные запросы)
- Подсистемы приложения (кэш, очереди)
Цель: следить за состоянием работы приложений и сервисов и выявлять проблемы, которые влияют на бизнес-логику
Что мониторится:
Цель: обеспечить, чтобы бизнес-задачи выполнялись корректно, и понимать влияние технических сбоев на бизнес
- Ключевые бизнес-метрики (количество продаж, регистраций, транзакций и др.)
- Пользовательский опыт (метрики конверсии, UX-показатели и др.)
Цель: обеспечить, чтобы бизнес-задачи выполнялись корректно, и понимать влияние технических сбоев на бизнес
Типы алертинга:
- Реактивный: срабатывает, когда произошел сбой (например, сервер недоступен)
- Прогнозирующий: уведомляет о ситуации, которая может перерасти в проблему (например, заполнение диска на 80%)
- Функциональный: информирует о нарушениях в работе бизнес-функций (например, низкий уровень продаж за час)
- По состоянию (State-based): выявление отклонений от заданных пороговых значений (например, загрузка CPU > 90%)
- По событиям (Event-based): срабатывает при определенном событии, независимо от его продолжительности.
- По аномалиям (Anomaly-based): анализирует отклонения от привычного поведения системы. (резкое увеличение времени ответа базы данных
- Комбинированный: учитывает несколько условий. (алерт при одновременном увеличении CPU > 80% и пропускной способности сети > 90%)
Настройка мониторинга – это тонкий процесс. Для начала нужно определить приоритеты мониторинга, фокусируясь на критически важных компонентах системы
Настройка алертов должна быть для разных уровней - критических, значительных и низкоприоритетных событий. Важный поинт – при настройке пороговых значений не стоит ставить слишком низкие пороги, если только вы не хотите получить шторм алертов, которые вы будете, как истинный чилл-гай, игнорировать
Для настройки метрик очень поможет использование исторических данных, чтобы понимать, что нормально для системы в данном конкретном случае и не забываем, что норма может (и будет) меняться и по историческим данным мы можем делать прогнозирование роста и актуализацию значений
Использование интеграций с системами управления инцидентами (например, OpsGenie, PagerDuty) упростит процесс эскалации. Сделать автоисправление там, где это возможно - сильно экономит время. Если не получилось починить автоматически, то чтобы минимизировать время простоя есть золотое правило: сначала поднимаем, потом разбираемся и исправляем
Тестирование, тестирование и еще раз тестирование на регулярной основе с использованием мониторинга и побольше. Тестирование также поможет в проверке алертов и их релевантности. И не забываем про своевременное обновление мониторинга при изменениях в системе
Настройка алертов должна быть для разных уровней - критических, значительных и низкоприоритетных событий. Важный поинт – при настройке пороговых значений не стоит ставить слишком низкие пороги, если только вы не хотите получить шторм алертов, которые вы будете, как истинный чилл-гай, игнорировать
Для настройки метрик очень поможет использование исторических данных, чтобы понимать, что нормально для системы в данном конкретном случае и не забываем, что норма может (и будет) меняться и по историческим данным мы можем делать прогнозирование роста и актуализацию значений
Использование интеграций с системами управления инцидентами (например, OpsGenie, PagerDuty) упростит процесс эскалации. Сделать автоисправление там, где это возможно - сильно экономит время. Если не получилось починить автоматически, то чтобы минимизировать время простоя есть золотое правило: сначала поднимаем, потом разбираемся и исправляем
Тестирование, тестирование и еще раз тестирование на регулярной основе с использованием мониторинга и побольше. Тестирование также поможет в проверке алертов и их релевантности. И не забываем про своевременное обновление мониторинга при изменениях в системе
Быстрые выводы
Эффективный мониторинг и алертинг обеспечивают оперативное устранение проблем, стратегическое планирование для предотвращения сбоев в будущем, повышение эффективности работы систем, и играют важную роль в защите репутации бизнеса предотвращая или уменьшая время инцидентов. Даже бесплатные решения для мониторинга позволяют не только улучшить производительность, но и снизить затраты на устранение последствий аварий. Не пренебрегайте! C мониторингом жизнь спокойнее и приятнее, чем без)
Эффективный мониторинг и алертинг обеспечивают оперативное устранение проблем, стратегическое планирование для предотвращения сбоев в будущем, повышение эффективности работы систем, и играют важную роль в защите репутации бизнеса предотвращая или уменьшая время инцидентов. Даже бесплатные решения для мониторинга позволяют не только улучшить производительность, но и снизить затраты на устранение последствий аварий. Не пренебрегайте! C мониторингом жизнь спокойнее и приятнее, чем без)
Что важно
Самое важное - держать команды в курсе:
обучать сотрудников правильной интерпретации метрик и алертов, а также проводить обзоры инцидентов и доносить их итоги до команд для предотвращения повторных сбоев
Самое важное - держать команды в курсе:
обучать сотрудников правильной интерпретации метрик и алертов, а также проводить обзоры инцидентов и доносить их итоги до команд для предотвращения повторных сбоев
"Кофе не помогает программировать, зато он приятен на вкус"
Джеймс Гослинг
родной отец Java
Наши статьи так же приятны как кофе, но при этом не поднимают давление:
Антипаттерны в DevOps и SRE: Частые ошибки и способы их предотвращения
Выделим и рассмотрим основные антипаттерны в DevOps и SRE — распространённые ошибки, которые могут свести на нет все преимущества данных подходов
Руководство по проведению постмортемов
Как правильно разбирать инциденты для улучшения стабильности в будущем
Chaos Engineering
Кому и как хаос-инжиниринг помогает найти слабые места и помогает ли? Что может дать Хаос инжиниринг для ИТ-команд и бизнеса? Какие есть минусы применения хаос-инжиниринга для этих акторов?
План восстановления при катастрофе: DRP
Что делать, если не сработал план А? Если не сработал план B? А если провалился план C? Тогда приходит план D - и имя ему DRP