Текст книги "Саммари книги «Проект „Феникс“. Роман о том, как DevOps меняет бизнес к лучшему»"

Елена Москвичева
«Проект „Феникс“. Роман о том, как DevOps меняет бизнес к лучшему»

Серия: CrossReads: О бизнесе – просто

* * *

DevOps как инструмент преобразований

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

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

Чтобы добиться этого, необходимо:

1. сформировать корпоративную культуру доверия,

2. наладить коммуникацию между различными сотрудниками на всех этапах работы,

3. способствовать интеграции между IT-подразделениями.

В книге авторы на примере вымышленной корпорации рассматривают основные проблемы в IT-деятельности бизнеса, определяют способы их выявления и решения и рассказывают о Трёх Путях, которые помогают наладить и улучшить внутренние IT-процессы компании.

Parts Unlimited – один из крупнейших производителей и продавцов автомобильных запчастей. Но в условиях современной конкуренции компания проигрывает, так как не может быстро реагировать на потребительские нужды. Вернуть компании её преимущества и восстановить уровень прибыли рассчитывали благодаря проекту «Феникс». Однако запуск программы постоянно откладывался из-за различных сбоев и пропусков. Правление Parts Unlimited поставило перед генеральным директором Стивом Мастерсом задачу исправить положение за шесть месяцев, иначе организация будет разделена. Специалист в свою очередь потребовали разобраться со всеми проблемами в IT-процессах корпорации Билла Палмера, которого назначили вице-президентом отдела IT-поддержки. План практически невыполним, ведь последние десять лет директора по информационным технологиям сменяются каждые два года, а специалисты области между собой называют эту должность концом карьеры («CIO – Career is Over»).

В текущем положении внедрение методологии DevOps оказалось для Parts Unlimited единственным способом спасти ситуацию. Компании нужно было выполнить несколько шагов:

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

• начать систематизацию и автоматизацию процессов (чем больше процессов в работе выполняется автоматически по строгим, простым и понятным алгоритмам, тем быстрее процесс производства, деятельность завода или IT-отдела);

• расставить приоритеты (выявить первоочередные задачи и избавиться от лишней нагрузки, что позволит сфокусироваться на проектах, которые принесут реальную пользу);

• изменить внутреннюю культуру компании (создать атмосферу взаимопомощи, доверия и понимания деятельности всей компании, а не только собственного производственного участка; такое отношение позволяет с максимальной пользой расходовать ресурсы для успеха всей системы);

• составить чек-листы проверок и оценить улучшения (разработка системы анализа и изучение полученных данных позволяют определить сильные и слабые стороны и наметить дальнейшие пути развития и исправлений).

Выявление ключевых проблем

Прежде чем что-то менять в компании, нужно определиться с фронтом работ, а именно:

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

• определить роль каждого отдела в работоспособности всей компании.

В первый день назначения на должность вице-президента отдела IT-поддержки Билл Палмер столкнулся с серьёзными системными сбоями, давящими дедлайнами и отсутствием необходимой для работы информации. Его отдел работал хаотично, а руководство понятия не имело об объёмах задач и степени загруженности специалистов. Вместе с тем сотрудники не понимали собственных обязанностей.

В рабочих процессах можно было выделить несколько главных проблем:

• загруженность работников отдела внеплановыми задачами (специалисты выполняли неизвестные бизнес– и внутренние IT-проекты, а также попадали под влияние регулярных неконтролируемых изменений и форс-мажоров; любой сотрудник компании по желанию мог загрузить специалистов IT-отдела работой, не несущей в себе никакой пользы для организации);

• отсутствие понимания приоритетов (важность той или иной задачи определялась положением в компании того, кто продвигал проект, и уровнем громкости его голоса);

• низкий уровень коммуникации с отделами безопасности и разработчиками (разработчики часто конфликтовали с отделом IT-сопровождения, укорачивали дедлайны, не присылали полных инструкций, необходимых для успешных тестирований. Отдел безопасности без уведомления вводил бессмысленные изменения, из-за чего происходили сбои. На ранних этапах разработки ПО не прорабатывалось совместно различными специалистами);

