Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

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

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

Мы верим, что важно не падать духом. Те, кто занимается преобразованием привычных способов работы, с самого начала понимали: их инициативы с большой долей вероятности могут провалиться. Но они все равно действовали. Возможно, самым важным результатом становилось то, что они показали, каких результатов можно добиться. Инновации без риска невозможны, и, если вы не расстроили хотя бы одного начальника, видимо, вы недостаточно сильно стараетесь. Не позволяйте иммунной системе компании отвлечь вас от вашей задачи. Как любит говорить Джесс Роббинс, «мастер аварий» компании Amazon, «не боритесь с глупостью, делайте больше крутого».

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

Мы искренне надеемся, что Руководство по DevOps поможет вам достичь этих целей.

Дополнительные материалы

Приложения

Приложение 1

Свод правил DevOps

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

Джон Уиллис назвал этот процесс «конвергенцией DevOps». Подходы к управлению, ставшие предками DevOps, описаны ниже в порядке появления (отметим, что это не подробные описания, а скорее, заметки, призванные показать развитие мысли и неочевидные связи между направлениями. Они в итоге привели к созданию DevOps).

Бережливое производство

Бережливое производство возникло в 1980-х гг. как попытка формализовать производственную систему компании Toyota и популяризовать такие методики, как систематизирование потока ценности, канбан-доски и всеобщий уход за оборудованием.

Два основополагающих принципа бережливого производства — глубокая вера в то, что время производственного цикла (то есть время, затраченное на преобразование исходных материалов в готовую продукцию) — лучший показатель качества работы, удовлетворенности клиентов и сотрудников, а также того, что одним из главных факторов сокращения времени производственного цикла были небольшие размеры партии. Идеалом был «поток единичных изделий» (то есть поток «1×1»: одна единица исходных материалов — одна единица готовой продукции).

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

Гибкая разработка

Agile-манифест был создан в 2001 г. семнадцатью ведущими мыслителями в области разработки ПО. Их целью было преобразование таких «неглубоких» методов, как DP и DSDM[180], в более широкую систему, куда можно было бы включить более масштабные подходы к разработке, такие как каскадная модель (Waterfall Model) или унифицированный процесс разработки (Rational Unified Process).

Ключевой принцип — «частая поставка работающего программного обеспечения, от нескольких недель до нескольких месяцев, чем быстрее — тем лучше». Два других важных принципа гибкой разработки — небольшие, целеустремленные команды, работающие по модели управления с высоким уровнем доверия, и предпочтение небольшим объемам работы. С гибкой методологией разработки также связаны такие наборы инструментов и методики, как Scrum, Stand-up[181] и так далее.

Конференции Velocity