В российских IT-компаниях термин SRE стал модным синонимом эксплуатации.
При этом в оригинале SRE - это конкретные принципы эксплуатации, сформулированные в Google, и они являются естественным продолжением остальных особенностей культуры внутри Google и не факт, что подходят любой другой компании, тем более в России.
Что же было до появления SRE? Те, кто работал в крупных компаниях, могли сталкиваться с ITIL - библиотекой лучших практик.
ITIL имеет намного большую сферу приложения, чем SRE, но следующие части ITIL пересекаются с SRE:
* Управление доступностью
* Управление производительностью
* Контроль за изменениями
* Управление инцидентами
* Мониторинг и реакция на события
* Управление проблемами
* Управление релизами
* Управление конфигурацией
* Управление непрерывностью
* Процессы поддержки
* Менеджмент SLA
* Менеджмент заявок
* Управление валидацией и тестированием
* Управление развёртыванием
* Управление инфраструктурой и платформами
* Управление разработкой
Неплохо, неправда ли? Одних заголовков хватит, чтобы набросать процесс работы команды эксплуатации.
На фоне ITIL SRE превращается в "мы не объясним как вам наладить эксплуатацию, но вы должны быть инженером и писать код". Фундаментальные вещи в SRE: риски, SLO/SLI, мониторинг - это база в ITIL, которую в ITIL уже снабдили подробной инструкцией по внедрению.
Место SRE - в треугольнике с ITIL и DevOps. С одной стороны SRE не предлагает принципиально новых процессов эксплуатации, а с другой предлагает конкретную реализацию принципов CALMS из философии DevOps.