9.1 Инженерия надёжности сайтов

Обзор и мотивация

Инженерия надёжности сайтов (SRE) применяет практики программной инженерии к эксплуатации производственных систем. Вместо того чтобы воспринимать эксплуатацию как ручную работу по заявкам, отделённую от разработки, SRE воспринимает надёжность как инженерную задачу, которую вы решаете кодом, измерением и ясными целями обслуживания. Основная идея, популяризированная Google, но теперь широко распространённая, проста: люди, поддерживающие системы в работе, должны тратить большую часть времени на построение автоматизации и улучшение систем, а не на тушение одних и тех же отказов вручную снова и снова.

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

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

См. также: глава 9.2 (наблюдаемость и мониторинг), глава 9.3 (управление инцидентами) и глава 3.5 (масштабируемость, производительность и устойчивость).

Ключевые принципы

Надёжность важнейшая функция. Система, которая не работает, бесполезна, сколько бы у неё ни было функций, но идеальная надёжность недостижима и не стоит своей цены.
Определяйте надёжность измеримыми целями. Показатели (SLI), цели (SLO) и соглашения (SLA) уровня обслуживания превращают расплывчатые ожидания в числа, о которых все могут договориться.
100 процентов неверная цель. Пользователи не отличают очень надёжную систему от идеально надёжной, поэтому стремитесь к «достаточно надёжно» и тратьте оставшийся бюджет на скорость.
Бюджеты ошибок выравнивают стимулы. Разрыв между SLO и 100 процентами это бюджет риска, который делят разработчики и операторы, заменяя споры арифметикой.
Рутина враг. Повторяющуюся ручную автоматизируемую эксплуатационную работу следует измерять, ограничивать и систематически устранять.
Автоматизируйте намеренно. Автоматизация то, как малая команда эксплуатирует большую систему; вложение в неё первоклассная инженерная деятельность.
Обучение без обвинений. Отказы воспринимаются как возможности улучшить системы и процессы, а не наказать людей.

Компромиссы: плюсы и минусы

Решение	Плюсы	Минусы
Строгие SLO (больше девяток)	Выше доверие пользователей, соответствует контрактам	Растущая цена, медленнее поставка функций
Мягкие SLO (меньше девяток)	Быстрее отгрузка, ниже цена	Риск оттока пользователей и штрафов по SLA
Централизованная SRE	Согласованность, общая экспертиза	Узкие места, дистанция от продукта
Встроенная SRE	Тесное сотрудничество, контекст	Несогласованность, трудно комплектовать
Тяжёлые вложения в автоматизацию	Масштабируется, сокращает рутину	Цена заранее, автоматизация сама может отказать

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

Вопросы для обсуждения с командой

