Елена Москвичева
«Проект „Феникс“. Роман о том, как 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-сопровождения, укорачивали дедлайны, не присылали полных инструкций, необходимых для успешных тестирований. Отдел безопасности без уведомления вводил бессмысленные изменения, из-за чего происходили сбои. На ранних этапах разработки ПО не прорабатывалось совместно различными специалистами);
• зависимость работоспособности отдела от одного специалиста
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.