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

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

• Готовых IT-решений, удовлетворяющих всем требованиям бизнеса, как правило, не существует. Как следствие, в рамках проекта внедрения выполняются кастомные доработки.
• При внедрении IT-решения оно должно вписаться в текущий контур IT-решений компании. Таким образом, дополнительно создаются интеграционные решения.
• Часто бизнес диктует сроки, для выдерживания которых команда разработки идет на компромисс и в результате появляется технический долг.

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

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

• Поддерживать стабильность того, что выпустили.
• Улучшать решение, добавляя новые возможности.

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

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

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

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

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

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

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

• Наблюдаемость: мониторинги + информинги.
  Цель: максимально оперативно (а еще лучше - заблаговременно) знать о проблеме.
• Инструменты диагностики аварий и автоматизация процедур восстановления.
  Цель: максимально быстро диагностировать проблему и восстанавливать работоспособность.
  
• Оцифровка инцидентов и культура PostMortem.
  Цель: извлекать уроки из проблем чтобы они не повторялись.
• Автотесты.
  Цель: максимально безопасный поток изменений на продакшен.

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

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

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

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

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

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

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

• 99,999% (“пять девяток”) означает, что IT-решение исправно работает 99,999% времени, а допустимое время простоя - 0,001% времени, т.е. 5 минут 15 секунд в год.
• 99,99% (“четыре девятки”) - допустимое время простоя - 52 минуты 33 секунды в год.
  
• 99,9% (“три девятки”) - допустимое время простоя - 8 часов 45 минут 36 секунд в год.
  
• 99% (“две девятки”) - допустимое время простоя - 3 дня 15 часов 36 минут в год.
  

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

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

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

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

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

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

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

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

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

• MTBF (Mean Time Between Failures) - среднее время между инцидентами.
• MTTR (Mean Time To Recovery) - среднее время восстановления (сколько прошло от начала инцидента до полного восстановления нормальной работы).
  

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

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

Система сбора и анализа логов. 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.

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

• https://sre.google/ - азбука SRE от Google.
• http://r-n-d-lab.ru/sre - команда скорой помощи во внедрении практик SRE.