DevOps

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

Автоматизация – не только экономия времени или денег. При правильной реализации средства автоматизации уменьшают число ошибок, повышают степень удовлетворенности сотрудников, освобождают их от необходимости выполнения утомительных операций, улучшают восприятие клиентов (customer experience, CX) и позволяют масштабировать бизнес.

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

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

Вице-президент Constellation Research Дион Хинчклифф призывает ИТ-директоров к 2025 году довести уровень автоматизации до 90% там, где это представляется естественным: в службе технической поддержки, при выполнении запросов на обслуживание, поиске кандидатов на замещение вакантных должностей и приеме их на работу, закупках ИТ, в операционной деятельности, обеспечении кибербезопасности, администрировании проектов и формировании отчетности. «Поначалу эти области с трудом поддаются автоматизации, но все равно они должны быть максимально автоматизированы», – говорит Хинчклифф.

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

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

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

1. Обслуживание клиентов

Для многих руководителей ИТ-служб улучшение обслуживания клиентов является главным приоритетом. В ходе недавнего опроса Harvey Nash/KPMG CIO Survey, проводившегося в Великобритании, 62% ИТ-директоров назвали это своей первоочередной целью.

Результаты исследования DigitalGenius показывают, что у 80% служб техподдержки (service desk) 20% поступающих заявок повторяются и обслуживаются достаточно легко. Соответствующие задачи хорошо поддаются автоматизации, что повышает степень удовлетворенности клиентов и снижает текучку кадров в службе поддержки клиентов.

Чатботы и виртуальные агенты идеально подходят для простых, повторяющихся запросов и для клиентов, отдающих предпочтение самообслуживанию. Для поддержки корпоративных клиентов Microsoft использует в своих контакт-центрах решение AI Solution for Customer Service. За последние полгода число клиентов, сумевших решить свои проблемы, удвоилось. Сегодня их ежедневно обслуживают более 100 тыс. виртуальных агентов. Использующая аналогичную систему компания HP удовлетворяет с ее помощью 70% всех поступающих заявок на техническое обслуживание.

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

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

2. Управление персоналом и наем сотрудников

«Еще одна перспективная область — автоматизация административных задач, разгружающая сотрудников кадровых служб, – отмечает Курт Хайккинен, директор компании Montage, разрабатывающей ПО для проведения видеоинтервью. – Следует рассмотреть возможность автоматизации рутинных, административных операций, выполняемых при подборе персонала, в том числе с использованием телефонов и планированием времени интервью. Более половины опрошенных Montage организаций уже используют средства автоматизации для составления расписаний собеседований. Это помогает проводить отсев на ранних этапах при большом количестве кандидатов. Средства автоматизации позволят рекрутерам сосредоточиться на решении стратегических задач, удовлетворении нужд и потребностей кандидатов и выстраивании взаимовыгодных отношений, помогающих им удерживать в своих рядах талантливых специалистов».

Следующим этапом использования искусственного интеллекта становится оценка кандидатов, позволяющая обеспечивать согласованность процесса подбора персонала.

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

3. Платежи

Неэффективные системы учета командировок и прочих затрат отнимают много дополнительного времени. В платформы облачного хранения наподобие Box и OneDrive интегрированы средства распознавания, позволяющие считывать информацию из квитанций. Сервис MileIQ отслеживает заявки на поездки, а его разработчики создали новое приложение Spend, подключаемое к банкам и учетным записям банковских карт для автоматической классификации расходов. Аналогичное приложение SAP Concur собирает информацию о платежах за гостиничные услуги и аренду автомобилей. Оно учитывает даже обменные курсы при совершении зарубежных поездок и автоматически переводит деньги на банковские счета сотрудников и кредитные карты компаний.

Растет интерес к таким областям, как автоматизация оплаты по счетам. По оценкам McKinsey, 27% всей финансовой деятельности можно автоматизировать, а треть этого объема поддается автоматизации с помощью программных роботов (Robotic Process Automation, RPA).

4. ИТ-операции

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

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

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

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

5. Подготовка устройств

Подключение инфраструктуры, находящейся на территории предприятия, к облачным сервисам с помощью Microsoft System Center и Intune позволяет ИТ-службе автоматизировать процедуры развертывания и настройки конфигурации устройств. С помощью функции Windows 10 Autopilot, например, новый ПК при первом включении подключается к Azure Active Directory.