• зависимость работоспособности отдела от одного специалиста (ведущий инженер Брент Геллер был единственным человеком в Parts Unlimited, который мог исправить очередной сбой. Без него работа останавливалась, а самому специалисту приходилось отвлекаться от непосредственных задач, чтобы наладить работоспособность системы);

• частично устаревшее оборудование и ПО (многие форс-мажоры в компании случались из-за программ и систем, которые с трудом перестраивались под новые задачи бизнеса, поскольку их разработчики давно отошли от дел. Не было и оборудования, способного поддерживать функционирование IT-отдела);

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

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

Билл Палмер выявил слабые места своего отдела и осознал, что команду можно сравнить с «бутылочным горлышком» – ограниченным ресурсом, задающим темп работы всей компании. Требовалась такая система, которая бы четко контролировала «входной поток» и оберегала от работы на износ, повысила бы качество и эффективность действий.

Систематизация и автоматизация

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

Чтобы заставить отдел IT-сопровождения работать четко и структурированно, Билл Палмер вместе с директором по внешним техническим операциям Вэсом Дэвисом и директором отдела поддержки Патти МакКи разработал и внедрил систему управления изменениями. Алгоритм фиксировал любое изменение в ПО компании и отводил для его выполнения определённое время. Система представляла собой карточки, на которых указывалось:

• кто вносит изменения;

• в чем они заключаются и какие системы могут затронуть;

• когда предполагается их производить;

• нужно ли для этих изменений привлекать Брента Геллера как ведущего специалиста.

Все изменения были разделены на несколько основных групп:

1. «стандартные» – постоянные изменения с низким уровнем риска, которые в 99 % случаев проходят без сбоев и нарушений. Такие процессы не требуют одобрения на собраниях;

2. «изменения среднего уровня риска» – одобрять которые должны профильные специалисты.

3. «хрупкие» – наиболее рискованные изменения, которые могут затронуть всю деятельность компании. Они должны одобряться на совете CAB, а кроме того информацию о них необходимо отправлять бизнес-руководству.

Помимо прочего, карточки были разделены по цветовому принципу на четыре группы:

1. сиреневые – для изменений, способных поддерживать работоспособность топ-5 бизнес-проектов;

2. жёлтые – изменения для всех остальных бизнес-проектов;

3. синие – внутренние проекты по совершенствованию IT-инфраструктуры;

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

Также нужно было разгрузить ведущего инженера. Для этого выполнили несколько последовательных действий:

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

• во-вторых, была создана особая группа инженеров третьей линии, цель которых – устранение форс-мажоров. Они должны были собирать информацию и искать решения проблем. Связаться с ведущим инженером они могли лишь с согласия руководства. Всё, чему научились у него, они обязаны были фиксировать, чтобы оградить Брента от мелкой работы;

• в-третьих, к Бренту не могли обращаться сотрудники других отделов, кроме IT-сопровождения.

Билл Палмер выделил четыре типа работы IT-отдела:

• бизнес-процессы;

• внутренние IT-процессы;

• изменения;

• незапланированная работа.

Первые три типа – контролируемые, которые можно выполнить в назначенный срок. Для полного понимания был создан список с описанием задачи и примерным временем на её выполнение.

Незапланированная работа появляется внезапно, отнимает много сил и времени, отвлекает от настоящих целей и не позволяет бизнесу двигаться вперёд. Чтобы деятельность организации велась эффективно, количество задач такого типа необходимо снижать. Для этого Билл Палмер:

• ввёл контроль изменений, чтобы они не вызывали сбоев;

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

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

Систематизации подверглись все базы данных компании. Единое хранилище данных позволяло использовать их совместно в различных проектах, не опасаясь сбоев.

Наконец, было решено максимально систематизировать, автоматизировать и визуализировать самые основные сервисные запросы сотрудников, такие как: «смена рабочего места», «добавить/удалить аккаунт», «предоставить новый стационарный компьютер/ноутбук», «восстановить пароль».

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

