DevOps

Когда год назад глава Сбербанка Герман Греф назвал одним из признаков технологических компаний отсутствие в их структуре ИТ-департаментов и призвал избавляться от них, это вызвало широкий резонанс и массу обсуждений. Но на самом деле речь шла лишь о том, что банк официально признал ИТ своим бизнесом и начал активные действия по его оптимизации. С объявлением курса на Agile функции ИТ начали стремительно охватывать остальные подразделения, расплываясь по ним. Как следствие, лучшие ИТ-практики находят свое применение в нетрадиционных прежде областях. Более того, появляются новые направления карьерного развития для тех ИТ-руководителей, кто желает открыть новые горизонты. Андрей Заварзин, директор дивизиона «Массовая персонализация» Сбербанка, рассказывает об изменениях, обусловленных слиянием ИТ и бизнеса, о ценностях подходов Agile и опыте использования традиционных ИТ-инструментов в нетипичных процессах.

Андрей Заварзин Возраст: 39 лет Послужной список: 2016 – настоящее время Сбербанк, директор дивизиона «Массовая персонализация» 2012 – 2016 Сбербанк, СТО/CIO различных направлений 2010 – 2012 «Альфа-Банк», директор дирекции Business Intelligence 2008 – 2010 Авиахолдинг «Волга-Днепр», директор по ИТ 2004 – 2008 «ЛУКОЙЛ-Информ», советник генерального директора 1999 – 2004 Академия ФСБ, преподаватель факультета прикладной математики Образование: Академия ФСБ, ИКСИ («прикладная математика») РЭА им. Плеханова («стратегический менеджмент») Финансовая академия при Правительстве РФ. Бизнес-школа

Вы пришли в Сбербанк, когда крылатая фраза про «ИТ-компанию с банковской лицензией» еще произнесена не была. Как ИТ входили в бизнес, какие ключевые этапы можно выделить?

Это действительно очень интересная трансформация. И очень динамичная. За тот период, что я в Сбербанке, мы прошли уже четыре стадии! В 2012 году я пришел в «Сбербанк Технологии» (ИТ-дочку Сбербанка) на должность начальника управления в департамент клиентских отношений и наблюдал все проходившие изменения непосредственно в ходе своего карьерного роста.

Идея создания департамента клиентских отношений в «СберТехе» была в том, чтобы централизовать управление ИТ-развитием в интересах конкретного блока (бизнес-блока или обеспечивающего), потому что тогда в «СберТехе» никто не отвечал перед конкретным членом правления Сбербанка за результат всех своих проектов, не отслеживал взаимосвязи между ними. Я отвечал за все проекты операционного блока, и моим визави была его руководитель Ольга Канович. Такая модель управления очень понравилась правлению, и вскоре ее решили расширить. Теперь ИТ-директор блока (CIO) должен был отвечать не только за ИТ-проекты, но и за все ИТ-роли – архитектуру, аналитику, разработку, проектное управление, тестирование, внедрение, сопровождение. А раз так, то это должна была быть роль в центральном аппарате, а не в ИТ-дочке. Так ИТ начали постепенно проникать в основной бизнес.

В дальнейшем я был назначен CIO всех обеспечивающих блоков – к операционному блоку прибавились безопасность, управление кадрами, стратегия. Мы выстраивали процессы не только развития, но и сопровождения, заключали соглашения об уровне обслуживания (SLA). Эта модель тоже «взлетела», и мы пошли дальше – ввели должность Chief Technology Officer. Произошло создание блока «Технологии» на базе блока ИТ и операционного блока, а СТО стал отвечать не только за ИТ, но и за операционную деятельность, одновременно накапливая ресурсы и экспертизу по сквозным бизнес-процессам. Так я стал СТО розничного бизнеса. Чтобы решать задачи, я мог внедрять ИТ или ручные процессы, балансируя скорость, стоимость и качество. По задумке, СТО должен был стать чуть ли не вторым человеком в бизнесе, так как глубоко понимал процессную составляющую всех направлений.

И здесь пришел Agile – пришел весьма стремительно. В январе 2016-го мы первый раз съездили с референс-визитом в голландский финансовый конгломерат ING, а уже в сентябре 2016 года Герман Оскарович дал старт Agile в новом офисе на Кутузовском (мы этот офис называем Agile home). Идея, что бизнес на самом деле и есть ИТ (и наоборот), означала, что все действующие лица должны перемешаться. И в такой модели роли CIO или CТO уже не требовалось. Для меня это стало не угрозой для карьеры, а новой возможностью. Я получил новое назначение – возглавил дивизион «Массовая персонализация», который отвечает за розничные данные, моделирование, персональные предложения во всех каналах, вторичные продажи и телемаркетинг. На мой взгляд, это самая интересная область бизнеса.

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

«Сбербанк накрыло волной цифровой трансформации, и все те математические и технические знания, которые у меня накопились, стали абсолютно востребованными в основной деятельности банка»

Правомерно ли говорить о цифровой трансформации организации без изменения ее бизнес-модели?

Действительно, трансформация может быть, что называется, Disrupt. Это наиболее радикальный вариант – изменение бизнес-модели. Но можно говорить и о Change – трансформации внутренних процессов, когда они принципиально меняются.

Например, бизнес-модель Сбербанка, касающаяся выдачи кредитов, не поменялась. Еще в 2008 году был принят курс на то, что у нас должна быть самая лучшая риск-служба. Мы сделали очень качественный полуручной процесс. Профессиональные сотрудники проверяли документы и принимали решение о выдаче кредитов. У нас действительно была лучшая система управления рисками, мы хорошо определяли, кому следует давать кредиты, а кому – нет. Дальше началась эра больших данных, и ручной труд стал замещаться алгоритмами. При этом качество нашего портфеля продолжает расти. Бизнес-модель не менялась, просто один из процессов, который был полностью ручным, стал полностью цифровым. Один из моих совместных проектов с департаментом рисков – «Ноль полей в анкете». Мы не должны заставлять нашего клиента ждать и тратить лишнее время.

Что касается мобильных приложений, то они, я считаю, в традиционном виде будут постепенно умирать. Клиенты все больше предпочитают взаимодействовать с виртуальным ассистентом, а не самостоятельно вносить данные. Если раньше у нас был лозунг Mobile first, то теперь – Artificial Intelligence first, и все, что мы делаем, должно восприниматься через призму анализа данных. Тенденция очевидна: все большая доля поисковых запросов в Google происходит посредством голоса, и дальше она будет расти как снежный ком. Пока виртуальные помощники, конечно, «сырые», но развиваются очень быстро.

Agile в Сбербанке, который благодаря усилиям Германа Грефа стал широко известен даже далеким от ИТ людям, – это в первую очередь скорость и гибкость или это больше ориентация на потребности бизнеса?

Скорее, речь нужно вести о результате. Этот подход позволяет добиться того, что нужно. Заметьте, не «того, что хотели», а «того, что на самом деле нужно», так как изначальная цель вполне может в ходе проекта поменяться. Однако не менее важны культурные изменения в работе.

