Содержание курса

• Предмет исследования

• Варианты организации производства

• Жизненный цикл производства информационных систем

• Фаза: Предпроектное исследование. Предмет автоматизации

• Фаза: Предпроектное исследование. Предварительная оценка реализации

• Фаза: Проектирование, дизайн, формирование требований

• Фаза: Разработка (реализация). Планирование работ

• Фаза: Разработка (реализация). Имплементация проектного решения

• Фаза: Внедрение (развертывание), ввод в эксплуатацию

• Роли специалистов в ИТ-производстве. Предпроектное исследование и Проектирование

• Роли специалистов в ИТ-производстве. Разработка

• Роли специалистов в ИТ-производстве. Внедрение

• Современные подходы ИТ-производства

В последнее время происходит фундаментальный сдвиг парадигмы от управления изменениями (проектами) к управлению ценностью (продуктами). Жесткие границы проектов (начало → конец) размываются, уступая место непрерывному потоку операционного производства (DevOps, продуктовая модель).

Если цель в классической модели ЖЦ — создать целевой продукт за конечное время, используя выделенные ресурсы, то в операционной деятельности — это постоянная и непрерывная поставка новый функциональности, добавляющей ценность заказчику от ее использования в ИТ-продукте. То есть стираются явные временные границы производства, “нарезанного” на проекты. Но это не значит, что прекращается измерение конечного успеха производства, просто диагностирование смещается из плоскости проектной деятельности в плоскость достижения бизнес-метрик. Что в свою очередь заставляет менять организацию производства, в частности: подходы к планированию и распределению бюджета (от фиксированных к периодическим), принципы формирования команд (от временных проектных к постоянным кросс-функциональным потоковым). Эти модели мы рассматривали ранее в “Части 2. Варианты организации производства”.

По существу, производство переходит после первого этапа внедрения минимальной функциональности (иногда MVP) в операционную деятельность, переплетаясь с процессами сопровождения. Зачастую операционка начинается еще до окончания формального конца проекта.

Заказчики все реже соглашаются на чистый Fixed Price (классический проект). Растет доля:

• Time & Material. Ооплата за фактическое время — чистая операционка.

• Outcome-based. Оплата за достижение метрик — например, рост конверсии.

• Смешанные. FP на первый этап, далее T&M или подписка SaaS (Software as a Service).

Большинство крупных ИТ-компаний живут в гибридном мире:

• На уровне портфеля: есть проекты (инициативы с началом и концом).

• На уровне команды: работа организована как продуктовая операционка (бэклог, спринты, непрерывная доставка).

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

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

• Сложность настройки. Необходимость регламентации и автоматизации ручной настройки уникального окружения. Написать пайплайн (особенно для сложного проекта) — это отдельный проект, требует квалификации DevOps-инженера.

• Стоимость инфраструктуры. Агенты сборки, хранилище артефактов, лицензии на инструменты, а это дополнительные расходы.

• Хаос зависимостей.  Использование “зоопарка” инструментов, сложные интеграции. Успех измеряется не скоростью деплоя (хотя она важна), а тем, насколько предсказуемо работает тестовое окружение и насколько прозрачен след для аудита.

• Мониторинг. Сложность сбора метрик в цепочке сервисов операционного процесса. Сложность корреляции разных типов данных в едином ID запросе. Разрыв метрик между пилотом и масштабированием.

• Безопасность. Конфликт со службами ИБ (длительные процедуры проверок и согласования VS скорость DevOps). Наличие изолированных контуров, строго регулируемых сред, большое количество интеграций, в том числе с legacy-системами.

• Культурные проблемы. Необходимость принимать сквозную совместную ответственность за общий результат на всех шагах производства. Не все операторы готовы допустить разработчиков к серверам.

• Надежность тестов. Если тесты «мигают» (flaky tests), пайплайн будет тормозить или ложно сигналить. Хорошие автотесты — отдельная большая работа.

• Прочее…

При рассмотрении данной темы остановимся лишь на самых злободневных аспектах.

1.    DevOps конвейер

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

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

Обязательные компоненты DevOps конвейера (по Gartner):

