Несмотря на то, что я не единственный айтишник в семье, объяснить свою профессию выходило немного накладно. "Что такое 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: надежность и доступность сервиса

Что такое мониторинг?

Работу 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 можно указывать за разные временные окна, причем они могут быть фиксированы по календарю (месяц/год), так и со скользящим окном. И у того, и у другого способа есть и плюсы, и минусы.

А как вы узнаете, если что-то идет не так?

Конечно, мы не сидим 24/7 перед мониторами и не следим за графиками во время обеда (хотя и такое иногда бывает), ровно как и пожарные выдвигаются на место ЧП по сигналу, мы выдвигаемся на зов алертов.

Алерты - оповещение о каком-то событии. Как пример - работа пожарной сигнализации, которая реагирует на задымление.

Алерты можно получать разными способами, самые популярные из них:

• Мессенджеры (Telegram/Slack и др.)

• СМС

• Телефонные звонки

• Email

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

Что вы делаете во время крупных сбоев?

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

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

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

Заключение

Надеюсь, эта статья была полезна тем, кто хотел соориентироваться в базовых понятиях. Многое в этой статье пришлось опустить (то же capacity планирование - мегасложная вещь, по которой можно написать отдельную статью с тегом hard) для того, чтобы познакомить массы с SRE, вакансии на которых начали активно появляться на карьерных платформах.

Если вы хотите вкатиться в SRE - мониторинг будет одной из последних вещей, которыми вы овладеете в полной мере. Инструменты по типу Kubernetes, Terraform, GitLab и т. д. можно изучить в рамках построения тех же домашних серверов, однако SRE, на мой взгляд, становятся после получения опыта работы с инцидентами, мониторингом и управления ресурсами, что делает подготовку новых специалистов более трудной.

А вы смогли объяснить своим близким/друзьям, кем вы работаете?