«Благодаря функции Windows Autopilot можно прямо в облаке автоматически организовать полноценное управление новыми устройствами, – уверен генеральный менеджер группы Microsoft Windows Commercial Бернардо Кальдас. – Сегодня эта процедура по большей части выполняется вручную: нужно сначала создать соответствующие образы, организовать их развертывание и управление ими. С помощью Autopilot все эти операции проделывают облачные сервисы, что существенно упрощает ИТ-службе жизнь».

Новый сервис Desktop Analytics расширяет возможности автоматизации функциями тестирования на совместимость приложений. Сегодня это требует значительных ресурсов и замедляет переход на новые версии Windows. «Мы используем средства машинного обучения и облачную информацию о приложениях, которые уже работают в среде Windows и Office, что позволяет клиентам оценить совместимость с новыми версиями Windows и Office, сэкономив тем самым свое время», – поясняет Кальдас.

6. Автоматизация обеспечения безопасности

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

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

7. Тестирование приложений

«Автоматизация – ключевая составляющая DevOps, особенно при создании сборок для непрерывного развертывания, – полагает вице-президент Sauce Labs Любош Паробек. – Устранение влияния человека помогает ускорить получение результатов, выполнение процедур и разработку приложений. Кроме того, обеспечивается повторяемость: при наличии средств автоматизации вам уже не нужно изобретать велосипед. Устраняется и источник ошибок: людям свойственно ошибаться, а машинам нет».

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

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

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

Организациям, использующим ITIL, нужно учесть: в популярном своде знаний произошли существенные изменения, направленные на модернизацию управления сервисами ИТ (IT service management, ITSM) и трансформацию их в более гибкий ресурс, приносящий дополнительные ценности бизнесу.

В последний раз ITIL обновлялась в 2011 году, но это были скорее косметические изменения. Обновление же 2019 года вносит гораздо более серьезные коррективы и сравнимо с теми, что произошли в 2007 году. Версия ITIL 4 ориентирована в первую очередь на адаптивность, настраиваемость и гибкость управления ИТ-сервисами.

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

Девять основных принципов ITIL

Два года назад компания AXELOS представила набор руководящих принципов, которые нашли отражение в экзамене ITIL Practitioner, охватывающем вопросы управления организационными изменениями, коммуникациями, измеримостью и метриками. К этим критериям, известным как девять основных принципов ITIL, относятся:

• фокус на ценности (Focus on value);
• работа на людей (Design for experience);
• старт исходя из текущей ситуации (Start where you are);
• системное мышление (Work holistically);
• итерационное развитие (Progress iteratively);
• непосредственный контроль (Observe directly);
• прозрачность (Be transparent);
• взаимодействие (Collaborate);
• упрощение (Keep it simple).

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

Ориентация на культуру

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

По словам директора AXELOS Global Best Practice по продуктам Марго Лич, управление ИТ естественным образом поддерживает «разобщенный стиль работы», который отделяет ИТ от бизнеса и негативным образом отражается на взаимодействии.

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

Переход к Agile-методикам и DevOps

«Фокус прошлых версий на организации советов по управлению изменениями (CAB) привел к негативному восприятию ITIL, – отметила Лич. – Претензии предъявлялись к недостаточной гибкости и созданию препятствий на пути быстрого развертывания. Вместе с тем в ITIL никогда не подразумевалось, что необходимо тщательно оценивать любое простое изменение в ИТ».

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

Построение прочного фундамента для изменений

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

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

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

Больше внимания клиентам

Клиентов всегда причисляли к ключевым аспектам ITSM, но в ITIL 4 им отводится еще более важная роль.

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

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

«Общепризнанно, что ценности не создаются в вакууме, – подчеркнула Лич. – Клиенты должны принимать самое непосредственное участие в определении того, что для них является ценностью, а что нет, и декларировать, что они ищут. – Необходимо поддерживать постоянную обратную связь, и эта концепция занимает важное место в ITIL 4».

