Статьи

Черные пятницы и киберпонедельники – источники радости для покупателей и периоды наибольшей занятости для многих продавцов. В компании Hudson’s Bay Company (HBC), которой принадлежат торговые марки Lord & Taylor, Saks 5th Avenue и ряд других, прошлогодняя предпраздничная лихорадка стала самым подходящим поводом для испытания новых функций веб-сайтов.

HBC использует типичный сервер приложений Oracle WebLogic и платформу электронной коммерции Blue Martini, предлагаемую разработчиками RedPrairie. Общий ее стек создавался и совершенствовался на протяжении многих лет. «Она работала, но были проблемы с ее развертыванием, сложно было вносить изменения и обновления», – указал Мэтью Пик, управляющий в HBC командой инженеров по инфраструктуре.

Инженеры HBC стали выяснять, как можно решить эти вопросы. Для решения проблемы были предложены микросервисы и контейнеры.

Для начала реализации своего проекта по смене платформы Пик выбрал Product Detail Page (PDP). PDP представляет собой часть приложения электронной коммерции, в котором содержатся описания и фотографии товаров. Вместо того чтобы встраивать PDP в приложение, разработчики из HBC разбили его на 12 отдельных микросервисов, размещавшихся в контейнерах приложения (один из них загружал изображения, другой обслуживал текстовую часть и т. д.).

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

Запуская PDP в прошлогодние черную пятницу и киберпонедельник, HBC решила подстраховаться и направила на микросервисы PDP лишь часть трафика. В случае возникновения нештатных ситуаций их можно было бы отключить и вернуть весь трафик в традиционное русло. «Мы не стали рисковать всем сайтом, – вспоминал Пик, следивший за ситуацией на протяжении всего запуска новых технологий, с пятницы и до понедельника. – Но рано или поздно настает момент, когда нужно просто сказать: “Давайте попробуем”».

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

Что такое микросервисы?

Эксперты описывают микросервисы по-разному, и согласованного их определения пока не существует. По сути, идея заключается в том, чтобы вместо монолитных приложений проектировался набор компонентов, из которых и будут складываться приложения. Аналитик IDC Эл Хилуа описывает микросервисы как «децентрализованную программную архитектуру, в которой компоненты приложений проектируются и развиваются независимо друг от друга». Связь между отдельными компонентами поддерживается через общие API. Таким образом, приложение или сервис разбиваются на множество компонентов, которые взаимодействуют с помощью API.

Звучит знакомо? Несложно предположить, что микросервисы восходят к модному термину прошлых лет – сервисно ориентированной архитектуре (SOA), воплощавшей идею создания независимых отдельных компонентов приложения.

«Заинтересованность предприятий в микросервисах объясняется поиском нового подхода к построению сервисно ориентированной архитектуры, а также к использованию микросервисов с контейнерами», – пояснил старший вице-президент консультационной компании Cloud Technology Partners Дэвид Линтикум.

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

Преимущества

Микросервисный подход дает следующие преимущества:

Гибкость. Благодаря разбиению приложения на компоненты каждая отдельная его часть разрабатывается независимо. «Вам больше не нужно беспокоиться о синхронизации действий разработчиков», – заметил Сид Сиджбрандидж, генеральный директор стартапа GitLab, предлагающего репозитарий кода, который составляет конкуренцию GitHub. Вместо того чтобы собирать команду из 100 человек, которые будут работать над одним приложением, вы формируете 10 команд по 10 человек, проектирующих отдельные компоненты и внедряющих новые функции по мере их готовности. Не нужно составлять расписание обновлений и собирать приложение полностью – новые функции появляются сразу, как только они будут готовы.

Частичные нарушения. Если какой-то компонент приложения перестает работать, нет опасности того, что откажет все приложение полностью. «Цель заключается в том, чтобы сузить круг неисправностей и минимизировать их последствия», – пояснил аналитик 451 Research Донни Беркхольц. Например, если банковский сайт создан с использованием микросервисного подхода, при отказе функции перевода денег возможность проверить свой баланс у клиентов все равно остается.

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

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

Задачи

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

