SRE (Site Reliability Engineering) на языке бизнеса

Сегодня я хотел бы поговорить про SRE (Site Reliability Engineering). Это уже проверенная временем культура разработки IT-решений, которая позволяет сделать эти решения более предсказуемыми и устойчивыми.

В результате контур IT-решений компаний наполняется кастомными и проинтегрированными между собой решениями. А доработки + интеграционные решения + техдолг создают идеальную почву для нестабильности IT-решений.

Для каждого внедренного IT-решения есть 2 задачи:

Эти 2 задачи противоречат друг другу - чем больше нового кода добавляется в IT-решение, тем сложнее оно становится и тем выше вероятность того, что что-то сломается.

В 2016 году Google выпустила книгу SRE (Site Reliability Engineering).

SRE - это культура работы с IT-решениями, которая с помощью улучшения процессов разработки и тестирования, а также за счет автоматизации позволяет сократить аварийное время, делая IT-решения более предсказуемыми и устойчивыми, а бизнес в результате - более успешным.

Давайте разбираться подробнее.

Для начала нужно принять, что ошибки и аварии неизбежны. Аварии случаются у всех IT-решений и даже у таких крупных компаний как Google, Amazon, Telegram, Microsoft,...

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

SRE включает, но не ограничивается, следующими, максимально важными практиками:

Разберем их подробнее.

Часто команды разработки, которые заботятся о контроле работоспособности IT-решения, ограничиваются мониторингом базовых аппаратных метрик - загрузка процессора и памяти, занятость дисков. Это конечно же необходимо делать, но в конечном счете этого недостаточно. Тут и появляются SLI/SLO/SLA:

SLI (Service Level Indicator) - это метрики, которые измеряют ту или иную полезную для бизнеса функцию IT-решения. Например, это могут быть метрики работоспособности конкретного бизнес-процесса.

SLO (Service Level Objectives) - это допустимые показатели SLI метрик.

SLA (Service Level Agreement) - это “контракт”, который определяет, какие метрики и какое кол-во времени должно находиться в допустимых диапазонах.

Очевидное желание бизнеса сформулировать требование как “все индикаторы всегда должны быть в допустимых границах” или другими словами “всё всегда должно работать” - на практике же это не осуществимо. Вспоминаем, о чем говорили выше - ошибки и аварии неизбежны.

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

Также важно отметить, что доступность IT-решения - это не бинарная функция и зачастую аварии лишь частично ограничивают возможности пользователей в работе с системой.

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

Итак, для начала бизнес-заказчик (совместно с бизнес-аналитиком) определяет, какие бизнес-процессы и как должны измеряться. Т.е. определяют SLI, SLO и SLA. Далее разработчики добавляют в код соответствующие индикаторы, которые будут откидываться в систему мониторинга для дальнейшего анализа.

Итак, теперь мы собираем индикаторы. Что же дальше?

Во первых, при выходе того или иного индикатора (SLI) за допустимые границы (SLO) система мониторинга автоматически создает инцидент и начинает понижать доступность наблюдаемого IT-решения до момента закрытия инцидента. Закрытие инцидента возможно как в автоматическом так и в ручном режиме в зависимости от инцидента.

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

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

Случилось страшное - система мониторинга зафиксировала инцидент. Что же теперь? Теперь самое важное - в максимально короткое время восстановить работоспособность IT-решения.

Есть 2 важных показателя на эту тему:

Чтобы улучшить эти показатели применяются следующие практики:

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

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

Автоматизация процедур конфигурирования и запуска/перезапуска компонентов IT-решения. В рамках диагностики или для восстановления работоспособности (когда причины проблемы устранены) необходимо запускать/перезапускать определенные компоненты IT-решения, а работу каких-то компонентов, наоборот, блокировать. Это означает, что IT-решение должно обеспечивать гибкие возможности по настройке компонентов. Кроме этого, не стоит забывать, что аварийная ситуация является стрессовой и важно не допустить, чтобы инженер, выполняющий действия по диагностике и устранению проблемы, не усугубил ситуацию. Для этого у него должен быть под рукой набор заранее подготовленных процедур по запуску/рестарту и переконфигурированию тех или иных компонентов.

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

Кроме этого, важным ритуалом является так называемый PostMortem. Его смысл заключается в том, что уже после того как авария полностью ликвидирована, в спокойной обстановке команда разработки обсудила и зафиксировала:

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

Любое изменение, каким бы простым и очевидным оно ни казалось разработчику, может привести к фатальным авариям. И чем сложнее IT-решение, тем проще его сломать.

CI/CD (Continuous Integration / Continuous Delivery) как практика для обеспечения непрерывной интеграции и непрерывной поставки изменений на продакшен заслуживает отдельного обсуждения. Суть CI/CD в том, чтобы обеспечить максимально безопасный поток проверки и доставки изменений на продакшен.

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

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

Всё это влечет за собой и постоянно растущие требования к процессам разработки.

Ведь чем сложнее машина, тем сложнее ее обслуживать, а также требуются более профессиональные инструменты.

Если зрелось ваших IT-решений далека от описанного выше и при этом успешность бизнеса зависит от предсказуемости и устойчивости этих IT-решений, то вам пора заняться внедрением SRE.

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