Если вы знаете, что такое Site Reliability Engineering, вам может быть интересно, как эти практики связаны с DevOps. Важно сразу оговориться, что мы не ставим между ними слово «против». Хотя у этих подходов есть некоторые отличия в том, как лучше делать и быстрее доставлять программное обеспечение. В этом посте разберём каждый подход и выясним, чем отличаются DevOps и SRE. Вы заметите, что у подхода SRE есть своё мнение по поводу запуска производственных систем, в то время как DevOps больше фокусируется на людях, процессах и инструментах — именно в этом порядке.

Давайте начнем с того, что такое DevOps и SRE.

Что такое DevOps?

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

DevOps — это [] набор культурных норм и технологических практик, который [обеспечивает] быстрый поток запланированной работы, в том числе от разработки, через тестирование к эксплуатации, сохраняя при этом надежность, работу и безопасность мирового уровня. DevOps — это не то, что вы делаете, а то, каковы ваши результаты.

Таким образом, DevOps — это в основном культурный сдвиг внутри организации, а не группы, человека или должности. В DevOps важны результаты на финишной прямой. "Что" и "как" — не важно. Именно поэтому в концепции DevOps CALMS излагается набор принципов, которые следует учитывать при каждой инициативе DevOps, и начинается всё с культуры.

Теперь давайте поговорим об SRE.

Что такое SRE?

SRE расшифровывается как Site Reliability Engineering — проектирование надежности сайта. Этот термин придумали в Google. В 2016 году инженеры Google написали книгу, в которой объяснили, как они запускают и эксплуатируют свои системы в производственной среде. Затем они написали вторую книгу о практических способах реализации SRE. Обе книги сейчас доступны бесплатно.

Определение SRE от Google довольно простое:

SRE — это то, что происходит, когда вы просите инженера-программиста спроектировать операционную группу.

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

Теперь давайте подробно рассмотрим, чем SRE отличается от DevOps.

Устранение разрозненности в организации

Движение DevOps появилось, чтобы устранить разобщённость между разработчиками и операторами. Вот в чём она проявляется: разработчики хотят развернуть фичи, которые они только что написали и желательно как можно скорее, а специалисты по эксплуатации тянут с развертыванием, чтобы система не упала. Как DevOps решает эту проблему? Помимо фреймворка CALMS (Collaboration, Automation, Lean, Measurement, Sharing), существует также концепция Трех способов DevOps. Они направлены на устранение разобщенности между разработчиками и операторами. Подробно об этом можно прочитать в руководстве DevOps. Там также есть несколько идей по поводу их применения.

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

1. Измерение успешной реализации

DevOps в основном сфокусирован на том, насколько быстро и часто происходят развертывания и как часто они идут не так, как должны. Основные метрики: 

• количество развертываний, 

• время от коммита кода до релиза,

• количество неудачных развертываний,

• количество времени на восстановление после неудачи. 

SRE также ориентируется на эти метрики, но больше фокусируется на надёжности. Для SRE основными являются цели:

• уровень обслуживания (SLO),

• показатель уровня обслуживания (SLI),

• соглашение об уровне обслуживания (SLA).

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

2. Применение практики CI/CD

DevOps — активный сторонник автоматизации. В DevOps идея состоит в том, чтобы максимально автоматизировать и сделать релизы расслабленно. Большинство действий начинается после того, как разработчик закоммитил код. При этом многие эти действия можно и нужно автоматизировать. Например, можно автоматизировать процесс сборки приложения после интеграции кода всех сотрудников на машине. Или вы можете автоматизировать процесс развёртывания изменений в приложении, если он одинаковый каждый раз. DevOps использует CI/CD для повышения скорости и качества работы системы.

SRE использует CI/CD по другой причине — чтобы снизить цену отказа. SRE тоже не любит все утомительные и повторяющиеся задачи, такие как развертывание, перезапуск приложений или резервное копирование. По этой причине SRE старается тратить на это не более 50% времени, а в остальное время работать над оптимизацией труда. SRE использует те же методы, что и DevOps, такие, как канареечные релизы, blue/green деплой и Iac — инфраструктура как код. Но SRE делает это для других, более привлекательных целей, таких как развитие архитектуры или внедрение новых технологий.

3. Принятие неудач

DevOps воспитывает безупречную культуру и каждый раз, когда что-то идет не так, это рассматривается как возможность для обучения. Признание того, что неудачи будут продолжаться — первый шаг. Вместо того чтобы прилагать слишком много усилий для того, чтобы сделать системы полностью отказоустойчивыми, культура DevOps находит способы терпеть ошибки. Netflix является самым известным сторонником культуры Chaos Engeeneering. Отключать часть системы — это обычная практика, которая помогает держаться в тонусе и действовать правильно, если случится реальный сбой. Кроме того, если где-либо выходит из строя один набор серверов, Netflix автоматически подрубает другие серверы в другом месте. Они практикуют это прямо в производственной среде.

SRE практикует postmortem (вскрытие, разбор инцидентов) каждый раз, когда в системе происходит сбой, при этом никого не наказывает. Идея состоит в том, чтобы определить причину ошибки, а затем найти способы избежать её повторения. У SRE тоже допускаются отказы, но их считают. Это называется «Error budget», то есть бюджет ошибок. После определения SLI, SLO и SLA SRE определяет допустимый уровень отказов (бюджет), поскольку стопроцентная доступность обходится дорого. А в некоторых случаях это невозможно.

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

4. DevOps и SRE не конкурируют друг с другом

Мне очень нравится, как Google связывает SRE с DevOps, используя следующую фразу:

class SRE implements interface DevOps

(класс SRE реализует интерфейс DevOps)

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

Основное отличие заключается в том, что DevOps — это культура, которая в широком смысле определяет способ ведения дел. Может быть, поэтому существует слишком много определений DevOps и множество кейсов от компаний разного размера и отрасли. А у SRE есть свой взгляд на то, как вести дела. Оно появилось после того, как Google рассказал, как они запускают системы в производственной среде.

Добавим свои две копейки. Изучите обе методологии и выберите методы и принципы, которые сегодня работают в вашей организации. Что будет завтра? Завтра всё изменится и, возможно, придется перенять новые принципы от DevOps и SRE.

Если вы хотите узнать больше об SRE, приходите на курсы в Слёрм:
???? SRE: data-driven подход к управлению надежностью систем. Старт — 22 августа.
???? SRE: Observability. Старт — 24 июля.

Ознакомиться с программой и записаться на курс можно на нашем сайте.