У меня весьма богатый опыт ИТ-директора, я неоднократно видел, с какой разницей одни и те же ребята работают вместе и по отдельности. Раньше «СберТех» чувствовал себя отдельным организмом, иногда даже противопоставлял себя «большому» Сбербанку. Но если людей из разных подразделений усадить вместе, они начинают работать совершенно по-другому. У них появляется удовольствие от работы – так называемый фан. Раньше я видел в подразделениях обычную, размеренную работу. Но, когда айтишники сталкиваются с реальными клиентами и конкретными задачами, с реальной ответственностью за то, что делают, и когда видят конечный результат работы, все меняется.

«Если людей из разных подразделений усадить вместе, они начинают работать совершенно по-другому. У них появляется удовольствие от работы – так называемый фан. Когда айтишники сталкиваются с реальными клиентами и задачами, с реальной ответственностью за то, что делают, и видят конечный результат работы, все меняется»

Удовольствие от работы имеет и оборотную сторону. Если в ИТ-департаменте были недостаточно эффективные люди и это мало кого заботило, то agile-команда, взявшая на себя определенные обязательства, каждые две недели должна отчитываться за спринты. Если рядом сидит ничего не делающий балласт, то многие вспоминают фразу Атоса перед дракой с гвардейцами кардинала: «А потом скажут, что нас было четверо», – и команда самоочищается.

Неужели всё так просто – сели вместе и начали «получать удовольствие»? Не все к этому бывают готовы. И как быть с раздуванием штата? Для организации такого масштаба это критично...

Да, может показаться, что создание самодостаточных agile-команд способствует раздуванию штата. Но, когда в «СберТехе» работают 10 тыс. человек, разобраться, кто из них лишний, возможности нет. А вот когда мы их пересаживаем в отдельные команды, то, во-первых, сразу видно, кто работает, а кто – нет, и шлак отсеивается. Во-вторых, видно, сколько погонял-руководителей приходится на одного конкретного исполнителя. Выясняется, что столько руководителей не нужно, и происходит сокращение численности.

Сокращение также происходит за счет людей, не принимающих новые подходы. Например, у меня на протяжении долгих лет был личный кабинет, а сейчас я сижу в открытом пространстве в шумоподавляющих наушниках. Перемены, прямо скажем, непростые. В ING нам сказали, что при переходе в Agile они практически одномоментно потеряли 30% персонала. По моей оценке, Сбербанк покинуло поменьше народа, но тоже ощутимо. Надо сказать, что позитивных примеров гораздо больше. Ключевые соратники перестроились, набрали команды и сейчас показывают удивительные результаты.

Если говорить о более низком уровне, то где-то получилось перестроиться сразу, где-то нет. Я уже полгода пытаюсь решить задачу, как подружить в рамках единой команды исследователей данных, CRM-менеджеров и людей, занимающихся маркетинговыми кампаниями. Они не очень-то доверяют друг другу. Готовлю их, чтобы избежать потрясений, показываю плюсы и минусы. Для этого я использую институт agile-коучей, часто работающих как психологи. Они следят за климатом и помогают правильно скомбинировать людей.

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

Какие эффекты и последствия имело слияние ИТ с бизнесом?

Один из самых трудных вопросов, когда мы переходили на Agile, был такой: «Кто ответит за надежность?» Именно с надежностью ассоциируется Сбербанк. Развивая функциональность команды, мы поняли, что за надежность бизнес-сервиса должна отвечать именно команда, занимающаяся этим продуктом, а не только централизованная ИТ-служба. Часть служб, функций по поддержке той или иной конкретной системы передается в agile-команду, отвечающую за ее развитие.

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

ITSM – это именно про надежность и стабильность работы. Сейчас часть функций, отвечающих за это, перенесена в agile-команды. Мы, проверяя себя, задавали вопрос, кто пойдет «на ковер» в голландский парламент (у ING, как и у Сбербанка, около 50% доли местного рынка), если случится простой системы, – ИТ-директор или кто-то другой. Как выяснилось, ответственность лежит на руководителе, контролирующем продукт, – это product owner, central product owner или лидер трайба (трайбы – названия подразделений в методологии Agile. – Прим. ред.). Это особенность культуры – больше нет конфликта между развитием и сопровождением систем, жестких границ и непримиримых позиций. Есть команда, которая сама решает свои проблемы и, естественно, проблемы клиентов.

Фото: Сбербанк

Правильно ли противопоставлять классический ITSM, фокусирующийся на качестве, и гибкие методики? Возможно ли их подружить?

Agile и ITSM вовсе не являются конкурентами. Совершенно не нужно их противопоставлять, надо брать из каждой модели лучшее и комбинировать, важно уйти от поклонения какой-либо одной методологии. Да, ITSM изначально фокусируется на эксплуатации систем (Run), а Agile – на изменениях (Change), но в современном мире Run становится частью Change.

Кстати, ITSM – замечательный подход, который я уже второй раз применяю там, где раньше им даже не пахло. Я перестраиваю работу бизнес-подразделения в соответствии с ITSM, потому что требуется управлять инцидентами и проблемами. Это два базовых процесса для любого руководителя, не только ИТ.

В 2012 году, когда меня принимали на работу в Сбербанк, я проходил собеседование с двумя членами правления – тогдашним руководителем блока ИТ Виктором Орловским и руководителем операционного блока Ольгой Канович. Орловский спросил меня, какие управленческие инструменты я использую, мы начали это обсуждать. Он рассказал про свои – например, модель типологии менеджеров Адизеса. Я – про свои, в том числе о том, как применял ITSM в «Альфа-Банке» для решения совершенно нетипичной задачи – повышения качества информации.

Я пришел в «Альфа-Банк» руководить дирекцией Business Intelligence – это была очередная попытка уйти из ИТ. Весь банк с недоверием относился к той информации и отчетности, которую выпускала наша дирекция. Финансовые директора блоков говорили, что не могут управлять бизнесом. Например, невозможно мотивировать клиентских менеджеров на продажи, если результат не соответствует реальности. Такие недоверие и недовольство отражали объективное положение дел, но в каждом случае были очень субъективными. Претензии к отчетности предъявляли телефонными звонками, гневными письмами и т. д. Я перевел все претензии к отчетности в службу поддержки и создал соответствующую группу разбора. Через пару месяцев мы точно знали, в каких строках отчетности содержатся ошибки, каковы причины этих ошибок, кто из людей находит реальные ошибки, а кто «спамит» и перекладывает на других ответственность за свои плохие продажи. Я с удивлением увидел, что самые большие ошибки дают не технологии, а сбои на стыках процессов. Через полгода ситуацию удалось полностью выправить. Я не слышал до этого, чтобы кто-то применил ITSM для выпуска управленческой отчетности.

То же самое я внедряю сейчас в своем нынешнем подразделении – только применительно к персональным предложениям Сбербанка. Мы обслуживаем 100 млн клиентов, и все наши ошибки в данных, моделях, процессах влияют на всю страну. Создана точка входа в службу поддержки, через которую я получаю все претензии к персональным предложениям и улучшаю нашу работу.