В таких средах код пишется, тестируется и внедряется быстрее. Многие предприятия, придерживающиеся концепции DevOps, имеют автоматизированную инфраструктуру с самообслуживанием – например, виртуализированные или облачные среды для тестирования и разработки или для поставки уже готовых приложений. Исследования, проведенные 451 Research, показывают, что две трети организаций применяют при разработке приложений методологию agile-проектирования, а около 40% – концепцию DevOps. Именно в таких организациях вероятность успешного внедрения микросервисов наиболее высока. У компаний, не придерживающихся тенденции разработки следующего поколения, процесс перехода к микросервисам будет протекать сложнее.

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

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

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

Для поддержки инфраструктурной среды такого рода существует множество различных инструментов. Строить внутреннее облако можно при помощи программного обеспечения для частных облаков, предлагаемого VMware или OpenStack. Если ИТ-служба не хочет заниматься построением инфраструктуры самостоятельно, она может обратиться к платформам публичных облаков Amazon, Microsoft, Google и других поставщиков. Автоматизировать управление инфраструктурой можно при помощи платформ PaaS Cloud Foundry или Red Hat. Для приложений, управляемых событиями (например, для сценариев Интернета вещей), идеально подходят так называемые бессерверные вычислительные платформы. Каждая такая платформа меняет роль ИТ-службы – теперь перед ней могут ставиться разные задачи, начиная от поставок инфраструктуры и заканчивая построением среды, где разработчики самостоятельно будут развертывать микросервисы.

Для чего микросервисы подходят лучше всего

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

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

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

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

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

– Brandon Butler. What you need to know about microservices. Network World. November 9, 2016

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

Недавно сеть модных магазинов «Мэлон Фэшн Груп» завершила внедрение кассового решения на базе Microsoft Dynamics AX POS. Главной целью проекта была именно реализация концепции омниканальности. Подробностями проекта делится Алексей Морозов, ИТ-директор «Мэлон Фэшн Груп».

- Каковы корни проекта? Почему было принято решение о его реализации?

Ландшафт наших информационных систем сейчас эволюционирует: от стратегии Suite, то есть от монопольно представленной платформы «1С», мы постепенно переходим к стратегии Best of Breed, подразумевающей интеграцию лучших нишевых решений. Эта стратегия сложна в реализации и требует больше времени и компетенций, особенно в области качественной интеграции процессов и потоков данных. Однако комбинация лучших средств для решения каждой конкретной бизнес-задачи более выигрышна – не приходится идти на компромиссы: бизнес получает полную автоматизацию процессов каждого направления. В рамках реализации данной стратегии мы рассматривали и выбор лучшего решения для автоматизации точек продаж (Point Of Sale, POS).

Прежде в наших магазинах работала система на базе «1C:Предприятие 7.7». Это были автономные рабочие места, ими не могли централизованно управлять как бизнес-подразделения (скидки и акции), так и сервисные службы (обновления, контроль работы, сбор статистики). Загрузка справочных данных и выгрузка результатов были полностью в руках сотрудника конкретного магазина.

К тому же нас не устраивал слабый функционал и архаичный дизайн интерфейса. Еще хочу отметить архитектуру старого решения, работавшего под Linux через эмуляторы. Всё это ограничивало дальнейшее развитие: крупнейшие франчайзи «1С» отчаялись в попытках «скрещивать» решение с новым оборудованием, банковскими терминалами и т. д.

- Какую роль играет новое решение в развитии омниканальности?

Microsoft Dynamics мы рассматриваем как ядро для автоматизации всех процессов коммуникаций с розничными клиентами. Сейчас у нас реализованы не только стандартные POS-операции, но и процессы возврата в любом магазине, возвраты в обычном магазине покупок из интернет-магазина, есть поддержка акций и скидок, внутренние «фишки» (например, лимитные карты для своих сотрудников). Кроме того, разработана программа балльной лояльности, она постепенно запускается на первых двух брендах (BeFree и Zarina). Также начат ее запуск в Love Republic. Вся система работает как с классическим интерфейсом, так и в тач-реализации.

Каждый бренд самостоятельно разрабатывает требования к омниканальности, и базой для реализации этого служит именно новая платформа. Так, BeFree сейчас отказался от пластиковых карт лояльности – с клиентами теперь взаимодействуют через мобильное приложение, интегрированное с системой. С ней также интегрированы три автономные интернет-площадки, SMS- и почтовые сервисы. В ноябре передаем в эксплуатацию подсистему работы с остатками, потом запланированы процессы Click&Collect. На следующий, 2017 год в плане стоят проекты по самообслуживанию, а также сервисы, связанные с вводом в действие Федерального закона № 54-ФЗ «О применении контрольно-кассовой техники».

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

