[Время на прочтение: ~5 мин.]

В первой части мы разобрали, что такое SLO, SLA и SLI. Но одно дело — знать термины, а другое — уметь правильно их применять.

Часто SLO выглядят идеально на бумаге, но в реальности их не соблюдают, они не соответствуют реальной нагрузке или просто вводят всех в заблуждение.

Сегодня разберём:🔵Как учитывать зависимости, чтобы SLO не были оторваны от реальности. 🔵Как измерять SLO так, чтобы они действительно отражали пользовательский опыт. 🔵Как правильно согласовывать SLO между командами. 🔵Почему важно встроить процесс пересмотра SLO в культуру компании.

1️⃣ Почему даже хорошие SLO не работают? SLO сами по себе не решают проблем.

Они становятся бесполезными, когда: ❌ Их игнорируют. SLO есть, но мониторингом никто не пользуется. ❌ Они не соответствуют реальности. Цели взяты "из головы", а не на основе данных. ❌ Их слишком много. В команде 20 сервисов, и у каждого своё SLO — никто не понимает, на что ориентироваться. ❌ Они не привязаны к бизнес-логике. Например, поставили строгий аптайм, но забыли про реальные потребности пользователей.

🧷 Вывод: SLO должны быть гибкими и пересматриваться хотя бы раз в квартал.

2️⃣ *Как учитывать зависимости?_Вы можете идеально построить свой сервис, но он не будет работать лучше, чем его слабое звено. _Пример: Допустим, ваш сервис аналитики имеет SLO = 99.95%. Но он зависит от базы данных с SLO = __99.9%. Если база недоступна, ваш сервис тоже ломается.

➡️ Какие есть варианты?🟡Каскадный анализ: Если ваш сервис зависит от базы, API и кэша, то нужно учитывать их SLO. 🟡Приоритеты: У критичных компонентов (например, платежей) должен быть отдельный, более строгий SLO. 🟡Резервные механизмы:** Если один сервис упал, может ли ваш сервис деградировать gracefully, а не просто падать?

Кейс из реальной жизни: 🤍 Авито: При сбое Redis переключаются на Postgres — пусть медленно, но система продолжает работать. 📱 Zoom: В периоды высокой нагрузки распределяет пользователей между дата-центрами, снижая риски перегрузки.

3️⃣ Как правильно измерять SLO? Ошибки, которые часто встречаются: ❌ Считать только средние значения. Среднее время загрузки — 2 сек., но 10% пользователей ждут 10 сек. ❌ Игнорировать разные категории пользователей. Мобильные пользователи сталкиваются с другими проблемами, чем десктопные. ❌ Ориентироваться на технические метрики вместо пользовательских.

➡️ Как стоит поступить? ✅ Использовать перцентили (например, 95-й вместо среднего значения). ✅ Разделять пользователей по сегментам (например, новые vs. старые клиенты). ✅ Учитывать бизнес-контекст (например, SLO для корзины важнее, чем для страницы отзывов).

4️⃣ Как согласовывать SLO между командами? Одна из самых сложных проблем — разные команды ставят SLO в отрыве друг от друга._ Пример ошибки: Бекенд обещает 99.99% доступности API, но фронтенд стабильно отдаёт 2% ошибок из-за багов в коде.

➡️ Как избежать этого?✅ _Обсуждать SLO между командами, а не только внутри одной.✅ Синхронизировать метрики: SLO фронта должны учитывать SLO бекенда.✅ _Включать SLO в OKR компании, а не просто в документацию.

Пример:📱 Slack: Разрабатывает SLO совместно между инфраструктурными и клиентскими командами, чтобы учесть весь путь пользователя.📱 GitHub: Имеет единый центр управления SLO, где следят за зависимостями между сервисами.5️⃣ Когда пересматривать SLO?_Один раз настроили и забыли? Это худшее, что можно сделать. ➡️ Когда точно стоит пересматривать SLO? ✅ Раз в квартал — как минимум, для проверки соответствия реальности. ✅ После инцидентов — если SLA нарушили, значит, SLO могли быть нереалистичными. ✅ При росте нагрузки — если трафик увеличился в 3 раза, старые метрики могут устареть. ✅ При изменении инфраструктуры* — новый провайдер API или переход на другую базу может повлиять на SLO.

Пример: 🏦 Т банк: После запуска новых сервисов анализируют, какие SLO устарели. 😁 Ozon: SLO на время загрузки страницы пересматривали 4 раза за год из-за изменений в инфраструктуре.

🔖 Свои выводы оставлю в комментариях ⬇️