Как изменились SRE-практики Google за 10 лет
13 октября 2026 года Google анонсировала полностью переписанное второе издание книги Site Reliability Engineering: How Google Runs Production Systems. Десять лет назад первая версия задала индустрии язык для разговора про надёжность: SLO, error budget, toil. Новое издание переписывает этот язык под инфраструктуру 2026 года — Kubernetes, multi-cloud, AI-нагрузки и платформенные команды.
Краткий ответ
Google переписала книгу SRE, потому что практики 2016 года — ручные error budget policies, статичные дашборды, скрипты для разовых задач — не выдерживают масштаба и сложности современных систем. Второе издание фиксирует сдвиг от task-specific automation к platform-wide capabilities: динамический burn-rate alerting вместо ручных порогов, наблюдаемость на базе открытых стандартов вместо логов и дашбордов, декларативный IaC и внутренние платформы вместо скриптов, непрерывное resilience-тестирование вместо редких game days.
Почему первое издание SRE устарело
Книга 2016 года описывала мир, где компании только начинали миграцию в облако и переход от монолитов. Задача звучала просто: научиться работать в облаке вообще. Сегодня, по словам авторов поста в блоге Google Cloud — Betsy Beyer, SRE Program Manager, и David Huska, инженера-программиста и site reliability engineer в Google, — вызов другой: не освоить облачную инфраструктуру, а удержать надёжность при колоссальной сложности.
Современные системы живут в постоянных изменениях. Границы сервисов размыты микросервисной архитектурой, зависимости глубокие и непрозрачные, отказы распространяются быстрее и бьют больнее. Добавьте сюда ресурсоёмкие генеративные AI-нагрузки — и экономика и требования к эксплуатации инфраструктуры меняются целиком. Авторы прямо пишут, что переписать книгу их заставила необходимость заново оценить, что вообще значит «внедрить SRE» в этих условиях.
Главный сдвиг: от ручных задач к платформенным возможностям
Если искать один тезис, который держит на себе всю книгу, — это переход от ручной, точечной работы к автоматизированным возможностям уровня платформы. В 2016 году SRE-команда писала скрипт под конкретную проблему. В 2026-м она строит платформу, которая решает класс проблем заранее — для всех команд сразу.
Это не абстрактная формула, а конкретные изменения в шести областях практики, которые разбирает книга: SLO и error budget, observability, автоматизация и платформы, тестирование надёжности, управление ресурсами и организационные модели SRE. Дальше — что именно изменилось в каждой.
SLO и error budget: от ручных порогов к динамическому burn-rate alerting
В 2016 году команды считали базовую доступность и вручную решали, когда сработала error budget policy. Это работало, пока сервисов было немного и зависимости были простыми.
Сегодня практика выросла до многоуровневых, user-centric SLO с динамическим burn-rate alerting и автоматическим применением политик. Разница принципиальна: вместо одного порога на весь сервис — SLO, завязанные на реальный пользовательский опыт по слоям системы, и alerting, который реагирует на скорость расхода бюджета ошибок, а не на статичный процент. Для платформенной команды это значит меньше ложных тревог и быстрее реакция на деградацию, которая реально угрожает бюджету.
Observability: от дашбордов к корреляции аномалий
Ранние setup для мониторинга — это статичные дашборды, базовые логи и ручной разбор алертов. Человек смотрел на графики и сам сопоставлял причину со следствием.
Второе издание описывает мир, где наблюдаемость строится на OpenTelemetry — открытом стандарте для сбора трасс, метрик и логов, — распределённой трассировке и автоматической корреляции аномалий. Root cause ищет не инженер глазами, а система, которая сопоставляет сигналы из десятков сервисов. Для команд, уже перешедших на observability-стек вокруг OpenTelemetry, это подтверждение правильного направления, а не новость. Для тех, кто всё ещё живёт на логах и ручном триаже, — сигнал, что разрыв с индустрией увеличивается.
Automation и platform engineering: от скриптов к внутренним платформам
Здесь книга фиксирует, пожалуй, самый заметный сдвиг последнего десятилетия. Вместо написания кастомных скриптов под изолированные задачи — декларативный infrastructure as code, внутренние платформы разработчиков и самовосстанавливающиеся системы.
Параллельно меняется и организационная модель. SRE больше не живёт только как выделенная команда, закреплённая за конкретным приложением. Второе издание описывает гибридные модели: интеграцию с platform engineering и reliability-чемпионов, встроенных прямо в продуктовые команды. Это ровно та траектория, которую последние несколько лет проходят компании, строящие внутренние платформы (Internal Developer Platform) поверх Kubernetes: SRE-практики перестают быть отдельной дисциплиной и становятся частью платформы, которую использует вся инженерная организация.
Resilience testing и управление ресурсами для AI-нагрузок
Раньше надёжность проверяли эпизодически — запланированные game days и синтетическая нагрузка раз в квартал. Современная инженерия встраивает непрерывные проверки устойчивости прямо в пайплайн: автоматическое тестирование на каждом деплое и canary-верификацию в проде, без отдельного события «день хаоса».
Схожая логика и в управлении ресурсами. Ручное планирование мощностей и статичные прогнозы Google описывает как пройденный этап. На смену пришли динамическое автомасштабирование, согласование с FinOps-практиками и отдельная оптимизация стоимости и кластеров под GPU и TPU-нагрузки. Это выглядит прямым следствием роста generative AI: ресурсоёмкие модели в проде требуют не просто мощностей, а дисциплины их экономного расходования.
Где это ломается для команд за пределами Google
Книга описывает практики компании, которая управляет инфраструктурой планетарного масштаба. Это важная оговорка: динамический burn-rate alerting, автоматическая корреляция аномалий и self-healing платформы требуют зрелого observability-стека, выделенной платформенной команды и объёма данных, на котором такая автоматизация вообще имеет смысл.
Небольшой команде без зрелого observability-стека копировать весь набор практик один в один рискованно: можно построить сложную платформу под нагрузку, которой у компании пока нет. Здесь полезнее брать принцип — переход от точечных решений к переиспользуемым возможностям, — и применять его к своему масштабу, а не воспроизводить архитектуру Google буквально.
Что проверить у себя до внедрения
CTO и platform lead, которые решат опереться на второе издание, разумно начать не с копирования практик, а с ревизии своего стека:
- Насколько SLO в компании завязаны на пользовательский опыт, а не на техническую доступность инфраструктуры.
- Построен ли observability-стек на открытых стандартах вроде OpenTelemetry или команда всё ещё зависит от проприетарных агентов и ручного разбора логов.
- Есть ли внутренняя платформа, которая берёт на себя повторяющиеся задачи эксплуатации, или команды до сих пор решают одни и те же проблемы скриптами по отдельности.
- Встроено ли тестирование устойчивости в CI/CD или оно существует только как отдельное мероприятие раз в квартал.
- Как считается стоимость GPU- и TPU-ресурсов под AI-нагрузки — отдельно от остального FinOps-учёта или вместе с ним.
Похоже, что второе издание скорее закрепляет практики, которые зрелые платформенные команды уже применяют, чем вводит принципиально новый подход. Для компаний, которые только формализуют SRE-практики, это теперь актуальный ориентир вместо книги десятилетней давности.
Заключение
Первое издание SRE book задало индустрии словарь для разговора о надёжности в облаке. Второе фиксирует, что этот словарь успел устареть: инфраструктура усложнилась, появились AI-нагрузки, а платформенная инженерия забрала на себя часть функций, которые раньше выполняла выделенная SRE-команда. Книга не меняет цель SRE — строить масштабируемые, надёжные и устойчивые системы, — но описывает, какими средствами эта цель достигается сегодня. Второе издание уже доступно для заказа: в физическом формате через Google Books и в цифровом — через O'Reilly.
FAQ
Когда вышло второе издание книги SRE от Google?
Google анонсировала переработанное второе издание 13 октября 2026 года, к 10-летию выхода первой версии. По данным анонса, книга уже доступна для заказа: в физическом формате через Google Books и в цифровом — через O'Reilly.
Чем новое издание отличается от книги 2016 года?
Первое издание описывало практики для эпохи ранних облачных миграций и монолитов. Второе отражает переход к микросервисам, multi-cloud, serverless, платформенной инженерии и AI-нагрузкам и фиксирует сдвиг от ручной, точечной автоматизации к платформенным возможностям.
Что такое dynamic burn-rate alerting?
Это подход к мониторингу error budget, при котором алерт срабатывает не по статичному порогу доступности, а по скорости расходования бюджета ошибок. Чем быстрее сервис «прожигает» бюджет, тем быстрее и точнее система поднимает тревогу.
Нужно ли платформенным командам сразу внедрять все практики из книги?
Нет. Книга описывает практики компании с инфраструктурой планетарного масштаба. Разумнее сверить с ней зрелость своего observability-стека, SLO и платформы и применять принципы соразмерно собственному масштабу, а не копировать архитектуру Google целиком.
Как SRE соотносится с platform engineering в новом издании?
Google описывает гибридные организационные модели, где SRE интегрируется с платформенной инженерией, а reliability-практики распределяются через «чемпионов надёжности», встроенных в продуктовые команды, а не живут только в отдельной выделенной SRE-команде.