Почему мониторинг и алертинг — это основа надежной системы. Часть 1.
 
“Мониторинг и алертинг являются ключевыми элементами обеспечения надежности IT-систем!”. Такой яркий заголовок часто можно встретить в начале любой статьи. Но почему это действительно так важно для любой системы и любого бизнеса?

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

Не менее важный игрок в этой гонке за девятками – быстрое оповещение (алертинг) об инцидентах, который помогает оперативно реагировать и минимизировать негативное воздействие на пользователей.

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

Мониторинг и алертинг выступают надежными товарищами в планировании и соблюдении бюджета ошибок. Получается, что мониторинг и алертинг действительно являются must have-ом для любой компании. Звучит круто, но как это выглядит на практике?

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

Уровни мониторинга:
Инфраструктурный мониторинг (базовый уровень)

Что мониторится:
🔧Серверы (CPU, RAM, диск)
🔧Сети (пропускная способность, потери пакетов, задержки)
🔧Базы данных (доступность, время выполнения запросов, место на диске)
🔧Аппаратные компоненты (температура процессоров, состояние жестких дисков)

Цель: убедиться, что все базовые компоненты системы работают корректно


Сервисный мониторинг (средний уровень)

Что мониторится:
🔧Внутренние метрики сервисов и приложений
🔧Логи (ошибки, исключения)
🔧Производительность (время отклика API, успешные/ошибочные запросы)
🔧Подсистемы приложения (кэш, очереди)

Цель: следить за состоянием работы приложений и сервисов и выявлять проблемы, которые влияют на бизнес-логику


Бизнес-мониторинг (уровень продукта)

Что мониторится:
🔧Ключевые бизнес-метрики (количество продаж, регистраций, транзакций и др.)
🔧Пользовательский опыт (метрики конверсии, UX-показатели и др.)

Цель: обеспечить, чтобы бизнес-задачи выполнялись корректно, и понимать влияние технических сбоев на бизнес

Продолжение здесь

#полезныематериалы #SRE @downtime_bar

Почему мониторинг и алертинг — это основа надежной системы. Часть 2.

Начало здесь

Типы алертинга:
🔧Реактивный: срабатывает, когда произошел сбой (например, сервер недоступен)

🔧Прогнозирующий: уведомляет о ситуации, которая может перерасти в проблему (например, заполнение диска на 80%)

🔧Функциональный: информирует о нарушениях в работе бизнес-функций (например, низкий уровень продаж за час)

🔧По состоянию (State-based): выявление отклонений от заданных пороговых значений (например, загрузка CPU > 90%)

🔧По событиям (Event-based): срабатывает при определенном событии, независимо от его продолжительности.