• необходимые шаги для выполнения,

• какие специалисты должны быть привлечены к задаче;

• время выполнения операции.

Это значительно ускорило обработку и выполнение заявок, а также улучшило эффективность работы всей компании.

Расстановка приоритетов, превентивные меры

Для IT-отдела один из основных критериев выбора проекта для запуска в разработку – его польза для деятельности компании. Также важны объём и перечень необходимых для реализации ресурсов.

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

• временная заморозка поступающих проектов снизила мультизадачность и значительно сказалась на производительности;

• фокусировка всех сил на проектах-приоритетах, «Фениксе» и других наиболее активных задачах;

• выбор пяти наиболее важных проектов, которые можно было запустить в работу после снятия заморозки.

В дальнейшем каждый крупный проект рассматривали с точки зрения полезности его для бизнеса и возможности снизить нагрузку на отдел IT-сопровождения после его развертывания. Только если проект удовлетворял этим параметрам, его брали на разработку.

Чтобы расставить приоритеты в работе, Билл Палмер вместе со своими коллегами принял решение определиться со списком целей компании. Он выявил основные вопросы, ответы на которые должны были проложить курс дальнейшим действиям.

1. Мы конкурентоспособны?

2. Понимаем ли мы желания и потребности клиентов, знаем ли, что производить?

3. Есть ли у нас правильные товары?

4. Эффективна ли наша исследовательская работа?

5. Можем ли мы поставлять продукты вовремя, чтобы они были востребованы?

6. Можем ли предоставлять продукты заинтересованным заказчикам?

7. Мы эффективны?

8. Хорош ли уровень доставки, получают ли клиенты то, что мы им обещаем?

9. Мы удерживаем или теряем клиентов?

10. Можем ли мы опираться на прогнозы продаж при планировании?

Анализ направлений помог лучше понять задачи, на которых должен сфокусироваться IT-отдел. Среди них, например:

• помощь в своевременной генерации отчетности для увеличения точности продаж и понимания потребностей потребителей,

• работа над небольшими профильными проектами, которые позволят увеличить скорость выхода на рынок, чтобы быть востребованными;

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

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

• сократить размах программы, отвечающей за соответствие SOX-404 (оказалось, контролировать риски по аудиту можно без привлечения IT-службы);

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

• особым образом помечать в системе контроля изменений системы, связанные с аудиторами, чтобы избежать сомнительных последствий;

• сократить размер программы по проверке уязвимых мест, избавившись от лишних данных;

• сэкономленное время потратить на выполнение всех технических обязательств по «Фениксу», избавив его от стратегических, операционных рисков и рисков системы безопасности.

Выявление приоритетных направлений, понимание целей корпорации, а не задач отдельных её участков привело к перестройке внутренней работы компании и её культуры.

Изменение внутренней культуры компании

До преобразований различные отделы компании, в том числе и IT, часто конфликтовали друг с другом. Каждый отдел стремился занять всё время на отведённые задачи, не задумываясь о том, смогут ли коллеги выполнить работу в указанные сроки. Атмосфера недоверия и стремление к демонстрации собственных успехов в обход партнёров приводило к снижению эффективности бизнеса.

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

IT-отдел стал преображаться:

• стандартизировались инструменты, приложения и программы, которые специалисты использовали в работе;

• были созданы локальные команды тестировщиков, разработчиков и «безопасников», которые совместно прорабатывали новые продукты. Это высвободило время – больше проект не передавали с одного участка на другой;

• сотрудники не только определились со своими задачами, но и выяснили цели компании, узнали свою роль в их достижении;

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

Принцип методологии DevOps заключается в совместной командной работе всех производственных участков бизнеса. Необходимо убедить работников, от руководителей до рядовых специалистов, поменять привычные изолированные способы работы и расширить командное сотрудничество. В конечном счёте для успешной деятельности бизнеса IT-отдел должен работать слажено, как единый организм, и максимально интегрироваться во все бизнес-процессы. Только тогда он сможет обеспечить компанию необходимой скоростью, стабильностью, а в итоге – высокими результатами и продуктивностью.

