Close

Путь к успешному управлению инцидентами начинается здесь

Просмотр тем

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

Возможно, вы слышали об одной компании под названием Google. Она изобретает потрясающие вещи, например беспилотные машины и лифты в открытый космос. А еще она разрабатывает невероятно успешные приложения, среди которых Gmail, Google Документы и Google Карты. Похоже, там что-то смыслят в разработке.

Она также является инициатором набирающего популярность движения под названием Site Reliability Engineering (обеспечение надежности, SRE), которое ставит точку в многолетней войне между командами разработчиков и операционными командами. SRE призывает обеспечивать надежность продукта, принимать личную ответственность и внедрять инновации, но при этом обходиться без коридорных разборок, какие вы привыкли видеть в ИТ-вузах.

Как? Давайте изучим основы.

Что такое SRE?

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок: люди, использующие прожектор

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

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

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

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

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

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

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

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

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

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

Наше мнение

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

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

Об авторе
Patrick Hill
Patrick Hill

I've been with Atlassian a while now, and recently transfered from Sydney to our Austin office. (G'day, y'all!) In my free time, I enjoy taking my beard from "distinguished professor" to "lumberjack" and back again. Find me on Twitter! @topofthehill

продолжение темы
You built it, you run it