Site Reliability Engineering (SRE)

Зачем вам SRE

ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 Google о том, как удерживать надёжность работающего сервиса инженерными средствами. Определение автора практики короткое: это то, что получается, когда проектировать эксплуатационную команду поручают программисту4.

Разворачивается оно в конкретное требование: рутину не терпят, её автоматизируют; надёжность не обсуждают на словах, а задают числом; за сбоями следуют разборы без поиска виноватого.

Нужен, если у вас есть сервис, простой которого стоит денег, и разговор о надёжности до сих пор идёт в словах «должно работать хорошо».

Нужен, если дежурная смена тонет в ручных операциях и не успевает ничего улучшать.

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

Не нужен буквально, если у вас три сервера и два инженера. Практика выросла на масштабе6; из неё берут понятия, а не устройство команды.

Книги большие и открыты у владельца целиком, ссылка ниже; их текста здесь нет. Ниже — что внутри, какие понятия стоит забрать и где применение ломается.

Что внутри

Первоисточник — не стандарт с номером редакции, а серия из трёх книг владельца: собственно о практике надёжности, рабочая тетрадь с примерами внедрения и книга о построении безопасных и надёжных систем3.

Первая книга разбита на пять частей: введение, принципы, практики, управление и выводы7. Ядро — в принципах и практиках: допустимый риск, цели уровня обслуживанияЦель уровня обслуживанияЧисло, которым задают требуемую надёжность услуги: какая доля обращений должна отрабатывать успешно и достаточно быстро.Google. Site Reliability Engineering, глава о целях уровня обслуживания, вытеснение рутиныРутинаРучная повторяющаяся работа без долговременной ценности, которая растёт вместе с сервисом и поддаётся автоматизации.Google. Site Reliability Engineering, глава о вытеснении рутины, мониторинг, инженерия выпуска, простота, дежурство, реагирование на аварии, разбор после сбоя, тестирование надёжности7.

Вторая книга отвечает на вопрос «а как это внедрить у себя» и разбирает случаи сторонних компаний, а не только собственный опыт владельца6.

Про возраст практики стоит сказать точно, потому что в пересказах путают две даты. Сам владелец отсчитывает её от 2004 года, а автор в книге пишет о своём приходе в компанию в 2003-м5. Речь о разных событиях: приход человека и начало практики.

Ключевые понятия

Цель уровня обслуживания. Число, которым описывают требуемую надёжность: какая доля запросов должна отрабатывать успешно и быстро. Именно оно превращает разговор «работает плохо» в проверяемое утверждение7.

Бюджет ошибокБюджет ошибокРазрешённый объём сбоев за период — разница между стопроцентной надёжностью и поставленной целью уровня обслуживания.Google. Site Reliability Engineering, глава о допустимом риске. Обратная сторона этой цели: если целевая надёжность не сто процентов, разница — разрешённый объём сбоев за период. Практическая ценностьЦенностьПольза и выгода, которые сторона получает от услуги; величина субъективная.ITIL 4, книга ITIL Foundation в том, что бюджет снимает вечный спор между теми, кто хочет выпускать быстрее, и теми, кто отвечает за стабильность: пока бюджет не израсходован, выпускать можно; кончился — приоритетПриоритизацияВыбор задач, которыми займутся первыми, когда ресурсов не хватает на все.ITIL 4, практическое руководство по управлению инцидентами переходит к надёжности7.

Рутина. В этой практике у слова точное значение. Это не «работа, которая мне не нравится» и не любые скучные обязанности: рутина — ручная, повторяющаяся, автоматизируемая работа без долговременной ценности, растущая вместе с сервисом7. Административные дела вроде совещаний и целеполагания в неё не входят: это накладные расходы, другая категория.

ДежурствоДежурствоИнженерная функция: назначенный человек отвечает за реакцию на сбои в оговорённые часы, с посчитанной нагрузкой и правом на передышку.Google. Site Reliability Engineering, главы о дежурстве и о работе с прерываниями. Отдельная глава книги и отдельная тема управления: сколько человек в смене, как их готовят, что делать с потоком прерываний7. Дежурство здесь — инженерная функция с нагрузкой, которую считают, а не «кто-то же должен смотреть в телефон».

Разбор после сбояРазбор после сбояПисьменный разбор произошедшего отказа без поиска виноватого: что случилось, почему и что изменить, чтобы не повторилось.Google. Site Reliability Engineering, глава о культуре разборов. Письменный разбор без поиска виноватого, задача которого — вытащить из отказа знание, а не наказание7. В приложении к книге владелец приводит пример такого разбора целиком.