Про agile-трансформацию, начатую в 2016 году, слышали все. А с марта 2017 года наступила ее вторая, менее разрекламированная стадия – переход на DevOps. Что реально изменилось?

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

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

Андрей Заварзин, директор дивизиона «Массовая персонализация» Сбербанка: «У меня на протяжении долгих лет был личный кабинет, а сейчас я сижу в открытом пространстве в шумоподавляющих наушниках»

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

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

Итак, ITSM в бизнесе – уже пройденный этап, его эффективность доказана. А DevOps в бизнесе?

Да, у меня ситуация еще интереснее, чем в ИТ-службах. Наш дивизион занимается управлением розничными данными, их анализом и формированием кампаний. У нас есть много различных ролей: инженеры по данным; аналитики, просчитывающие результаты кампаний; классические исследователи данных, строящие глубокие модели; специалисты по кампаниям в реальном времени, строящие инфраструктуру для создания автоматических предложений в контексте жизненных ситуаций. Есть и более традиционные специалисты по статическим кампаниям, занимающиеся вопросами CRM и управления рисками.

Эти люди раньше сидели в отдельных «колодцах». А мне нужно «шить костюм», демонстрировать клиентам ценность, и ценность дает именно комбинация всех ролей. Как и в случае с ITSM, я использую Agile иногда вообще не там, где можно ожидать. В тех случаях, когда идет речь о работе с данными, все относительно традиционно: есть бизнес-специалисты и ИТ-специалисты, они объединяются в команды и строят компоненты клиентского профиля. Но параллельно с ними работает слой анализа кампаний – это полностью бизнесовые роли, и я их тоже комбинирую, формируя эффективные команды.

Конечно, подход DevOps – полностью айтишный: он заключается в том, что необходимо иметь возможность оперативно протестировать функциональность, отследить обратную связь. Я делаю «бизнес-DevOps»: например, у нас есть гипотеза относительно того, какие предложения будут хорошо восприняты клиентом. Мы берем выборку из тысяч людей (в Сбербанке это можно себе позволить) и делаем автоматизированную систему, чтобы специалист настроил параметры кампаний и на следующий день уже видел результаты. В этом случае можно поправить параметры и мгновенно запустить следующую итерацию. Таким образом, DevOps применяется в абсолютно бизнесовых процессах. Раньше такого никогда не делали – специалист может пропилотировать модель, она пройдет по всей стране и соберет отклик, и на следующий день будет видно, на правильном ли мы пути.

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

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

Это разделение основывалось на простом принципе: разработчики занимались только кодом, специалисты по эксплуатации принимали код и следили за тем, чтобы он выполнялся. Отсутствие связи между двумя группами приводило к длительным циклам контроля качества и максимально редким рабочим развертываниям, что было обусловлено страхом простоев и нарушений работы.

Из-за внутриорганизационных границ, стремления избежать рисков и последовательных, основанных на принципе «водопада» методов поставки ПО, между масштабными обновлениями систем мог пройти целый год, а то и больше. Во многих крупных организациях такие методы применяются и по сей день.

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

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

И это не мимолетная «мода». Тенденция автоматизации постепенно развивается уже около десяти лет, и сегодня соответствующее ПО и процессы достигли высокого уровня зрелости, а потому игнорировать приход DevOps в корпоративные отделы ИТ невозможно.

Организации, где все еще не понимают важности DevOps и не готовы к соответствующим изменениям, окажутся в отстающих.

Как DevOps влияет на разработчиков

Корни DevOps – в таких инструментах, как Puppet, который появился в 2005 году, еще до самого термина DevOps. Его автор Люк Канис, программист на Ruby, решил покончить с необходимостью постоянно вручную менять конфигурационные файлы Linux. Он хотел добиться того, чтобы можно было готовить к работе и конфигурировать Unix-подобные системы автоматически с возможностью повторения соответствующих процессов. Эту задачу Канис решил, написав на Ruby скрипт, который он и назвал Puppet.

Позднее появились другие похожие инструменты: Chef, Ansible, SaltStack и пр., – и вокруг каждого из них сформировались свои сообщества. Разработчики и специалисты по эксплуатации делятся знаниями, добавляя их в виде «рецептов» (recipe) в «поваренные книги» (cookbook), помогающие конфигурировать ПО нужным образом независимо от используемого дистрибутива Linux.

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

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

В связи с этим появился еще один класс инструментов – платформы в виде сервиса (PaaS). Провайдерами первых систем такого рода стали компании Salesforce и Google, но от разработчиков требовалось написание кода, привязывающего к конкретной платформе. PaaS достигли популярности, лишь когда компания Heroku предложила сервис, который давал возможность выполнять код и на других платформах с минимальными изменениями.

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

Говоря о DevOps, нельзя не упомянуть Docker и контейнеры. Главный недостаток PaaS в том, что платформа жестко задает архитектуру приложения. Если разработчику нужно больше контроля над средой, добиться этого, сохранив скорость и гибкость, можно с помощью контейнеров. Настройка среды с помощью Chef или Puppet с нуля может занять несколько часов, и при этом вы можете не получить точной копии исходной среды. А воспользовавшись контейнером, программист может воспроизвести среду Linux или Windows меньше чем за секунду, и это будет абсолютно идентичная копия оригинала.

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

Как DevOps влияет на эксплуатацию

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

До DevOps именно сисадмины отвечали за работоспособность крупномасштабных приложений. Им приходилось настраивать СУБД и веб-серверы, конфигурировать балансировщики нагрузки, управлять безопасностью, системами кэширования и т. п.

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

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

Платформы и средства DevOps создали буфер, благодаря которому команды разработки и эксплуатации могут действовать независимо друг от друга. До появления таких инструментов существовал последовательный конвейер выпуска приложения. Перед тем как новое приложение развертывали, нужно было делать массу запросов в отделы эксплуатации и закупок, а затем дожидаться конфигурирования серверов.

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

Этот технологический буфер позволил разорвать последовательный жизненный цикл приложения, дав разработчикам и специалистам по эксплуатации возможность более тесно взаимодействовать. Возможно, выглядит противоречием то, что разрыв зависимости позволил сблизить соответствующие команды, но ведь главное здесь – не допустить ситуацию, когда «у семи нянек дитя без глаза». Если позволить работать программистам в рамках четко заданной системы (писать код для готовой к его приему среды), а команде эксплуатации – за пределами «контейнера», то между «няньками» будет четкое разделение ответственности.

Сами инструменты DevOps, то есть то, что сближает группы разработки и эксплуатации, стали экосистемой взаимодействия, где разграничение обязанностей размывается. Специалисты по эксплуатации очень хорошо знают оптимальные методы администрирования и сопровождения сложных программных систем. А разработчики умеют «обучать» компьютеры применению этих знаний без участия человека.

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

«Добродетельный» круг

Знаменитое высказывание Марка Андриссена, инженера, инвестора и предпринимателя, одного из сооснователей Netscape Communications, о том, что «программное обеспечение пожирает мир» справедливо для сборки и выполнения приложений так же, как для вызова такси или бронирования гостиничного номера. На протяжении десятилетий сопровождение приложений лежало на плечах элитной группы высококвалифицированных сисадминов, а сегодня этим могут заниматься любые сотрудники отдела ИТ.

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