Официальная презентация ITIL 4 состоялась буквально на днях (книга ITIL Foundation book of the ITIL 4 Edition увидела свет 18 февраля 2019 года — Прим. ред.), но обновления будут появляться в течение всего нынешнего года по мере модернизации отдельных модулей. Для обеспечения плавного перехода экзамены, сертификация, книги и аккредитации по ITIL v3 сохранятся до июня 2020 года. Для тех, кто уже проходит процесс сертификации, заработанные кредиты будут переведены в новые схемы.

Я люблю смотреть разные спортивные игры. Можно сказать, я просто рожден для этого занятия. А вот играть в них — не мое призвание. И однажды мне стало интересно, чем мир спорта схож с миром программного обеспечения, а точнее — с моделью DevOps. В какой-то момент меня осенило, что если и есть что-то, совсем не похожее на спорт, то это модель DevSecOps. Попробуем разобраться на примерах.

С самого начала сохранение безопасности процессов DevOps было общей обязанностью, и в результате возникло такое понятие, как DevSecOps. DevSecOps — это полностью интегрированная система, а не просто безопасность «вокруг» приложений и данных. Если безопасность перенесена в конец конвейера разработки, то организации, внедряющие DevOps, могут оказаться в ситуации, когда придется вернуться к долгим циклам разработки, которых они пытались избежать. DevSecOps означает, что нужно думать о безопасности приложений и безопасной инфраструктуре с самого начала работы. Также подразумевается необходимость автоматизации некоторых доступов для того, чтобы поддерживать рабочий процесс, а не тормозить его. Однако DevSecOps — это больше, чем подобранные инструменты. Это система, построенная на культурных изменениях DevOps для внедрения в работу security-команд, и чем раньше такое произойдет, тем лучше.

1. Нельзя во всем винить вратаря

Я начну с сугубо личного, но, надеюсь, хорошо понятного примера: когда в детстве мы играли в футбол, меня, как наименее ценного игрока, обычно ставили на ворота. И всякий раз, когда мяч со всей дури влетал в ворота (или неторопливо закатывался в них мимо меня), все, конечно же, винили вратаря. Должен сказать, что такой подход не только ужасно влияет на командный дух, но и является полной противоположностью тому, как необходимо работать в команде.

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

2. Вы не знаете, кто ваш противник

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

3. В отличие от спорта, здесь нет правил

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

4. В игре участвуют все и всё время

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

5. В проигрыше нет ничего страшного

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

Подводя итоги

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

Автор — Майк Берселл, главный архитектор по безопасности Red Hat

Эксперты пока не пришли к единому мнению о том, сколько рабочих мест роботизация бизнес-процессов (Robotic Process Automation, RPA) уничтожит, а сколько создаст — в частности, в МТИ проанализировали ряд исследований, обнаружив, что прогнозы на этот счет сильно расходятся. Но так или иначе, автоматизация идет полным ходом: в компаниях внедряют соответствующие технологии для оптимизации процессов бизнеса, ИТ, разработки и обслуживания. С ростом этой тенденции в компаниях всех отраслей все более остро ощущается потребность в инженерах по автоматизации — они помогают обеспечивать автоматизацию предприятия и контролируют соответствующие процессы.

Роль инженера по автоматизации

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

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

Обязанности инженера по автоматизации

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

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

Навыки инженера по ИТ-автоматизации

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

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

Как стать инженером по автоматизации

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

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

Инструменты автоматизации

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

По данным Capterra, к числу программных средств автоматизации тестирования, получающих самые высокие оценки, относятся следующие продукты: UiPath Robotic Process Automation, Cypress, LambdaTest, Rainforest, Testim, Usetrace, pCloudy и PractiTest.

- Sarah K. White What is an automation engineer? A growing role to address IT automation. CIO. November 23, 2018

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

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

Шаг № 1. Почистить ИТ-организм — провести входной аудит

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

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

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

Шаг № 2. Обеспечить простую и недорогую масштабируемость ИТ-инфраструктуры: гибридные схемы и сайзинг ресурсов в IaaS

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

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

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

