Любите DevOps? Вы еще не знаете об SRE!

Что такое SRE?

Автор идеи SRE, Бен Трейнор из компании Google, до сих пор не опубликовал краткое определение своего подхода, но, по его словам, это «то, что происходит, когда программисту поручают выполнять то, что раньше называлось операциями».

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

С SRE не приходится гадать и спорить о том, что и когда может быть запущено. Вместо этого предлагается математическая формула, позволяющая определить возможность выпуска релиза. Специальная команда сотрудников с навыками операционной работы (обычно их называют инженерами по техническому обеспечению надежности сервиса или SRE-специалистами) постоянно контролирует надежность продукта. Руководитель отдела по SRE в Google Эндрю Уидоусон описывает свою команду так: «Мы — как самый быстрый в мире экипаж механиков. Мы на лету меняем шины гоночного автомобиля, мчащегося со скоростью 160 километров в час».

Все еще звучит не слишком революционно? Вся прелесть в том, как это работает. Далее мы расскажем о нескольких основных принципах SRE. Стоит заметить, что они разительно отличаются от традиционных методов работы ИТ-команды.

Во-первых, решение о выпуске новых релизов принимается в зависимости от текущей производительности продукта.

Большинство приложений не может работать без перебоев в течение 100 % времени. Поэтому команда SRE устанавливает для каждого сервиса соглашение об уровне обслуживания (SLA), в котором определяет уровень надежности системы для конечных пользователей. Если команда соглашается на SLA с доступностью на уровне 99,9 %, то допустимый простой равен 0,1 %. Допустимый простой следует понимать буквально — это максимально допустимый процент ошибок и сбоев.

Подсказка. «Минуты простоя» на основе SLA можно легко рассчитать с помощью этой шпаргалки по времени безотказной работы.

Команда разработчиков может «потратить» этот допустимый простой, как ей захочется. Если продукт в настоящее время работает безупречно, с небольшим количеством ошибок или вовсе без них, разработчики могут запускать в любой момент все, что захотят. И наоборот, если они «потратили» или превысили допустимый простой и работают на уровне, определенном в SLA (или не достигают его), то запуск любых новых возможностей замораживается до тех пор, пока команда не уменьшит количество ошибок до уровня, позволяющего продолжить запуск.

Гениально, правда? Это хорошо мотивирует как инженеров по обеспечению надежности, так и разработчиков совместно работать над сокращением количества ошибок.

Инженеры по техническому обеспечению надежности сервиса тоже могут писать код

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

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

Разработчики тоже занимаются черной работой

В Google Бену Трейнору пришлось бороться за это требование, и он рад, что настоял. В своем замечательном выступлении об SRE на конференции SREcon14 он подчеркнул, что руководители должны ввести это требование до запуска SRE.

Обычно команда разработчиков обрабатывает 5 % всей рабочей нагрузки по операциям (обработка заявок, дежурство и т. д.). Благодаря этому они тесно связаны со своим продуктом, видят, как он работает, и могут принимать более эффективные решения при написании кода и выпуске релизов.

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

Инженеры по SRE — это свободные агенты (и при необходимости их можно привлечь)

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

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

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

Наше мнение

Бесспорно, мир ИТ полон модных слов и тенденций. Сейчас это облако, через минуту — DevOps, клиентский опыт или геймификация. Но SRE имеет все шансы перерасти в нечто большее, поскольку это скорее про людей и процесс, чем про технологию, которая берется за основу. Технология может (и, скорее всего, будет) адаптироваться к концепции в процессе совершенствования. Ее будут внедрять все больше команд, но вам не потребуются новые инструменты, чтобы привести деятельность команд разработчиков и операционных команд в соответствие с принципами обеспечения надежности.

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