Итого, SR инженер, который DevOps, это конкретная должность по версии Google причём так же прямолинейно делящая свои обязанности по времени - 50% на операционную деятельность и 50% на инженерную деятельность. Операционная деятельность, рутина - сервису надо больше памяти чем обычно, видим тикет, накидываем память. Инженерная деятельность - найти причину утечки, если она в инфраструктуре, что-то автоматизировать, что-то инфраструктурное переписать, а если дело в самом сервисе то поработать с разработчиками. Если мы знаем что память можно накинуть автоматически, по каким-то предпосылкам, а потом убрать, то можно и так сделать, главное не в ручную. При этом SRE скорее не разработчик, хотя на эту позицию ищут людей с опытом разработки, есть целая глава с примером как писали сервис внутри службы SRE и как это важно - программная разработка, но её наличие мне показалось именно подчеркиванием исключительности этого. Упоминается что это часто что-то не очень большое и разработчики сервисов отделены от SRE, эволюционно (на момент выпуска книги 2016 года), Google пришли к тому что SRE надо приглашать на этапы разработки сервиса, чтобы сразу оценивать его будущую надёжность, но непосредственное участие в разработке они не принимают.

Главное для чего возникла служба SRE - это попытка разбить линейную зависимость между количеством сервисов и количеством сотрудников которые их эксплуатируют. Т.е. количество SR инженеров должно расти медленнее чем количество сервисов которые они обслуживают, за счёт как раз инженерного подхода поиска причин неисправностей, организации работы с сервисами и заданных параметров их надёжности, автоматизации. В конечном счёте, если рассматривать последовательность повествования, сервисы унифицировались до микросервисов.

Интересно про жёсткое следование правилу 50 Dev/50 Ops - если упустить собственно Ops с перекосом в Dev, то инженеры перестанут понимать внутренности построенной системы, не хватит оперативных знаний и опыта и всё начнёт разваливаться. А если будет перекос в Ops то всех заест рутина, эффективность упадёт, сотрудников надо будет набирать больше. В приложениях есть конкретные опросники и примеры документов, в главах есть примеры работы с этими документами. В 2016 году, кстати, Google был за проектные команды в одном физическом месте, так проще с коммуникацией, хотя строгость подхода к дежурствам подразумевает что будь хоть какая авария, обязанность по её ведению передаётся новой смене если текущая смена кончается, пусть она даже заступает за тридевять земель.

Читать стоит, если никогда не касались вопроса организации службы эксплуатации не важно DevOps или нет, я думаю будет интересно. Если касались, настройтесь получить интерес в ответе на вопрос: "А как у них?".