Эти ИТ-сервисы дают возможность собрать и проанализировать объективные данные о том, хватает ли ресурсов. А если уже не хватает или не будет хватать через какое-то время (скажем, через две недели), то каких именно и сколько. Необходимая для этого информация автоматически стекается в сервис в режиме реального времени, а на выходе появляются рекомендации: какие ресурсы и когда надо докупить, а от каких можно безболезненно отказаться. Это позволяет предприятию своевременно и оптимально перераспределять затраты на облако и гарантированно избегать неприятной ситуации, когда ресурсов вдруг не хватило и бизнес начал простаивать. Также можно получить представление о том, когда и на сколько сократить потребление ресурсов, если, скажем, произошел сезонный или внезапный спад деловой активности. Или если часть пользователей либо какие-то сервисы были переброшены в другой ЦОД.

Шаг № 3. Поддержать высокую изменчивость — начать непрерывный ИТ-аудит

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

Непрерывный ИТ-аудит призван отслеживать именно такие вещи в режиме реального времени. Это, конечно, не делается вручную. Здесь нужна автоматизация — в данном случае дополнительный аналитический модуль, на оперативность, надежность и компетентность которого организация может положиться.

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

Шаг № 4 (дополнительный). Обеспечить постоянное взаимодействие команд на проектах по цифровой трансформации

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

Сегодня наилучшим способом преодолеть этот давний «камень преткновения» является выстраивание горизонтальных связей между командами в виде системы процессов, дополненной современными средствами коммуникации «для данного случая» (ad hoc). Если организация решает внедрить технологии управления Agile, нужно тщательно выбрать конкретную методику, настроить соответствующие процессы (чемпион здесь — Scrum) и уделить большое внимание компетенциям участников. В любом случае (даже если перехода на Agile нет) помогает формирование небольших рабочих DevOps-групп под проекты (в том числе и по цифровой трансформации). В эти группы входят представители каждой из вышеперечисленных команд. Однако всем им нужна общая информационная среда и доступ к постоянно обновляющейся информации в ней — о состоянии всего проекта и его составных частей. Чтобы каждый мог наблюдать и анализировать одни и те же тренды, осуществлять правильные и своевременные корректирующие действия. И не каждая команда — только по своему участку, а совместно, по общему ходу проекта. DevOps-группы в проектах цифровой трансформации должны стать потребителями объективных данных об информационных системах и инфраструктуре, чтобы своевременно принимать взвешенные и правильные для компании решения.

Автор — Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALP Group.

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

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

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

«Большинству команд DevOps делать ставку на искусственный интеллект еще рановато, но мы видим, что все больше клиентов намерены использовать искусственный интеллекта и связанный с ним анализ данных, – добавил Стивен Эллиот, вице-президент International Data Corp. по вопросам DevOps, управления облачными конфигурациями, ITSM и программно-конфигурируемых архитектур. – Наиболее заметные области применения искусственного интеллекта в DevOps связаны с непрерывной интеграцией (continuous integration, CI) и непрерывной разработкой (continuous development, CD), выявлением и разрешением возникающих проблем, а также с углублением обработки и понимания собранных клиентских данных. Мы отмечаем, что инфраструктурные и операционные команды испытывают тягу к аналитике. Многие уже внедряют сервисы управления производительностью приложений и анализа данных в реальном времени, дающие возможность оперативно выявлять и решать возникающие проблемы. Командам DevOps следует подумать об использовании аналитики, которая помогает диагностировать и устранять неисправности, способствует повышению эффективности процессов и улучшению клиентского восприятия, а также достижению более высоких бизнес-результатов в целом».

В русле тенденций

Компания Power Home Remodeling использует искусственный интеллект в сочетании с DevOps при создании решений, предназначенных для перестройки внешних элементов зданий. Она разработала собственную технологическую платформу NITRO, выполняющую самые разные задачи, начиная от управления отношениями с клиентами (customer relationship management, CRM) и заканчивая функциями внутренней социальной сети.

«Мы являемся центром разработки и у нас сформирована полноценная команда DevOps», – сообщил директор Power Home Remodeling по инновациям Тим Уэнхолд. С помощью NITRO компания выстраивает всеобъемлющую инфраструктуру искусственного интеллекта, используя накопленное богатство данных для машинного обучения, что способствует улучшению обслуживания клиентов, более высокой эффективности и расширению возможностей персонала.

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

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

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

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

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

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

Будущее уже сейчас