Разработка чек-листов и оценка произведённых улучшений

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

В Parts Unlimited было принято решение – определять время для каждого нововведения, по прошествии которого можно было бы с уверенностью сказать о его успехе или провале. В IT-отделе нашла применение практика учебных тревог, которая позволяла:

• проверить систему сбора данных о форс-мажорах;

• максимально сократить и автоматизировать все действия персонала по их решению;

• определить и при необходимости уменьшить уровень уязвимости используемых приложений.

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

Тренировки подготовили команду к непредвиденным ситуациям, максимально сократили время решения проблем, а некоторые и вовсе предотвратили. Тренинги позволили руководству оценить продуктивность работы.

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

Философия Трёх Путей

Введение и успешное применение методологии DevOps невозможно без понимания Трёх Путей. В основе Первого Пути – отладка скорости потока работы. На этом этапе необходимо:

• исправить основные дефекты рабочего процесса,

• максимально систематизировать и автоматизировать работу,

• определить собственные ограниченные ресурсы;

• организовать темп работы производственных участков исходя из ограничений;

• расставить приоритеты в бизнес-процессах.

Суть Второго Пути в том, чтобы сократить и усилить цикл обратной связи. Это позволит фиксировать качество производимой продукции, избегать переделок. В случае с Parts Unlimited на этом этапе Биллу Палмеру нужно было наладить обратную связь между отделом IT-сопровождения и разработчиками. В результате это позволило создать качественные продукты за короткий срок.

Третий Путь делится на три компонента:

• культуры постоянного эксперимента;

• извлечение уроков из ошибок;

• постоянное повторение и практика.

В Parts Unlimited на третьем этапе запустили специальные коды и стресс-тесты, имитирующие уничтожение сервера и выявляющие проблемы в системе безопасности. Такая культура борьбы с рисками, обучение на собственном опыте и постоянная практика позволяют добиться настоящего мастерства и организовать бесперебойный рабочий процесс.

Философия Трёх Путей – это три столпа DevOps. Она включает в себя первые шаги введения методологии в производство и обозначает основные направления движения для достижения результатов.

10 лучших мыслей книги

1. Любой производственный участок состоит из четырёх компонентов: машина, человек, метод работы и измерения. В IT-отделе машиной являются компьютеры и программы, человеком – специалисты поддержки, методом работы – стандартные шаги для достижения целей. Продукция, которую производят в этом отделе, сложнее визуализировать. Она требует разработки и специальных показателей для определения эффективности.

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

3. Время ожидания задачи в очереди равно проценту «занятого времени», разделённого на процент «свободного». Т. е. если ресурс, необходимый для выполнения задачи, загружен на 50 %, то он так же свободен на 50 %, а значит, время ожидания будет равняться условной единице. Но если ресурс будет занят на 90 %, то время ожидания будет увеличено в 9 раз.

4. Эффективный способ справиться с непредвиденной работой – не допускать её появления. Для этого нужно выявить причины образования срочной задачи и исключить их из рабочего процесса, т. е. ввести превентивные меры.

5. Эффективной работа любой системы будет не тогда, когда много проектов и задач, а когда увеличена отдача, т. е. результаты.

6. Расстановка приоритетов позволяет исключить бесполезные проекты и работать только на результат. Все отделы должны знать и понимать цели компании, чтобы иметь возможность сформулировать единые приоритеты, исключив вариативность трактовок.

7. Контроль процесса передачи работы от одной инстанции к другой – это гарант её выполнения в срок, без «пробок», авралов и ажиотажа.

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

9. Развитие IT-отдела сродни развитию целой компании. И в основе этого процесса должно быть доверие и сотрудничество между всеми членами команды.

10. Успешное внедрение DevOps зависит от последовательного освоения Трёх Путей: отладки быстрого потока работы, сокращения и усиления цикла обратной связи (улучшение коммуникации между отделами), постоянной практики с извлечением уроков из собственных ошибок.