Мониторинг простыми словами, или как я объяснил маме работу SRE
Несмотря на то, что я не единственный айтишник в семье, объяснить свою профессию выходило немного накладно. «Что такое SRE? Как сис.админ что ли? А в чем разница-то?». И ведь действительно, с учетом того, что в РФ границы между теми же DevOps и SRE размыты, а на должность системного администратора ищут чернокнижника с опытом стабилизации прода, неудивительно, что человек и вовсе не связанный с этой сферой может запутаться.
Ахтунг!
Это скорее life-story, автор не претендует на то, что его статья — истина в последней инстанции, это скорее азбука для тех, кто хочет понять базовые принципы, в частности, мониторинга. За точными определениями и полезными практиками нужно идти к Google и читать все их книги по SRE. Книги очень занимательные, кстати!
Еще подобную тему вкратце раскрывала эта статья.
И да, в этой статье мы не будем говорить о конкретных инструментах, не будем развивать холивары ELK vs Loki и т.п.
Если вы заметили какую-то очепятку или грубую ошибку — напишите в комментариях, чтобы я ее исправил, буду очень благодарен :)
Кто такие SRE?
SRE (Site Reliability Engineer, «инженер по надежности») — профессия, а также набор принципов и практик для создания отказоустойчивых и масштабируемых систем.
Зачастую SRE вам не нужны. Вряд ли маленькому магазину игрушек с простым одностраничником, которым пользуются два с половиной человека в неделю потребуется большая отказоустойчивая и масштабируемая система. Это дорого, это сложно, да и люди, которые умеют этим управлять тоже требуют немало.
Однако если вы заведуете всемирной сетью таких магазинов (назовем ее «Подростковая вселенная»), то появляется много проблем, которые нельзя решить, наняв одного эникейщика, например, SRE занимаются следующими вещами:
Эксплуатация (поддержание стабильной работы сервиса, Ops)
Планирование ресурсов (capacity planning)
Реагирование на инциденты (incident management)
Мониторинг и оповещение (monitoring and alerting)
Основной фокус внимания SRE: надежность и доступность сервиса
Для любознательных: DevOps, SRE и системные администраторы
TL; DR: DevOps — философия про ускорение разработки и тестирования → доставки → интеграции кода, SRE — набор практик, направленных на высокую надежность сервиса. SRE в какой-то степени использует идеи DevOps, просто направляет их в другое русло.
А теперь немного подробнее:
Инженеры эксплуатации (их же все называют сис.админами) делятся на разные типы:
Техники (support technician), или Эникейщики — специалисты, которые занимаются «бытовухой». Настроить принтеры, почистить рабочий стол от вирусни, которая неожиданно оказалась на чьем-то компьютере и т.п., типичный «тыжпрограммист».
Инфраструктурная эксплуатация — специалисты, которые непосредственно создают инфраструктуру компании: подбирают инструменты, автоматизируют их развертывание, налаживают безопасность и т.п.
Команда эксплуатации (их часто называют Ops) стремится сделать систему максимально стабильной, что приводит к разногласиям с разработчиками (Dev), которые, наоборот, хотят менять ее достаточно часто.
Для того, чтобы объединить эти две команды, были созданы DevOps принципы, ключевые из них описываются моделью CALMS:
1) Культура (Culture) — и разработчики, и тестирование, и эксплуатация являются одной командой, которая взаимодействует между собой и несет ответственность за качество продукта.
2) Автоматизация (Automation) — автоматизируем рутину для того, чтобы освободить время на создание кода и другие креативные процессы.
3) Поддержка (в других вариантах Бережливость от Lean Management) — ошибки случаются и от них никто не застрахован, поэтому вместо обвинений провинившегося лучше потратить время на обучение и предотвращение подобных случаев, опираясь на полученный опыт.
4) Измерения (Measurement) — ускорять процесс можно только тогда, когда мы понимаем, что делаем, а для того, чтобы понимать хоть что-то, нужно это что-то измерять. Если ресурсы позволяют, то измерять нужно все, а наблюдать за какими-то действительно значимыми вещами. «Плюшкинский» подход, так сказать.
5) Обмен (Sharing) — если у вас есть в чем-то экспертиза, то поделитесь этой информацией с другими членами команды. Обмен информацией позволяет ускорить работу команды благодаря четкому пониманию проекта.
Из этих принципов вытекают такие практики как CI/CD (непрерывная интеграция, тестирование и доставка кода), мониторинг, а также подход IaC (инфраструктура как код). Вместе они ускоряют действия команды разработки, не нарушая спокойствия Ops’ов.
SRE использует DevOps, однако фокусируется не столько на скорости доставки изменений, сколько на общей стабильности ее работы для конечных пользователей. Можно сказать, что SRE — случай, когда разработчика ротировали в команду эксплуатации.
Что такое мониторинг?
Работу SRE можно сравнить с работой врача, правда лечим мы не людей.
Скорее всего вы сталкивались с представителями мониторинга в жизни, может, даже не замечая:
биржи, отслеживающие цены акций и курсы валют
всевозможные медицинские аппараты для отслеживания жизненных показателей
цены на гречку и ежегодное «опять поднялась!»
Мониторинг — процесс сбора метрик и их анализа для принятия последующих решений.
А что измеряют SRE?
Обычно SRE оперируют следующими понятиями:
SLI (Service Level Indicator) — метрика, показывающая фактический уровень обслуживания.
SLO (Service Level Objective) — цель по качеству обслуживания. Считается, что пользователи довольны, если фактические показатели равны установленному SLO или выше.
SLA (Service Level Agreement) — соглашение об уровне обслуживания, обычно устанавливается бизнесом. SLA — обещания, которые бизнес дает пользователю, их нарушать больнее всего.
Представим, что мы генеральный директор крупного оператора почтовой связи «Быстро и точка». Ежедневно в каждом пункте мы принимаем больше сотни отправлений и примерно столько же отдаем, а сами посылки доезжают примерно за неделю. Эти метрики (сколько мы приняли и отдали, а также за сколько посылки доезжают до приемщика) и есть SLI.
Мы стремимся к тому, чтобы посылки доставлялись максимум за две недели, это наше целевое время доставки (SLO). Если же посылка не будет доставлена в течение трёх недель, мы гарантируем начало процедуры её розыска и предоставление компенсации в случае утери согласно нашему соглашению об уровне обслуживания (SLA).
Для того, чтобы различать SLO и SLA, можно задать вопрос «а что будет, если это условие не выполняется?». Если вы можете на него ответить, то, скорее всего, вы смотрите на SLA.
Стоит заметить, что SLI и SLO измеряются в процентах и рассчитываются по формуле:
%
В IT зачастую используют следующие SLI:
Утилизация (использование) ресурсов
Количество ошибок (4xx и 5xx)
Время ответа
Общее время доступности
Количество времени, во время которого система работает без ошибок
и другие. Более подробно с ними можно ознакомиться в этой статье.
Очевидно, что мы не можем поддерживать SLO = 100%. Нет (пока что) такой системы, которая работала бы всегда без ошибок, поэтому обычно SLO измеряется «девятками»: 99%, 99.9%, 99.99% и т.п. Исходя из SLO выставляется бюджет на ошибки (Error Budget).
Например, если ежедневно в сортировочный центр приходит 100000 посылок и мы хотим отдавать 99% из них, то оставить необработанными мы можем только 1000.
SLO можно указывать за разные временные окна, причем они могут быть фиксированы по календарю (месяц/год), так и со скользящим окном. И у того, и у другого способа есть и плюсы, и минусы.
+ | - | |
Скользящее окно | Учитывается динамика за промежуток времени, ближе к пользовательскому опыту | В праздники пользовательский трафик увеличивается, из-за чего SLI могут часто варьировать |
Фиксированное окно | Прост и удобен для ведения бизнес-процессов | Пользователи не забудут факап, случившийся 31 декабря, если начнется новый месяц |
А как вы узнаете, если что-то идет не так?
Конечно, мы не сидим 24/7 перед мониторами и не следим за графиками во время обеда (хотя и такое иногда бывает), ровно как и пожарные выдвигаются на место ЧП по сигналу, мы выдвигаемся на зов алертов.
Алерты — оповещение о каком-то событии. Как пример — работа пожарной сигнализации, которая реагирует на задымление.
Алерты можно получать разными способами, самые популярные из них:
При этом можно настроить эскалации уведомлений. Некритичные отсылать только в Телеграм, а крупные сбои подтверждать несколькими этапами: мессенджер, после звонок первому дежурному, если он не ответил, то второму и т.д.
Что вы делаете во время крупных сбоев?
Крупные сбои (они же инциденты, они же факапы, они же упячки) случаются и застраховаться от них нельзя. Первым делом во время инцидента необходимо стабилизировать систему — если быстрее найти проблему, то устранить ее, если нет — использовать сценарии деградации.
Сценарии деградации — туз в рукаве разработчиков, они позволяют выключать те или иные функции приложения. Это может пригодиться, если сбоит конкретный блок, либо необходимо снизить нагрузку на сервис.
После стабилизации сервиса необходимо найти проблему и устранить ее, а также завести постмортем (postmortem). Подобно тому, как врачи проводят аутопсию, мы анализируем причины инцидента, чтобы предотвратить его повторение в будущем. В постмортеме важны все аспекты: хронология, предпринятые меры для стабилизации сервиса, сами причины и потенциальные факторы, которые могли повлиять на развитие ситуации во время инцидента.
Заключение
Надеюсь, эта статья была полезна тем, кто хотел соориентироваться в базовых понятиях. Многое в этой статье пришлось опустить (то же capacity планирование — мегасложная вещь, по которой можно написать отдельную статью с тегом hard) для того, чтобы познакомить массы с SRE, вакансии на которых начали активно появляться на карьерных платформах.
Если вы хотите вкатиться в SRE — мониторинг будет одной из последних вещей, которыми вы овладеете в полной мере. Инструменты по типу Kubernetes, Terraform, GitLab и т. д. можно изучить в рамках построения тех же домашних серверов, однако для изучения мониторинга нужен трафик, нужны факапы и нужны реальные сценарии, что делает эту тему ещё более сложной и интересной.
А вы смогли объяснить своим близким/друзьям, кем вы работаете?