«Будущее видится нам в том, чтобы, исходя из своих аналитических возможностей, принимать необходимые меры с определенным прицелом: с точки зрения CI/CD, клиентского восприятия, управления проблемами и т.д., – указал Эллиот. – Автоматизация и анализ – это как джем и масло: гораздо лучше, когда они вместе. Дело будет сводиться к повышению производительности технологических и бизнес-процессов, к выполнению определенных действий в специфичных деловых и технологических ситуациях».

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

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

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

«Искусственному интеллекту присущи три свойства – самообучение, прогнозирование и автоматизация, – отметил Сумендра Моханти, руководитель направления анализа данных компании Larsen & Tourbo Infotech, являющейся глобальным поставщиком ИТ-решений и поддерживающей цифровую трансформацию своих корпоративных клиентов путем внедрения средств искусственного интеллекта. – Они позволяют улучшить такие практики DevOps, как CI и CD».

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

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

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

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

Управление данными

Искусственный интеллект помогает организовать управление растущими объемами данных в средах DevOps.

«Средства искусственного интеллекта и машинного обучения призваны выявлять тенденции и закономерности в растущих объемах данных, – отметил Элиэзер Канал, технический менеджер по кибербезопасности группы быстрого реагирования Института программной инженерии при университете Карнеги-Меллона. – Успех в этой области по большей части связан с наличием достаточного количества слабых индикаторов. Например, для того чтобы узнать температуру на улице, лучше всего взглянуть на термометр. К сожалению, зачастую у нас в распоряжении нет датчиков, которые точно измеряли бы то, что мы хотим знать. Поэтому приходится полагаться на множество слабых индикаторов. Люди считают задачи такого рода очень сложными, но для современных машин они, в сущности, тривиальны».

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

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

- Bob Violino. How AI will revolutionize DevOps. CIO. July 18, 2018

Похоже, гибкое проектирование становится уже вчерашним днем. А как же передовые компании? Они уже перешли на DevOps. Более того, многие разработчики приложений не только не взяли на вооружение agile-технологии, но даже не имели таких намерений.

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

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

Один из главных принципов ИТ формулируется так: покупай, когда можешь, создавай, когда нужно. ИТ-службы лицензируют около 90% всего нового функционала в виде готового коммерческого программного обеспечения (commercial off-the-shelf software, COTS) или программного обеспечения, предоставляемого в виде сервиса (software as a service, SaaS), оставляя на разработку его собственными силами всего 10%.

Scrum, Kanban, Lean Software Development и другие agile-методологии предназначены для создания всего 10% программного обеспечения. При этом 70% своего времени типичный разработчик тратит на поддержку и расширение функционала уже эксплуатируемых приложений и только 30% остается у него для создания новых.

Проведем несложные подсчеты. Agile-проектирование оказывается полезным лишь для 10 из 30% – то есть для 3% приложений, которыми занимаются команды разработчиков.

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

Agile-путь поддержки и улучшений

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

Не нужно сильно всматриваться в очередь, чтобы заметить, насколько все здесь напоминает agile-методологию. Добавляем владельца продукта (человека, отвечающего за его разработку) и начинаем формулировать запросы, представленные в виде пользовательских историй (изложенных на бизнес-языке требований к разрабатываемой системе). Мы проделали это за минуту. Применяем Kanban: владелец продукта определяет приоритеты, а разработчик, выполнив очередное задание с пользовательской историей, переходит к следующему. Накладные расходы минимальны, а работа выполнена.

Agile-разработка COTS

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

Однако agile-технологии можно применять и к COTS. Нужно только учитывать два важных момента.

Первый: внедрение COTS, как на своей территории, так и в виде SaaS, не предполагает разработку программного обеспечения с нуля, а ограничивается одной-двумя настройками. А потому Scrum и Kanban фактически непригодны для решения таких задач.

Второй момент: помимо Scrum и Kanban существуют и другие agile-методологии.

Разработка приложений против внедрения COTS: все начинается с данных

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

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

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

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

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

Что должно делать программное обеспечение

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

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

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

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

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

Огромные расходы и никаких улучшений с точки зрения бизнеса. Зачем?

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

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

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

Двухэтапный проект COTS

Когда бизнес, а не ИТ-подразделение, внедряя COTS, вносит в свою деятельность намеренные коррективы, усилия разбиваются на два этапа: сделать программное обеспечение приемлемым для себя и оптимизировать бизнес.

