Site Reliability Engineering: как Google и Ozon добиваются 99.99% доступности платформ

Когда речь заходит о масштабируемых IT-системах, Site Reliability Engineering (SRE) становится не просто трендом, а необходимостью. Компании вроде Google и Ozon обрабатывают миллионы запросов в секунду, и даже минимальный простой обходится в миллионы рублей упущенной выручки. Но как именно эти гиганты обеспечивают надежность на уровне 99.99%? Спойлер: это не только про серверы и код — это про культуру ответственности, где каждый инженер понимает, что его ошибка может обрушить платформу для миллионов пользователей.

В этой статье мы разберём ключевые принципы SRE, которые применяют в Google (где концепция и родилась) и Ozon (где её адаптировали под реалии российского e-commerce). Вы узнаете, как работают метрики SLO/SLI, почему error budget — это не про деньги, а про баланс между инновациями и стабильностью, и какие инструменты помогают предотвращать сбои до того, как они станут критичными. А ещё — как продавцам на Ozon эти знания помогут избежать простоя витрины в пиковые сезоны.

Если вы думаете, что SRE нужна только гигантам вроде Amazon или AliExpress, то ошибаетесь. Даже небольшой интернет-магазин на Ozon может применять базовые практики — например, настраивать мониторинг критичных метрик или автоматизировать откат неудачных релизов. Главное — понять, что надежность не появляется сама собой: это результат системного подхода, где технологии и процессы работают вместе.

Что такое Site Reliability Engineering (SRE) и почему это не то же самое, что DevOps

Многие путают SRE и DevOps, но это принципиально разные подходы. DevOps фокусируется на скорости доставки новых фич, в то время как SRE — на надежности системы в долгосрочной перспективе. В Google даже шутят: "DevOps говорит'давай выпустим быстрее!', а SRE спрашивает'а что будет, если это сломается?'".

Ключевое отличие SRE — это инженерный подход к надежности. Вместо того чтобы тушить пожары по мере их возникновения, SRE-инженеры:

• 📊 Определяют количественные метрики надежности (например, 99.95% доступности для корзины покупок на Ozon).
• 🛠️ Автоматизируют рутинные задачи (скажем, перезапуск упавших микросервисов).
• 🔍 Анализируют инциденты постфактум, чтобы предотвратить их повторение (постмортемы в Google — это целый ритуал).
• ⚖️ Балансируют между скоростью разработки и стабильностью через концепцию error budget.

В Ozon, например, SRE-команды тесно интегрированы с командами разработки. Если в Google SRE часто выступает как отдельная роль, то в Ozon это скорее культура, которую внедряют во все процессы — от деплоя нового функционала до масштабирования инфраструктуры в Чёрную пятницу.

⚠️ Внимание: Если ваш бизнес на Ozon зависит от API платформы (например, автоматическая выгрузка товаров), то сбои в работе API могут парализовать продажи. SRE-подход поможет заранее выявить слабые места — например, настроить алерты на превышение времени ответа >500 мс.

Метрики SLO, SLI и SLA: как Google и Ozon измеряют надежность

Без метрик невозможно управлять надежностью. В SRE используют три ключевых понятия:

• SLI (Service Level Indicator) — конкретная метрика, которую можно измерить. Например, время ответа API или процент успешных платежей.
• SLO (Service Level Objective) — целевое значение SLI. Скажем, 99.9% успешных запросов к API Ozon FBO.
• SLA (Service Level Agreement) — договорённость с пользователями о штрафах за невыполнение SLO. В Ozon SLA чаще внутренние (между командами), чем внешние.

В Google для поисковой выдачи SLI может быть задержка ответа, а SLO — 95-й перцентиль <500 мс. На Ozon критичными SLI для продавцов будут:

• 🛒 Доступность страницы товара (SLO: 99.95%).
• 💳 Успешность обработки заказов (SLO: 99.99%).
• 📦 Время генерации этикеток для FBS (SLO: <2 сек).

Важно: SLO должны быть реалистичными. Если задать 100% доступность, это приведёт к тому, что команды будут боятся выпускать обновления (страх превысить error budget). В Google считают, что 99.95% — это золотой стандарт для большинства сервисов.

⚠️ Внимание: Если ваш товар на Ozon внезапно пропал из поиска, это может быть связано с превышением SLI по времени ответа вашего фида. Настройте мониторинг time-to-first-byte (TTFB) для вашего сервера с прайс-листами.

Error Budget: как балансировать между инновациями и стабильностью

Концепция error budget (бюджет ошибок) — это то, что делает SRE уникальным. Идея проста: если ваш сервис работает лучше целевого SLO, вы можете позволить себе рисковать (выпускать новые фичи, экспериментировать). Если же SLO не выполняется — все силы бросаются на стабилизацию.

Формула простая:

