Джин Ким - Руководство по DevOps

Весной 2009 г. в ходе того, что Снайдер называл «великим культурным преобразованием в компании Etsy», к компании в качестве технического директора присоединился Чад Дикерсон. Дикерсон привел в движение множество вещей, включая крупные инвестиции в стабильность сайта, дал разработчикам возможность самостоятельно выполнять развертывание кода в производство, а также начал занявшую два года ликвидацию Sprouter.

Для этого команда решила переместить всю обработку бизнес-логики из уровня базы данных на уровень приложений, устраняя необходимость Sprouter. Исполнители создали небольшую группу, написавшую на языке PHP уровень объектно-реляционного сопоставления (ORM — Object Relational Mapping) [47], что позволило разработчикам внешнего интерфейса обращаться непосредственно к базе данных и сократило число команд, задействованных в изменении бизнес-логики, с трех до одной.

Как описывал Снайдер, «мы начали использовать ORM для любых новых областей сайта и постепенно переносили небольшие части нашего сайта из Sprouter в ORM. Нам потребовалось два года для переноса всего сайта и отключения Sprouter. И хотя все это время мы недовольно ворчали на Sprouter, он, несмотря на это, оставался в производственной среде».

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

Sprouter был удален из производственной среды и репозиториев версионного контроля компании Etsy в 2001 г. Как сказал Снайдер, «класс! Отличные ощущения!» [48].

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

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

• Функциональные организации оптимизируются во имя компетентности, разделения труда или сокращения затрат. Эти компании централизуют знания, помогающие служебному росту и развитию навыков, и нередко имеют длинную иерархическую организационную структуру. Долгое время это был преобладающий метод организации для эксплуатации (например, администраторов серверов, сетевых администраторов, администраторов баз данных и так далее — все они были собраны в отдельные группы).

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

• Организации, ориентированные на рынок, нацелены быстро реагировать на потребности клиентов. Как правило, структура таких организаций плоская, состоящая из нескольких кросс-функциональных направлений (например, маркетинга, проектирования и т. д.), что зачастую приводит к потенциальной избыточности во всей организации. Именно такой метод применяется во многих известных компаниях, внедривших принципы DevOps. Яркие примеры — Amazon и Netflix: каждая команда одновременно отвечает и за реализацию функций доставки, и за поддержку [49].

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

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

Проблема обычно усугубляется тем, что исполнитель часто не видит задачу целиком или не понимает, как его деятельность связана с целями потока создания ценностей (например, «я конфигурирую серверы, просто потому что мне это поручили»). Это помещает работников в творческий и инновационный вакуум.

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

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