Первым этапом можно управлять с помощью малоизвестной agile-методологии Conference Room Pilot (CRP). Вот как это работает.

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

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

Затем в зале размещаем несколько бизнес-пользователей и ряд гуру в области приложений.

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

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

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

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

Темные стороны agile-проектирования

У agile-проектирования есть недостатки и похуже, чем бесполезность для решения большинства ИТ-задач. Гибкое проектирование направлено на доставку продукта. Независимо от того, идет ли речь о Scrum, Kanban, Lean или о чем-то еще, проект считается завершенным после поставки программного продукта.

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

Весь второй этап CRP направлен на то, чтобы заставить бизнес работать лучше. Внутренние изменения бизнеса заложены в нем изначально.

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

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

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

***

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

– Bob Lewis. Agile’s dark secret? IT has little need for the usual methodologies. CIO. MAR 30, 2018

Выступление Антона Исанина, руководителя центра качества «Альфа-Банка», набрало максимальное число позитивных отзывов участников конференции «Agile, DevOps и ITIL – инструменты цифровизации», проведенной издательством «Открытые системы». Сокращение вывода новых продуктов на рынок до пяти дней с помощью подходов DevOps – результат, заслуживающий уважения.

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

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

Успеть за возможностями

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

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

Антон Исанин, руководитель центра качества «Альфа-Банка»: «DevOps позволяет быть ближе к клиенту, а если мы понимаем клиента, то понимаем, как заработать деньги, и это уже половина успеха. Вторая половина успеха – максимально быстро удовлетворить эти потребности»

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

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

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

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

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

«Команда должна быть целиком сфокусирована на рынке. Чем больше барьеров мы устраним между рынком и командой, тем больше вероятность коммерческой состоятельности банка», – говорит Исанин.

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

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

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

Мельче, но быстрее

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

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

В «Альфа-Банке» автоматизация процессов разработки была начата с процессов тестирования.

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

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

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

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

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

Значительному числу организаций не удается провести преобразования правильно из-за фундаментального непонимания того, что на самом деле представляет собой цифровая трансформация.

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

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

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

1. Цифровая трансформация – это на самом деле трансформация человека

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

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

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

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

Этот сдвиг мышления помог компании совершить рывок вперед. «За прошедшие 10 лет мы сделали 80 приобретений, смогли укрепить связи, сформировать новые взаимоотношения и добиться того, чтобы сотрудники получше узнали друг друга», – отметил Фейруэзер.

2. Придерживайтесь ориентированного на клиентов подхода

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

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

Прежде всего они ориентируются на клиентское восприятие.

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

3. Формируйте новые команды

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

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

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

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

Аналогичного подхода придерживаются и в компании – поставщике сельскохозяйственного оборудования John Deere, где руководство составило план реализации перспективного проекта умного подключенного предприятия. На одной из фабрик компании было организовано пространство Foundry площадью 650 квадратных метров с более низкими, чем обычно, столами, с тем чтобы людям удобнее было общаться. Там предполагалось собирать новые команды и изучать agile-методологии при содействии экспертов, которые проводили бы сотрудников через полный цикл разработки.

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

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

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

«В прошлом нас считали центром затрат, – указал Джаярам. – Теперь же нам отводится роль пробивного тарана. Впервые в истории John Deere мы возглавили процесс. Мы приняли врученный нам мандат».

4. В процессе внедрения технологий укрепляйте взаимодействие

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

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

Усилия, направленные на укрепление взаимодействия, окупают себя. «Делясь практическим опытом, мы выявили типичные сбои, возникавшие в процессе операционной деятельности, – отметил Фейруэзер. – Нам удалось распространить свою практику на все команды, улучшив и скорректировав их совместную работу».

Руководство провело также обследование своей стратегической фундаментальной технологической программы. Один из комментариев сотрудников Фейруэзера звучал так: «Раньше мне отводилась роль винтика, теперь же, располагая полученной информацией, я буду вносить свой весомый вклад в общее дело. Научиться у коллег возможно, только если с ними налажены контакты. В рамках глобальной организации мы уже объединены в десяти областях, для этого всё сделано».

5. Когда дело касается изменений, будьте непримиримы

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