Что покрывает — и чего не покрывает

Вопрос задан каждой практике справочника: описывает ли её серия книг. Клетка закрашена только там, где есть конкретная глава или книга серии7.

Картина честная: практика густо покрывает эксплуатацию и надёжность и почти не касается остального. Денег, поставщиков, каталога услуг, портфеля и организационных изменений в ней нет.

Отдельно про соглашения об уровне услугСоглашение об уровне услугЗаписанная договорённость поставщика и заказчика: что даёт услуга, когда доступна и как быстро её восстановят.ITIL 4: практическое руководство Service Level Management и книга ITIL Foundation, 5.2.15.1; ГОСТ Р ИСО/МЭК 20000-1-2021, пункты 3.2.16, 3.2.20, 3.2.21, 7.5.4, 8.3.2–8.3.4; FitSM-0, FitSM-1 (PR2), FitSM-2 (PR2), шаблон и образец SLA из FitSM-4; MOF 4.0, глоссарий; itSMF, «Введение в ИТ Сервис-менеджмент», 2003; Ami Nahari, «Secrets of Service Level Management», TSO, 2013; Молоткова, Сахаров, «Качество услуг ИТ-аутсорсинга», 2008; «Аутсорсинг в стратегии современного бизнеса», 2019; альманах itSMF России, 2015; «Свободный ITIL» Елхимова; Брукс, «Метрики для управления ИТ-услугами». Цели уровня обслуживания — внутренний измеритель надёжности, а не договор с заказчиком: юридическую сторону, санкции и переговоры практика не рассматривает.

Чем отличается от соседей

От сводов практик управления услугами. Те описывают, как устроена работа службы: процессы, роли, согласования. Эта практика описывает, как инженер удерживает надёжность конкретного сервиса, и вместо процессов предлагает числа и бюджеты.

От подхода к совместной работе разработки и эксплуатации. Тот задаёт направление и не имеет ни владельца, ни текста. Здесь есть и владелец, и открытые книги: это один из способов ответить на вопрос «а как именно».

От программы измерения поставки. Та меряет поток изменений до продуктивной среды; эта отвечает за то, что происходит с сервисом после. Пересекаются в одной точке — восстановлении после сбоя.

Сколько стоит

Ничего, если читать онлайн: все три книги открыты на сайте владельца под свободной лицензией с указанием авторства, без права коммерческого использования и переработки1. Бумажные и электронные издания продаются отдельно2.

Для внутреннего обучения это значит: цитировать и разбирать на занятиях можно, включать куски в платный курс — нет.

Сертификация

Сертификации по этой практике у владельца нет. Ближайшее, что есть, — облачный экзамен Google, где применение практик надёжности заявлено как одна из проверяемых компетенций; экзамен длится два часа, взнос — 200 долларов8. Это сертификация по облаку, а не по практике.

Сторонние организации сертификаты по надёжности выдают — например, линейка одного из коммерческих институтов9. Правообладателем книг эти программы не выпускаются, и понимать их стоит именно так.

В России

ГОСТ-аналога нет: поиск по базе Росстандарта не даёт ни одного документа ни по короткому названию практики, ни по полному10. Русскоязычного издания книг у владельца тоже нет — на сайте только английский2.

Где ломается применение

Ставят цель надёжности «сто процентов». Тогда бюджета ошибок не существует, и вся конструкция рассыпается: выпускать нельзя никогда, а любой сбой — чрезвычайное происшествие.

Переименовывают эксплуатацию в надёжность. Смена вывески без права команды останавливать выпуски и без времени на инженерную работу даёт прежнюю дежурную смену с новым названием.

Считают рутиной всё скучное. У понятия точное определение7; подмена превращает разговор об автоматизации в жалобы.

Берут дежурство без расчёта нагрузки. Практика прямо занимается тем, сколько прерываний выдерживает человек7; игнорирование этого даёт выгорание за квартал.

Ждут, что цели уровня обслуживания заменят соглашение с заказчиком. Это разные документы с разным назначением.

С чего начать

1. Возьмите один сервис и сформулируйте для него цель надёжности числом: какая доля запросов и за какое время. Одна строка.
2. Посчитайте по ней бюджет ошибок за квартал и договоритесь заранее, что происходит при его исчерпании.
3. Заведите разбор после сбоя без поиска виноватого и проведите его хотя бы один раз до конца — вместе с решениями и сроками.

Что читать дальше

Три свода рядом: подход к совместной работе разработки и эксплуатации, программа измерения поставки ПО и ITIL, с которым эту практику чаще всего сравнивают.