Самое интересное

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

Старайтесь избегать сетей Wi-Fi с открытым доступом

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

Защитите домашнюю сеть

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

Подключайте все мобильные устройства через VPN

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

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

Не путайте свои персональные данные с деловыми

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

Не распространяйтесь в социальных сетях о работе

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

Смените, наконец, пароли, установленные по умолчанию!

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

Обновляйте программы регулярно

Киберпреступники активно эксплуатируют также и известные уязвимости в ПО и плагинах – например, в Adobe Flash, Acrobat Reader и Java. Плагины и программное обеспечение – в том числе мобильную операционную систему и доверенные приложения – необходимо регулярно обновлять на всех используемых устройствах.

Путешествуйте с умом

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

Берегитесь подслушивающих и подглядывающих!

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

Держите компьютер «на замке»

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

– Ryan Francis. 10 ways to make sure your remote workers are being safe. CSO. November 1, 2016

Черные пятницы и киберпонедельники – источники радости для покупателей и периоды наибольшей занятости для многих продавцов. В компании 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

Почему вопросам безопасности перед слиянием или поглощением (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

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

В мире сторонников программного обеспечения с открытым кодом Брайан Белендорф – личность известная. Он был ведущим разработчиков веб-сервера Apache – основы Всемирной паутины в том виде, в котором она нам известна. Белендорф – один из основателей организации, которая впоследствии трансформировалась в Apache Software Foundation. В 2003 году издание MIT Technology Review назвало его одним из 100 лучших инноваторов в мире в возрасте до 35 лет.

И вот теперь Белендорф присоединился к Linux Foundation, для того чтобы возглавить Hyperledger Project – совместный проект консорциума Linux Foundation, цель которого заключается в дальнейшем развитии технологии блокчейна. Белендорф рассказывает о проекте Hyperledger и своей роли в нем.

- Как, по вашему мнению, Hyperledger Project изменит финансовую и банковскую отрасли? Что побудило вас принять в нем участие?

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

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

И я почувствовал, что, если хотя бы часть идей осуществится, будь то создание валют или просто цепочек, подтверждающих достоверность выполненных операций, они окажут огромное положительное влияние не только на технологическое пространство, но и на общество в целом. Мне тоже захотелось в этом поучаствовать. Вместе с тем я не желал отстаивать интересы какой-то одной отдельно взятой компании, будь то крупное предприятие или стартап. Нужна была организация, которая помогала бы выстраивать общую технологическую базу. Сначала я просто наблюдал, как работают технологии, в том числе и биткойны, а затем поговорил с Джимом Землиным, исполнительным директором Linux Foundation, о Hyperledger. Я чувствовал, что проект этот многообещающий и может стать весьма прагматичным, весьма практичным.

Наряду с Apache и веб-сервером HTTP он способствовал бы борьбе за открытость Web. Речь шла также о создании печатного станка для всех и передаче его в руки любого желающего. Казалось, что весь проект Hyperledger пронизан таким прагматизмом и практичностью. И мне захотелось в нем поучаствовать.

- Какие преимущества проект Hyperledger получает благодаря его реализации под эгидой Linux Foundation?

Как-то я пошутил, что нам следовало бы пригласить Расмуса Лердорфа (создателя PHP) и кого-нибудь из парней, занимающихся MySQL. И тогда организацию можно было бы назвать LAMP (Linux, Apache, MySQL, PHP) Foundation. Я считаю, Линус и Джим проделали с ОС поистине удивительные вещи, и это замечательно. Им удалось привлечь компании, опирающиеся на общие технологии и помогающие выстраивать интероперабельные системы. Раньше для этого пришлось бы создавать специальные органы, занимающиеся утверждением стандартов. Теперь же все понимают, что открытый код представляет собой новый путь к стандартизации.

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

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

- Давайте вернемся к проекту Hyperledger. Какие отрасли получат реальную выгоду от блокчейна и Hyperledger Project?

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

- Какая отрасль окажется следующей? Или это слишком сложный вопрос?

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

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

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

- Каковы будут ваша роль и работа в качестве исполнительного директора проекта?

Проект уже запущен. В нем принимает участие большое количество разработчиков из множества компаний, в том числе из IBM, Intel и Blockstream. Нужно, чтобы их вклад рос и дальше. Мы уже проводим личные встречи, хакатоны и т. п.

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

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

- С какими сложностями вам придется столкнуться, ведь проект этот относительно новый?

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

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

– Swapnil Bhartiya. Open source veteran Brian Behlendorf on leading the Hyperledger Project. CIO. May 20, 2016