Правильный SRE или как извлечь максимум из DevOps
Александр Серпичев, старший менеджер практики инфраструктурного консалтинга и ИБ компании Axenix (экс-Accenture)
Сегодня, после нескольких лет хайпа в отношении DevOps как методологии, все чаще говорят о деградации DevOps-инженеров как профессии. Если на начальном этапе они еще пытались разбираться в процессах поставки и работе команды, то сейчас– это такой же разработчик, только код он пишет не для приложения, а для автоматизации задач доставки кода, не уделяя должного внимания стабильности работы самого приложения. В связи с этим растет спрос на SRE как направление и компетентных в нем специалистов.
SRE (Site Reliability Engineering) –подход, объединяющий программную инженерию и операционное управление ИТ-ресурсами для создания и поддержки масштабируемых, надежных и эффективных систем. Концепция была сформирована Google на основе собственного опыта.
Команды SRE-инженеров отвечают за способность ИТ-систем оставаться доступными для пользователя при высокой нагрузке и в случае серьезных сбоев. Их задачи: мониторинг и протоколирование производительности, разработка и внедрение систем и решений ИТ-инфраструктуры, автоматизация повторяющихся процессов.
Внедрили SRE – а результата нет?
Распространено ошибочное мнение, что для достижения желаемых результатов достаточно просто внедрить подходы SRE, привлекая внешних экспертов, принимая улучшенные методы контроля SLI и SLO, а также управление «бюджетом ошибок».
Уточним термины.
SLI (Service level indicators) – индикаторы уровня обслуживания, предоставляемого системами. Это доступность (время безотказной работы) и задержки в ответах ИТ-системы.
SLO (Service level objectives) – цели уровня обслуживания, т.е. согласованные целевые показатели, соответствие которым подтверждает, что наша система доступна.
«Бюджет ошибок» – максимальное количество времени, в течение которого система может давать сбои или работать некачественно, не нарушая договорных условий SLA. Этот инструмент позволяет приоритезировать задачи повышения доступности над функциональными задачами, а также оперативно внедрять новые решения, установка которых может негативно влиять на доступность сервиса.
SRE – не готовый коробочный продукт, они должны быть адаптированы к конкретному бизнес-кейсу для обеспечения успеха проекта.
Если не учитывать эти моменты, применение отдельных инструментов не даст фактических улучшений. Более того, может произойти блокирование разработки нового функционала и несоблюдение целевых показателей работы ИТ-систем. В результате будет расти бэклог инженерных и продуктовых команд по улучшению доступности этих систем.
SRE-проблемы и их причины
Причин, по которым SRE-инициативы «не взлетают», может быть множество. Корень проблемы часто в том, что SRE-специалистов по функциональности путают с инженерами по автоматизации мониторинга. То есть от них требуют только настройки инструментов сбора метрик и дашбордов.
После чего начинают ждать улучшений, не потрудившись ни составить план изменений по результатам анализа собранных данных, ни тем более перейти к практическим шагам в этой области. Между тем, задачи SRE-специалистов включают в себя все аспекты обеспечения доступности сервисов, а мониторинг – только один из инструментов.
Далее. SRE-практики всегда требуют значительных трудозатрат команды. Между тем, работы по дополнительной настройке приложений возлагаются на SRE-специалиста либо идут с низким приоритетом.
Здесь необходимо выделение дополнительных ресурсов команды для доработки приложения в необходимый формат передачи данных для метрик и аналитики.
Крайне важна поддержка руководителей, принимающих решения на самом высоком уровне. Иначе приоритет задач SRE будет ниже ввода новых «фич», а у команды не будет инструментов для его повышения.
Наконец, SRE не работает без понимания взаимосвязей и взаимозависимостей сервисов. Если не учитываются взаимосвязи систем для корректной идентификации и устранения сбоев, то механизмы эскалации сбоя в связанные команды оказываются не проработаны, что ведет к увеличению времени устранения неполадок.
Требуется перестройка взаимодействия при инцидентах с учетом прав доступа, матрицы коммуникации и организации взаимодействия команд.
Есть путь
Существует структура внедрения SRE-практик, позволяющая минимизировать влияние всех негативных факторов и гарантировать хорошее качество первого этапа работ.
1. «Начало»
Все стартует с определение метрик и способов измерения: настройка наблюдения
и мониторинга (SLI), определение способов измерения ценности (SLO), а также практика составления отчетов «пост-мортем» для всех критичных инцидентов.
Postmortem Report — элемент инженерный культуры, своего рода «вскрытие» (отсюда и название) инцидента или сбоя в рамках постоянного процесса работы над ошибками.
На этом этапе также определяются задачи в бэклог команды SRE на первое время. Самое главное – запускается автоматизация повторяющихся операций, которые имеют потенциально наиболее высокое влияние на доступность ИТ-системы в случае сбоя.
2. «Стабилизация»
На этом этапе происходит развитие инструментов автоматизации для текущих задач, а также задач эксплуатации. Основной принцип на этом этапе – снижение вероятности сбоев за счет минимизации ручных операций и времени их выполнения.
Мы переходим от автоматизации наиболее критичных часто повторяющихся действий к автоматизации типовых операций, сокращая время внесения изменений или упрощая сам процесс обновления ИТ-систем.
Движение идет от обеспечения гарантированного выполнения рутинных операций (как по шагам, так и по результату) к «комфортному» управлению ландшафтом ИТ-систем.
3. «Развитие»
Далее можно переходить к развитию культуры работы с ошибками. Согласование бюджета ошибок, определение паттернов обеспечения надежности, создание операционной модели SRE и развитие культуры пост-мортем отчетов и обучения.
Также происходит уточнение SLO и согласование SLA. На данном этапе особенно остры риски замедления работы из-за специфики формирования бюджета ошибок (формализация его значения) и определения основных подходов к работе с ним (когда и как использовать, на что влияет превышение).
Предыдущие два этапа нужны для того, чтобы мы точно могли измерять его значение, а также иметь необходимый инструментарий и набор скриптов автоматизации.
В сумме это позволяет отрабатывать известное нам время для оперативного восстановления в случае сбоев в процессе публикации не протестированного изменения (когда важнее, например, проверка гипотезы или получения дополнительных данных здесь и сейчас).
4. «Эволюция»
Здесь происходит использование и развитие автоматизированных проверок сервисов. Этап включает в себя проведение симуляций по прошлым пост-мортем, автоматическое масштабирование, а также тестирование устойчивости в пайплайне.
Симуляция строится на сценарии прошлого сбоя, который становится тестовым кейсом для текущей проверки. Тест считается успешным, если в прошлый раз был значительный сбой (с нарушением доступности), а в этот – либо масштаб был меньше, либо сбоя не было.
Выводы
Качественное внедрение SRE дает снижение среднего времени простоя в несколько раз, а также позволяет повысить скорость доставки изменений до 30% (для отдельных операций в 15-20 раз).
Как ни странно, улучшается и прогнозирование по функциональным задачам. То есть можно более точно оценить, когда та или иная доработка будет выпущена, потому что команда гораздо реже «вдруг» уходит «тушить пожар».
Важно понимать, что DevOps инженер занимается гарантированной доставкой, а SRE – обеспечением доступности. То есть в первом случае курьер должен донести хрустальные бокалы (каждый раз по дороге проверяя, а не разбились ли они), во втором – один раз разбив бокалы при доставке, SRE-инженер принимает меры, чтобы не допустить повторения этого.
В современной команде разработки нужны обе функции.