- Почему была выбрана именно платформа Dynamics AX, какие рассматривались альтернативы?

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

Выбор был богатый. Мы просмотрели более 10 систем: решения компаний «Пилот», «Сервис Плюс», Cegid, продукты GK/Retail, TP.Net, Set Retail. Везде были свои плюсы и минусы, но по совокупности победило выбранное нами решение. Изначально оно проигрывало в двух составляющих: требования к инфраструктуре и стоимость владения. Однако необходимость в глобальном апгрейде оборудования стояла уже давно, кроме того, переход на решения Microsoft позволил сократить требования к инженерной службе и в итоге решить вопросы централизованного управления.

При выборе решения мы консультировались с системным интегратором «Корус Консалтинг», с которым уже реализовали несколько проектов. Совместно пришли к выводу: у решения Microsoft будет достаточно низкая стоимость владения, что в конечном итоге и определило выбор.

- Какие проблемы – ожидаемые и не очень – проявились в ходе реализации проекта? Как их решали?

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

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

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

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

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

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

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

- За счет чего ожидаете возврат инвестиций, и какой? На какие эффекты рассчитываете?

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

Еще важна лояльность персонала. Как показывают электронные опросы по факту внедрения POS, она выросла: сотрудники признают удобство новой системы. Внедренное решение с тач-интерфейсом действительно красиво выглядит по сравнению с обычным торговым оборудованием. Заодно удалось усилить новую концепцию оформления (сейчас производится переформатирование магазинов), а также повысить оборот благодаря использованию второго дисплея для демонстрации покупателям промоматериалов.

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

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

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

К сказанному нужно добавить, что есть и дефицит специалистов по безопасности.

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

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

Необходимые навыки

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

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

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

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

Как отмечает Дэвид Фут, глава компании Foote Partners, занимающейся исследованиями рынка труда, наиболее востребованными будут специалисты по оценке защищенности, инфраструктуре открытого ключа, этичному хакерству, анализу вторжений, корпоративным системам защиты, криминалистической экспертизе и защите беспроводных сетей.

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

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

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

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

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

В компании Foote Partners в числе наиболее востребованных называют навыки работы с Apache Hadoop, базами NoSQL и NewSQL, а также с Apache Spark.

В компании GE Aviation после реализации проекта цифровой трансформации и внедрения технологий Интернета вещей появились две новые должности – директор по данным и главный инженер по новым методологиям производства. Для проектов разработки ПО компании требуются профессионалы с широкими познаниями в сфере Больших Данных, говорит ИТ-директор GE Aviation Джуд Шрамм: «Нам нужны люди, разбирающиеся в широком круге технологий, таких как Hadoop, Cassandra, Greenplum. Мы вкладываем деньги, чтобы нанимать новых специалистов и обучать имеющихся. Мы стремимся максимально расширить их компетенцию и приучить к адаптивности. Нам не нужны те, кто хорошо разбирается только в одной области, – мы ищем специалистов по Большим Данным, имеющим познания по всем технологиям».

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

Примерно в 60% компаний, ставших участниками опроса LNS Research, признались, что им не хватает собственных специалистов, чтобы начать проект в области Интернета вещей или аналитики. Мэтью Литлфилд, президент LNS, говорит, что остальные 40% – те, кто утверждают, что располагают нужными навыками, – «просто не осознают реальных масштабов проблемы».

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

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

– Облачные вычисления. С ростом объема данных в рамках проектов Интернета вещей предпочтительной инфраструктурой для них станет облачная.

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

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

– Деловые качества. С ростом применения Интернета вещей техническим специалистам понадобятся знания в области бизнеса.

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

Работник новой эпохи

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

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

В GE Aviation для обучения технических специалистов смежным профессиям сформирован отдел, получивший название «Цифровая лига». В него вошли 35 сотрудников, поровну из отделов ИТ, инженерного проектирования и управления производством и цепочкой поставок. Участники «лиги» совместно разрабатывают аналитические решения для управления запасами, оптимизации времени безотказной работы машин и автоматизации сборочных цехов.

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

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

Курс на инновацию

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

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

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

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

