Книга: Руководство по DevOps

Тестирование, эксплуатация и безопасность — повседневная работа каждого

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

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

С учетом общих целей и разработчиков, и отдела эксплуатации технический директор компании Ticketmaster Джоди Малки заявил: «Почти 25 лет я использовал метафоры из американского футбола для описания разработчиков (Dev) и эксплуатации (Ops). Вы знаете, что Ops — это оборона, не дающая пропускать голы, а Dev — нападение, старающееся голы забивать. И в один прекрасный день я понял, как ошибочна эта метафора: они никогда не играют одновременно. Фактически они даже не одна команда!»

Он продолжает: «Теперь я использую другие аналогии. Ops — игроки нападения, а Dev — квотербеки и принимающие игроки, чья деятельность заключается в перемещении мяча по полю. Задание Ops — обеспечить Dev достаточно времени для надлежащего проведения игры».

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

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

Оглавление книги