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