Использование DevOps стало превращать все эти «эзотерические практики» в открытые стандарты, подробно документируемые вместе со всеми изменениями. Соответствующие знания теперь можно превратить в программную логику, на основе которой строятся платформы в виде сервиса и кластеры Linux-контейнеров и которую можно дублировать, чтобы делиться с другими.

По мере того как разработчики осваивают знания об эксплуатации, а сисадмины совершенствуются в программировании, их роли объединяются. Границы уже сегодня стираются, и появляются все новые инструменты взаимодействия между группами, сотрудничество которых некогда было минимальным.

Docker, лидирующая платформа управления контейнерами, стала типичным плодом этой эволюции. Сервис GitHub дает разработчикам открытую среду обмена кодом и упрощенного взаимодействия. Docker Hub обеспечивает такую же простоту взаимодействия для сисадминов, запуская очередную волну перерождения методов развертывания инфраструктуры и управления ею.

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

– Lucas Carlson. How devops changes both dev and ops. InfoWorld. October 4, 2017

Если бы Ахиллес был ИТ-директором, его сгубил бы самообман. Непреложная уверенность в том, что ИТ-служба и бизнес-подразделения действуют согласованно, информационная безопасность пуленепробиваема, а все проекты реализуются вовремя, стала бы его «уязвимой пятой». А между тем, обманывая себя, ИТ- руководители закладывают мину замедленного действия и создают предпосылки для грядущих катастроф.

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

Давайте рассмотрим девять ситуаций, в которых ИТ-директор обманывает не подчиненных или коллег по бизнесу, а самого себя.

Иллюзия № 1. Мы ориентируем ИТ на бизнес.

Добиться соответствия своих действий целям бизнеса. Звучит настолько впечатляюще, что многие ИТ- руководители выстраивают процессы управления ИТ таким образом, чтобы обеспечить эту согласованность.

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

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

При таких внутренних расчетах ИТ-служба пытается добиться прежде всего согласованности с бюджетом бизнеса. И если это соответствует его целям, то хорошо, а если нет, пусть голова об этом болит у кого-то другого.

Иллюзия № 2. Единственная причина обновления программного обеспечения обусловлена реализацией в новой версии важных ценностей бизнеса.

Это не просто звучит убедительно, а принимается как руководство к действию. Явно, что ИТ-директор, проводящий такую политику, ориентирован на бизнес (и соответствие его целям) и его никак нельзя обвинить в тратах на технологии ради самих технологий.

Более того, при таком раскладе ИТ-бюджет можно сокращать, поскольку нет необходимости в средствах на поддержание актуальных версий.

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

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

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

Вот как обычно развиваются события.

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

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

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

Желтый уровень. Это состояние проекта, при котором отставание от сроков становится настолько существенным, что никакого пути к спасению уже нет, но при этом до сдачи остается еще немало времени и отрицание проблем по-прежнему подменяет собой реальность. Когда проект переходит в такую стадию, ловкие менеджеры начинают действовать в двух направлениях. Во-первых, они сокращают продолжительность тестирования. Проект вновь возвращается в зеленый статус (и тот же оттенок приобретают лица людей, работающих над ним).

А во-вторых, начинают подыскивать себе работу, пока проваленный проект еще не погубил их репутацию.

Тестирование первого уровня. Здесь качество, считавшееся отличным, снижается до достаточно хорошего. При отсутствии четких стандартов и наличии определенного политического влияния даже самый плохой код можно пропихнуть в производство.

Тестирование второго уровня. Вы всегда проводите тестирование, и причем весьма тщательно. Единственный вопрос, выполняется ли тщательное тестирование до или после того, как программное обеспечение уйдет в производство.

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

Иллюзия № 4. Мы придерживаемся методологии ITIL.

Это может показаться придиркой, но «придерживаться» ITIL невозможно. ITIL – это библиотека инфраструктуры ИТ, как терпеливо объясняют ее сторонники всем, кто готов слушать.

В ITIL перечислены направления, в которых применение ИТ целесообразно. Там не описано, как добиться этой целесообразности, равно как нет рекомендаций ITIL на все случаи жизни.

Между тем есть много ИТ-директоров, для которых «соблюдение ITIL» эквивалентно созданию приличной сервисной службы (или, по крайней мере, переименованию службы поддержки в «сервисную службу») и формированию консультативного совета по изменениям, который будет располагаться между разработчиками приложений и обслуживающим персоналом. В этом случае и те и другие будут апеллировать к консультативному совету, а не друг к другу.

Иллюзия № 5. Мы исповедуем agile-разработку.

В мире есть много ИТ-организаций, уже перешедших от разработки приложений методом водопада к одному или нескольким вариантам agile-проектирования либо находящихся в процессе такого перехода.

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

Те же, кто избежал гибко-водопадной ловушки, движутся в ином направлении. Их уделом становится не гибкость, а бессистемность, навязываемая зачастую по указке «водопадника», который убежден в том, что усилия по продвижению гибкого проектирования обречены на провал, и делает все для того, чтобы так и случилось.

Иллюзия № 6. Мы придерживаемся DevOps.

Ничего подобного. Вы не придерживаетесь даже agile-проектирования. И удосужились ли прочесть все то, что было написано ранее?

Ну хорошо, соглашусь с тем, что при всей шумихе вокруг DevOps сторонники этого подхода не являются изобретателями взаимодействия. Гибкое проектирование – реальное, а не гибко-водопадное – способствовало реальному взаимодействию задолго до появления DevOps, хотя справедливости ради следует признать, что разработчики не больно-то взаимодействуют с персоналом, занимающимся обслуживанием.

Вот что DevOps добавляет в гибкое проектирование.

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

Третий момент связан с DevOps, а не с другими вариантами гибкого проектирования и уж, конечно, не с водопадной методологией. Дело в том, что программное обеспечение находится в состоянии постоянного развертывания (deployable). Нет, нет, не deplorable (в плачевном виде), а deployable. Наряду с многочисленными неудобствами для большинства сторонников гибкой разработки это означает, что DevOps и Scrum не являются полностью совместимыми. Kanban работает лучше.

Иллюзия № 7. У нас есть культура обслуживания клиентов.

Слышите смешок, доносящийся из службы поддержки … ой, простите, сервисной службы. Это сотрудники вашей сервисной службы делятся друг с другом историями про тупых пользователей - никакой культуры обслуживания! Потому что культура начинается с уважения.

Впрочем, это неважно, ведь когда культура есть, ИТ-директор считает, что весь бизнес является его клиентом.

Очень плохая идея. Она ведет к нездоровой концепции платежей между подразделениями – отличной возможности растратить время и энергию на споры о счетах ИТ-службы, а заодно и исчерпать доверие к ней.

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

ИТ-директор должен воспитывать в ИТ-службе культуру обслуживания.

