Как понять, кто у тебя 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