В 2016-ом году на свет вышла книга за авторством нескольких сотрудников Google под названием “Site Reliability Engineering: How Google runs production systems”. Безусловно, у Google есть чему поучиться: компания предоставляет сервисы для миллиардов пользователей, и на своем опыте я не могу вспомнить, когда хоть какой-то из них слег так же жестко, как S3 в 2017-ом.

Однако, если открыть поисковик от Google и поискать там истории уволившихся сотрудников, ушедших либо на вольные хлеба, либо в стартапы, либо в другие конторы, мы начинаем понимать простую истину, касающихся 99.99% все ИТ-гигантов: Google не всегда все делает “правильно”, и я сейчас не о десятках экспериментальных проектов, которые были закрыты по каким-то внутренним причинам, а сотрудники, болевшие ими, либо ушли, либо были переведены в другие проекты.

Однако Google как, наверное, самый престижный ИТ гигант служит примером для всей индустрии и, пусть и неосознанно, но обладает огромным влиянием на бесчисленное множество крупных, средних и маленьких контор. Некоторое время после выхода книги про SRE, о создании SRE группы заявил LinkedIn - социальная сеть для соискателей и работодателей.

В отличие от DevOps, SRE, на мой взгляд, выступает полноценным фреймворком, поскольку содержит в себе конкретный набор инструкций по внедрению и применению. Основным различием является то, что SRE подразумевает наличие отдельной команды, состоящих из очень крутых специалистов, шарящих и в разработке, и в инженерии. Главным фокусом является не только обеспечение максимально высокого uptime, но и предварительный расчет оптимального значения оного (когда сравнивают расходы на uptime с потерями от падения) - нет смысла гарантировать максимум 10 минут “лежания”, если это стоит миллиард долларов, а “спасаете” вы миллион.

Эксперты SRE переходят в команду конкретного продукта по запросу самой команды. По “правилам” команда может взять либо одного SRE, либо одного feature разработчика. Проще говоря - если максимальный headcount вашей команды 8 человек (и у вас уже 8 человек), и вы хотите себе одного SRE, то придется одного разработчика из команды прогнать. Таким образом скорость доставки обновлений приносится в жертву стабильности продукта.
Есть еще одна “фишка” SRE - взятый в команду SRE эксперт может по собственному разумению уйти из продукта, если (цитата) “он видит, что действия команды по стабильности не эффективны и не приносят пользы”.

Когда мы говорим о применении такого подхода в Google, мы понимаем, что SREшник не покинет продукт просто так - он подставит не только команду продукта, но и себя (его экспертиза ставится под вопрос). Но если представить такое в, простите, русской конторе, где, еще раз простите, царит бардак - получим человека с завышенным ЧСВ, который не смог с полпинка поднять uptime до 99.999% и, плюнув на все, свалил.