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

Эти успехи дали группе уверенность: используемые принципы и методы DevOps могут быть применены к широкому кругу потоков создания ценности. Кисслер получила повышение — должность вице-президента по электронной коммерции и технологиям хранения в 2014 г.

В 2015 г. Кисслер заявила, что для достижения целей по продажам и развития технологий, ориентированных на клиентов, «необходимо увеличить продуктивность всех потоков создания ценности, а не только отдельных. На уровне управления мы сформировали общее по всей компании требование сокращения времени выполнения заказов на 20 % для всех услуг, ориентированных на клиентов».

«Это дерзкий вызов, — продолжила она. — У нас много проблем при текущем состоянии — процессы и времена циклов не совпадают у различных команд, они непрозрачны. Первое целевое состояние требует от нас помочь всем командам ввести одинаковую систему оценок, сделать процессы видимыми и проводить эксперименты, чтобы сокращать длительность процессов от итерации к итерации».

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

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

Сервисы чистые и нечистые

Мы часто категоризируем программные услуги или продукты как «чистые» (greenfield, «гринфилд») или как «нечистые» (brownfield, «браунфилд»). Эти обозначения первоначально использовались при планировании городов и строительных объектов. «Чистое» строительство ведется на неосвоенных землях. «Нечистым» называется такое, которое ведется на земле, ранее использовавшейся для промышленных целей, потенциально зараженной опасными отходами или загрязнениями. При застройке городов многие факторы могут сделать реализацию «чистых» проектов более простой, чем «нечистых», — нет конструкций, которые прежде необходимо демонтировать, и нет токсичных материалов, которые предварительно требуется вывезти.

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

«Чистые» DevOps-проекты часто используются в качестве пилотных, демонстрируя осуществимость публичного или частного облака, экспериментальной автоматизации развертывания и аналогичных инструментов. Пример такого проекта — Hosted LabView, разработанный в 2009 г. в компании National Instruments, существующей 30 лет, имеющей 5000 сотрудников и миллиард долларов годового дохода. Чтобы быстро вывести продукт на рынок, была создана новая команда разработчиков. Ей было разрешено не соблюдать существующие процессы и поручено изучить возможность использования публичных облаков. Первоначально в состав входили архитектор приложений, системный архитектор, два разработчика, разработчик системы автоматизации, руководитель команды и два специалиста из офшорного подразделения. Используя методы DevOps, они смогли вывести Hosted LabView на рынок за половину времени, обычно нужного для разработки продукта.

На другом конце спектра — «нечистые» DevOps-проекты. Это существующие продукты, уже находящиеся у клиентов, возможно, в течение многих лет или даже десятилетий. «Нечистые» проекты зачастую включают значительные объемы технического долга, например неавтоматизированное тестирование или работа на неподдерживаемых платформах. В примере с Nordstrom, приведенном выше, и система ресторанов в магазинах, и система электронной торговли были браунфилд-проектами.