– Stacy Collett. Is your IT staff ready for IoT? Computerworld. Oct 31, 2016

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

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

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

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

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

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

В-третьих, были инициированы предварительные согласование и утверждение новых инвестиций в ИТ, что предусматривало три нововведения:

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

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

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

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

– Пол Уимпенни, директор по цифровой стратегии в ИТ-подразделении Продовольственной и сельскохозяйственной организации при ООН

– Paul Whimpenny, Senior Officer for Digital Strategy in the IT Division of the Food and Agriculture Organization of the United Nations. What happens when IT is guilty of Shadow IT? Network World. October 5, 2016

Почему вопросам безопасности перед слиянием или поглощением (Mergers and Acquisitions, M&A) уделяется так много внимания? Эксперты привели сразу несколько примеров кошмарных сценариев, когда компания с хорошим уровнем кибербезопасности приобретала организацию, у которой уже имелись серьезные бреши. Был случай проникновения к покупателю вредоносного кода из приобретаемой компании. Об этом никто не знал почти год, выяснилось же все только при подсчете нанесенного ущерба. Исходный код был украден, продукт скомпрометирован, репутация пострадала.

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

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

Раннее планирование

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

Публичная информация может сыграть вам на руку

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

Целью хакеров может оказаться сама информация о слиянии

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

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

Задавайте конкретные вопросы

Запрашивайте конкретную информацию, позволяющую получить представление о том, как вел себя потенциальный партнер по слиянию в прошлом:

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

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

Добейтесь максимальной прозрачности

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

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

Больше компаний – больше проблем

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

Трудности приобретаемой компании

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

Документируйте все тщательно и заблаговременно

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

Автоматизируйте свои процессы

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

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

Кто за что отвечает

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

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

Следите за людьми, которые пытаются делать все по-старому

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

Держите системы под замком, даже если планируете от них отказаться

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

Временные меры могут оказаться необходимыми

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

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

Не забывайте о человеческом факторе

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

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

Следите за утечкой мозгов

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

Жизнь вносит коррективы, и их следует учитывать

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

– Josh Fruhlinger. How to keep IT security at the forefront during a merger. CSO. Sep 19, 2016

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

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

Исследователи Грегорио Роблес и Хесус Гонсалес-Барахона из испанского Университета короля Хуана Карлоса определяют «ответвление» (forking) следующим образом: «Ответвление возникает, когда часть сообщества разработчиков (или независимая сторона, вовлеченная в проект) начинает проводить полностью независимую дальнейшую модернизацию имеющегося исходного кода. Для того чтобы считаться ответвлением, проект должен иметь: новое название; иное направление развития; параллельную инфраструктуру (веб-сайт, систему управления версиями, список подписчиков и т. д.); новое сообщество разработчиков (не связанное с оригинальным проектом).

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

Оценка ответвления с обеих сторон

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

«С одной стороны, возможность ответвления — одно из основополагающих прав разработчиков свободного программного обеспечения, — заметил президент Open Source Initiative Эллисон Рандал. — И мы понимаем, что свобода ответвления очень важна. Это отличный способ оживить умирающий проект».

В качестве примера Рандал привел пакет LibreOffice. До появления этой ветви проект OpenOffice.org страдал от «человеческого фактора», который не позволял развивать код дальше. Ветвь LibreOffice оказалась весьма успешной и сегодня уже затмила собой OpenOffice.org.

Но, к сожалению, ответвление не всегда дает такой положительный результат. «Я сталкивался с ситуациями, когда ветвление проекта разделяло сообщество, приводило к напряженности, сокращению ресурсов и в конечном итоге убивало проект, — указал Рандал. — Если проект разделяется, с каждой стороны остается только половина работающих над ним. Обе стороны начинают бороться за одних и тех же пользователей и в конечном итоге не получают критической массы. В такой ситуации пользователи оказываются в беде».

Но можно предпринять меры, которые помогут вам остаться на правильной стороне.

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

Опасности реальной жизни

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

Когда в начале нынешнего года от проекта ownCloud отделилась ветвь Nextcloud, за ней стоял основатель ownCloud Фрэнк Карличек. Он хотя и является инициатором Nextcloud, но в целом выступает против ответвления, объясняя свою позицию так: «Ответвления — это крайняя мера. У такого развития событий есть множество недостатков. Ответвления вредят сообществу и разрушают его, и в самом худшем случае разделяют его на две равные части».

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

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

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

