Из истории вопроса
Когда-то давным-давно не было никакой технической поддержки и была одна только разработка…
И никто, кроме разработчиков, толком не знал как работает продукт. И никто, кроме разработчиков, не мог ответить на вопросы о продукте.
Но когда разработчики отвечали на вопросы о продукте - они не могли ничего разрабатывать. И теряли навыки. И продукт не развивался. И будили разработчиков по ночам, если продукт ломался. И не нравилось это разработчикам.
Так образовалась техническая поддержка. Специальные люди, которые поддерживали пользователей продукта, помогали с внедрением, прибегали тушить пожары, когда всё шло совсем не так, как должно было.
Классическая поддержка
Чтобы навести в работе технической поддержки порядок, придумали стандарт ITIL, внутри него расписали разные уровни поддержки, описали контракт поддержки через SLA.
Так образовалась классическая поддержка, для работы которой надо:
Постоянно актуальное описание продукта и процедур по обслуживанию
Возможность эскалации задач в разработку
Строгое следование процедурам
И почти сразу возник конфликт между поддержкой и разработкой. Конфликт этот заложен в самом подходе и формируется он так:
Разработчики: в поддержке работают глупые люди, которые не понимают что мы делаем, а поэтому постоянно требуют от нас какие-то идиотские инструкции
Поддержка: разработчики постоянно делают всякую хрень, а нам приходится расхлёбывать?
Руководство: зачем нужна поддержка и чем они там занимаются? И занимаются ли вообще, а то может лучше их там всех уволить?
Любители решать конфликты до сих пор работают в этой концепции и между ними разворачиваются постоянные драмы, в которых конфликтующие тратят свои эмоциональные силы. Оставим их и позволим времени разобраться с этой концепцией.
SRE
Концепция SRE - это следующее поколение методов для организации поддержки. В ней можно выделить тезисы:
Ключевым показателем качества работы SRE является надежность сервиса
Получается, что KPI для SRE значим для бизнеса и его легко измерить
Инженеры SRE должны тратить не более 50% своего времени на операционные задачи
Отсюда явно видно, решение инцидентов больше не основная задача поддержки. Основная задача - это превентивные меры, направленные на повышение надежности
Инженеры SRE могут быть взаимозаменяемы с DevOps
И тогда поддержка становится гораздо ближе к разработчикам, по сути участвуя в развертывании и управлении надежностью на самых ранних стадиях.
Основные активности SRE
Для иллюстрации приведу "пирамиды Маслоу" роли SRE-инженера
Как видим, на нижних уровнях у нас остались мониторинг и работа с инцидентами - базовые активности любой технической поддержки. В продвинутых командах поддержки тоже есть культура написания постмортемов (или "анализ корневых причин").
При этом добавляются участие в тестирование и доработка процедур релиза, участие в разработке и планировании продукта. Эти активности в традиционной технической поддержке как правило не предусмотрены совсем.
Выделю следующие ключевые особенности, характерные именно для роли SRE:
сообщение об ошибке от заказчика и/или внешнего пользователя должно приводить к изменению в настройках мониторинга и автотестах. Это необходимо для того, чтобы не бегать от пожара к пожару и работать на предотвращение инцидентов.
регулярные обращения от пользователей с типовыми запросами должны приводить к заведению задачи в беклог разработки (системная мера для снижения нагрузки на поддержку)
процедура деплоя должна быть синхронизирована с конфигурацией мониторинга (новые фичи должны быть под мониторингом сразу после выхода релиза)
многоуровневый мониторинг: уровень системного ПО (операционные системы, БД, брокеры и т.д.), прикладное ПО (наш собственный софт), функциональный мониторинг (насколько хорошо работает функционал нашего продукта), CI/CD, бизнес-метрики
конфигурация мониторинга как код
конфигурация автотестов как код
Эти меры позволяют удерживать нагрузку на SRE-инженера в пределах половины его рабочего времени и не перегружать людей беготнёй от пожара к пожару.
Выводы
Концепция SRE - это следующая ступень развития технической поддержки. Сама концепция значительно расширяет роль технической поддержки, переводя её из разряда эксплуатанта в роль участника развития инфраструктуры и продукта.
Руководство получает внятное объяснение зачем нужна эта команда и как измерить качество её работы. А бизнес видит чёткое соответствие верхнеуровневым бизнес-целям, ведь качественный продукт -> надежный продукт.