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

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

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

• Снизить процентную долю расходов на поддержку продуктов и незапланированные работы на 50 %.

• Обеспечить срок с момента фиксации кода до релиза его в производство не более недели для 95 % изменений.

• Обеспечить релиз кода в производство только в обычное рабочее время с нулевым временем простоя.

• Интегрировать все необходимые управляющие элементы контроля безопасности в конвейер развертывания, чтобы обеспечить проверку соответствия всем необходимым требованиям.

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

Продолжать улучшения, планируя на короткие сроки

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

Продолжая планировать на небольшие интервалы времени и поддерживая короткие итерации, мы достигаем следующего:

• гибкости и способности быстро изменить приоритеты и планы;

• уменьшения интервала между временем, когда были затрачены усилия, и реализацией улучшений, что укрепляет петлю обратной связи и повышает вероятность того, что она упрочит желаемое поведение — когда инициативы по улучшению успешны, это поощряет дополнительные инвестиции;

• более быстрого обучения, начинающегося с первой итерации, что означает более быструю интеграцию выводов на следующем шаге;

• уменьшения усилий, необходимых для создания улучшений;

• более быстрой реализации усовершенствований, значительно влияющих на повседневную деятельность;

• сокращение риска того, что проект погибнет, прежде чем мы сможем получить какие-либо ощутимые результаты.

Резервируем 20 % времени для реализации требований, не связанных с функциональностью, и для выплаты технического долга

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

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

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

Рис. 11. Вкладывайте 20 % времени в создание положительных ценностей, даже если они незаметны для пользователя (источник: запись Machine Learning and Technical Debt with D. Sculley в подкасте Software Engineering Daily, November 17, 2015, http://softwareengineeringdaily.com/2015/11/17/machine-learning-and-technical-debt-with-d-sculley/)