Применение практик DevOps - стр. 7

Рис. 4. Функциональная структура традиционного ИТ-подразделения.

В отличие от такой схемы, в DevOps деление специалистов производится по командам, и каждая команда работает над своим продуктом. Будучи самодостаточной, команда включает в себя и владельца продукта, и архитекторов, и разработчиков, и тестировщиков, и ответственных за эксплуатацию, и за информационную безопасность (Рис. 5).

Рис. 5. Пример состава DevOps-команды.

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

Таким образом, можно утверждать, что традиционная организация ИТ-подразделения больше направлена на оптимизацию затрат (англ. Optimize for cost), в то время как организация по DevOps направлена на оптимизацию скорости (англ. Optimize for speed), и эти цели в общем случае являются разнонаправленными. Отметим также, что DevOps предлагает инструменты и способы ограничения роста затрат, такие как максимальная автоматизация всех рутинных операций, а также взаимозаменяемость в пределах одной команды. Кроме того, адепты DevOps справедливо указывают, что оптимизация скорости во многих случаях направлена на предоставление возможности бизнесу зарабатывать больше, что компенсирует возрастающие расходы на ИТ. В таком случае можно рассуждать об ИТ-отделе, как истинном бизнес-партнёре, а не центре затрат.

Понятие технического долга предложил У. Каннингем в 1992 году. Возникновение такого долга происходит, когда программист выбирает неоптимальный путь решения задачи для того, чтобы сократить сроки разработки. Уорд отмечал, что это естественный процесс, и, собственно, проблема заключается в том, что накапливающиеся неоптимальные решения приводят к постепенному ухудшению результатов разработки, и, как следствие, к деградации продукта. Со временем команда разработки будет вынуждена больше времени уделять исправлению последствий ранее принятых решений, то есть переделке кода, нежели разработке новых функциональных возможностей. Аналогия с финансовым долгом в этом случае является очень наглядной – для ускорения получения результата компания может «влезть в долги», однако, она не должна допускать ситуации, когда вся получаемая прибыль уходит на обслуживание долга.

Мартин Фаулер (Martin Fowler) в дальнейшем развил идею технического долга, предложив условную классификацию причин его возникновения (Табл. 1).

Табл. 1. Классификация технического долга по М. Фаулеру.

Его точка зрения в целом повторяет мысль У. Каннингема – в правильно организованной команде разработчиков увеличение технического долга может быть осознанным шагом для получения краткосрочных преимуществ; важно уделять внимание «выплате» этого долга.

В настоящее время понятие технического долга обычно употребляется намного более широко. При расширении его применения на вопросы эксплуатации поднимается целый пласт проблем традиционного ИТ-отдела: устранение сбоев с помощью перезагрузки устройств; установка программной заплатки, не протестированной должным образом; выполнение изменений ИТинфраструктуры без тщательного планирования; ручное исправление какого-либо скрипта или настройки сервера без документирования – это лишь отдельные примеры накопления технического долга, который в обычном ИТ-отделе никто никогда не будет «выплачивать». Некоторые ИТорганизации даже не планируют таких работ или проектов, другие тешат себя иллюзиями наведения порядка, «как только для этого появится свободная минута» – разумеется, свободной минуты в современном ИТ-подразделении не появляется.