Статьи

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

Почему согласование ИТ и бизнеса по-прежнему остается в числе наиболее злободневных вопросов для ИТ-руководителей и их подчиненных?

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

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

Пол Вилкинсон активно занимается ITSM больше 20 лет, вначале как консультант, затем как менеджер по развитию сервисов и разработчик ITIL. Соавтор книги «ITIL Planning to Implement IT Service Management», участник консультативного комитета ITIL Version 3. Соавтор текстов и художник справочника itSMF по худшим практикам «IT Service Management from Hell».

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

На это есть две причины. Первую мы только что обсудили: если в ИТ-подразделении не понимают, как бизнес использует ИТ, то оно никогда не станет партнером, а будет лишь ИТ-провайдером. Другая причина – это метрики. Если взглянуть на типичные метрики, которые используются в управлении ИТ-услугами, станет очевидно, что их применение направлено на достижение результатов внутренней деятельности: доступность сервисов 99%, снижение числа инцидентов на 25%, сокращение времени реакции на запросы и пр. Но сами по себе все они ничего не значат для бизнес-руководителей. За снижением числа инцидентов на 25% может стоять, например, увеличение на 300 тыс. количества транзакций, которые обеспечат дополнительную прибыль 300 млн долл. В свою очередь, снижение числа простоев позволит сэкономить много денег, которые раньше терялись. Те метрики, которые сейчас предоставляют ИТ-службы, мало кому понятны из бизнес-руководителей. Эти метрики должны быть значимы для бизнеса – например, демонстрировать ценность того или иного сервиса для бизнеса, общую стоимость владения, отражать уровень бизнес-рисков и пр. Есть еще одна проблема: ИТ-департаменты пытаются использовать сборники рекомендаций, основанных на передовом опыте, чтобы обеспечить согласование бизнеса и ИТ. В результате ИТ-службы нацеливаются на внедрение ITIL или COBIT, но не на снижение общей стоимости владения. ИТ-службам, которые хотят стать настоящими партнерами для бизнеса, необходимо пристально всматриваться в появляющиеся на рынке технологии и учиться объяснять бизнесу, какие возможности для его роста несут в себе эти новые технологии. Так, руководство одной голландской страховой компании захотело увеличить продажи полисов страхования жизни. ИТ-руководитель компании предложил начать продажи онлайн-полисов и убедил руководство в том, что это принесет компании выгоду. Компания вывела на рынок новую услугу, провела рекламную акцию. Продажи онлайн-полисов пошли, и бизнес получил дополнительный доход 3,5 млн евро.

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

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

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

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

«Теневые» ИТ – это вовсе не то, чего хочет бизнес. Он не ставит своей целью создание «теневых» ИТ. Бизнес хочет как можно скорее освоить новые технологии и получить от них выгоду. Поскольку ИТ-департаменты слишком медленно реагируют на запросы бизнеса, да и не вполне понимают его потребности, бизнес ищет пути для быстрого развертывания и освоения новых ИТ. Некоторые компании, такие, например, как Google, NetFlex, развертывают и дорабатывают свои системы практически непрерывно, потому что их бизнес хочет меняться очень быстро, получая новую выгоду. Чтобы обеспечить возможность быстрых изменений, ИТ-службы используют DevOps, Agile, Scrum и другие подходы, позволяющие оперативно внедрять технологии, которые зачастую оказываются в «тени». Если ИТ-департамент продемонстрирует, что он может быстро развертывать новые технологии, бизнес доверит это дело ему. Если же ИТ-служба не сможет доказать свою способность без промедления внедрять нужные бизнесу технологии, то «теневых» ИТ будет в компании все больше и больше, а сама ИТ-служба перестанет соответствовать запросам бизнеса. Чтобы этого не произошло, ИТ-департамент должен измениться.

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

