Текстовый курс по DevOps

Как построить организацию DevOps и спроектировать архитектуру ПО?

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

Структура организации определяет, какое ПО вы создаёте

Большинство компаний, вероятно включая вашу, делят подразделения поставки ПО на несколько команд и в итоге создают ПО с таким же количеством архитектурных слоёв. Контролируемые эксперименты это подтвердили: когда организации из 6 команд поручили создать ПО, команды предложили архитектуру из 6 слоёв. Когда то же самое ПО поручили создать организации из 3 команд, получилась архитектура из 3 слоёв. Есть много похожих примеров.

В известной страховой компании с 86,000 сотрудников по всему миру одно из ИТ-подразделений, отвечавшее за серверную часть для работы с клиентами, договорами, счетами и услугами, состояло из двух основных функциональных команд. Одна специализировалась на Java, другая — на хранимых процедурах PL/SQL. Кроме того, обе зависели от централизованных служб эксплуатации ИТ, администраторов баз данных, инфраструктуры, сетей, информационной безопасности и обеспечения качества, что дополнительно затрудняло безопасную поставку ПО.

Несмотря на разделение команд, в архитектуре не удавалось правильно отделить логику координации бизнес-процессов на Java от логики доступа к данным на PL/SQL. Команды поставили сотни функций, и в каждой причудливо переплетался код на Java и PL/SQL. Каждое изменение и каждый запрос новой функции требовали десятков передач работы от одной команды другой. Даже небольшие изменения подолгу ждали в очередях и долго выполнялись. В такой сложной среде последствия даже мелких изменений было трудно предвидеть. Они постоянно нарушали работу существующих функций и вызывали простои, устранение которых требовало времени, переделок, вмешательства руководства и сил.

Чтобы изменить этот порядок, две функциональные команды объединились в одну продуктовую. Они постепенно переработали ПО, превратив слой доступа к данным в набор функций API. Они также создали новую бизнес-систему, полностью независимую от внутренней работы API доступа к данным. Уже на раннем этапе это подняло боевой дух: специалисты Java и PL/SQL начали работать на успех общего продукта, а не в интересах прежних изолированных команд. Благодаря слабосвязанной архитектуре теперь легче оценивать влияние изменений, быстрее вносить их и проще находить и устранять дефекты. В результате среднее время поставки новых функций сократилось с 4 месяцев до 3 недель, а очередь инцидентов почти опустела. Освободившееся время команда использует для проверки, рефакторинга и улучшения кодовой базы.

Матричные организации, функциональные команды и иллюзия экономии

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

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

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

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

Как DevOps решает эту серьёзную проблему? С помощью команд, отвечающих за продукты и услуги

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

DevOps предлагает вам команды, ориентированные на продукты и услуги. Это независимые, кросс-функциональные, автономные, самодостаточные и обычно небольшие команды, которые могут самостоятельно пройти весь инженерный жизненный цикл продукта или услуги, а не временного проекта: от архитектуры, проектирования, написания кода, тестирования и экспериментов до развёртывания, эксплуатации и сопровождения ПО. Да, вы всё правильно прочитали. Кто лучше создателей ПО может его эксплуатировать и сопровождать? Никто. Неудивительно, что самые успешные команды DevOps в Amazon и Netflix не бросают свои продукты и услуги после выпуска. Они также отвечают за их эксплуатацию и сопровождение в собственных рабочих системах.

Ваша организация финансирует продукты и услуги вместо временных проектов

Чтобы улучшить результаты бизнеса, организация прекращает финансировать временные проекты, конкретные долгосрочные результаты которых сложно оценить. С DevOps она финансирует собственную миссию и цели, а также продукты и услуги, которые им соответствуют. Успех команд оценивают по результатам в ИТ и бизнесе, включая отдачу от вложений в тех областях, где они предоставляют продукты, услуги и микросервисы внутренним или внешним клиентам. Команды ведут себя как владельцы продуктов и услуг, которые создают и предоставляют. Они уже не ограничиваются задачами своего функционального подразделения и обращают внимание на результаты бизнеса.

Как создать команды DevOps и спроектировать архитектуру ПО?

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

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

Можно рассмотреть и другой вариант

Google — пример исключительно успешной DevOps-организации, которая продолжает широко использовать функциональные команды наряду с командами DevOps, ориентированными на продукты и услуги. И те и другие считают миссию организации и её продукты и услуги общей целью. Функциональные команды создают типовые решения, например шаблоны, контрольные списки и каркасы приложений, и системы самообслуживания, например для самостоятельного создания и настройки серверов и сетей. Так их работа не становится узким местом, замедляющим команды продуктов и услуг. Функциональные команды Google помогают таким командам на ранних этапах разработки ПО, конструктивно проверяют проектные решения, код и тесты и постоянно консультируют команды DevOps.

Какой должна быть численность команды DevOps?

Оптимальный размер команды DevOps — от 5 до 10 человек. Такой состав упрощает общение и согласование работы. Руководитель и участники команды тратят меньше времени на мелкие поручения и организационные задачи. Это также ограничивает масштаб продукта или услуги, за которые отвечает команда, упрощает ПО и облегчает его сопровождение и эксплуатацию. Каждый участник небольшой команды видит общую картину и получает небольшой опыт руководства, участвуя в выполнении важной для организации задачи. Руководитель команды вместе с высшим руководством уточняет цели и объясняет их участникам команды.

Что делать, если продукт или услуга уже слишком велики для команды до 10 человек?

Выделите новый продукт или услугу и сформируйте команду DevOps, которая возьмёт за них ответственность. Продукты и услуги могут предназначаться не только для внешних клиентов, которые за них платят. Вы также можете создавать внутренние продукты, услуги или так называемые API микросервисов и формировать для них команды DevOps, обслуживающие внутренних клиентов. Например, если биллинговая система становится слишком большой для команды до 10 человек, выделите новую команду для API доступа к базе данных. Возможно, ещё одну — для API онлайн-платежей и ещё одну — для пакетной обработки. Всем этим командам нужен общий репозиторий кода и совместный конвейер развёртывания для непрерывной интеграции, быстрой поставки и успеха организации.

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

Как небольшие команды до 10 человек могут сами пройти весь цикл разработки ПО от архитектуры до эксплуатации?

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

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

Спрос изменится завтра, если не сегодня.

ВЫВОДЫ

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

DevOps предлагает формировать небольшие команды до 10 человек вокруг продуктов, услуг или API микросервисов.

Такие команды DevOps должны состоять из универсальных full-stack-инженеров, способных самостоятельно пройти все этапы разработки ПО, от проектирования до сопровождения.

DevOps опирается на слабосвязанную сервис-ориентированную архитектуру (SOA), в которой каждая команда DevOps отвечает за одну часть архитектуры и эксплуатирует её.