Нужно ли ИТ-директору бояться ответвления? Лучший способ получить ответ на этот вопрос — изучить историю появления новых ветвей.

В своем исследовании Роблес и Гонсалес-Барахона проанализировали «все сколько-нибудь значимые ответвления». В августе 2011 года ими было выявлено 220 подобных проектов. Прекращение реализации как первоначального проекта, так и всех его ветвей наблюдалось в 9% случаев. При появлении ветвей, обусловленных прекращением реализации оригинального проекта (возможным или фактическим), доля действительно прекращенных оригинальных проектов составила 10%. Дальнейшее развитие ответвлений обрывалось чуть чаще — в 14% случаев.

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

– Paul Rubens What CIOs need to know about open source forking. CIO. October 4, 2016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– Paul Whimpenny, Senior Officer for Digital Strategy in the IT Division of the Food and Agriculture Organization of the United Nations. A pragmatic approach to Enterprise Architecture. Network World. October 4, 2016

На конференции Gartner Data Center, Infrastructure & Operations Management Events, которая пройдет 28-29 ноября в Лондоне и 5-8 декабря в Лас-Вегасе, аналитики обсудят тенденции развития ЦОД.

Появление новых технологических тенденций всегда сопровождается распространением определенных допущений и посулов, которые могут повлиять на поведение покупателей и привести к принятию неверных решений. На рынке гиперконвергентных интегрированных систем (Hyperconverged Integrated Systems, HCIS) компания Gartner выделяет семь наиболее общих деструктивных предположений такого рода.

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

Миф 1. Во всех реализациях HCIS фигурируют стандартные и открытые архитектуры

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

Миф 2. HCIS проваливают тесты на масштабируемость и устойчивость

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

Миф 3. Стоимость HCIS соответствует максимально экономичной модели развертывания

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

Миф 4. Важнейший сценарий использования HCIS связан с VDI

Инфраструктура виртуальных рабочих столов (Virtual Desktop Infrastructure, VDI) – самый известный сценарий использования HCIS. Но сегодня сильные стороны HCIS рассматриваются и при решении многих задач общего назначения, поскольку обеспечивают увеличение производительности, масштабируемость, защиту данных и простоту развертывания, а также расширение гибридной облачной экосистемы. В ближайшие три года ИТ-руководителям следует ориентироваться на дальнейшую их экспансию, что позволит добиться еще большей гибкости, будет способствовать использованию методик DevOps, внедрению контейнеризации и т. д.

Миф 5. HCIS подразумевают отход от традиционных массивов хранения

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

Миф 6. HCIS не обеспечивают интероперабельности

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

Миф 7. Традиционные предпочтения при выборе вендоров останутся прежними

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

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

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

- Gartner Reveals Seven Myths for Hyperconverged Integrated Systems. Analysts to Discuss Data Center Trends at the Gartner Data Center, Infrastructure & Operations Management Events

Польза DevOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Появившаяся в 1990-х служба доставки WebVan считалась высокотехнологичной, потому что обеспечивала возможность заказывать продукты на веб-сайте. Возникнув на волне бума дот-комов, впоследствии она пала жертвой мыльного пузыря интернет-компаний: в 2001-м WebVan обанкротилась.

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

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

«Последняя миля» ждет своей революции. Но как именно она могла бы совершиться?

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

С Google Express соперничает сервис доставки AmazonFresh, за который приходится выкладывать по 299 долл. в год, и это предложение от компании, знаменитой бесплатной доставкой обычных заказов (AmazonFresh доставляет продукты питания; еще в Amazon создают отдельный курьерский сервис для непродуктовых посылок, который будет соперничать с FedEx и UPS).

Оптимально организовать доставку пищевых продуктов также пытаются в компаниях Peapod, Fresh Direct, Whole Foods и других. Но ни в одной из них по сути так и не решили проблему последней мили – доставка по-прежнему медлительна и обходится дорого. Как же быть? Может, использовать дроны?

Когда в 2013 году глава Amazon Джефф Безос объявил о планах организовать доставку заказов дронами, инициативу встретили со скепсисом. С тех пор о похожих намерениях и экспериментах сообщили в Google и других технологических компаниях, а также в рознично-торговых сетях вроде Wal-Mart и курьерских службах наподобие UPS.

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

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

