tokeon.ru: почему SRE?

Из истории вопроса

Когда-то давным-давно не было никакой технической поддержки и была одна только разработка…

И никто, кроме разработчиков, толком не знал как работает продукт. И никто, кроме разработчиков, не мог ответить на вопросы о продукте.

Но когда разработчики отвечали на вопросы о продукте — они не могли ничего разрабатывать. И теряли навыки. И продукт не развивался. И будили разработчиков по ночам, если продукт ломался. И не нравилось это разработчикам.

Так образовалась техническая поддержка. Специальные люди, которые поддерживали пользователей продукта, помогали с внедрением, прибегали тушить пожары, когда всё шло совсем не так, как должно было.

Классическая поддержка

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

Так образовалась классическая поддержка, для работы которой надо:

• Постоянно актуальное описание продукта и процедур по обслуживанию

• Возможность эскалации задач в разработку

• Строгое следование процедурам

И почти сразу возник конфликт между поддержкой и разработкой. Конфликт этот заложен в самом подходе и формируется он так:

• Разработчики: в поддержке работают глупые люди, которые не понимают что мы делаем, а поэтому постоянно требуют от нас какие-то идиотские инструкции

• Поддержка: разработчики постоянно делают всякую хрень, а нам приходится расхлёбывать?

• Руководство: зачем нужна поддержка и чем они там занимаются? И занимаются ли вообще, а то может лучше их там всех уволить? 

Любители решать конфликты до сих пор работают в этой концепции и между ними разворачиваются постоянные драмы, в которых конфликтующие тратят свои эмоциональные силы. Оставим их и позволим времени разобраться с этой концепцией.

SRE

Концепция SRE — это следующее поколение методов для организации поддержки. В ней можно выделить тезисы:

Ключевым показателем качества работы SRE является надежность сервиса

Получается, что KPI для SRE значим для бизнеса и его легко измерить

Инженеры SRE должны тратить не более 50% своего времени на операционные задачи

Отсюда явно видно, решение инцидентов больше не основная задача поддержки. Основная задача — это превентивные меры, направленные на повышение надежности

Инженеры SRE могут быть взаимозаменяемы с DevOps

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

Выводы

Концепция SRE — это следующая ступень развития технической поддержки. Сама концепция значительно расширяет роль технической поддержки, переводя её из разряда эксплуатанта в роль участника развития инфраструктуры и продукта.

Руководство получает внятное объяснение зачем нужна эта команда и как измерить качество её работы. А бизнес видит чёткое соответствие верхнеуровневым бизнес-целям, ведь качественный продукт -> надежный продукт.