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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SRE

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

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

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

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

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

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

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

Основные активности SRE

Для иллюстрации приведу "пирамиды Маслоу" роли SRE-инженера

Как видим, на нижних уровнях у нас остались мониторинг и работа с инцидентами - базовые активности любой технической поддержки. В продвинутых командах поддержки тоже есть культура написания постмортемов (или "анализ корневых причин").

При этом добавляются участие в тестирование и доработка процедур релиза, участие в разработке и планировании продукта. Эти активности в традиционной технической поддержке как правило не предусмотрены совсем.

Выделю следующие ключевые особенности, характерные именно для роли SRE:

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

• регулярные обращения от пользователей с типовыми запросами должны приводить к заведению задачи в беклог разработки (системная мера для снижения нагрузки на поддержку)

• процедура деплоя должна быть синхронизирована с конфигурацией мониторинга (новые фичи должны быть под мониторингом сразу после выхода релиза)

• многоуровневый мониторинг: уровень системного ПО (операционные системы, БД, брокеры и т.д.), прикладное ПО (наш собственный софт), функциональный мониторинг (насколько хорошо работает функционал нашего продукта), CI/CD, бизнес-метрики

• конфигурация мониторинга как код

• конфигурация автотестов как код

Эти меры позволяют удерживать нагрузку на SRE-инженера в пределах половины его рабочего времени и не перегружать людей беготнёй от пожара к пожару.

Выводы

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

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