Какой именно SLI отражает то, что пользователи на самом деле чувствуют, и можете ли вы показать, что это не метрика тщеславия? Выберите неверный показатель, и каждая панель выглядит зелёной, пока пользователи страдают, что и есть ловушка SLI тщеславия, о которой предупреждает эта глава. Принесите на обсуждение реальные данные: измеряйте тот же пользовательский маршрут по реальному пути запроса (вход в панель, оформление заказа до подтверждения), а не процессор сервера или проверку здоровья бэкенда. Для большой команды один плохой SLI распространяется: десятки сервисов наследуют его, оповещения срабатывают не на то, и бюджет ошибок перестаёт что-либо значить. В корпоративной и государственной среде, где SLA несёт возвраты или влияние на граждан, ваш SLI это свидетельство, которое вы защищаете перед аудиторами, так что оно должно прослеживаться прямо до видимого пользователю успеха. Если вы не можете провести линию от числа к опыту пользователя, замените число.
Что сервис должен доказать, прежде чем ваша команда SRE возьмёт его на дежурство, и кто говорит «нет»? Без планки готовности к производству центральная команда SRE становится свалкой для каждого нестабильного сервиса и тонет в чужом техническом долге. Запишите критерии входа: SLO с владельцем, рабочие ранбуки, действенные оповещения, запас мощности и продемонстрированный путь развёртывания и отката. Для большой организации эта модель взаимодействия не даёт команде надёжности стать узким местом, замедляющим всех. В регулируемых условиях рецензия готовности служит также средством контроля, которое можно показать надзорным органам. Решите, у кого полномочия отказать во включении, потому что планка, которую никто не принуждает, не планка, и ответ определяет, масштабируется ли SRE или рушится под унаследованной болью.
За какое время вы заранее подготавливаете мощность для своего наибольшего предсказуемого пика и знаете ли вы свой срок подготовки? Допущение, что облачная эластичность мгновенна и бесконечна, приглашает нехватку именно на тех пиках, что важнее всего, а эти пики (налоговые сроки, окна регистрации, распродажи) моменты, когда отказ наиболее виден и наиболее дорог. Принесите числа: историческую пиковую нагрузку, прогноз роста, кратность, до которой вы нагрузочно тестируете, и реальный срок получения большой зарезервированной мощности или специализированных экземпляров. Для государственных сезонных сервисов пик может в несколько раз превышать обычную нагрузку и политически не допускает промаха, поэтому подготовка за недели вперёд побеждает надежду, что автомасштабирование успеет. Ответ должен задать конкретный календарь: когда вы нагрузочно тестируете, когда фиксируете мощность и кто владеет решением «идти».
Когда ваш бюджет ошибок кончается, что на самом деле происходит и у кого есть право это принуждать? Бюджет ошибок, по которому никогда не действуют при исчерпании, просто декорация, а момент сбоя худшее время для согласования политики с нуля. Конкурирующее давление реально: обещанный запуск, срок по выручке или публичное объявление будут сильно давить против заморозки рискованных изменений. Принесите данные скорости сгорания, заранее согласованный текст политики и запись нескольких последних случаев нарушения бюджета, чтобы увидеть, действительно ли заморозка держалась. Для большой команды бюджет выравнивает стимулы, только если каждая группа наследует одно и то же принуждение, поэтому решите заранее, кто подписывает отмену и как это исключение журналируется. В корпоративной и государственной среде, где SLA несёт штрафы или влияние на граждан, след отмен становится артефактом аудита, поэтому назовите подотчётного владельца сейчас, а не импровизируйте, когда бюджета уже нет.
Какая доля недели вашей команды SRE рутина и это измеренное число или ощущение? Рутина, которую никто не считает, тихо расширяется, пока команда не тратит всё время на тушение пожаров и ничего на долговечные улучшения, а это именно ловушка, от которой SRE призвана уйти. Напряжение в том, что измерение рутины само работа, а инженеры под давлением сроков сопротивляются учёту того, куда уходят их часы. Принесите честную выборку: неделя-две отслеженного времени по общему определению рутины (ручная, повторяющаяся, автоматизируемая, тактическая и растущая вместе с системой) плюс очередь проектов автоматизации, ранжированная по частоте, умноженной на цену. Для большой организации потолок в 50 процентов значит что-то, только если о нём сообщают и его защищают команда за командой, поэтому договоритесь, кто рецензирует число и что происходит, когда команда его нарушает. В регулируемых и государственных контекстах ограничение рутины освобождает дефицитных специалистов для работы по контролю и аудиту, которую вытесняют ручные операции, поэтому воспринимайте цифру рутины как сигнал мощности, который должно видеть руководство.
Какую организационную модель SRE вы ведёте и какие свидетельства сказали бы, что она перестала подходить? Централизованная команда даёт согласованность и общие инструменты, но может стать узким местом; встроенная модель даёт контекст, но дрейфует в несогласованность; гибрид, на котором останавливается большинство больших организаций, нуждается в ясной модели взаимодействия, иначе наследует слабости обоих. Принесите сигналы, выявляющие напряжение: как долго сервисы ждут поддержки SRE, насколько практика надёжности различается между командами и чувствуют ли встроенные инженеры оторванность от профессионального сообщества. Правильный ответ зависит от размера компании, инженерной зрелости и однородности ваших сервисов, поэтому пересматривайте его по мере их изменения, а не воспринимайте первый выбор как постоянный. Для корпоративного или государственного органа со многими командами и строгими требованиями единообразия центральная группа стандартов и платформы плюс встроенные инженеры надёжности обычно уравновешивают согласованность и локальный контекст, но только если модель взаимодействия и планка готовности к производству записаны и кто-то ими владеет.

