Часть 1 [key moments]

Поскольку роль администратора требует набора навыков, который заметно отличается от навыков разработчика, эти два направления разделяют на две команды: команду разработчиков (development) и службу эксплуатации (operations)

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

Традиционные ops и dev часто конфликтуют, особенно из-за сроков выпуска продуктов. Разработчики хотят быстрее запустить новый функционал и увидеть, что пользователи его приняли. Команда эксплуатации же хочет убедиться, что сервис не откажет в самый неподходящий момент

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

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

Изначально определено, что приоритетная задача для SRE-команд - именно разработка. Без постоянных доработок сложность эксплуатации системы будет постоянно расти, поэтому потребуется нанимать все больше людей в команду эксплуатации (а это деньги)
Чтобы этого избежать команда должна управлять потребностями системы, иначе она утонет в запросах. Поэтому в Гугл установлен лимит 50% для операционной работы всех SR-инженеров - запросы на оперативное вмешательство в работу системы (тикеты), дежурства, выполняемые вручную действия итд. Этот лимит гарантирует, что в расписании команды SRE достаточно времени на работы по улучшению сервиса, чтобы он оставался стабильным и работоспособным. Это верхняя граница. Со временем предоставленная сама себе команда SRE должна прийти к минимизации работ по эксплуатации и практически полностью посвящать себя разработке, поскольку сервис, по сути, работает автономно и восстанавливает себя сам: мы хотим, чтобы системы были автоматическими, а не только автоматизированными. На практике масштабирование и ввод нового функционала держит SR-инженеров в тонусе

Как только команда SRE будет укомплектована, ее потенциально непривычные подходы к управлению сервисами потребуют серьезной поддержки со стороны менеджмента. Например, решение приостановить выпуск версий до конца квартала лишь из-за того, что исчерпан лимит времени недоступности сервиса, может быть негативно встречено командой разработчиков, если только оно не санкционированно руководством

На практике контроль, за тем что команда тратит не более 50% на операционную деятельность, достигается путем наблюдения за количеством операционной работы, выполняемой SR-инженерами, и перенаправлением избытка таких задач командам разработчиков: переадресацией ошибок и поступающих запросов менеджерам по разработке, привлечением разработчиков к дежурствам итд. Перенаправление заканчивается, когда операционная нагрузка снижается до 50% и менее. Это также обеспечивает эффективную обратную связь, ориентируя разработчиков на создание систем, не требующих вмешательства человека

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

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

На операционные задачи выделяется не более 50% от общего времени SR-инженеров. Остальное время должно быть использовано для работы над проектами с применением навыков программирования. Если операционных задач становится слишком много, то часть их перенаправляют на разработчиков (чтобы сохранить 50% для SRE)
Это также обеспечивает хорошую обратную связь, ориентируя разработчиков на создание систем, не требующих вмешательства человека

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

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

Продукт должен иметь SLO. Error budget будет равен - 1 - SLO
Мы можем тратить этот бюджет на все что сочтем нужным (пока не выйдем за его рамки)