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

Методология 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-сопровождения, укорачивали дедлайны, не присылали полных инструкций, необходимых для успешных тестирований. Отдел безопасности без уведомления вводил бессмысленные изменения, из-за чего происходили сбои. На ранних этапах разработки ПО не прорабатывалось совместно различными специалистами);

      • зависимость работоспособности отдела от одного специалиста