Одна голландская компания специально искала на должность CIO кого-нибудь из руководителей, знающих бизнес. Почему? Потому что руководители верхнего уровня должны понимать бизнес и его процессы. Сегодня очень важна роль руководителя, отвечающего за отношения ИТ-департамента с бизнесом. И директор информационной службы должен заниматься именно этим. Он должен иметь у себя команду менеджеров, умеющих развивать отношения с бизнесом (Business Relationship Management, BRM). Их задача в том, чтобы идти к пользователям, разбираться, каковы движущие силы бизнеса, вникать в бизнес-процессы, выяснять, почему пользователям нужны новые технологии. Это критически важная роль. Зачастую бизнес и ИТ не понимают друг друга, примерно как супруги, находящиеся на грани развода. Чтобы снизить напряженность между ними и наладить взаимопонимание, необходим посредник – советник по семейным вопросам. Точно так же посредник нужен и между бизнесом и ИТ, этим как раз и занимаются специалисты по BRM. Многие ИТ-руководители пользуются таким инструментом, как COBIT. Его ключевая идея – основываясь на стратегических целях бизнеса, выстроить стратегические цели ИТ-департамента. COBIT говорит, как согласовать цели бизнеса и ИТ. Другой инструмент – BRM, его ключевая идея – основываясь на выводах из COBIT, наладить диалог между бизнесом и ИТ. Третий инструмент – ITIL. Используя его, необходимо концентрироваться на доходах бизнеса. Эти три инструмента охватывают стратегический, тактический и операционный уровни управления ИТ. Подводя итог нашей беседе, я еще раз хочу сказать, что ИТ-департаментам необходимо меняться: не замыкаться на своих внутренних проблемах и изменить менталитет сотрудников ИТ-служб, привить им новую культуру – культуру диалога с бизнесом, погружения в его нужды и потребности, изменить позицию ИТ в отношении бизнеса, стимулировать ИТ-специалистов к тому, чтобы они поняли, что, зачем и как делают бизнес-пользователи, ежедневно встречались с ними и беседовали. Изменив свою позицию в отношении бизнеса, ИТ-специалисты изменят и свое поведение. Другими словами, необходим революционный сдвиг во внутренней культуре ИТ-департамента.

Вычислительные мощности есть у всех дата-центров, и во всех в той или иной мере присутствует охлаждение. Конечно, доступные вычислительные мощности могут отличаться, но большинство ЦОД вполне способно удовлетворить потребности большей части клиентов. На недавней конференции Finance and Investment Forum, прошедшей в Лондоне, от клиентов и инвесторов исходил четкий посыл: «Нас не заботят ваши пустые заявления. Нам интересны лишь безопасность ЦОД и получаемый уровень обслуживания».

Между тем большинство владельцев ЦОД, похоже, больше беспокоит то, что они думают о себе сами. (Возможно, мы просто преувеличиваем степень их зрелости?) «Мой ЦОД отвечает стандарту Tier 3, а мой – Tier 3*, у моего показатель PUE, характеризующий эффективность энергопотребления, составляет 1,2, а у меня – 1,1» – слышим мы то и дело.

Но: a) на самом деле это не так; б) такие уровни по большей части недостижимы; в) практически всегда это не более чем похвальба; г) клиентов все это совершенно не интересует.

Клиенты справедливо ждут, что ЦОД будет находиться в состоянии постоянной готовности. Источник: Leonardo Rizzi — CC BY-SA 3.0

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

Клиенты справедливо ждут, что ЦОД будет находиться в состоянии постоянной готовности. Они рассчитывают также, что мощности его обладают достаточным уровнем резервирования, и, если один элемент выйдет из строя, его тут же заменит другой без какого-либо прерывания обслуживания. Клиенты надеются, что ЦОД работает максимально эффективно. В конце концов, на протяжении многих лет нам постоянно твердят об этом. Редко когда можно встретить владельца коммерческого ЦОД, который не упомянул бы о «Tier 3» (очень часто это является саморекламой) или не утверждал, что у него показатель PUE меньше, чем у кого бы то ни было (еще одно голословное заявление). А вот о чем многие предпочитают не упоминать, так это о безопасности и реальном качестве обслуживания,  ведь это отнюдь не является их сильной стороной.

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

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

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

Встречаются ЦОД, проникать в которые можно часами, даже если вашего появления там ждут. Полчаса уйдет на то, чтобы пройти через входную дверь, если же вы хотите попасть внутрь, проще подойти сзади и воспользоваться грузовым дебаркадером. Здесь нет никого, и вы легко сможете пройти в любое место здания. Между тем все процессы должны быть надежны и эффективны с точки зрения защиты клиентских данных и оборудования, но просты и прозрачны в части получения авторизованного доступа. Большинство организаций превыше всего ценит безопасность своих данных, но многие ЦОД отделываются здесь лишь пустыми словами, предпочитая акцентировать внимание на том, какой у них Tier и насколько низким является показатель PUE: проверить это все равно невозможно и рассуждать об этом гораздо проще!

Позиция облачных провайдеров по вопросу надежности предоставляемых сервисов

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

Источник: OSP Data, 2015

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

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

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

Оптимальный вариант размещения ИТ-систем

На VI форуме «МИР ЦОД – 2015» аналитическая группа OSP Data провела блицопрос относительно оптимального варианта размещения ИТ-систем.

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

Источник: OSP Data, 2015

 

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

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

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

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

«Главным результатом усилий партнеров стала оптимизация быстродействия решений «1С»», Антон Думин, директор по ИТ компании «АЭМ-технологии»

Таким путем пошла компания «АЭМ-Технологии», входящая в структуру «Росатома». В 2012 году она начала внедрение системы планирования и оперативного управления производством на платформе «1С:Предприятие». В ходе проекта функционал решения рос взрывоопасно и в какой-то момент вышел из-под контроля.

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

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

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