Error Budget = 100% - SLO
Пример: если SLO = 99.95%, то error budget = 0.05% простоя в месяц (~22 минуты.

В Google команды строго следят за error budget:

• 🟢 Если бюджет не исчерпан — можно выпускать новые фичи.
• 🟡 Если бюджет на исходе — приостанавливают релизы и фокусируются на надежности.
• 🔴 Если бюджет превышен — вводятся моратории на изменения.

На Ozon этот подход адаптировали под e-commerce. Например, перед Новым годом error budget для систем обработки заказов сокращают до минимума, чтобы избежать сбоев в пиковые дни. А вот для некритичных сервисов (например, рекомендации товаров) бюджет могут увеличить, чтобы тестировать новые алгоритмы.

Определите критичные SLI (например, успешность заказов)|Установите реалистичные SLO (например, 99.9%)|Отслеживайте расход error budget в реальном времени|При исчерпании бюджета приостанавливайте некритичные обновления-->

Инструменты мониторинга и алертинга: чем пользуются Google и Ozon

Без инструментов SRE немыслим. В Google используют собственные решения вроде Borg (для оркестрации контейнеров) и Stackdriver (для мониторинга), но многие принципы универсальны. На Ozon комбинируют открытые инструменты и самописные системы. Вот что можно позаимствовать:

Базовый стек для мониторинга:

• 📈 Prometheus + Grafana — для сбора метрик и визуализации. Например, отслеживание quantile_95(latency) для API.
• 🚨 Alertmanager — для алертов. Правило: алерты должны быть действительными (не спамить по мелочам).
• 🔍 OpenTelemetry — для трассировки запросов (полезно, если ваш сервис интегрирован с Ozon API).
• 🤖 SRE-боты — в Ozon используют чат-ботов в Slack, которые автоматически собирают контекст инцидента.

Для продавцов на Ozon критично мониторить:

• 📦 Статусы заказов (чтобы не пропустить сбои в FBS).
• 💰 Успешность платежей (например, через Ozon Банк).
• 📈 Трафик на страницы товаров (вдруг ваш товар исчез из поиска).

⚠️ Внимание: Если вы используете Ozon API для автоматической выгрузки товаров, настройте алерты на ошибки 429 (Too Many Requests) и 503 (Service Unavailable). Это сигнал, что ваш лимит запросов превышен или на платформе технические работы.

Постмортемы: как Google и Ozon учатся на ошибках

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

Структура эффективного постмортема:

1. Что произошло? (факты без оценок).
2. Почему это произошло? (коренная причина, а не симптом).
3. Каково было воздействие? (потери денег, репутации, времени).
4. Как мы это исправили? (временные меры).
5. Как предотвратим в будущем? (долгосрочные действия).

Пример из практики Ozon: в 2022 году был сбой в системе логистики, из-за которого заказы FBS задерживались на 6+ часов. В постмортеме выяснилось, что проблема была в недостаточной ёмкости базы данных для пиковой нагрузки. Решение: внедрили автоскейлинг и увеличили резервные мощности на 30%.

Для продавцов на Ozon постмортемы тоже полезны. Например, если ваш товар неожиданно исчез из поиска, разберите:

• 🔍 Были ли изменения в вашем фиде?
• ⚡ Не было ли простоя вашего сервера?
• 📉 Не изменились ли правила ранжирования на Ozon?

Автоматизация и Chaos Engineering: как ломать системы, чтобы они стали крепче

Один из принципов SRE — "если что-то может сломаться, оно сломается". Поэтому в Google и Ozon активно применяют Chaos Engineering — контролируемое"ломание" систем, чтобы проверить их устойчивость. Классический пример: Netflix со своим Chaos Monkey, который случайно"убивает" серверы в рабочем окружении.

На Ozon используют похожие практики:

• 🌪️ Имитация пиковых нагрузок — перед Чёрной пятницей тестируют систему на 200% от ожидаемого трафика.
• 🔌 Отключение дата-центров — проверяют, как быстро переключается трафик на резервные узлы.
• 🐢 Искусственные задержки — добавляют latency в API, чтобы проверить, как реагируют клиентские приложения.

Для продавцов на Ozon Chaos Engineering может означать:

• 🛒 Тестирование отмены заказов в пиковые часы.
• 📦 Проверку, что ваша система генерации этикеток FBS работает при потере связи с Ozon API.
• 💰 Имитацию сбоев платежей через Ozon Банк.

Главное правило: начинайте с малого. Не ломайте продакшн в разгар распродажи! Начните с тестового окружения или некритичных сервисов.

Как продавцам на Ozon применять принципы SRE

Вы можете думать: "Мне не нужна SRE, я же не Google!". Но даже небольшой бизнес на Ozon сталкивается с проблемами надежности:

• 🛑 Витрина недоступна из-за проблем на вашем хостинге.
• 📉 Товары пропадают из поиска из-за ошибок в фиде.
• 💸 Платежи не проходят из-за сбоев в интеграции с Ozon Банком.

Вот 5 практических шагов, чтобы сделать ваш бизнес надежнее:

1. Мониторьте критичные метрики:
   • 📊 Успешность загрузки фида товаров (цель: 100%).
   • ⏱️ Время ответа вашего сервера на вебхуки от Ozon (цель: <500 мс).
2. Автоматизируйте рутину:
   • 🤖 Настройте автообновление остатков в Ozon через cron или Airflow.
   • 🔄 Автоматизируйте откат неудачных обновлений фида.
3. Готовьтесь к пиковым нагрузкам:
   • 📈 Тестируйте ваш сервер на нагрузку в 2-3 раза выше обычной (используйте Locust или JMeter).
4. Документируйте инциденты:
   • 📝 Ведите журнал сбоев и их решений (даже если это просто таблица в Google Sheets).

Error Budget = (100% - SLO) × количество запросов/операций в месяц
Пример: если ваш SLO = 99.9% и вы обрабатываете 100 000 заказов в месяц, то error budget = 0.1% × 100 000 = 100 неудачных заказов.