Текстовый курс по DevOps
Что такое DevOps?
DevOps — это процесс разработки, поставки и эксплуатации ПО. Определение кажется простым, но важно разобраться в том, что за ним стоит. В книгах и Интернете полно определений DevOps, которые продвигают чьи-то интересы или в лучшем случае неполны и запутанны.
Некоторые определения, продиктованные коммерческими интересами, тесно связывают DevOps с конкретными инструментами сборки и поставки или платформами облачной инфраструктуры. Эти инструменты и платформы действительно могут помочь достичь целей ИТ и организации. Но нельзя просто подключить ещё один инструмент, который вы, скорее всего, почти не контролируете, поскольку не сами его написали, или перенести приложения в облако, а потом объявить, что ваша организация теперь поставляет ПО по DevOps. Как гласит старая и малоизвестная поговорка, вороны бы засмеялись.
Другое определение ближе к сути, но тоже вводит в заблуждение. Оно рассматривает DevOps как объединение работы и людей в ИТ-организации, где разработчики ПО, тестировщики и инженеры эксплуатации рабочих систем работают вместе. К концу этой книги вы сами увидите, насколько сухо такое определение.
Лучше всего понять DevOps через сравнение с итеративной гибкой разработкой ПО и подходами к совершенствованию процессов, такими как Scrum, Lean, ITIL, IDEAL (инициирование, определение, разработка плана, действие и обучение) и Six Sigma DMAIC (определение, измерение, анализ, совершенствование и контроль).
Agile Scrum, Lean, ITIL, IDEAL и Six Sigma DMAIC помогают внедрять DevOps, но DevOps не задумывался как расширенный и усовершенствованный набор этих методов. Причина проста: из перечисленных подходов только Agile Scrum создавался специально для решения задач отрасли разработки ПО.
Многие практики и принципы DevOps пришли из бережливого подхода после того, как их адаптировали, опробовали, проверили и доработали для разработки, поставки и эксплуатации ПО. DevOps также заимствовал и адаптировал множество методов и идей движения за непрерывную поставку, ката совершенствования Toyota, теории ограничений, Манифеста Agile и гибкой инфраструктуры.
Бережливый подход
Бережливый подход можно свести к семи принципам:
- Видьте систему целиком и создавайте ценность для заказчика с помощью системного мышления.
- Закладывайте качество в процесс, создавайте поток и организуйте работу по принципу вытягивания вместо выталкивания.
- Поставляйте результаты как можно быстрее, сокращая время превращения сырья в готовую продукцию, а в случае ПО — идей в работающие и полезные функции в рабочей среде.
- Уделяйте больше внимания обучению и применяйте научное мышление.
- Давайте команде полномочия, руководите без высокомерия и уважайте каждого.
- Устраняйте потери — лишние инструменты, системы и особенно время, которое вы можете тратить на непродуктивную работу.
- Принимайте решения как можно позже, ровно тогда, когда они нужны.
Движение за непрерывную поставку
Конвейер развёртывания позволяет обеспечить непрерывную поставку. У него три задачи: прозрачность, обратная связь и непрерывное развёртывание.
- Прозрачность — Все аспекты системы поставки, включая сборку, развёртывание, тестирование и выпуск, видны каждому участнику вашей и других команд. Так вы содействуете сотрудничеству в команде и обеспечиваете прозрачность для клиентов и заинтересованных сторон.
- Обратная связь — Вы и ваша команда узнаёте о проблемах сразу после их возникновения и можете быстро устранить их, прежде чем продолжать работу на уже ненадёжной основе.
- Непрерывное развёртывание — Вы развёртываете и выпускаете любую версию ПО в любой среде, включая тестовую и рабочую, с помощью полностью автоматизированного процесса.
Ката совершенствования Toyota
Ката совершенствования Toyota — это регулярная практика, которая позволяет творчески, осознанно и целенаправленно перейти от текущего состояния к новому. Она основана на четырёх этапах:
- Учитывая более широкое видение или новое направление развития…
- Разберитесь в текущем состоянии.
- Затем определите следующее целевое состояние.
- Наконец, последовательно приближайтесь к цели небольшими итерациями. По пути выявляйте и устраняйте препятствия.
В других подходах к совершенствованию вы пытаетесь заранее предсказать путь и сосредоточиться на реализации. Ката совершенствования Toyota позволяет учиться в процессе и опираться на новые открытия. Вместе с командой вы стремитесь к целевому состоянию и корректируете действия по мере того, как узнаёте новое.
Теория ограничений
В любой организации, в том числе вашей, которая поставляет ПО, постоянно возникают противоречия между ИТ и бизнесом. ИТ-подразделению приходится искать компромисс между быстрой реакцией на потребности бизнеса и стабильной, предсказуемой работой систем. Как вы уже знаете, выпусков без риска не бывает. В такой сложной системе, как ваша, трудно работать достаточно быстро и одновременно сохранять низкий риск выпуска. И наоборот, при быстрой поставке кода в рабочие системы трудно обеспечить низкий риск.
Справиться с этим противоречием помогают следующие шаги:
- Разделите ИТ-подразделение на множество небольших автономных, независимых и самодостаточных команд, которые активно взаимодействуют. Начните воспринимать их как самостоятельные подразделения, способные принимать решения и выполнять свою миссию.
- Уменьшите размер пакета работ, который получает каждая команда, то есть объём незавершённой работы.
- Сократите время от появления идей и требований до появления работающих полезных функций в рабочих системах.
- Наладьте быстрые, надёжные и непрерывные циклы обратной связи, чтобы обеспечить готовность к развёртыванию.
Манифест Agile
DevOps следует основополагающим ценностям Манифеста Agile:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающее программное обеспечение важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее условий контракта и переговоров.
- Готовность к изменениям важнее следования плану.
Гибкая инфраструктура
И крупные, и небольшие организации, вероятно включая вашу, пользуются гибридной облачной инфраструктурой, сочетающей публичные и частные облака с выделенными серверами. Так вы получаете и защищённость оборудования, размещённого в ЦОД, и гибкость и масштабируемость публичного облака.
Вот основные причины, по которым гибкая инфраструктура полезна для DevOps:
- Вы платите за то, чем пользуетесь, по прозрачным и понятным тарифам.
- Вы можете быстро создавать и удалять тестовые и рабочие среды из своей кодовой базы (IaC — инфраструктура как код).
- Ваша архитектура остаётся гибкой.
- Вы можете легко выйти в другие регионы.
- Вероятно, у вас будет более высокий уровень безопасности.
- Вы соблюдаете требования без аудитов и дополнительных затрат.
ВЫВОДЫ
В этой главе мы объяснили, что относится к DevOps, а что нет. Мы также рассмотрели основные движения и принципы, из которых вырос DevOps.
Небольшая оговорка: многие сторонники гибких подходов годами, к сожалению, придерживались жёстких определений. Не стоит так же жёстко определять DevOps и навязывать это определение вашей организации, продукту, услуге и, главное, команде. Универсального решения нет ни в гибких подходах, ни в DevOps.
Помните: главное — учиться, экспериментировать и адаптироваться. DevOps многое сделает для нас, но именно мы должны понять, какой вариант DevOps и какой способ его применения нам подходят. Так поступают все успешные DevOps-организации, включая Google, Amazon, Facebook, Netflix и Apple.
