🔥 Как похоронить SRE в компании, пытаясь его масштабировать

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

Разбираем классические ошибки хаотичного масштабирования и то, как сделать это по уму.

⚪️ Парад кастомных велосипедов. Без единых стандартов у всех свои форматы алертов, разные метрики SLO и уникальные плейбуки.
⚪️ Размытие экспертизы. Топовых инженеров, которые запускали первые SRE-практики, начинают размазывать тонким слоем по компании и кидать на дежурства в незнакомые системы. В итоге они превращаются в «пожарных» на full-time.
⚪️ Платформа без инвестиций. Пока SRE-шники тушат локальные пожары в продуктовых командах, общие инфраструктурные инструменты остаются без внимания. Техдолг растет, команда топчется на месте.
⚪️ Лучшие люди выгорают и уходят. Компания теряет экспертизу из-за кривого менеджмента, а не из-за того, что «SRE не масштабируется».

Как масштабировать SRE, ничего не сломав

⚪️ Вводим критерии готовности. Нельзя просто так взять и прийти к SRE. Продуктовая команда сначала должна сама сделать домашку: настроить базовую инструментацию, определить SLO и написать минимальные инструкции для дежурств.
⚪️ Гибкие модели взаимодействия. Выделенный SRE нужен далеко не всем. Миксуйте форматы: используйте консалтинг со стороны SRE и Self-Service для зрелых команд.
⚪️ Защищаем правило 50/50. Помните классику из Google SRE book? Не более 50% времени на эксплуатацию (ops). Остальное время — строго на проектную работу и автоматизацию. Иначе выгорание неизбежно.
⚪️ Инвестируем в платформу (IDP). Вместо раздувания штата автоматизируйте стандарты. Нужны единые библиотеки логирования, общие конфигурации PagerDuty и готовые инструменты для работы с SLO.
⚪️ Алерт на онколл. Если нагрузка на дежурствах зашкаливает — это не кадровая проблема, которую можно решить наймом джунов. Это архитектурная проблема системы.

Масштабировать нужно не людей, а стандарты и платформенные решения.

@DevOpsKaz 😛