«Кроме того, у нас перестали появляться ошибки СУБД и ошибки блокировки, сильно портившие кровь мастерам смены и диспетчерам, а отчетность теперь формируется в два с лишним раза быстрее», – добавляет Думин. В планах на будущее – работа с партнерами над интеграционными схемами между «1С» и системой оперативного планирования Ortems, а также средствами конструкторско-технологической подготовки производства «Интермех».

Гибкость имеет значение

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

Например, на аутсорсинге находятся услуги печати, а система объединенных коммуникаций Microsoft Lync, известная как «Skype для бизнеса», развернута в облаке. Каждый год компания возвращается к вопросу аренды офисных приложений Office 365, но пока решение принимается отрицательное.

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

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

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

Решение о поддержке внешней компанией подкреплялось еще несколькими факторами. Главный – это наличие квалифицированных кадров. В ходе общения с несколькими компаниями выяснилось, что высококлассных специалистов по Dynamics Ax на рынке мало. Более того, их не так уж много даже в крупных компаниях.

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

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

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

Избежать шантажа

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

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

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

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

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

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

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

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

«Мы доказали, что в России есть системы, способные полноценно заменить зарубежные. После анализа функционала российских и западных решений, проведенного еще в 2010 году, выяснилось, что отечественные продукты на 80–90% соответствуют западным», — считает Валерий Бордюже, председатель Координационного совета по ИТ предприятий оборонно-промышленного комплекса (КС ИТ-ОПК). Отставание отечественных решений от западных не такое уж сильное — в первую очередь оно касается удобства и «красоты». Тот отчет чиновники просто приняли к сведению. Когда же грянули санкции, они стряхнули пыль с отчетов и стали доказывать, что замещать есть на что.

Совет, возглавляемый Бордюже, состоит из трех групп: ИТ-директора предприятий ОПК, руководители отечественных ИТ-компаний и представители регуляторов (министерства, ФСБ, ФСТЭК и т. п.).

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

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

«Мы терпели, когда западные продукты внедрялись в добывающих отраслях. Там речь шла о “вхождении в клуб” мировых поставщиков и готовности играть по сложившимся правилам. Однако столь веские аргументы были далеко не всегда. Мы просили Счетную палату оценить, во сколько обошлось стране чрезмерное увлечение продуктами SAP, но наша просьба пока осталась без ответа», — говорит Бордюже.

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

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

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

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

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

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

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

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

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

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

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

Стоимость имеет значение

Что такое «озеро данных» и почему оно позволяет решить поставленные аналитические задачи?

«Идея очень простая: мы все данные грузим в кластер на платформе Hadoop, и все приложения используют эти данные, — объясняет Сотниченко. — Можно использовать и другие платформы, но Hadoop, на наш взгляд, имеет много плюсов, в том числе экономических».

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

Что еще немаловажно, Hadoop реально, а не на словах поддерживается сообществом разработчиков — любую возникшую проблему можно довольно оперативно решить.

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

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

Не превратить озеро в болото

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

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

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

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

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

Хранилища еще пригодятся

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

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

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

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

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

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

Ежедневно сотрудники службы информационной безопасности регистрируют, анализируют сотни событий и инцидентов информационной безопасности и реагируют на них. Однако одна из важнейших тенденций современности — смещение от «массовых» атак к более узким, целенаправленным атакам. Как от них защититься? Расскажем об опыте КБ «РосинтерБанк».

Целенаправленнные атаки (advanced persistent threats, APT) — это основательно подготовленные, специализированные кибератаки, направленные на достижение конкретных целей злоумышленников. Даже серьезные компании, такие как Sony, RSA, Google, Adobe, потратившие десятки миллионов долларов на защиту своих ресурсов, остаются незащищенными и несут потери в результате успешных целенаправленных атак. Пристальное внимание разного рода злоумышленников всегда привлекали финансовые организации, и сегодня они являются одними из основных объектов нападения.

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

Оценка рисков

Первым шагом к созданию эффективной защиты от APT является объективная и разносторонняя оценка рисков. КБ «РосинтерБанк» в рамках ежегодной оценки рисков проанализировал риски нарушения информационной безопасности и оценил потенциальный ущерб от реализации целенаправленных атак (см. врезку).

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

Ключевые принципы

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

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

На организационном уровне применяются следующие принципы.

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

План действий на случай атаки

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

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

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

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

Насолить злоумышленнику

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

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

Также советую всем специалистам по информационной безопасности использовать рекомендации по реагированию на инциденты ИБ, содержащиеся в документах: ISO/IEC 27035:2011, ISO/IEC 27043:2015, ISO/IEC 27037:2012, NIST SP 800–61 Rev. 2, NIST SP 800–86 и материалы организаций SANS и CERT.

Альберт Тазетдинов — заместитель начальника управления информационной безопасности АО КБ «РосинтерБанк»; amtazetdinov@gmail.com.