Site Reliability Engineering (SRE) и DevOps – два популярных направления, которые во многом совпадают. Ранее находились те, кто называл SRE конкурирующим с DevOps набором практик. Но мы считаем, что они не такие уж и разные.

1. Различия между DevOps и SRE

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

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

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

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

DevOps и SRE – это не два конкурирующих метода разработки и эксплуатации программного обеспечения, а скорее близкие друзья, призванные сломать организационные барьеры для еще более быстрой поставки качественного ПО. Если вы читаете книги, ознакомьтесь с тем, как SRE соотносится с DevOps (Betsy Beyer, Niall Richard Murphy, Liz Fong-Jones) более подробно.

2. SLI, SLO, и SLA

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

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

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

• SLI – это метрики времени, такие как задержка запроса, пропускная способность (запросы в секунду) или число сбоев на запрос. Они, как правило, агрегируются во времени, а затем преобразуются в ставку, среднее или процент по отношению к пороговому значению.
• SLO – это целевые показатели совокупного успеха SLI в течение определенного периода времени (например, за “последние 30 дней” или “за этот квартал”), согласованные заинтересованными сторонами.

Хотя Соглашения об уровне услуг (SLA) и не являются постоянной заботой SRE, SLA – это обещание провайдера услуги потребителю, касающееся доступности и последствий ситуаций, когда он не в состоянии обеспечить согласованный уровень сервиса. SLA обычно определяются и согласовываются руководителями для клиентов и предлагают меньшую доступность, чем SLO. В конце концов, вы предпочтете для начала сломать свой собственный внутренний SLO, прежде чем сломать клиентский SLA.

SLI, SLO и SLA тесно связаны с одной из основ DevOps – “измерять всё”, – и это одна из причин, по которой мы говорим, что класс SRE реализует DevOps.

3. Бюджеты рисков и ошибок

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

Стремление к максимальной стабильности системы является контрпродуктивным и бессмысленным. Нереалистичные целевые показатели надежности ограничивают скорость доставки новых функций пользователям, к тому же, пользователи обычно не замечают крайней доступности (например, 99,999999%), потому что в их опыте преобладают менее надежные компоненты, такие как Интернет-провайдеры, сотовые сети или Wi-Fi. Наличие требования 100% доступности серьезно ограничивает возможности команды или разработчика по доставке обновлений и улучшений в систему. Владельцы услуг, которые хотят предоставить много новых функций, должны выбрать менее строгие SLO, тем самым давая возможность продолжать поставку в случае ошибки. Владельцы сервисов, ориентированные на надежность, могут выбрать более высокий SLO, но признают, что нарушение этого SLO задержит выпуски функций. SRE количественно определяет этот приемлемый риск как “бюджет ошибок”. Когда бюджеты ошибок исчерпаны, фокус смещается с разработки функций на повышение надежности.

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

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

4. Труд и бюджеты труда

Важным компонентом SRE является труд, бюджеты на труд и способы снижения трудозатрат. Труд происходит постоянно, оператору нужно вручную касаться системы во время нормальных операций – но определение «нормальности» постоянно меняется.

Труд – это не просто “работа, которую я не люблю делать”. Например, следующие задачи требуют времени, но сюда не относятся: предоставление авансовых отчетов, участие в совещаниях, ответы на электронную почту по дороге на работу и т.д. Напротив, труд – это специфика, связанная с обеспечением продуктивности услуги. Это работа имеет тенденцию быть ручной, повторяющейся, автоматизируемой и лишенной долгосрочной ценности. Кроме того, объём труда возрастает линейно по мере роста услуги. Каждый раз, когда оператору необходимо выполнить работу в системе, например, обработать  запрос или заявку, вероятно, возникает труд.

SRE направлен на снижение трудозатрат, фокусируясь на “инженерной ” составляющей Site Reliability Engineering. Когда специалисты SRE находят задачи, которые могут быть автоматизированы, они работают над тем, чтобы спроектировать решение, предотвращающее этот труд в будущем. Хотя минимизация труда важна, реально от него невозможно уйти полностью. Google стремится гарантировать, что, по крайней мере, 50% времени каждого специалиста SRE тратится на инженерные проекты, и эти специалисты индивидуально сообщают о своих трудностях в ежеквартальных обследованиях для оперативного выявления перегруженных команд. Как говорится, труд не всегда плох. Предсказуемые, повторяющиеся задачи отлично подходят для адаптации нового члена команды, порождают чувство выполненного долга и удовлетворения с низким риском и стрессом. Однако в долгосрочной перспективе такие трудозатраты быстро перевешивают преимущества и могут привести к стагнации.

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

Бюджеты на труд и труд тесно связаны с ключевыми тезисами DevOps “измерить все” и “убрать организационные барьеры”.

1. Customer Reliability Engineering (CRE)

Завершающий принцип SRE – Customer Reliability Engineering (CRE). Основной замысел CRE  – научить практикам SRE клиентов и потребителей услуг.

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

Таким образом, в 2016 году была запущена программа CRE, чтобы повысить надежность наших клиентов Google Cloud Platform (GCP), а также средство предоставления Google SRE непосредственно для изменений, с которыми сталкиваются клиенты. Программа CRE направлена на снижение беспокойства клиентов, обучая их принципам SRE и помогая им принять практики SRE.

CRE согласуется с такими основами DevOps, как “устранение организационных барьеров”, активизируя сотрудничество внутри организации, а также тесно связана с концепциями “принятия отказа как нормы” и “измерения всего”, создавая общую ответственность среди всех заинтересованных сторон в форме общих SLO.

Автор Сет Варго (Seth Vargo), SRE vs. DevOps: competing standards or close friends?