Как понять, кто у тебя Tier-1, а кто Tier-3

Привет, %username%! Когда мы говорим о надёжности, часто хочется всё и сразу — 99.999 % аптайма, моментальное восстановление, горячие резервные кластеры… Но у такой «фатальнойтотальной надёжности» есть цена, и не всегда она оправдана.

Тут на помощь приходит тиринг сервисов — практика распределения систем по уровням критичности. Вместо бинарного деления «критично / не критично» мы вводим несколько уровней (Tier-1, Tier-2, Tier-3 и т.д.) и понимаем, где действительно нельзя ошибаться, а где разумно жить по принципу best effort.

• Tier-1 (Mission Critical) — сервисы, от которых зависит бизнес: платёжка, аутентификация, маршрутизация запросов. Для них — строгие SLA, круглосуточный on-call, двойные резервы.
• Tier-2 (Business Critical) — важные, но не фатальные системы: отчётность, панель аналитики, почта поддержки. SLA помягче, RTO/RPO больше.
• Tier-3 (Internal / Non-critical) — внутренние тулзы и вспомогательные сервисы, которые можно чинить по мере возможностей.

Такой подход помогает SRE-командам:

• расставлять приоритеты: критическое чинится первым;
• правильно распределять ресурсы (время on-call, бюджет, инфраструктуру);
• избегать избыточной защиты менее важных систем (а значит — не тратить зря).

Итог: не весь аптайм одинаково полезен. Иногда меньше надёжности = больше эффективности.

А как у тебя построен тиринг сервисов? Есть ли формальные критерии или всё держится на интуиции и исторических решениях? Делись опытом — интересно, как в разных командах решается этот вопрос!

#SRE #DevOps #ServiceTiering #Reliability #SLA #Prioritization #Observability