Как узнать, есть ли у вас эта культура или нет? Если вы по-прежнему слышите рассказы об идиотах-пользователях, значит, ее нет.

Иллюзия № 8. Наша информационная безопасность на высоте

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

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

Если ИТ-директор полагает, что информационная безопасность у него на высоте, он, очевидно, ошибается. Сохранить все в приличном виде удается обычно как раз тем, кто озабочен наличием брешей в своей системе безопасности.

Иллюзия № 9. Наш процесс управления ИТ гарантирует реализацию только тех проектов, которые имеют высокую ценность для бизнеса

Давайте опять вернемся к соответствию целям бизнеса.

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

Таким образом окончательные решения становятся еще и предметом торга и выстраивания личных взаимоотношений.

Сюда следует добавить и еще одну неприятную деталь: проекты, цель которых заключается в сокращении расходов, будут приоритетнее, чем проекты, направленные на увеличение доходов. Почему? Сокращение расходов бизнес может контролировать. Если все идет по плану, расходы будут сокращаться.

Увеличение же доходов требует от клиентов того, чего вы хотите. А они зачастую этого не делают. И вы не можете им приказывать, а вынуждены пытаться убеждать.

Какой же вывод можно сделать? Если вы в чем-либо уверены, то почти наверняка ваша уверенность ошибочна. И если, будучи ИТ-директором, вы готовы записать в свой актив девять перечисленных пунктов (или каких-то других), задайте себе простой вопрос: почему? И постарайтесь на него ответить.

– Bob Lewis. 9 lies CIOs tell themselves. CIO. August 21, 2017

Существенная часть аgile-трансформации – изменение культуры. Гибкой следует делать всю организацию целиком. Николай Кныш, директор по развитию ИТ-продуктов «Райффайзенбанка», рекомендует руководителям, которые хотят построить гибкую организацию, запастись терпением и быть аgile, а не внедрять его. Таков был главный посыл его выступления на форуме ITMF 2017, организованном издательством «Открытые системы».

– Зачем вы хотите стать agile?

Чтобы быстро запускать новые идеи и делать так, чтобы клиентам это очень нравилось.

– С чего у вас все началось?

Все началось с дирекции ИТ, которой предъявляли две классические претензии: долго и дорого. Если все делать быстро, нужно минимум шесть месяцев, чтобы установить минорную задачу в продуктив. И то, если вложиться всей душой. Сегодня это малоинтересно бизнесу.

Agile, DevOps и Scrum – это зачастую дорого. Но на уровне правления мы решили, что нам важнее скорость запуска продуктов и уровень удовлетворенности клиентов.

– Почему дорого, если вы экономите время. Ведь время стоит денег?

Но размер команды-то меняется... Например, за развитие фронт-офисных систем отвечает команда из 50 человек, у нее 30 заказчиков. В этих системах обслуживаются кредиты, депозиты и другие банковские продукты. Если мы строим продуктовую команду, нам нужны разработчики, хотя бы по два на каждый продукт. То же самое с тестировщиками и поддержкой, которые нужны в каждой команде. То есть штат растет, и надо понимать для чего это.

– Рост штата не компенсируется повышением скорости?

Затраты растут, но мы ожидаем, что и прибыль вырастет – благодаря тому, что мы делаем быстрее и больше, фокусируемся на удовлетворении потребностей клиентов. Когда целями являются time-to-market, клиентский опыт (customer experience) и повышение индекса потребительской лояльности (net promoter score, NPS), то аргумент «дорого» отходит на второй план.

Вот, к примеру, такая ситуация. Бизнес-заказчик спрашивает, когда для него сделают нужную ему доработку, а ему отвечают: вот очередь твоих коллег, приходи через месяц или докажи, что твоя задача – самая приоритетная. Вариант нанять еще 10 человек и сделать работу за месяц не проходит, потому что нет возможности наращивать расходы на ИТ. Количество запросов от заказчиков очень высоко, и если не увеличить число разработчиков, то нужные продукты будут получены только к 2028 году.

Сейчас ситуация меняется: человек из бизнеса сам приходит в правление банка и говорит, что из заработанной в прошлом году суммы хочет инвестировать часть в расширение ИТ-команды, потому что видит набор идей, которые можно реализовать, что позволит заработать больше. Таким образом, ушел тезис, что ИТ – это дорого.

Теперь второй тезис: ИТ – это долго. У нас порядка 30 заказчиков на одну систему, а в банке их – условно 300. Портфельное управление задачами – это сложные и долгие процессы. Cейчас мы уходим в парадигму, когда у нас есть «собственник» продукта. Ответственный за конкретный бизнес-продукт по сути сам себе заказчик, поэтому три месяца из семи на совершение формальных действий по согласованиям автоматически исчезают. Теперь «собственники» решают, какая следующая опция появится в депозитах, а какая – в картах, у них получаются компактные команды, так как они отвечают за заработок в конце года.

– Сколько у вас команд сейчас и сколько предполагается в будущем?

Раньше у нас была одна команда из 50 человек и псевдогибкость – релизы мы выдавали не чаще раза в месяц. Теперь ее разбили на 10 команд поменьше, убрали очередь заказчиков. Сервисных команд сейчас 25, а продуктовых будет не менее 50.

– Внедрить гибкий подход вы пытались неоднократно. Когда наступил переломный момент?

До 2013 года предпринимались попытки внедрить аgile «снизу вверх», а в 2014-2015 годах – привнести его извне. В 2016 году председатель правления банка вышел на совет директоров и сказал, что хочет построить agile-организацию. C тех пор все изменилось, agile-команда стала не айтишной, а полнофункциональной, в нее вошли управляющие директора, которые отвечают за кредитные и некредитные продукты в ретейле. Они почувствовали все преимущества гибкости и теперь сами ее хотят. Поменялось и то, как мы внедряем agile. Мы внедряем его не по плану, а по Scrum.

Раньше это было «играми айтишников» и предполагалось, что agile – это про то, как мы пишем код. А в действительности это про то, как мы развиваем продукты, как работаем в условиях неопределенности и как в целом принимаем решения. И мы поняли, что можем масштабировать этот подход на корпоративный уровень. Это означает изменение культуры всей организации, изменение того, как мы планируем бюджет, оцениваем людей, делегируем полномочия. Это история не про ИТ, а про банк в целом, и менять надо весь банк.

В связи с этим возникает множество вопросов. Как работают проекты? Какие нужны метрики? Как меняется роль топ-менеджеров?

– На каких проектах происходило внедрение agile?

Мы от управления проектами переходим к управлению продуктами. Трансформация – дело длинное. К примеру, мы развиваем новый ипотечный конвейер. Раньше кредитный конвейер внедрялся так: к 30 заказчикам приставлялся бизнес-аналитик, который писал большущую спецификацию, на нее рисовалась сложная архитектура, мы писали код, тестировали, отдавали через полтора года заказчику. А теперь команда, которая пишет конвейер, и человек, отвечающий в банке за все кредитные продукты, собираются вместе и смотрят на идею нового конвейера с точки зрения того, зачем он нужен и что нам мешает реализовать его прямо сейчас.

