Книга Google о SRE, статьи экспертов, документация и обучающие курсы дают исчерпывающие знания о том, как в идеале должен работать SRE в компаниях. Правда, ключевое здесь – «в идеале». Работа с метриками и управление инцидентами в командах может сильно различаться по ряду причин: количество людей в команде, скорость выкатки нового функционала, число микросервисов, распределение компетенций и тд.

Когда переходишь от теории к реалиям жизни непременно возникают тупики и вопросы: как внедрить error budget, кто за него будет ответственен, как договориться с разработкой, должны ли SRE-инженеры лезть в код при инцидентах и многое другое. В этой статье мы поговорим о выстраивании рабочего процесса на старте, когда вам нужно выставить первый SLO,   рассчитать error budget и мирно обо всем договориться с командой разработки и бизнесом. 

Как работает error budget

Error budget (бюджет ошибок) – четкая и объективная метрика, которая рассчитывается на основе SLO (Service-Level Objective, внутренний показатель качества работы сервиса). Она определяет, насколько ненадежным может быть ваш сервис в течение одного квартала и помогает разработчикам договариваться с SRE при принятии решения о допустимом уровне риска.

Другими словами, error budget (как его иногда называют, «право на ошибку») – это количество ошибок, которые ваш сервис может накопить за определенный период времени, прежде чем ваши пользователи станут недовольны. Вы можете думать об этом как о терпимости к боли для ваших пользователей, но применительно к определенному параметру вашего сервиса: доступности, задержке и так далее. 

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

Измерение надежности сервисов

Как мы уже сказали, для каждой команды и каждого сервиса можно завести свой собственный error budget. Но тут встает другой вопрос – а как рассчитывать бюджеты ошибок? 

• По времени: один из популярных вариантов подсчета, когда оценивается сколько времени доступен или недоступен сервис. Например, если error budget содержит 43 минуты даунтайма в месяц, и 40 минут из них сервис уже был недоступен, то очевидно: чтобы оставаться в рамках SLO, надо сократить риски. Как вариант, остановить выпуск фич и сосредоточиться на баг-фиксах. 

• Per request (по запросу): подходит для контроля надежности именно внутри сервисов. Каждый запрос отмечается, как успешный или неуспешный. Соблюдено SLO или нет, уложился ли сервис в те критерии, которые в него вложили? Если сервис не отвечает, значит он не соблюдает свои SLO, следовательно, запрос считается ошибочным. В этом случае одинаково выглядит, отвечает сервис слишком долго либо отвечает ошибкой. После рассчитывается соотношение «хороших» и «плохих» запросов. 

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

Что ставить в SLO на первых порах

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

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

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

Когда нужно пересматривать SLO

Пересмотр SLO – регулярный процесс. На старте SLO можно пересматривать раз в две недели, потом раз в месяц. Что-то менять придется до тех пор, пока SLO не стабилизируется и не будет согласован с командами разработки и стейкхолдерами, которым этот сервис принципиален. 

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

Пересматривать метрики придется в любом случае. Во время разбора инцидента проверяется, как стригерились метрики error budget, как вели себя метрики SLO, соблюдались они или нет, показали ли они проблему или не показали, пробило ли это бюджет. Если бюджеты исчерпались, значит где-то что-то не так считалось. Каждый раз вам нужно обосновывать, ожидаем ли был инцидент или нужно пересматривать метрики. 

Если error budget исчерпывается каждую неделю

Вот вы дошли до настройки метрик и заложили error budget на 1-2 недели. А потом бюджет начал не соблюдаться каждую неделю. Что делать? Застопить всю разработку и выкатку релизов? Получается не очень реалистичная картинка. 

Когда вы только начали внедрять error budget, расходовать месячный бюджет за пять дней – это нормально. Эти границы ставятся не для того, чтобы шокировать команду разработки, а чтобы менеджмент понимал, что что-то идет не так. На первых порах error budget нужно регулярно пересматривать: 98% за неделю было слишком жестко, поставьте 97% или 96%. Двигайте границы до тех пор, пока они не соприкоснуться с реальным отражением вашей системы. Только тогда начинайте улучшать. 

В первую очередь вам нужно обкатать процесс: как все это будет читаться и измеряться. Error budget говорит лишь о том, что либо мы сейчас занимаемся стабилизацией системы, либо ее развитием. Не добавляйте к нему никакую автоматику и остановки релизов на этапе внедрения. Максимум, что в этот момент стоит делать – просто начать разговаривать с командами. Например, обсудить, нормально ли для нашей системы, что вы израсходовали оговоренное значение бюджет ошибок или нет. Если вы не ожидали этого, то неплохо бы взять в следующий спринт задачи по стабилизации системы. 

Как еще измерить стабильность системы

Помимо стандартного подсчета девяток или какой-то другой метрики можно совместно с error budget просчитывать ABDEX по всем сервисам, критичным и конечным точкам. 

ABDEX (Application Performance Index) – это числовая мера удовлетворенности пользователей производительностью приложений. Для расчета Apdex используются статистические данные с программных счетчиков, содержащие: наименование операций, время начала каждой операции, и длительность исполнения каждой операции приложением. 

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

Application Performance Index дает более полную картину и показывает явную деградацию сервиса, если она присутствует. Какой толк от четырех девяток, если эндпоинт сервиса отвечает по 500+мс. Классический подсчет по error budget этого не учитывает, а нам все-таки нужно не только отдать 200, но и достаточно быстро это делать.  

Должен ли SRE коммитить в код

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

Как еще может быть: 

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

• SRE-инженеры работают только с инфраструктурным кодом. Если у проекта инфраструктурная специфика, команды SRE могут отвечать за часть имеющихся сервисов вместо команды разработки. В этом случае они будут отвечать за изменения на уровне скриптов, кода и тд.

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

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

Немного про дежурства и мониторинг

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

Как может выглядеть дежурство: 

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

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

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

Старт практического курса SRE: data-driven подход к управлению надёжностью систем 28 февраля.

Итог

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

• В начале пути сделайте error budget показателем того, чем вам нужно заниматься. Отвечать за стабильность он будет позже, когда начнет точно отражать состояние системы на текущий момент. Не спешите добавлять к нему автоматизацию и останавливать разработку.

• Процесс внедрения error budget может занять от трех месяцев. И даже тогда для начала используйте голову. Смотрите на уже использованный бюджет и на то, как это отразилось на состоянии продакшена. Может это случилось по причинам, на которые вы сейчас не можете повлиять, или закралась ошибка в расчетах.

• Пересматривать метрики придется в любом случае. Во время разбора инцидента проверяйте, как повел себя error budget, как вели себя метрики SLO, соблюдались они или нет, показали ли они проблему или не показали, пробило ли это бюджет. Каждый раз вам нужно все обосновать. 

• Использовать оставшийся error budget не только можно, но и нужно. Вы можете потратить его на различного рода оптимизации, например, расселить базы, которые обычно считаются критичным элементом. 

• И хотя в книге Google SRE-инженеры – в первую очередь разработчики, в реальности существует гораздо больше вариаций. Однако SRE-инженера, который как-то взаимодействует с кодом, вы встретите чаще, чем SRE-инженера, который с ним вообще не работает.