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

Команда смогла определить проблемные области — сбор информации и развертывание — и сосредоточила на них усилия по улучшению. Она смогла сократить время развертывания кода на 60 % и число ошибок, требующих вмешательства вручную, на 60–90 %.

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

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

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

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

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

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

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

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

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

Хотя многие считают, что DevOps предназначен в первую очередь для «чистых» проектов, он использовался и для успешного преобразования различного рода «нечистых» проектов. Фактически свыше 60 % проектов трансформации, о которых шла речь на конференции DevOps Enterprise Summit в 2014 г., были второго типа. В этих случаях существовал большой разрыв между потребностями клиентов и тем, что организации фактически давали. И DevOps-преобразования принесли огромные преимущества для бизнеса.

По сути, один из выводов доклада 2015 State of DevOps Report (о состоянии DevOps) подтвердил, что по возрасту приложения сложно предсказать его производительность. Для такого предсказания надо определить, было ли оно спроектировано (или перепроектировано) для обеспечения удобства тестирования и развертывания.

Команды, поддерживающие гринфилд-проекты, могут быть очень восприимчивы к экспериментированию с DevOps. В частности, в этой области широко распространено мнение, что традиционные методы недостаточны для достижения целей, и существует твердое ощущение неотложной необходимости совершенствования [41].

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

Можно привести следующие примеры успешных преобразований браунфилд-проектов.

• Компания CSG (2013 г.).В 2013 г. компания CSG International получила 747 миллионов долларов дохода и имела более 3500 сотрудников, более 90 тысяч агентов службы поддержки клиентов для выставления счетов и обслуживания более чем 50 миллионов клиентов, пользующихся услугами видео- и голосовой связи и передачи данных. Каждый месяц выполнялось более шести миллиардов операций, печатались и рассылались по почте более 70 миллионов бумажных счетов. Первоначально улучшения должны были охватить печать документов, одно из их главных занятий, использующее приложение для мейнфреймов, написанное на языке COBOL и связанное с двадцатью технологическими платформами. В качестве составной части трансформации компания приступила к выполнению ежедневных развертывания в среде, близкой к производственной, и в два раза чаще стала выпускать обновленные версии для клиентов, — не два, а четыре раза в год. В результате была значительно увеличена надежность приложения, а время развертывания кода сократилось с двух недель до менее чем одного дня.