Теперь мы не пытаемся угадать, каким рынок будет через два года, и к тому времени выдать бизнес-заказчику продукт, который на 80% не соответствует его ожиданиям. Теперь заказчик в процессе разработки сам перечисляет свои ожидания и говорит, что конкретно ему надо прямо завтра.

Когда CPO (Chief Product Owner) это попробовал, то стал самым главным поборником всей этой истории, потому что понимает, чем заняты его сотрудники каждый день, почему это столько стоит, и отдачу начинает получать через месяц. Мы быстро тестируем идеи и начинаем зарабатывать сразу. А если это не нужно, то понимаем это не через три года, а через месяц и перестаем тратить деньги.

– В перспективе вы откажетесь от проектного управления или будете комбинировать его с agile? Какие ограничения agile вы видите?

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

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

– Банк по сути жесткая структура, как он может быть agile? Как можно сочетать жесткость и гибкость?

Сочетать можно и нужно. Да, мы зарегулированы, однако регуляторные требования и групповые стандарты, которые нельзя нарушать для процессов планирования, бюджетирования, практически не имеют отношения к разработке продуктов, если мы не нарушаем базовых правил, типа обработки персональных данных. Поэтому Scrum тут вполне применим. Однако Scrum, родившийся в стартапах, где возможно все, в нашем случае, образно говоря, помещается в «контейнер» из стандартов, и градус свободы для Product Owner’a (ответственного за продукт) снижается.

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

– Помимо поддержки руководителя компании, какие еще условия должны выполняться, чтобы agile был эффективен?

Без поддержки руководства трансформация просто невозможна. И вся корпоративная бюрократия должна ее поддерживать. Корпоративные ценности должны соответствовать agile, а если не соответствуют, то их надо менять.

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

Cистема корпоративного обучения также подвергается изменениям, особенно если она была построена на таких вещах как ITSM или PMBOK.

Кроме того, надо менять всю систему карьерного продвижения людей в организации. Гибкая организация ведет себя по-разному в зависимости от ситуации, исходя из этого строится вся система мотивации, карьерного продвижения и бонусов. Сейчас все, как всегда, упирается в людей. Нужно нанимать людей с правильным складом ума и с правильными ценностями, смотреть, может ли человек работать в команде и нацелен ли он на общий результат.

– Что вы посоветуете ИТ-руководителям, которые хотят внедрить agile?

Первым делом – запастись терпением. Каждую неделю мы рассказываем про аgile на разных уровнях – и этого все равно недостаточно. Мы занимались DevOps полтора года, много и активно вкладываясь, но казалось, что ничего не происходило. Однако спустя полгода вдруг что-то начинает появляться как бы само. Мозг у людей быстро не поменяется, надо несколько лет рассказывать одно и то же.

С точки зрения agile в ИТ мы лидеры среди европейских подразделений банка, но с точки зрения бизнеса мы только в начале пути, хотя по сравнению с другими организациями у нас большой прогресс. Мы поняли, что такое продукт, каковы полномочия «собственника» продукта, и к концу 2017 года запустим множество продуктовых команд по Scrum. А дальше будем долго «докручивать» всю бюрократическую обвязку и долго-долго менять мышление.

Сегодня столько говорят о DevOps, что, возможно, кто-то уже готов пойти и купить себе коробочку этого... Вот только DevOps в коробке не продается.

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

1. Команды, ориентированные на продукт

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

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

Группированию по дисциплинам по-прежнему придается важное значение. Если попросить сисадминов следить за общей картиной происходящего, это поможет слаженной работе, а разработчики могли бы время от времени собираться, чтобы делиться новыми методами, обмениваться опытом и ценными сведениями. Можно организовывать межпродуктовые «гильдии», участники которых время от времени собираются для бесед по делу и обмена информацией.

2. Неудачи переносятся с достоинством

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

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

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

3. Тотальная автоматизация

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

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

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

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

DevOps как фундаментальный сдвиг

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

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

– Don Jones. 3 signs you're on an actual devops team. InfoWorld. November 28, 2016

Польза DevOps

Культура организаций, происходящие в них процессы и используемые технологии сегодня меняются беспрецедентно быстрыми темпами. Поэтому вряд ли удастся просто переждать, пока пройдет «мода» на DevOps. Это не преходящее увлечение, а новая эволюционная ступень разработки программного обеспечения. Не стоит также откладывать преобразования в области безопасности как нечто слишком сложное. Безопасность тоже должна эволюционировать, плавно переходя в SecDevOps.

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

Создает культуру единства и взаимодействия

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

Помогает координировать обеспечение безопасности с бизнесом

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

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

Способствует безопасной инновации и agile-разработке

Сегодня все больше организаций переходят на agile-методы разработки ПО; по сути, они уже стали предпочтительными для многих компаний во всем мире. Но обеспечивать слаженную работу и высокие темпы без контроля безопасности можно лишь до определенной степени. Чтобы agile-разработка дала оптимальные результаты, необходима грамотная реализация процессов обеспечения безопасности. Когда специалисты по безопасности больше вовлечены в процессы разработки, защищать новые продукты с самого начала становится проще. DevOps позволяет встроить ревизии безопасности непосредственно в спринты разработки, что дает возможность быстро добавлять новый защищенный функционал. Контроль защищенности при разработке новшеств помогает бизнесу, делая специалистов по безопасности реальной опорой разработки ПО.

Обеспечивает приоритет автоматизации

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

За безопасность отвечают все участники

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

Когда у специалистов по разработке и эксплуатации появляется ответственность за безопасность кода, у них будет больше стимулов расширять свои познания в соответствующей области. И помогут в этом учебные программы, соревнования по «захвату флага» и т. п.

Способствует улучшению мониторинга

Краткость спринтов разработки способствует непрерывному совершенствованию. Без интеграции контроля безопасности с DevOps мониторинг характеристик приложений нередко выполняется как отдельный процесс. А при встраивании безопасности в процесс разработки соответствующий контроль можно интегрировать в существующие процедуры мониторинга. Как следствие, показатели безопасности будут лучше согласованы c процессами разработки, эксплуатации и управления.

Скажем, команда DevOps задается целью обнаружить 75% всех ошибок на ранних стадиях разработки. SecDevOps позволяет осуществлять мониторинг и проводить измерения, направленные на обнаружение уязвимостей, уже на первых этапах цикла, благодаря чему все ошибки, способные задержать разработку, будут выявлены и посчитаны.

Устраняет узкие места

Без DevOps пользователям приходится самим выискивать нужную информацию и тратить время на поиск контакта, чтобы решить возникшую проблему. Поскольку в командах DevOps обязательны каналы связи между отделами, у пользователей всегда есть доступ к различным контактам, которые помогут решать проблемы по мере возникновения. Еще одним ключевым компонентом инициатив DevOps наряду с доступностью связи является обучение участников. Согласно данным уже упомянутого опроса Puppet Labs, эффективные организации тратят на 50% меньше времени по сравнению с остальными на устранение проблем безопасности и следят за тем, чтобы соответствующий отдел заранее готовил простые в использовании библиотеки, комплекты, инструментальные цепочки и процессы для применения разработчиками и специалистами по эксплуатации.

