Анализ ИТ-ландшафта и методика выбора технического решения

Россин Д.В.

Выпускник группы MBA CIO-54

Школа IT-менеджмента

РАНХиГС при Президенте РФ

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

В рамках проекта необходимо было:

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

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

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

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

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

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

2. После определения потребностей бизнеса начали определять ИТ-возможности:
   • Рассматривали текущее состояние инфраструктуры;
   • Анализировали имеющиеся на рынке ИТ-решения и практики.

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

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

• приложение / сервис;
• назначение сервиса;
• количество пользователей по отделам;
• общее количество пользователей;
• качественная оценка интенсивности использования сервиса;
• прогноз изменения использования сервиса на 5 лет;
• местоположение пользователей (ЦО/Филиалы/Интернет);
• допустимый простой;

Среди всех этих данных основными для анализа со стороны риск-менеджмента является показатель допустимого времени простоя каждого из сервисов RTO (Recovery Time Objective, или целевое время восстановления), а также важность каждого из сервисов для бизнеса.

В кратком виде в рамках данного проекта мы получили его от бизнес-подразделений в виде таблицы №1.

Таблица №1

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

Состояние ИТ-инфраструктуры было получено от сотрудников ИТ-подразделения. В качестве шаблона для передачи данных была предложена таблица №2.

Таблица №2

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

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

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

Таблица №3

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

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

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

Основное бизнес-приложение, на котором было построено большинсво бизнес-операций по поддержке, продаже товара, по учету и т.п., называется OCS. Данное приложение построено на основе базы данных Oracle. Графический анализ структуры этого приложения представлен на рис.1

Структура работы приложения OCS, Рис 1.

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

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

Например, система СХД НР StorageWorks P2000 была снята производителем Hewelett Packard с производства и поддержки, ввиду чего найти на замену вышедший из строя контроллер было невозможно. Данный факт приводит к тому, что размещение любых бизнес-критичных сервисов, требующих оговоренного времени восстановления RTO, представляется невозможным на оборудовании, не имеющем резервирования и не имеющем гарантийной и сервисной поддержки вендора. Общая таблица по итогам аудита, представленная собственникам и руководству Холдинга, дана в табл.№4

Таблица №4

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

Дерево выбора решения представлено на рис.2

Рис 2.

Данное дерево предлагает рассмотреть три основных варианта развития инфраструктурной части проекта:

• Собственная аппаратная платформа;
• Аренда виртуальных машин VMWare в рамках IaaS;
• Интегральные (гиперконвергентные) системы.

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

Услуга IaaS (Infrastructure as a Service) – представляет собой облако от какого-то из сервис-провайдеров, предоставляющих такую услугу. Все обеспечивается сервис-провайдером в своих ЦОД (центрах обработки данных), а для клиента данное решение является операционными затратами OPEX.

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

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

Далее применялся алгоритм многофакторного сравнения:

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

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

Таблица №5

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

Таблица №6

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

Диаграмма общей стоимости владения на 5 лет, Рис 3

На основании этих 2-х коэффициентов (стоимость решения и применимость решения) была построена карта выбора итогового решения в зависимости от баланса между финансовыми и качественными критериями. Сводим эти показатели в таблицу №6

Таблица №7

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

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

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

Приведенная выше модель выбора решения была создана с 2 основными целями:

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