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

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

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

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

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

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

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

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

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

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

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

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