– Ryan Francis, 7 ways DevOps benefits security programs. CSO. Oct 4, 2016

Максим Тамбиев, региональный директор Forrester Research: «У компаний не осталось других конкурентных преимуществ, кроме умения работать с клиентами»

По мере того как бизнес становится цифровым и все больше зависит от технологий, границы между ИТ и бизнесом размываются настолько, что сегодня их уже практически невозможно определить. «ИТ-стратегия – это не часть бизнес-стратегии. По сути, это и есть бизнес-стратегия, выраженная языком технологий», – полагает Сергей Потапов, директор по ИТ холдинга «Русагро». По его мнению, говорить о бизнес-грамотности ИТ-специалистов недостаточно, сегодня бизнес должен быть грамотным в области ИТ.

И дело не только в «революциях», которые практически каждый год открывают новые возможности для бизнеса: облака и мобильность, Интернет вещей и Большие Данные, аналитика и социальные сети, совместная работа и прямое общение с заказчиком. Самые важные изменения под воздействием технологий происходят с бизнес-моделями. Один из крупнейших в мире ретейлеров Alibaba не имеет собственных товарных запасов, а отельер Airbnb – своих отелей. Самое популярное СМИ – Facebook – не производит контента, а чрезвычайно динамично развивающаяся кредитная организация – SocietyOne – не обладает реальными деньгами.

Маартен Бордевийк, основатель Bordewijk Traininig@Advie

Все новые компании имеют много общего, и прежде всего они ориентированы на клиента, подчеркнул Патрик Бьюх, руководитель направления Service Management компании FNT. Традиционному бизнесу приходится жить в изменившихся условиях, но он не столь гибок.

«У компаний не осталось других конкурентных преимуществ, кроме умения работать с клиентами», – напомнил Максим Тамбиев, региональный директор Forrester Research. Все остальное в современнных условиях легко копируется. При этом потребности заказчиков сегодня меняются гораздо быстрее, чем возможности организаций по их удовлетворению посредством изменения своих технологий, бизнес-процессов и оргструктур.

«Пользовательский опыт и опыт сотрудников остаются, пожалуй, единственными конкурентными преимуществами», – согласен Кирилл Кушнарев, генеральный директор компании «Devoteam Россия». Он уверен в том, что бизнес не сможет выжить, оставаясь в старой парадигме управления ИТ. «Экосистемы» бизнеса, еще вчера казавшиеся крепкими, разрушаются, и если текущие тенденции сохранятся, то к 2027 году рейтинг Standard & Poor’s 500 покинут 75% компаний.

Олег Лекучев, ИТ-директор Abbyy International Headquarters

Эта боль должна стать двигателем прогресса. «Если нет болезненных ощущений, невозможно добиться чего-то нового», – считает Маартен Бордевийк, основатель Bordewijk Traininig@Advies. «Ищите реальные проблемы – там, где «болит»», – добавляет Олег Лекучев, ИТ-директор Abbyy International Headquarters. Внедрять ITSM-решения только потому, что так решил руководитель, он считает в корне неверным подходом.

Что делать?

Согласно опросу, проведенному PWC в 2015 году, руководители бизнеса ждут от цифровой трансформации роста выручки, прибыльности и улучшения пользовательского опыта. Этих целей можно достичь, если использовать преимущества «трансформированных» технологиями бизнес-моделей – скорость, быструю утилизацию ресурсов и новые подходы к оценке эффективности.

Аналитики прогнозируют, что в скором времени все компании станут разработчиками программного обеспечения и провайдерами облачных сервисов. А значит, им придется конкурировать с «мэтрами» в этих областях и брать на вооружение такие методики, как, например, agile. Но, как заметил Владимир Каленов, руководитель проектов компании «Туту.ру», можно и не меняться: выживание – дело добровольное.

Чтобы освоить новый стиль управления ИТ, стоит присмотреться к положениям, которые объединяют цифровые стратегии наиболее крупных и динамичных компаний мира. PWC провела исследование среди компаний с оборотом свыше 500 млн долл. и темпом роста бизнеса в 2015 году более 5%. Его результаты показали, что лидеры рынка включают задачи технологического и ИТ-развития в стратегическое планирование, разрабатывают единую стратегию развития бизнеса и доводят ее до сведения сотрудников. Такие компании рассматривают ИТ-проекты не только в разрезе соблюдения сроков и бюджетов, так как полагают, что отрицательные результаты инноваций могут быть эффективными для быстрой проверки каких-либо бизнес-концептов и позитивными с точки зрения понимания бизнеса. Они инвестируют в мобильную автоматизацию рабочих процессов и взаимодействуют с заказчиками при помощи мобильных технологий, активно вкладывают ресурсы в облачные технологии и максимально полно используют возможности социальных сетей.

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

Человеческий фактор

Эпоха массового внедрения базовых процессов управления ИТ-сервисами и Service Desk завершилась, и начался новый, интересный виток развития практики ITSM. Cегодня каждая компания внедряет то, что ей интересно: управление активами, управление поставщиками или DevOps, – что обычно требует серьезных организационных изменений. «При этом все течет, все изменяется, вечны только «грабли» с коммуникациями в ITSM-проектах», – отметил Дмитрий Королев, ведущий эксперт направления «Управление ИТ-процессами и инфраструктурой» компании «Крок». По его убеждению, эффективное взаимодействие внедренческой команды с бизнес-пользователями остается ключевым фактором успеха таких проектов.

Основы такого взаимодействия полезно закладывать еще на стадии выбора системы управления ИТ-сервисами. «Системы ITSM настолько зрелые, что все могут всё», – отметил Лекучев. По его словам, все три отобранных решения в доступном Abbyy ценовом диапазоне вполне могли решить задачи компании, поэтому выбирали не столько ПО, сколько людей со сходной «картиной мира». «Выбирая любую систему, мы всегда просим привести команду, которая будет с нами работать», – сообщил Лекучев.

Переход на хозрасчет

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

Кирилл Кушнарев, генеральный директор «Devoteam Россия»: «Необходимо подготовить бизнес к цифровой трансформации, сделать ИТ героем бизнеса, а сотрудников – адаптировать к цифровой культуре»

«ИТ и так всегда жили по правилу «денег нет, но вы держитесь», а сегодня бюджеты на новые закупки уходят из ИТ-департаментов в маркетинг, HR и прочие подразделения», – отметил Кушнарев. По оценке Forrester Research, уже в 2016 году 26% всех ИТ-затрат придется на бизнес-технологии или «системы взаимодействия», а в структуре новых закупок доля расходов на бизнес-технологии превысит затраты на трансакционные ИТ-системы. При этом требования таких решений далеко не всегда укладываются в традиционную ИТ-архитектуру, поскольку необходимо собрать данные не только о каждом взаимодействии, но и о его контексте. Для бизнес-технологий характерны большие объемы данных, причем значительная их часть поступает из внешних источников, да и потребители результатов обработки данных тоже могут находиться снаружи организации, что коренным образом меняет требования к качеству и быстродействию ИТ-систем.