Взгляд по секторам

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

Малый бизнес. Без специалиста для ведения надёжности воспринимайте её как дисциплину, в которую вы входите через вашу платформу: размещённый мониторинг доступности, управляемые базы данных и инструменты страницы статуса вместо заказного стека. Задайте один-два SLO, привязанных к транзакциям, что оплачивают счета, и честно решите, какие отказы стоили бы вам клиента. Покупайте устойчивость там, где это дешевле построения, и держите эксплуатационное бремя достаточно лёгким, чтобы ваши имеющиеся инженеры могли нести его вместе с работой над функциями.

Крупная организация. Проблема согласованность по многим командам: общий словарь SLO, общая политика бюджета ошибок и планка готовности к производству, которую проходит каждый сервис, прежде чем SRE возьмёт его на дежурство. Центральная группа платформы и стандартов плюс встроенные инженеры надёжности держат практику единообразной, не становясь узким местом, а управление требует, чтобы бюджеты ошибок сообщались и принуждались везде одинаково. Бюджетируйте инфраструктуру наблюдаемости и вложения в автоматизацию явно и управляйте надёжностью как портфелем с метриками, которые видит руководство.

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

Примеры

Стартап. Стартап из десяти человек ведёт единое веб-приложение и делит дежурство между тремя инженерами. Вместо построения команды надёжности, которую он не может себе позволить, он выбирает один осмысленный SLO: 99,5 процента успеха на потоке от входа до панели, измеряемый по реальным пользовательским запросам. Когда ненадёжный сторонний API начинает съедать этот бюджет, команда тратит пятницу на добавление повтора и кэша вместо отгрузки следующей функции, затем пишет двухабзацный разбор в общем документе, чтобы исправление закрепилось.

Крупная организация. Глобальная платёжная компания задаёт SLO доступности 99,99 процента для своего API транзакций, что даёт бюджет ошибок примерно четыре минуты в месяц. Центральная платформенная команда SRE владеет общей наблюдаемостью, инструментами инцидентов и политикой бюджета ошибок, тогда как встроенные инженеры надёжности работают внутри каждой продуктовой группы. Когда новая функция обнаружения мошенничества сжигает половину месячного бюджета за неделю, заранее согласованная политика замораживает некритичные выпуски, пока работа над надёжностью не восстановит запас. Руководители принимают это без споров, потому что ратифицировали политику заранее.

Государственный сектор. Национальное налоговое ведомство ведёт сервис онлайн-подачи с экстремальными сезонными пиками вокруг годового срока. Его команда SRE прогнозирует спрос по прошлым годам плюс изменения населения и политики, нагрузочно тестирует до нескольких кратностей обычного пика и заранее подготавливает мощность за недели. Публичные SLO доступности и задержки страниц выводятся на панель статуса. Культура разборов без обвинений (рецензии отказов для улучшения систем, а не назначения личной вины) и мандат на автоматизацию неуклонно сокращают ручные вмешательства, когда-то доминировавшие в сезон подач, освобождая сотрудников улучшать систему, а не выхаживать её через каждый срок.

Бизнес-обоснование: мотивы, ROI и TCO

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

Цена принятия реальна. SRE нужны квалифицированные инженеры, инфраструктура наблюдаемости и культурные изменения, конкурирующие со сроками по функциям. Но цена непринятия выше в масштабе: неограниченный операционный штат, непредсказуемые сбои, выгорание и уход сотрудников и репутационный ущерб, трудно измеримый, но легко претерпеваемый. Чтобы обосновать перед руководством, формулируйте SRE как управление рисками с измеримой отдачей. Представьте нынешнюю цену инцидентов и ручных операций, цели SLO, привязанные к бизнес-обязательствам, и прогнозируемое сокращение обоих. Закрепите довод на бюджете ошибок как инструменте управления, дающем руководству рычаг над компромиссом надёжности и скорости.

Антипаттерны и ловушки

