SRE в контексте

Завершено

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

Журнал

Недолгая история SRE началась в 2003 году в Google. Бен Трейнор, теперь Трейнор Слосс, возглавил рабочую группу Google (в то время состоящую всего из семи инженеров) и создал концепцию, которую он сформулировал следующим образом: "что происходит, когда вы просите разработчика ПО решить задачу по эксплуатации". История этой концепции помогает понять, почему специалисты по эксплуатации воспринимают SRE как программную инженерию. Этот подход строится на основе таких принципов и инструментов, как программирование и системы управления версиями. Исходная и текущая реализация Google SRE хорошо описывается в двух книгах, опубликованных издательством O'Reilly (см. модуль "Начало работы").

Некоторые сотрудники уходили из Google, другие все больше рассказывали о своих методах, и концепция SRE начала распространяться в других организациях в отрасли. Эти организации принимали и адаптировали принципы и методы SRE к своим системам. В результате появились различные варианты реализации SRE.

DevOps и SRE

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

Много полезных сведений о DevOps см. в разделе https://docs.microsoft.com/azure/devops/learn/.

Примечание

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

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

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

DevOps и SRE объединяет общая любовь к мониторингу и автоматизации (но, возможно, по разным причинам). Это одна из причин, почему часто бывает проще внедрить принципы и рекомендации SRE в организацию с существующей методикой DevOps. Но действовать нужно осторожно и обдуманно. И, разумеется, постепенно и без спешки.

Предупреждение

Нельзя просто изменить названия должностей — такая стратегия почти никогда не срабатывает. Так вы не сможете использовать преимущества SRE. Более разумные подходы вы найдете в разделе "Начало работы" в этом модуле.

Заключение

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

Теперь, когда мы познакомились с историей SRE, давайте перейдем к основным принципам этого подхода.

Проверьте свои знания

1.

Учитывая происхождение SRE, какая дисциплина оказала на него наиболее сильное влияние?

2.

Что было раньше, DevOps или SRE?

3.

Является ли SRE следующим эволюционным этапом после DevOps?

4.

Какие два основных принципа являются общими для DevOps и SRE?