К счастью, поскольку Site Reliability Engineering разработала внутренне в Google и только недавно начала проникать в более широкое сообщество, она довольно четко определена. Что не является , однако, веб-операциями (или «системным администрированием» - в качестве примера отсутствия ясности, вы используете оба в своем вопросе). Трудно обсуждать различия между двумя вещами, когда вы не совсем уверены, что из них является.
Но я любитель приключений, поэтому я попробую.
В очень традиционных магазинах разработчики и системные администраторы очень изолированы друг от друга. Разработчики создают приложение, а затем считают свою работу завершенной, как только их код будет зафиксирован. Системные администраторы берут артефакты сборки (которые могут быть просто кодом, если это интерпретируемый язык) и развертывают его на рабочих серверах. Задача сисадминов заключается в том, чтобы приложение работало гладко и в целом управляло производственной средой. Однако часто проблемы с производительностью возникают из-за проблем архитектуры в приложении; Системные администраторы не обладают знаниями в области программирования, чтобы знать, что делает приложение, а разработчики не знают, как приложение работает в рабочей топологии с производственным трафиком, поэтому никто не может решить эту проблему самостоятельно.
Кроме того, разработчики, как правило, судят о том, как быстро они могут создавать новые функции, в то время как системные администраторы судят о том, как редко приложение прерывает работу. Поскольку изменения являются одной из основных причин разрыва, это ставит два департамента в противоречие друг с другом - давняя конкуренция, которая наносит ущерб бизнесу и вовлеченным людям.
В какой-то момент некоторые компании, ориентированные на разработчиков, были настолько раздражены этим , что начали практиковать «NoOps» - они ликвидировали свои операционные отделы и предполагаемые препятствия, которые пришли с ними. В действительности это означало, что разработчики взяли на себя рабочие роли, но сохранили свои старые названия.
В дискуссии вокруг NoOps Джон Аллспо, тогда вице-президент по техническим операциям в Etsy и редактор уважаемой книги веб-операций , определил роли в Etsy следующим образом:
Etsy Operations несет ответственность за:
- Отвечая на перебои, принимает по вызову
- Системы оповещения о пороге, дизайн
- Архитектурный дизайн и обзор
- Сборка метрик здания
- Конфигурация приложения
- Строительство инфраструктуры / управление
Etsy Development отвечает за:
- Отвечая на перебои, принимает по вызову
- Системы оповещения о пороге, дизайн
- Архитектурный дизайн и обзор
- Сборка метрик здания
- Конфигурация приложения
- Доставка общедоступного кода
Ни один из этих списков не является исчерпывающим, я уверен, что чего-то там не хватает. В то время как Etsy Ops внесла изменения в производственные приложения, они немногочисленны, но реальны (а иногда и достаточно глубоки). Пока Etsy Dev вносит изменения в Chef, их мало, но они настоящие. Если так много совпадений в обязанностях, почему вы спросите? Доменная экспертиза и фон. Не многие разработчики имеют глубокие знания о том, как работает медленный запуск TCP, но Ops делает. Не многие Ops обладают всесторонним знанием алгоритмов сортировки или релевантности, но Dev знает. Девс имеет многолетний опыт быстрого прогнозирования использования ресурсов с приемлемой точностью. Dev может не знать о плюсах и минусах распределения параметров рабочей нагрузки по всем уровням 1-7, может быть, только в 7, как делает Ops. Моделирование отношений между сущностями может быть естественным для разработчика, а может и не быть выполненным. В конце концов, они оба находят решения для различных форм византийских сценариев сбоев и моделей устойчивости на всех уровнях и уровнях.
В его мире разработчики и оперативные инженеры имели очень похожие навыки и обязанности высокого уровня; где они отличались, было в их экспертизе. Их различные специальности побуждали их работать вместе для решения проблем, а их общие навыки базового уровня дали им язык, на котором это можно сделать.
Как правило, это определение веб-операций, которое я использую в большинстве случаев. Так что это тот, с которым мы собираемся продолжить.
Итак, что же такое Надежность сайта?
Книга Google SRE открывается с определением SRE ..., а затем еще одним ..., а затем проводит главу, продолжающую определять роль, и целую книгу, охватывающую специфику. Даже когда разработано в одной организации, кажется, что трудно свести работу к одному согласованному определению.
Для начала нам нужно вернуться к 2003 году, когда Бен Трейнор присоединился к Google и основал то, что стало первой командой по разработке надежности сайта. Напомним, что несколько абзацев назад мы были в начале 2010-х годов; но в 2003 году индустрия все еще была настроена на разделение системного администратора и разработчика как естественный путь. Поэтому, когда Бен говорит, что SRE - это то, что произошло бы, если бы инженер-программист создал операционную команду, это было гораздо более радикальное слияние двух миров, чем кажется сейчас.
Определение, данное в предисловии, подчеркивает каждое из трех слов в отдельности:
- Инжиниринг - использование компьютерных наук и инженерных концепций для решения задач
- Надежность - стремление сделать системы более масштабируемыми, надежными и эффективными
- Сервис - последующее развитие «сайта», подчеркивающее, что SRE отвечают за сетевые сервисы
В вводной главе перечислены принципы проектирования надежности сайта:
- Обеспечение длительного внимания к проектированию - принятие упреждающих действий, чтобы избежать частых страниц и других «трудов»
- Обеспечение максимальной скорости изменений без нарушения SLO сервиса - предмет, который может легко иметь свой собственный ответ из нескольких сотен слов, но в целом он помогает разработчикам вносить изменения, если они не вызывают слишком много проблем
- Мониторинг - автоматические оповещения, когда что-то идет не так
- Аварийное реагирование - исправление вещей, когда они сломаны
- Управление изменениями
- Планирование мощности
- Provisioning
- Эффективность и производительность - гарантируя , что сервис выполняет на ожидаемом уровне - узких мест мешает пользователям, но избыток производственных мощностей стоит денег
Я бы классифицировал Надежность сайта как специализированное подразделение современных веб-операций. Организация SRE сосредоточена на автоматизации всего , до такой степени, что это рентабельно только в довольно крупных компаниях. Идеи, такие как бюджеты ошибок, могут работать только тогда, когда у вашей службы много запросов, в противном случае вы потеряете детализацию (для более мелкой службы конкретная ошибка может повлиять на 0-20% ваших запросов, в зависимости от минуты). Связанные области, такие как безопасность, отсутствуют в определении SRE, потому что компании, достаточно большие, чтобы иметь настоящие команды SRE, имеют выделенные группы для обеспечения безопасности.
Программа SRE, как определено Google, - это веб-операции, разработанные для конкретных потребностей Google и не обязательно применимые в других местах.
Тем не менее, проект «Надежность сайта» в последнее время расширяется в более широком использовании в промышленности. Моя текущая должность - SRE, хотя я работаю в гораздо более мелкой компании, и мое описание работы вполне соответствует определению Джона Олспоу в Etsy. Моя теория состоит в том, что мы продвигаемся через названия как сокращение для поддержки развития единственной области:
- Мы начинали как сисадмины .
- Затем, когда веб-сайты стали чем-то вроде «вещи», объявления о вакансиях стали ссылаться на инженеров веб-операций, чтобы отличить системных администраторов, которые специализировались на сети, от тех, кто также занимался ИТ-службой общего назначения.
- Затем DevOps должен был выделить тех, кому было удобно использовать программирование, чтобы уменьшить нагрузку на веб-операции.
- Но так как DevOps запутался из- за отсутствия четкого определения , мы приняли решение по обеспечению надежности сайта, чтобы указать, что мы ищем людей, которые поддерживают производственные услуги по вызову.
Так в чем же разница между системным администратором и SRE? Год, в который они получили свое звание. В чем разница между традиционными операциями и проектированием надежности сайта? SRE - это просто текущее воплощение операций, использующее новые инструменты (привет, контейнеры!), И, поскольку сетевые программы продолжают становиться все более крупными и важными, повышенное внимание уделяется методам, которые позволяют одному инженеру делать больше .