SRE как переименованная эксплуатация. Переименование команды эксплуатации без инженерного времени, мандата на автоматизацию и полномочий возражать ничего не меняет.
Стремление к 100 процентам. Погоня за идеальной надёжностью тратит деньги и блокирует поставку ради выигрыша, которого пользователи не воспринимают.
SLI тщеславия. Измерение процессора сервера вместо видимого пользователю успеха даёт числа, выглядящие хорошо, пока пользователи страдают.
Бюджеты ошибок без зубов. Бюджет, который никогда не принуждается при исчерпании, просто декорация.
Рутина без измерения. Если вы не отслеживаете рутину, она молча пожирает команду, пока не перестанет случаться работа по улучшению.
SRE как свалка. Централизованные команды, наследующие каждый нестабильный сервис без планки готовности, тонут в чужом техническом долге.
Игнорирование сроков подготовки мощности. Допущение, что облачная эластичность мгновенна и бесконечна, приглашает нехватку на самых важных пиках.

Модель зрелости

Уровень 1, Начальный. Эксплуатация ручная и реактивная. Формальных SLO нет, надёжность вопрос мнения, и те же инциденты повторяются, пока доминирует тушение пожаров. Любая автоматизация случайна, и никто не владеет надёжностью как инженерной заботой.

Уровень 2, Развитие. У некоторых сервисов есть базовые SLI и SLO и зачаточный мониторинг и оповещение, но практика сильно различается между командами. Рутина признана, но не измеряется, автоматизация стихийна, а разборы случаются непоследовательно. Надёжность улучшается в карманах, где её продвигают отдельные люди, а не потому, что этого требует организация.

Уровень 3, Стандартизация. SLI, SLO и политика бюджета ошибок документированы и применяются последовательно по командам. Рутина определена и отслеживается, планирование мощности рутинно, существует модель взаимодействия SRE с рецензиями готовности к производству, а автоматизация финансируемое направление работы, а не побочный проект. Практика надёжности записана и принуждается по организации.

Уровень 4, Управление. Программа надёжности измеряется и контролируется данными относительно базовых значений. Скорость сгорания бюджета ошибок, доля рутины, достижение SLO, среднее время восстановления и сроки подготовки отслеживаются как метрики, рецензируются по фиксированному ритму и используются, чтобы держать команды на целях. Нарушения бюджета запускают согласованную заморозку, мощность прогнозируется по моделям спроса, а каждое решение «пускать или нет» опирается на свидетельства, а не мнение.

Уровень 5, Оркестрация. Инженерия надёжности интегрирована по организации и непрерывно улучшается. Политика бюджета ошибок автоматизирована и соблюдается везде, большинство операций самообслуживаются, мощность подготавливается упреждающе, а данные надёжности двигают адаптивные компромиссы между скоростью и стабильностью. Организация регулярно пересматривает объём SLO, выводит рутину и перебалансирует вложения в надёжность по мере сдвигов бизнеса и картины рисков.

Идеи для обсуждения

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

Главные выводы

SRE применяет программную инженерию к эксплуатации, воспринимая надёжность как измеримую финансируемую функцию.
SLI, SLO и SLA превращают надёжность из мнения в согласованные числа; держите SLO строже SLA.
Бюджет ошибок выравнивает разработчиков и операторов, делая компромисс надёжности и скорости явным и заранее согласованным.
Измеряйте и ограничивайте рутину и воспринимайте автоматизацию как первоклассную инженерию, чтобы эксплуатация масштабировалась сублинейно.
Планируйте мощность по прогнозам спроса и уважайте сроки подготовки, особенно для сезонных пиков.
Выбирайте организационную модель SRE намеренно и определите ясную планку взаимодействия и готовности к производству.

Источники и дополнительное чтение

Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne, The Site Reliability Workbook: Practical Ways to Implement SRE
David N. Blank-Edelman (editor), Seeking SRE: Conversations About Running Production Systems at Scale
Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan, The Practice of Cloud System Administration
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps

9.1 Инженерия надёжности сайтов

Обзор и мотивация

Ключевые принципы

Рекомендации

Определяйте SLI, SLO и SLA намеренно

Принимайте бюджеты ошибок и принуждайте их

Измеряйте и сокращайте рутину

Планируйте мощность и прогнозируйте спрос

Воспринимайте надёжность как функцию с реальной ценой

Выбирайте организационную модель SRE