Колесная база для дронов

В Mercedes-Benz недавно представили концепцию курьерской службы Vision Van с роботизированными складами и фургонами, от которых до клиента товар доставляют как люди, так и дроны. Службу придумали в Mercedes совместно с компанией Matternet, разработчиком коммерческих дронов. На складе заказы размещаются на двух палетах, которые автоматически загружаются в фургон. Роботизированная система выбирает в нем нужную посылку согласно адресу очередной доставки и передает водителю через окно, пока тот еще в кабине. Та же система может вытолкнуть упаковку через люк в крыше, чтобы передать ее одному из двух ожидающих дронов, а те доставляют заказ к порогу дома покупателя. Таким образом можно ускорить доставку в дома, находящиеся вдалеке от автодороги. Доставлять можно одновременно до трех упаковок: одну относит водитель, две другие – дроны. Кроме того, дрон может оперативно принести посылку со склада к фургону уже отбывшего водителя, когда требуется срочная доставка.

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

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

Холодильник на колесах

В эстонской компании Starship Technologies создали робота-курьера, который выглядит как сумка-холодильник на колесах. Он может доставлять заказы в автономном и полуавтономном режиме.

По словам сооснователя Starship Ахти Хейнла, одного из создателей Skype, его робот-курьер абсолютно безопасен, поскольку ездит не спеша – всего 6 км/ч, а специальное программное обеспечение заставляет его уступать дорогу пешеходам. А еще за ним дистанционно следит оператор, который может взять управление на себя, если робот не справляется. По словам Хейнла, в ходе испытаний робот проехал уже почти 13 тыс. км, встретив на своем пути свыше миллиона пешеходов, и еще никого не травмировал. Сегодня он тестируется в городах Германии, в Сан-Франциско, в Лондоне, в Швейцарии и других местах, а недавно начались испытания в Вашингтоне.

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

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

Еще Starship совместно с Mercedes работает над проектом Robovan, в рамках которого специально оборудованные фургоны используются в качестве колесной базы для размещения до восьми роботов-курьеров. Фургон паркуется в заданном квартале, после чего роботы доставляют еду и другие товары в дома в радиусе до 3 км.

Похожие автоматические курьеры испытываются компанией Domino в Новой Зеландии для доставки пиццы. Робот – Domino's Robotic Unit – управляется программой, которую создали в австралийской компании Marathon, работающей на военно-промышленный комплекс. DRU перемещается автономно, объезжает препятствия и доставляет пиццу и напитки на расстояние до 19 км. Чтобы открыть отсек с пиццей, заказчик вводит переданный ему код.

Автономные колесные роботы появляются и в гостиницах. Робот Relay от компании-стартапа Savioke выполняет роль горничной – приносит в гостиничные номера полотенца и кофе. На сегодня в отелях США уже применяются 12 таких роботов.

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

Над автоматизированными колесными системами доставки грузов трудится еще целый ряд молодых компаний Кремниевой долины, в том числе Fetch Robotics, Marble, Dispatch Robotics и Robby Technologies, а в Китае подобные решения разрабатывают гиганты электронной коммерции Alibaba и JD.com.

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

Мобильная кухня

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

Штаб-квартира Zume Pizza находится в Маунтин-Вью – там же, где и Google. И сотрудники последней пользуются услугами Zume, которая известна сенсационными заявлениями о том, что пиццу у них готовят роботы. На самом деле промышленные машины просто наносят на основу соус и помещают пиццу в печь, где она разогревается.

В грузовике Zume Pizza – 56 печей, которые нагреваются до 430 °C за четыре минуты до прогнозируемого времени прибытия к заказчику. Тот в результате получает пиццу горячей, только что из печи.

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

На сегодня Zume Pizza высокотехнологична только отчасти. Люди делают основу для пиццы (с помощью механического пресса), осуществляют погрузку, водят фургоны, режут пиццу и доносят ее до двери. Но со временем в компании хотят автоматизировать все перечисленные процессы.

Главным преимуществом Zume стало то, что благодаря автоматическому приготовлению пиццы в пути можно за одну поездку доставить до 56 пицц – причем с пылу с жару.

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

- Mike Elgan. Why the future of package delivery is better than drones. Computerworld. October 1, 2016