Приоритеты сдвигаются

Современные пользователи хотят получать услуги быстрее, дешевле и безопаснее, причем их представления об этих критериях стремительно меняются. Но выше всего сегодня ценится удобство: 92% покупателей ПО называют удобство использования корпоративных решений главным в списке факторов, влияющих на мнение о поставщике. В том же направлении идет и внутренняя переоценка ценности ИТ-предложений для бизнеса.

Сдвиг приоритетов требует подхода DevOps, который позволяет быстро и точно реализовать требования бизнеса, причем качество разработки улучшается благодаря большому количеству обратных связей в процессе создания программного обеспечения, полагает Андрей Косыгин, ведущий консультант HPE по решениям в области ITSM и DevOps.

Согласно результатам опроса, проведенного на форуме аналитической группой OSP Data, российские менеджеры уже начали осваивать DevOps и не видят в этом подходе противоречий с традиционными принципами управления ИТ-сервисами. Более половины опрошенных (66%) отметили, что работают с ITSM и при этом присматриваются к DevOps, почти треть участников опроса (31%) реализуют оба подхода, еще 2% ответивших начали с DevOps и думают о внедрении ITSM, и лишь 1% респондентов считают эти подходы абсолютно несовместимыми.

Однако новым сервисам все равно придется жить с унаследованными системами. По мнению Косыгина, сочетание стабильных систем c гибкими (в терминологии Gartner – бимодальные ИТ) – это новое условие жизни. Тамбиев же, напротив, считает, что cтратегия бимодальных ИТ не сработает, так как она лишь увеличивает сложность, а не уменьшает ее и не приближает ИТ к бизнесу. Кроме того, она оставляет задачу изменений ИТ-специалистам, что невозможно без участия бизнеса.

Впрочем, подходы не стоит рассматривать отдельно от людей, которые их воплощают. «Мы не используем слова agile и Scrum, но у нас был проект с подобным итерационным подходом во внедрении SAP: мы делали небольшие прототипы с «докручиванием» системы, – сообщил Потапов. – К сожалению, это не сработало: внедрение заняло больше года, люди уходили из компании и уносили с собой идеи, заложенные в проект». По его словам, через три-четыре быстрых этапа заказчик устает, лишь консультанты могут в цейтноте работать круглый год. «Так что идея интересная, но для ее воплощения нужна готовность команды», – подытожил Потапов.

За пределы ИТ-сервисов

Для финансовой службы методологии ITSM и ITAM (IT Asset Management – комплексные решения для физического учета, финансового контроля и следования контрактным обязательствам на протяжении всего жизненного цикла активов) – инструмент оценки стоимости ИТ-составляющей в бизнес-операциях, причем до сих пор мало кто умеет ее считать, а если и считает, то лишь по нескольким статьям материальных и нематериальных активов. «Это не так просто – внедрить управление финансами в ИТ», – заметил Илья Масленкин, генеральный директор Axios Systems в России. Потребность же в оценке ИТ-составляющей, по его словам, очень высока. Особенно это актуально в добывающих, энергетических и крупных промышленных компаниях, где ИТ-подразделения постепенно вступают в товарно-денежные отношения со своими бизнес-заказчиками и им важно понимать себестоимость каждого сервиса, чтобы оценить его эффективность и возможность передачи на аутсорсинг. Однако зачастую процессы управления ИТ в этих отраслях либо еще недостаточно зрелые, либо чересчур забюрократизированы. А вот в финансовой сфере и крупном сетевом ретейле себестоимость ИТ рассчитывают весьма успешно, что помогает планировать и корректировать ИТ-стратегию на более отдаленную перспективу.

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

«Часть «IT» из ITSM вполне можно убрать, получится Service Management, поскольку это полноценный осмысленный подход для создания любого типа сервисов, как внешних, так и внутренних», – подчеркнул Масленкин. Практическое подтверждение этого тезиса можно увидеть в ряде крупных российских компаний и МФЦ.

Упоминал об этом в своем докладе и ИТ-директор Abbyy. «Мы пойдем дальше, чем ITIL, и будем включать в систему HR-специалистов, финансистов и юристов, им уже продемонстрировали ее, и она им нравится», – сообщил Лекучев.

Таким образом, никто не останется в стороне от прогресса. «Необходимо подготовить бизнес к цифровой трансформации, сделать ИТ героем бизнеса, а сотрудников – адаптировать к цифровой культуре», – резюмировал Кушнарев.

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

В 2014 году меньше 10% соглашений об услугах аренды приложений предусматривали выпуск по методам DevOps, выяснило исследование, проведенное компанией Everest Group, оказывающей консультации по аутсорсингу. Из этого следует, что на предприятиях пока не убеждены в том, что их аутсорсинг-партнеры могут серьезно помочь с внедрением новых методов выпуска, считает Югал Джоши, директор практики Everest Group.

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

Провайдеры с опытом интеграции услуг имеют больше всего шансов получить заказы на внедрение DevOps

«Заказчики пока что только разбираются, что такое DevOps, – продолжает Джоши. – Чтобы начать извлекать пользу из DevOps, нужно обеспечить координацию действий многих участников, а на типичном предприятии сделать это непросто. Эксперименты с DevOps проводят в рамках внутренних проектов и инициатив проверки концепции, причем чаще всего самостоятельно либо путем краткосрочного найма знающих людей – на роль скорее исполнителей, чем лидеров по проведению перемен».

Спрос на консультационные услуги по аренде приложений растет. Две из трех сделок на услуги аренды приложений, заключенных в 2014 году, предусматривали консалтинг, сообщают в Everest. А сам сегмент услуг аренды приложений в 2014 году вырос на 4%, тогда как общий рынок ИТ-услуг – на 3,4%.

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

Аутсорсинговые компании сами должны показывать свою компетенцию в сфере DevOps, прежде всего – свои возможности в области сквозной трансформации. «Учитывая, что большинство заказчиков пользуется услугами провайдеров для решения какого-то узкого круга задач, тем придется демонстрировать свои способности в других областях, – указывает Джоши. – Более того, надо показывать свою готовность взаимодействовать с другими сервис-провайдерами, чтобы достичь желаемого результата». Провайдеры с опытом интеграции услуг имеют больше всего шансов получить заказы на внедрение DevOps.

Что касается заказчиков, возможно, сейчас самое время прыгнуть в неизведанное и начать экспериментировать с аутсорсинг-партнерами, переводя на DevOps приложения с низким риском, чтобы выяснить, как лучше всего координировать деятельность разных сервис-провайдеров. «Здесь могут оказаться полезными уже установившиеся методы интеграции сервисов, – отмечает Джоши. – Заказчикам стоит понимать, что сервис-провайдер может сыграть важную роль в этом переходе, но общее управление переменами должно осуществляться собственными силами. На сервис-провайдеров эту задачу возлагать неразумно – слишком высок риск для бизнеса».

Stephanie Overby. IT customers slow to embrace outsourced DevOps. CIO (US). 08/07/2015