Цифровая трансформация

Опубликован атлас

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

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

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

Россия, следуя мировым технологическим тенденциям, принимает передовые зарубежные практики, положенные в основу международных стандартов (в частности, ISO), формализуя их в виде стандартов ГОСТ. Тут случаются коллизии. Если мы посмотрим на англоязычный термин «business continuity», с которого собственно и начинается данное направление, то в стандарте ГОСТ 22300 «Безопасность в чрезвычайных ситуациях. Термины и определения» он переведен как «непрерывность деятельности». А в стандарте ГОСТ 22301 «Системы менеджмента непрерывности бизнеса. Общие требования» термин переводится как «непрерывность бизнеса». И это, к сожалению, не единственное подобное расхождение.

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

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

Специалист широкого профиля

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

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

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

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

Источники знаний

Куда же обратиться тем, кто хочет развить свою компетенцию в сфере обеспечения непрерывности бизнеса, если упомянутых курсов недостаточно? Хорошо, если человек владеет английским языком на уровне чтения литературы – он может использовать и многообразие перечисленных выше стандартов, и множество литературы от опытных профессионалов, и услуги целых учреждений, работающих в данной области и представленных в Интернете. Среди последних наиболее авторитетными и предоставляющими для изучения большое количество профессиональной информации являются Институт непрерывности бизнеса (Business Continuity Institute, thebci.org) и Международный институт восстановления после катастроф (Disaster Recovery Institute International, drii.org). Эти институты выпустили свои подробные методики построения систем управления непрерывностью бизнеса, они публикуют дополнительные предметные руководства, а также статьи по отдельным вопросам непрерывности бизнеса.

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

В тематических и отраслевых журналах встречается некоторое количество более или менее подробных статей по вопросам непрерывности бизнеса, в том числе и в «Директоре информационной службы» (http://www.osp.ru/os/2012/01/13012922). Но нужно понимать, что, читая статью или даже серию статей, невозможно погрузиться в тему настолько, чтобы стать специалистом хотя бы начального уровня. Для сравнения, методики Института непрерывности бизнеса или Международного института восстановления после катастроф, подробно поясняющие все аспекты процессов управления непрерывностью бизнеса, – это книги объемом более 100 страниц текста.

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

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

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

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

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

* * *

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

Службе информационной безопасности приходится выстраивать все новые бастионы между физическими и виртуальными стенами своей организации. И конечные пользователи должны принимать непосредственное участие в обеспечении защиты корпоративных данных и систем. Для того чтобы обезопасить себя и свои организации, аналитики компании 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

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

Недавно сеть модных магазинов «Мэлон Фэшн Груп» завершила внедрение кассового решения на базе 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

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

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

Исследователи Грегорио Роблес и Хесус Гонсалес-Барахона из испанского Университета короля Хуана Карлоса определяют «ответвление» (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

Польза 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

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

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