DevOps и CloudOps: ускорение цифровой трансформации

DevOps трансформирует внутренние процессы выпуска программных продуктов и, как следствие, инновации, а CloudOps трансформирует взаимодействие IT с инфраструктурой и архитектурой. Об этой взаимосвязи написали Inforamtion-age.

Два схожих тренда DevOps и CloudOps порождают новые бизнес-модели и делают ненужными старые, переворачивая представление людей о том, как должны предоставляться IT-услуги. С одной стороны, в обоих трендах важно значение процессов и людей, а с другой, инструментов и технологий.

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

Иногда при повороте налево, можно врезаться в стену

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

В DevOps отлаженный набор инструментов работает параллельно с процессом разработки. Это же касается людей, но достижение идеального организационного процесса может быть затруднено, так как каждый обременен различными дополнительными служебными обязанностями.

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

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

Чтобы успешно использовать DevOps как трамплин для цифровой трансформации, стоит последовать советам пионеров гибкой разработки и приобрести экземпляр «The Phoenix Project».

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

Необходимо принять организационные изменения — все когда-нибудь меняется

Каждый IT-менеджер, который боялся, что развитие облачных технологий сделает его невостребованным на рынке труда, может спать спокойно. Дело в том, что существует потребность в том, чтобы такие специалисты нашли свое место в этом новом мире. В ходе недавнего опроса ServiceNow, 75% предприятий сообщили, что использование облачных сервисов усилило роль информационных технологий в бизнесе. К сожалению, 90% предприятий также сообщили, что IT-специалистам не хватало нужных квалификаций для воплощения этих планов.

Традиционные модели обслуживания для облачных вычислений «X как услуга» перекладывали обязанности поддержки IT на кого-то другого. Однако уже наступило будущее с большим количеством облачных компаний, и предприятия, использующие внешние облачные сервисы с целью наиболее оптимальной оптимизации приложений, столкнулись с очень большим количеством инструментов, соперничающих с сервисами из «дооблачной» эпохи (лучше разбить на несколько предложений по 15-20 слов). Решение для тех, кто пользуется облачными технологиями – изучить принципы автоматизации DevOps и применить их для управления гибридным IT… например CloudOps.

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

Роль специалиста по цифровой трансформации

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

В докладе McKinsey & Company определены два фактора, которые могут помешать специалисту по цифровой трансформации. Первый – нет возможности действовать на уровне полномочий гендиректора. Специалист по цифровой трансформации должен действовать от лица гендиректора, чтобы влиять на принятие важных решений.

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

Конец может быть началом

Брэд Паркс, директор по развитию бизнеса в Morpheus Data, рассказал о том, как во время конференции в Лондоне он обсуждал новейшие тенденции трансформации со специалистами по облачной архитектуре и разработчиками, в том числе с представителями Rackspace и Salesforce. Он попросил каждого участника дискуссии дать самый лучший совет аудитории и подумал, что будет полезно поделиться этими наскоро собранными выводами.

1) На первом месте не технологии, а люди.
2) Нужно быть готовым выходить за рамки.
3) Разработка должна быть с учетом непредвиденных обстоятельств.
4) Начинать следует с пониманием конечной цели.

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

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