«Конечно, у нас были скептики, – заметила вице-президент GE Commercial и подключенной цифровой экосистемы digitalTHREAD Кейт Гутовски. – Но, если мы нацелились провести какие-то преобразования, равняться на таких людей не стоит».

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

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

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

6. Вырабатывайте менталитет стартапа

В 2014 году к купленному AT&T оператору добавилась вновь приобретенная компания Cricket Wireless. Две конкурировавшие друг с другом организации требовалось преобразовать в единого крупного игрока национального масштаба.

Подобно John Deere и CarMax, Cricket Wireless взяла на вооружение модель Agile. Все силы были приложены к тому, чтобы действовать быстро и добросовестно.

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

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

7. Добивайтесь от руководства дополнительных полномочий

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

Выработкой стратегии ведения бизнеса обычно занимается высшее руководство, оно и информирует всех остальных о принятых решениях. Джаярам попытался изменить сложившийся порядок. «Я решил перевернуть традиционный подход с ног на голову и собрал 40 человек, находившихся на разных уровнях иерархии, чтобы сформировать новую ИТ-стратегию и трансформировать компанию в цифровое предприятие. Мы полностью проработали все процессы, прежде чем выносить их на уровень высшего руководства. Некоторые из тех, кто вносил предложения, были новичками в компании, но зато имели большой опыт в части формирования восприятия пользователей и организации гибкой разработки. По мере выработки стратегии мы опросили почти 170 коллег, поинтересовались, есть ли во всем этом смысл, и получили ответ, что идем в правильном направлении».

После этого Джаярам пошел к руководству и представил план интеллектуального подключения и agile-методологии.

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

– Esther Shein. 7 habits of highly effective digital transformations. CIO. November 6, 2017

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

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

Что представляет собой DevOps?

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

Путь к DevOps

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

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

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

1. Подготовка к культурным переменам

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

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

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

2. Формирование процесса непрерывной интеграции, платформы непрерывного предоставления

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

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

Вот как это работает:

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

3. Создание среды непрерывного тестирования

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

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

К непрерывному тестированию применимы следующие рекомендации:

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

4. Внедрение системы непрерывного развертывания

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

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

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

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

5. Использование нового и старого развертывания

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

6. Непрерывный мониторинг производительности

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

1. Циклы разработки. Чтобы иметь представление о функционировании конвейера автоматического развертывания, следите за тем, как часто в код вносятся изменения, сколько новых функций реализовано, какое количество ошибок обнаружено и исправлено и т. д.
2. Развертывание. Если процедура автоматического развертывания завершается неудачей, нужен инструмент, который предупредит об этом соответствующих специалистов. Большинство серверов непрерывной интеграции автоматически пересылают сообщения на серверы чатов в случае сбоя процедур развертывания или сборки.
3. Уязвимости. После передачи кода в производство управление уязвимостями следует осуществлять автоматически. Неважно, идет ли речь об известных уязвимостях (присутствующих в National Vulnerability Database) или неизвестных (возникших в результате небезопасных действий), в любом случае система обязана их обнаруживать и минимизировать последствия.
4. Состояние серверов. Мониторинг серверов имеет важное значение практически для любого типа инфраструктуры, не только при использовании DevOps. Производительность и соглашения об уровне обслуживания (service-level agreements, SLA) системы зависят от состояния сервера. Есть несколько инструментов, помогающих решать эту задачу. Следует также осуществлять мониторинг инфраструктуры.
5. Производительность приложений. Для определения ключевых моментов производительности и регресса приложений необходимо следить за их функционированием и своевременно принимать необходимые решения. Поможет вам в этом целый ряд инструментов, в том числе AppDynamics и New Relic. Инструменты мониторинга производительности приложений (application performance monitoring, APM) предоставляют дополнительную информацию о характере использования приложений и их производительности.

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

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

Ключевые инструменты DevOps

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

• репозиторий исходного кода (Git, CloudForce, TFS, Subversion);
• сервер сборки (SonarQube, Jenkins, Artifactory);
• управление конфигурацией (Puppet, Ansible, Salt, Chef);
• автоматизация тестирования (Selenium, Water);
• виртуальная инфраструктура (Amazon Web Services, Microsoft Azure, VMware vCloud).

***

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

– Adam Bertram. 6 steps to devops success. CIO. OCT 18, 2017