SRE в контексте
Прежде чем мы рассмотрим некоторые рекомендации, связанные с обеспечением надежности информационных систем (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, давайте перейдем вправо к некоторым из его основных принципов.