SRE в контексте

  • 10 мин

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

Журнал

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

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

DevOps и SRE

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

Дополнительные сведения о DevOps см. в центре ресурсов DevOps.

Примечание.

Важно отметить, что 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, давайте перейдем вправо к некоторым из его основных принципов.