Цитаты из книги «Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях»

Часто согласование дается чужими командами, слишком далекими от нашей работы. Принять обоснованное решение о рискованности правок затруднительно, а время на получение всех разрешений удлиняет сроки внесения изменений

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

Помимо роста показателя конверсии одна из самых интересных деталей этой истории — что в отделе TurboTax проводили эксперименты в периоды максимальной нагрузки на сайт. Десятилетиями в розничной торговле риск влияющих на выручку сбоев во время праздничных сезонов был настолько велик, что с середины октября по середину января мы просто запрещали вносить любые изменения. Однако, добившись быстрых и безопасных развертываний и релизов, команда TurboTax снизила риски пользовательских экспериментов и внесения изменений настолько, что их можно было проводить и в самые прибыльные периоды наибольшей нагрузки.

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

Обычай инженеров SRE помогать командам на первых стадиях проекта — важная культурная норма, постоянно укрепляемая в Google. Лимончелли объясняет: «Помощь разработчикам — долговременная инвестиция

Чтобы самостоятельные команды все же могли воспользоваться опытом организации SRE, Google создал два списка проверок для двух важнейших стадий релиза нового сервиса. Это проверка на готовность к передаче, к смене сопроводителя (Hand-Off Readiness Review, HRR), и проверка на готовность к запуску продукта (Launch Readiness Review, LRR).

Механизм возврата — одна из практик-долгожительниц компании Google и, пожалуй, отличный способ показать взаимное уважение между инженерами разработки и эксплуатации

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

Одна из возможных мер — сделать как Google: там все группы разработчиков сами поддерживают и управляют своими сервисами, пока они не перейдут к централизованной группе инженеров эксплуатации. Если разработчики сами будут отвечать за развертывание и сопровождение своего кода, переход к централизованной команде эксплуатации будет гораздо более гладким 129

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