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

Как писал Майк Ротер в уже упоминавшейся книге «Тойота Ката. Лидерство, менеджмент и развитие сотрудников для достижения выдающихся результатов», «как бы соблазнительно это ни казалось, нельзя реорганизовать путь к постоянному совершенствованию и приспосабливаемости. Решающий фактор — не форма организации, а то, как люди действуют и реагируют. Корни успеха компании Toyota лежат не в организационной структуре, но в развивающихся возможностях и особенностях ее работников. Это удивляет многих, обнаруживающих, что компания Toyota в основном организована традиционно — как система функциональных отделов». Развитие привычек и возможностей у отдельных инженеров и у персонала в целом будет рассматриваться в следующих разделах.

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

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

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

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

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

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

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

Каждый член команды может стать универсалом

Что касается организаций с функционально ориентированными подразделениями, то это отделы специалистов (администраторы сети, администраторы систем хранения данных и т. д.). Когда такие отделы узкоспециализированы, это вызывает их самоизоляцию, которую Спир описывает так: «работают подобно суверенным государствам». Любая сложная деятельность при этом требует неоднократной передачи задач от отдела к отделу, что ведет к очередям и, следовательно, к более длительному выполнению (например, потому что любое изменение конфигурации сети должно быть сделано сотрудником сетевого отдела).

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

Одна из контрмер — поощрять стремление каждого члена команды стать универсалом. Мы делаем это, предоставляя инженерам возможность приобрести навыки, необходимые для создания систем, за которые они отвечают, путем регулярной ротации сотрудников по разным ролям. Термин «специалист по комплексной разработке» (full stack engineer) в настоящее время часто используется (иногда как богатая тема для пародий) для описания специалиста широкого профиля, знакомого со всем набором используемых приложений (например, языком, на котором написаны коды приложений, баз данных, операционных систем, сетевых решений, облаков) или по крайней мере имеющего понимание всего этого на базовом уровне.