Когда я впервые услышал термин DevOps, от своих коллег я понял примерно следующее:
«Процесс развёртывания приложения в любой среде (dev/QA/prod) называется DevOps. Просто ещё один синоним эксплуатации».
Как начинающий программист, я подумал:
“Ок, здорово! Ещё одно модное словечко, поразившее в ИТ-индустрию».
Люди, которые имеют некоторое представление о DevOps, знают, как я ошибался!
Однако, через некоторое время в ИТ-разработке стали появляться сообщения о наборе вакансий с такими обозначениями, как AIOps, MLOps, DataOps, FinOps и xOps инженеры. Тогда я подумал: секундочку, похоже DevOps должен быть чем-то большим, чем просто развёртывание.
Когда я гуглил что же такое DevOps, Интернет выдал мне несколько определений.
«DevOps — это сочетание культурной философии, практик и инструментов, которые повышают способность организации производить программные приложения и услуги с высокой скоростью».
«Это точка пересечения между разработкой и эксплуатацией».
«Вы берете процесс, который выполняется вручную, и автоматизируете его».
Это понятие в целом имеет такое расплывчатое определение, что его трудно осознать, особенно если у вас нет достаточного восприятия исторического контекста разработки ПО и причин, приведших к этой концепции.
Но различные определения заставили меня задуматься:
- Разве мы не развёртываем приложения последние 20 лет?
- Что на самом деле привело к необходимости автоматизации в первую очередь?
- Какие неотъемлемые проблемы мы пытаемся решить с помощью DevOps?
- Какая часть разработки не относится к DevOps, и какая часть эксплуатации не относится к DevOps. Почему возникла необходимость увязывать их?
- Разве мы не можем разобраться с этим раз и навсегда, просто настроив несколько конвейеров CI/CD ?
- Когда я могу сказать, что у меня успешная практика DevOps в моей организации?
Мне в голову приходило ещё много подобных вопросов. Очевидно, чтобы вникнуть в понятие DevOps, нам придётся разобраться с историческим контекстом того, как традиционно осуществлялась поставка программного обеспечения.
Суть процесса выпуска ПО и его развития
Ниже приведены этапы типичного процесса разработки программного обеспечения.
Наш процесс разработки программного обеспечения не сильно изменился за последние три десятилетия. Команды, создающие ПО, обычно состоят из групп разработчиков (которые пишут код) и операционных групп или команд эксплуатации (которые развёртывают и поддерживают приложения). Обе эти группы отвечают за релиз программного обеспечения.
Имея в виду описанную выше структуру команды и то, как она работает, мы можем получить некоторый исторический контекст.
Раньше релизы программного обеспечения выпускались реже, поскольку требования практически не менялись. Системы были не предназначены для быстрого изменения после развёртывания. Главное они должны были быть стабильными.
Единственное, что нужно было сделать после развёртывания приложения — это общее сопровождение. Понятные вещи, вроде обновления ОС и пакетов, которые требуются системе.
Инфраструктура не была такой доступной, как сейчас. В результате операционная группа отвечала за планирование постоянной ёмкости, её предоставление и обслуживание. Это заставляло команду разработчиков и команду эксплуатации двигаться более или менее с одинаковой скоростью.
Однако, если разобраться внимательнее, то способ производства ИС был функционально изолированным, поскольку его осуществляли сотрудники, которые были специалистами в разных областях. Особой координации между ними не требовалось.
Этот подход отлично работал в то время, поскольку частота развёртывания была низкой. Редко можно было увидеть более одного релиза в месяц.
Процессы и методы укоренились, и команды адаптировались к этому типу подхода в управлении разработкой.
Но время шло, и требования начали быстро меняться. Начали появляться проблемы в процессе поставки программного обеспечения.
Для того, чтобы лучше понять и разобраться в принципах, изложенных в статье, рекомендуем обратить внимание на два наших учебных курса: “Трансформация ИТ” и “Продуктовый подход”. Первый из них объясняет, как построить высокоэффективную производственную систему, основываясь на современных принципах и практиках управления ИТ. Второй – как загружать такую производственную систему, чтобы получить от неё максимальную ценность. Эти два курса рекомендуется проходить сразу вместе, чтобы получить полное представление и целостную картину.
Проблемы, которые привели к DevOps революции
1) Меняющиеся требования
Внезапно возникла потребность в частом развёртывании. Релизные циклы были сокращены с месяцев до недель. Но поскольку концепция меняющихся требований не укладывалась в привычное планирование, попытки применить унаследованный способ ведения дел к новой ситуации не всегда срабатывали.
Командам эксплуатации было трудно часто развёртывать систему, обеспечивая при этом её стабильность.
Процессы и методы управления начали давать сбои, в основном из-за отсутствия координации между командами и используемыми инструментами (позже мы рассмотрим это более подробно).
Команды эксплуатации попытались адаптироваться к изменениям, создавая штучные сценарии и изменив процессы, чтобы получить некоторое облегчение.
Но по мере того, как программные системы становились все более сложными, включая контейнеризацию, микросервисы, автоматическое масштабирование и так далее, ситуация просто вышла из-под контроля. В процессе поставки программного обеспечения стало появляться много препятствий.
2) Разногласия между командами
Настоящая проблема связана с людьми, которые разрабатывают и поддерживают программное обеспечение.
Перед командой, рарабатывающей программне обеспечение, в любой организации стоит простая цель:
Поставляйте высококачественное программное обеспечение быстрее.
И все в команде работают вместе для достижения этой общей цели. Однако на практике команды не работают как единое целое, поскольку у каждого члена команды есть разные стимулы для работы, которые имеют приоритет над общей целью.
Давайте посмотрим на стимулы отдельных специалистов в командах.
- Группа разработчиков
Стимул: быстрее разрабатывать новые функции - Группа контроля качества
Стимул: обеспечить покрытие всех тестовых сценариев (занимающее много времени действие) - Группа безопасности
Стимул: гаранировать соблюдение передовых методов обеспечения безопасности (занимающее много времени действие) - Операционная группа
Стимул: обеспечить стабильность приложения, работающего в производственной среде (занимающее много времени действие).
Вследствие этого:
- Разработка и эксплуатация преследуют противоречивые цели: из-за этого между ними образуется огромная стена, возникают разногласия и замедляется весь релизный цикл.
- Группы работают изолированно друг от друга, и взаимодействие не происходит должным образом, что приводит к проблемам с обеих сторон.
Разработчики
- Руководство по развёртыванию плохо документировано
- Не учитывают, где развёртывается приложение
Эксплуатация
- Не представляют, как работает приложение
- Если что-то не получается, нужна помощь разработчиков, чтобы разобраться
- Приоритет отдаётся выполнению своих стимулов, а остальное «не моя проблема»
- Релизный цикл растягивается от дней до недель и месяцев.
- По мере того, как собственные стимулы становятся важнее, чем общая цель, возникают дедлайны, производственные сбои, негативный пользовательский опыт и т. д. Всё это в итоге влияет на бизнес.
Итак, чтобы убрать эти барьеры и возник DevOps
DevOps как решение
«Предоставление высококачественного программного обеспечения за счёт ускорения процесса и обеспечения стабильности».
Роль команды DevOps здесь состоит в том, чтобы определить препятствия в жизненном цикле разработки программного обеспечения и попытаться преодолеть их, внедрив некоторую автоматизацию. Это может быть достигнуто через инструменты и сценарии или процессы и методы, которые приведут к улучшению процесса разработки и развёртывания.
По сути, DevOps пытается устранить препятствия, внедряя автоматизацию и оптимизируя процесс поставки программного обеспечения. Вот почему процессы CI и CD находятся в центре DevOps.
В заключение я хотел бы процитировать определение DevOps от Патрика Дюбуа (человека, который придумал термин DevOps).
«Делать всё, чтобы преодолеть разногласия, возникающие из-за изоляции… Всё остальное — обычная инженерия»
by Sharad Regoti
Оригинал статьи
