tokeon.ru: почему SRE?
Из истории вопроса
Когда-то давным-давно не было никакой технической поддержки и была одна только разработка…
И никто, кроме разработчиков, толком не знал как работает продукт. И никто, кроме разработчиков, не мог ответить на вопросы о продукте.
Но когда разработчики отвечали на вопросы о продукте — они не могли ничего разрабатывать. И теряли навыки. И продукт не развивался. И будили разработчиков по ночам, если продукт ломался. И не нравилось это разработчикам.
Так образовалась техническая поддержка. Специальные люди, которые поддерживали пользователей продукта, помогали с внедрением, прибегали тушить пожары, когда всё шло совсем не так, как должно было.
Классическая поддержка
Чтобы навести в работе технической поддержки порядок, придумали стандарт ITIL, внутри него расписали разные уровни поддержки, описали контракт поддержки через SLA.
Так образовалась классическая поддержка, для работы которой надо:
Постоянно актуальное описание продукта и процедур по обслуживанию
Возможность эскалации задач в разработку
Строгое следование процедурам
И почти сразу возник конфликт между поддержкой и разработкой. Конфликт этот заложен в самом подходе и формируется он так:
Разработчики: в поддержке работают глупые люди, которые не понимают что мы делаем, а поэтому постоянно требуют от нас какие-то идиотские инструкции
Поддержка: разработчики постоянно делают всякую хрень, а нам приходится расхлёбывать?
Руководство: зачем нужна поддержка и чем они там занимаются? И занимаются ли вообще, а то может лучше их там всех уволить?
Любители решать конфликты до сих пор работают в этой концепции и между ними разворачиваются постоянные драмы, в которых конфликтующие тратят свои эмоциональные силы. Оставим их и позволим времени разобраться с этой концепцией.
SRE
Концепция SRE — это следующее поколение методов для организации поддержки. В ней можно выделить тезисы:
Ключевым показателем качества работы SRE является надежность сервиса
Получается, что KPI для SRE значим для бизнеса и его легко измерить
Инженеры SRE должны тратить не более 50% своего времени на операционные задачи
Отсюда явно видно, решение инцидентов больше не основная задача поддержки. Основная задача — это превентивные меры, направленные на повышение надежности
Инженеры SRE могут быть взаимозаменяемы с DevOps
И тогда поддержка становится гораздо ближе к разработчикам, по сути участвуя в развертывании и управлении надежностью на самых ранних стадиях.
Выводы
Концепция SRE — это следующая ступень развития технической поддержки. Сама концепция значительно расширяет роль технической поддержки, переводя её из разряда эксплуатанта в роль участника развития инфраструктуры и продукта.
Руководство получает внятное объяснение зачем нужна эта команда и как измерить качество её работы. А бизнес видит чёткое соответствие верхнеуровневым бизнес-целям, ведь качественный продукт → надежный продукт.