• Непрерывная интеграция (CI) — автоматическая сборка и оркестрация проверок (тесты, безопасность, соответствие стандартам).

• Непрерывная доставка (CD) — автоматическое развертывание с поддержкой gated approval (ручное подтверждение) и ungated deployment (полностью автоматическое).

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

Современный продуктовый конвейер может включать следующие элементы:

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

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

2.   Место требований в DevOps подходе

Для организации полного цикла производства, процессы должны начинаться со сбора и формализации требований заинтересованных лиц. В DevOps подходе требования к продукту превращаются из статичного контракта передаваемого на этап кодирования, в динамичные гипотезы, которые быстро, при минимальных затратах, проверяются “в бою”. С каждой поставкой, при помощи определенной метрики, собирается обратная связь от бизнеса, требования снова уточняются и отправляются по ЖЦ конвейера. Такой подход предполагает выбор иных предпочтений к составу и качеству самих требований. Вместо всеобъемлющего ТЗ используется Product Backlog; User Stories; Feature. Эти способы представления мы рассматривали в “Части 6. Разработка. 6.2. Имплементация проектного решения”.  

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

Чтобы организовать непрерывный конвейер крайне важно организовать сквозную трассируемость каждого требования: требование (критерии приемки) → задачи → ветка кода → сборка → релиз → метрика (удовлетворение критериям приемки). Такой подход заставляет хранить требования в репозитории и версионировать вместе с исходным кодом.

Полноценный конвейер позволяет в пайплайне (CI/CD) выполнять автоматические проверки соответствия реализации требованиям:

К ключевым практикам управления требованиями в DevOps можно отнести:

1)  Непрерывная приоритизация бэклога (Continuous Backlog Refinement)

В классике ТЗ составили, согласовали и зафиксировали. В DevOps бэклог пересматривается и переприоритизируется постоянно (обычно раз в 1-2 недели на встрече с Product Owner):

• Старые требования могут быть удалены, если потеряли актуальность.

• Новые требования добавляются на основе фидбека из production.

• Никакого Change Request. Просто меняется порядок задач.

2)  Управление требованиями через «Shift Left» (Сдвиг влево)

Требования начинают проверять как можно раньше, но не через документы, а через код и тесты: «Мы не знаем, что именно нужно пользователю, пока не покажем ему работающий продукт. Поэтому требования — это эксперименты, а не инструкции.»

Например: сценарий используют как автотест, который CI/CD пайплайн прогоняет при каждом коммите. Если тест не проходит — фича считается неработающей и не попадает в релиз.

3)  Управление требованиями через Feature Toggles (Флаги функций).

Это ключевая практика DevOps, которая полностью меняет подход к релизам. Суть состоит в том, что код фичи (функциональности) заливается в production выключенным (по флагу). Включение происходит в любой момент по команде Product Owner. Подход позволяет добиться того, что:

• Требование не нужно «замораживать» до релиза. Код пишется, даже если требование еще обсуждается.

• Можно включить фичу для 1% пользователей (Canary release) и посмотреть метрики.

• Если фича не пошла — выключается флагом в один момент (а не переписыванием кода).

3.    Организация безопасности в DevOps подходе

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

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

Безопасность в DevOps (DevSecOps) — это интеграция процессов обеспечения безопасности на всех этапах жизненного цикла конвейера, с использованием автоматизации, раннего выявления уязвимостей и непрерывного контроля. Такая необходимость продиктована следующими ключевыми изменениями ландшафта угроз:

• Приложения охватывают множество сервисов, регионов и облачных провайдеров.

• Данные перемещаются между микросервисами, API и внешними интеграциями.

• Контейнеры и условная инфраструктура постоянно меняются.

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

Учитывая все вышесказанное необходимо централизованно обеспечивать безопасность на каждом этапе DevOps цикла, используя специализированные инструменты:

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

Быстро внедрить весь набор перечисленных инструментов и практик не реалистично, поэтому подобные нововведения обычно интегрируют в ЖЦ итерационно. При этом можно выделить следующие уровни зрелости организации безопасности в DevOps: