Джин Ким - Руководство по DevOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы будем активно управлять техническим долгом, расходуя по меньшей мере 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/)

После изучения опыта компании eBay, оказавшейся в конце 1990-х гг. практически на грани исчезновения, Марти Кэган, автор книги Inspired: How To Create Products Customers Love, считающейся наиболее фундаментальным исследованием по конструированию продукции и управлению, пришел к такому выводу.

«Сделка с владельцами и инженерами заключается обычно так: отдел управления производством отнимает у руководителей верхнего звена право распоряжаться примерно 20 % времени инженерной группы и дает ей право тратить его так, как она посчитает нужным. Это время можно использовать, чтобы переписать код заново, перепроектировать систему или выполнить рефакторинг проблемных частей кода… все, что они считают необходимым сделать во избежание появления нужды прийти к команде и признаться: “Мы должны остановиться и переписать весь код”. Если ситуация действительно тяжелая, то на эти цели можно отдать 30 % ресурсов или даже больше. Однако я начинаю нервничать, когда сталкиваюсь с командами, уверенными, будто справятся с подобными задачами, получая гораздо меньше ресурсов, чем 20 %».