В чем разница между традиционной моделью разработки и эксплуатации и проектированием надежности сайта?

15

«SRE - это то, что происходит, когда вы просите инженера-программиста создать операционную группу». - Надежность сайта Инжиниринг

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

У нас была пара вопросов, которые определяли различия между Sys. Администраторы, инженеры DevOps и инженеры по надежности сайтов:

Однако ни один из этих вопросов или их ответы не описывают различия между системным администратором и инженером по надежности сайта .

В более широком смысле: каковы основные различия между практикой Google по разработке надежности сайтов и традиционными функциями разработки и эксплуатации в бизнесе.

Ричард Слейтер
источник

Ответы:

7

К счастью, поскольку 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 - это просто текущее воплощение операций, использующее новые инструменты (привет, контейнеры!), И, поскольку сетевые программы продолжают становиться все более крупными и важными, повышенное внимание уделяется методам, которые позволяют одному инженеру делать больше .

Бойкот SE для Моники Челлио
источник
Еще несколько интересных статей для чтения (с которыми я не обязательно согласен): charity.wtf/2016/06/30/… , charity.wtf/2016/05/31/wtf-is-operations-serverless , susanjfowler. ru / blog /
бойкот SE для Моники