Быстрая разработка и развертывание приложений недостаточны для достижения цифровизации — необходимо также перестроить ИТ-операции, пишет на портале ComputerWeekly аналитик Gigaom Джо Фэй.
Является ли цифровая трансформация исключительно вопросом скорости? Так вполне можно подумать, учитывая, что она обычно ассоциируется с переходом к более быстрому развертыванию ПО, функций и услуг.
Теоретически считается, что чем быстрее вы запустите их в производство, тем быстрее начнете получать выгоду. Из этого следует, что чем быстрее удастся устранить все препятствия на пути внедрения, тем быстрее разработчики и дизайнеры начнут творить волшебство, ускоряя развитие новых бизнесов или оживляя старые, дряхлеющие организации.
Стремление к непрерывному или, по крайней мере, быстрому развертыванию обычно сопровождается переходом в облако или, по крайней мере, в облакоподобную архитектуру с большим количеством средств автоматизации. Может показаться, что лучшее, что могут сделать операционные сотрудники, — это просто уйти с дороги.
Но, несмотря на то что этот путь может показаться проторенным, лишь немногие дошли до его конца, отмечает генеральный директор HashiCorp Дэйв Макджаннет. По его словам, облако может служить движущей силой модернизации, но в то время как некоторые люди пользуются этим очень хорошо, большинство так не делают, а некоторые делают это очень плохо.
«За последние семь-восемь лет мы поняли, что для успеха действия людей должны быть невероятно последовательны, — говорит Макджаннет. — Я не очень люблю триптих из людей, процессов и инструментов, но, как оказалось, именно он имеет значение. Изменить один или два элемента недостаточно. Необходимо учитывать все три».
Нет необходимости говорить о том, что Макджаннет выступает за стандартизацию по модели «инфраструктура как код» как часть рецепта успеха, в идеале — в виде инструментария Terraform. Но, по его словам, «вторая вещь, которая необходима для того, чтобы все это работало, — это определенная организационная структура».
Непонимание этого, по мнению Макджаннета, объясняет, почему внедрение облачных технологий в традиционном коммерческом мире происходит так медленно: «Все цифровые аборигены используют много облаков. Но какой процент таких компаний, как Wells Fargo или Goldman Sachs, работает в облаке? Почти никто».
Возможность «операционализировать» переход в облако означает переход от обычных «свободных действий», как правило основанных на использовании Open Source, к подходу, основанному на облачной разработке продуктов или платформенном инжиниринге. «Любая бизнес-группа, успешно внедряющая облачные технологии, организована именно таким образом», — говорит Макджаннет.
Это открывает путь к третьему элементу — процессу, который в конечном итоге определяет, что и как быстро будет развернуто. Как говорит Макджаннет, развертывание может затянуться, поскольку те, кто проводят преобразования, обнаруживают, что они все еще сталкиваются с теми же ограничениями, например, с требованиями служб безопасности и сетевых служб, которые должны быть соблюдены, прежде чем они подпишут изменения. Эти политики могут быть вполне разумными, но их соблюдение с помощью полуручных систем, основанных на тикетах, не способствует быстрому развертыванию.
Если существует условно 29 политик, которые должны быть соблюдены, прежде чем инфраструктура будет предоставлена, то выход — превратить их в кодифицированные правила, которые будут выполняться каждый раз, когда что-то предоставляется. «Может быть, я не могу санкционировать архитектуру в виде кодифицированного правила, но, возможно, 25 из этих 29 правил я действительно могу кодифицировать», — говорит Макджаннет.
Наличие правильных операционных процессов — как традиционных, так и автоматизированных в виде кода — по-прежнему является критически важным для успешной трансформации, которая приведет к ускоренной доставке.
Является ли быстрое развертывание единственной целью трансформации?
Специалист в области кибербезопасности Глен Уилсон считает, что важно четко определить цель. Действительно ли быстрое развертывание является самоцелью? Рассматривая, например, безопасность как «подкомпонент» качества и производительности, он говорит: «Когда вы сталкиваетесь с таким обилием инструментария при очень слабом контроле, то в итоге вы получаете снижение качества, снижение производительности — с точки зрения безопасности». Он считает, что «расширение инноваций важнее, чем их ускорение».
Важно создать среду для экспериментов — разумеется, безопасную и эффективную — и предоставить командам необходимую степень автономии для их проведения. Для этого необходимо, чтобы организация в целом имела целостное представление о своих целях и об инструментах, которые она собирается использовать для их достижения. «Таким образом, команды смогут выбирать свои собственные продукты, инструменты, любые технологии, если они остаются в рамках, заданных организацией», — говорит Уилсон.
Это чем-то напоминает подход платформенного инжиниринга, который отстаивает Макджаннет. Уилсон добавляет, что специалисту по безопасности, возможно, придется работать в нескольких командах, являясь командным игроком в каждой из них. Что, конечно же, очень напоминает Т-образные или даже гребнеобразные навыки, любимые в ITIL.
Какими бы ни были (предполагаемые) операционные препятствия на пути инноваций и преобразований, когда речь идет о переменах, важно понять корень проблемы, прежде чем предлагать значимое решение, которое улучшит, а не просто заменит процесс.
«Если процесс понятен только одному человеку в организации, то техническое решение только усугубит ситуацию с единой точкой отказа, если оно не будет распространяться на большее количество людей. Привычность процесса всегда является препятствием для принятия изменений», — говорит технологический евангелист Cockroach Labs Роб Рейд.
Стоит также помнить, что люди могут — пусть и подсознательно — сопротивляться усилиям по абстрагированию, кодированию или улучшению выполняемых ими задач. И это будет влиять на то, насколько вероятно, что они примут любое предлагаемое решение.
«Если процесс настолько хорошо понятен, что является второй натурой для тех, кто его выполняют, то наша задача как технологов — внимательно выслушать их. Таким образом, мы поймем не только проблему, но и то, как ее решить, чтобы улучшить повседневную жизнь тех, кто используют это решение, — утверждает Рейд. — Мы также должны признать, что наша работа (и наше существование) может представлять угрозу для других сотрудников организации. Поэтому мы должны работать совместно, чтобы улучшить жизнь наших коллег и помочь им в создании ценности».
Однако существует опасность слишком глубокого погружения и зацикливания на отдельных процессах. Каждый процесс — это часть большого целого, и вмешательство в один или два процесса в отдельности может иметь неожиданные последствия для всей организации.
А как насчет трансформации операций?
Джон Коллинз, вице-президент Gigaom и бывший технический директор, считает, что платформенный инжиниринг, безусловно, представляет собой развитие DevOps, который был нацелен на ускорение доставки ПО и сервисов и, более того, на обеспечение их непрерывности, без необходимости задумываться о базовой инфраструктуре. Платформенный инжиниринг признает, что разработчикам необходимо понимать базовую инфраструктуру и заранее проектировать ее.
Но, продолжает Коллинз, «проблема цифровой трансформации заключается в том, что она напрямую затрагивает операционные модели. И здесь мало сказать: „Эй, нам просто нужно измениться“».
По его мнению, нативно-облачный подход может быть достаточным для отдельных приложений и даже для нескольких приложений, выполненных сходным образом. «Но он недостаточен для массивной комплексной инфраструктуры, в которой есть вещи, существующие с
По словам Коллинза, модель «политика как код» полезна, но сама по себе она недостаточна для решения проблем, с которыми сталкивается операционный персонал: нехватка ресурсов и времени, дефицит квалификации и все остальные проблемы. Он считает, что для достижения реального прогресса операционным командам необходимы достижения в области визуализации и наблюдаемости, инсайтов и автоматизации.
«Если ваши операционные процессы неэффективны или несовершенны, то в итоге вы можете получить неэффективную автоматизацию. Вы просто усугубляете проблему или заклеиваете ее пластырем», — говорит Коллинз.
Сложность заключается в том, чтобы изначально иметь правильные операционные процессы и политики для всей организации. Если они верны, то их можно закодировать, но при этом необходимо, чтобы разработчики и проектировщики учитывали их.
По словам Коллинза, если разработчики «становятся собственными уборщиками», то это может привести к излишним накладным расходам на инновации, но «когда они будут проектировать для операционной деятельности, они будут понимать и знать, как она устроена, и это просто хорошая подготовка».
Не помешает и небольшой самоанализ со стороны операционного персонала. По словам Коллинза, эти работники склонны к «чрезмерной процессуализации». «Операционное совершенство — это не попытка достичь нирваны. Речь идет лишь о том, что все, что вы делаете, должно быть ориентировано на операции», — говорит он.
Это означает, что операционная служба должна четко понимать, чего она пытается достичь и как она может способствовать преобразованиям — будь то ускорение развертывания в производство, улучшение качества или повышение безопасности ПО.
Означает ли это, что в конечном итоге необходимость в операционной службе отпадет? Конечно, нет. Ведь, как говорит Коллинз, с пожарами все равно нужно бороться. Вещи часто идут не так. Изменения происходят постоянно. Но если цифровые продукты «созданы для операций», то это освободит время для всех остальных важных задач. И, возможно, обеспечит более быстрое развертывание.