🔧По аномалиям (Anomaly-based): анализирует отклонения от привычного поведения системы. (резкое увеличение времени ответа базы данных

🔧Комбинированный: учитывает несколько условий. (алерт при одновременном увеличении CPU > 80% и пропускной способности сети > 90%)

Настройка мониторинга – это тонкий процесс. Для начала нужно определить приоритеты мониторинга, фокусируясь на критически важных компонентах системы.

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

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

Использование интеграций с системами управления инцидентами (например, OpsGenie, PagerDuty) упростит процесс эскалации. Сделать автоисправление там, где это возможно - сильно экономит время. Если не получилось починить автоматически, то чтобы минимизировать время простоя есть золотое правило: сначала поднимаем, потом разбираемся и исправляем.

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

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

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

Что еще почитать?
Про инженерную культуру
- Зачем нужна инженерная культура
- Как на собесе понять, что в эту компанию тебе не надо
- Индикаторы упадка компании
- Можно ли в одиночку поменять культуру в компании

Про SRE и отказоустойчивость
- Почему падает прод?
- Что такое SRE?
- Мониторинг и алертинг
- Тренды современного IT
- Что такое Chaos Engineering?

Как делать и как не делать
- Мониторинг и алертинг
- Антипаттерны в DevOps и SRE
- Культура взаимодействия между DevOps и SRE

#полезныематериалы @downtime_bar

SLO, SLI и SLA – Разница между ними, примеры использования.
 
✍️ SLI (Service Level Indicator) — индикатор уровня сервиса.

Что это? SLI — это конкретная метрика, которая измеряет работу сервиса в реальном времени. Это основа для оценки выполнения SLO. Метрики бывают разных уровней - инфраструктурные, сервисные и бизнесовые, про это мы подробнее писали в посте про мониторинг.

Пример:
Метрика доступности сервиса: (Время работы сервиса / Общее время) × 100
(Время работы сервиса / Общее время)×100.
Среднее время ответа API: (Сумма времени ответов) / (Количество запросов)
(Сумма времени ответов) / (Количество запросов).

Где используется? SLI используется для сбора данных о текущей работе сервиса. Эти данные позволяют оценить, соответствует ли работа системы установленным целям или SLO.
 

✍️ SLO (Service Level Objective) — целевой уровень сервиса (метрики)

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

Пример:
Веб-приложение должно быть доступно для пользователей 99.95% времени.
Время ответа API должно быть меньше 300 миллисекунд в 95% запросов.

Где используется? SLO помогает управлять приоритетами разработки и эксплуатации, выдерживая баланс между выкаткой новых фичей и сохранением стабильности системы на необходимом заданном уровне. Например, если метрика (SLI) не достигает целевого значения (SLO), это может сигнализировать о необходимости анализа процессов и причин такого отклонения.

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

 
✍️ SLA (Service Level Agreement) — формальное соглашение об уровне сервиса

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

Пример:
Поставщик облачного хранилища гарантирует 99.9% доступности. Интернет-провайдер обязуется устранять сбои в течение 4 часов с момента заявки. Если доступность падает ниже 99.9%, клиенту возвращается часть оплаты.

Где используется? SLA используется как юридически или формально обязательное соглашение между сторонами. Оно прописывает ожидания между клиентами и поставщиками.
 
Взаимосвязь:
SLI измеряет фактическую производительность (например: доступность).
SLO задаёт целевое значение метрики (например, 99.95% доступности).
SLA устанавливает формальные обязательства на основе SLO (например, штрафы за доступность ниже 99.95%).
 
Когда использовать?
SLI: Когда вам нужно определить ключевые показатели для отслеживания состояния сервиса.
SLO: Чтобы установить цели для внутреннего контроля и качества.
SLA: Для официальных договорённостей и документов.

Эти понятия помогают управлять качеством сервисов и минимизировать риски, как для поставщиков, так и для клиентов. Более полно про SLA, SLO и SLI можно почитать в канале по тегу #SRE и в книгах.

Куда еще заглянуть?
- Мониторинг и алертинг
- Антипаттерны в DevOps и SRE
- Культура взаимодействия между DevOps и SRE

#полезныематериалы #SRE @downtime_bar

Сделали для вас новую подборку литературы по мотивам последних постов – ниже вы найдете полезные и интересные книги на тему мониторинга и инцидент-менеджмента. А чтобы вам было еще приятнее, собрали все эти книги в PDF формате в комментариях!

Мониторинг:

👀 The Art of Monitoring / James Turnbull
Отличная книга для тех, кто хочет построить комплексную систему мониторинга с использованием современных инструментов, таких как Grafana, Prometheus и ELK

👀 Monitoring Distributed Systems / Cindy Sridharan
Краткое, но ёмкое руководство по мониторингу распределённых систем. Фокус на подходах к проектированию мониторинга, а не только на инструментах

👀 Observability Engineering / Charity Majors, Liz Fong-Jones, George Miranda
Одна из самых современных книг по теме. Рассматривает принципы построения систем мониторинга для сложных распределённых приложений


Инцидент-менеджмент:

🔥 Seeking SRE: Conversations About Running Production Systems at Scale / David N. Blank-Edelman
Сборник эссе и интервью с инженерами SRE со всего мира. Затрагиваются темы управления инцидентами, культурных аспектов и организационных практик

🔥 Incident Management for Operations / Rob Schnepp, Ron Vidal, Chris Hawley
Руководство по методологии управления инцидентами. Подходит как для ИТ-команд, так и для кризисного менеджмента в более широком смысле

🔥 The Practice of Cloud System Administration / Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan
Хотя книга охватывает множество аспектов системного администрирования, в ней есть отличные главы, посвящённые управлению инцидентами и операционным процедурам

🔥 Incident Response & Computer Forensics / Jason Luttgens, Matthew Pepe, Kevin Mandia
Книга более ориентирована на безопасность, но многие принципы управления инцидентами применимы и к ИТ-инфраструктуре

Что еще почитать?

Про SRE и отказоустойчивость
- Почему падает прод?
- Что такое SRE?
- IT: эффективность и хайп
- Оптимизация и стоимость в сегодняшнем IT
- Что такое Chaos Engineering?

Как делать и как не делать
- Мониторинг и алертинг
- Антипаттерны в DevOps и SRE
- Культура взаимодействия между DevOps и SRE

Про инженерную культуру
- Зачем нужна инженерная культура
- Как на собесе понять, что в эту компанию тебе не надо
- Индикаторы упадка компании
- Можно ли в одиночку поменять культуру в компании

#полезныематериалы #книги @downtime_bar

🌙 Если вам не засыпается сегодня без сказки на ночь - вот пожалуйста, наслаждайтесь 🌙
https://habr.com/ru/articles/881952/

#полезныематериалы #сказки @downtime_bar

План восстановления при катастрофе: DRP. Часть 1

🔥Что такое DRP?

Disaster Recovery Plan (DRP) – это комплексная стратегия и набор технических решений для восстановления IT-инфраструктуры и данных после катастрофы, аварии или кибератаки. DRP позволяет минимизировать время простоя бизнеса, сократить финансовые потери и обеспечить бесперебойную работу критически важных систем.

🔥Цели DRP

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

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

Сейчас покупатель находится в самом привилегированном положении за всю историю – все сервисы: магазины, банки, сайты, приложения, доставки, такси, любой контент доступны 24 часа в сутки 7 дней в неделю. Бизнес получил до этого невообразимую возможность продавать вне рамок районов, городов, регионов и государств. География, объемы и интенсивность продаж выросла в разы.

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

Здесь в игру вступает проактивный подход. Отказ – это просто вопрос времени. Любая система, даже (особенно) если она очень дорогая и кажется вам невероятно надежной, рано или поздно упадет. Чем больше компонентов, чем сложнее ваша система – тем выше риск отказа одной или даже нескольких ее частей.
Если отказ неизбежен, то возникает резонный вопрос: что можно сделать, чтобы снизить его эффект? Один из вариантов решения этой проблемы – это Disaster Recovery Plan (DRP).

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

DRP помогает нам обеспечить бесперебойность работы критически важных компонентов и сократить финансовые потери из-за даунтайма.

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

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

🔥Основные принципы DRP

⚪️Минимизация времени простоя – оперативное восстановление систем
⚪️Приоритет критических сервисов – сначала восстанавливаются ключевые системы
⚪️Гибкость – адаптация плана к разным типам угроз
⚪️Автоматизация – использование скриптов и резервных систем
⚪️Регулярное тестирование – постоянная проверка работоспособности плана
⚪️Соответствие нормативным требованиям – выполнение требований законодательства

Продолжение: часть 2

#полезныематериалы #DRP @downtime_bar