Как связать сервисы предприятия с его процессами и ИТ-инфраструктурой

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

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

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

Предыстория проекта

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

Задача, предварительно озвученная нам, заключалась в том, чтобы найти истинные причины проблемы и разработать подход и меры, купирующие её возникновение в дальнейшем. Мы провели вводное совещание с CIO заказчика и пришли к выводу, что для решения вопроса необходимо изучить и проанализировать два направления: ИТ-инфраструктуру предприятия и его ИТ-процессы.
Изучать ИТ-процессы решили через призму ITSM-методологии, руководствуясь наличием частично внедренной  системы у самого заказчика. Также предстояло провести аудит имеющегося серверного оборудования, систем хранения данных, средств виртуализации, резервного копирования и восстановления данных, сетевых устройств. Иными словами – основных строительных блоков ИТ-ландшафта. Для предстоящего обоснования возможных вариантов модернизации ИТ-инфраструктуры и процессов предприятия мы воспользовались демонстрацией диаграммы затрат на достижение целевых показателей RTO (Recovery Time Objective) и RPO (Recovery Point Objective), при этом показав необходимость поиска баланса между ценой предлагаемых решений и запросами бизнеса.

Соответственно, наша работа должна была содержать также и обследование эксплуатируемых информационных систем, включая предъявляемые к ним требования по допустимым простоям и потере данных. Полноценных SLA (Service Level Agreement) у заказчика, к сожалению, не оказалось. Но в системе учёта ИС были определены градации их критичности для работы бизнеса. Этими данными и было решено руководствоваться в дальнейшем.

Часть 1. Обследование процессов 

Одна из составляющих проекта – обследование ITSM-процессов и оценка их зрелости, то есть уровня их стабильности, результативности и оптимизированности. Для этого часто используют модель CMMI (Capability Maturity Model Integration), которая определяет пять уровней зрелости.

1. Начальный. Деятельность ведется ситуационно. Например, именно так многие следят за своим здоровьем. Заболел зуб – начинаем выяснять, что делать и куда обращаться.

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

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

4. Контролируемый (управляемый на основе измерений). Регулярно проверяется соответствие регламента и реальной ситуации. График визитов не только вносится в календарь, но еще и контролируется.

5. Оптимизируемый. Процесс регулярно оптимизируется. Согласуется ли этот график с планом отпуска и загрузки на работе? Какой врач лучше? Не стоит ли одновременно планировать визиты к другим специалистам? 

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

Первое, с чем мы столкнулись, – огромная вариативность процессов и автоматизации. Какие-то из них детально формализованы (один только регламент на сотню листов, а еще рабочие и ролевые инструкции), а какие-то вообще никак не описаны. Где-то для автоматизации используется самописное решение, где-то – вендорский продукт, а где-то — ничего, кроме почты.

Также мы проанализировали заявки и обнаружили несколько интересных моментов.

• Категорию «другое» в запросах на обслуживание имеют примерно 50% из них. Это может говорить о том, что имеющиеся шаблоны не покрывают реальную ситуацию с типовыми запросами. Построили в них облако слов и гипотеза подтвердилась: ~40% запросов связаны с доступом (заявки на  доступ, смена пароля). Если для таких запросов сделать отдельную систему управления доступами (описывали в отдельной статье) и автоматизировать процедуру смены пароля (например, через SMS), то можно значительно снизить нагрузку на службу поддержки и высвободить ресурсы для развития.

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

• Ряд процессов, чья зрелость важна для бизнеса, находится на низком уровне. Например, для критичных информационных систем отсутствовали планы аварийного восстановления (Disaster Recovery Plan), не проводились учебные мероприятия для сотрудников.

• Процесс управления изменениями больше всего напоминал лоскутное одеяло: изменения в ПО собственной разработки были детально формализованы и велись сразу в трёх ИС без интеграции между ними. При этом они никак не синхронизировались с процессом внесения изменений в аппаратную инфраструктуру (этот процесс не был формализован, но частично велся в ITSM-системе). И оба процесса не имели связей с процессом управления изменениями в инфраструктуре информационной безопасности, в результате чего возникали проблемы несовместимости изменений и многочисленные инциденты.

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

Часть 2. Обследование и оценка ИТ-инфраструктуры 

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

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

• изрядно устаревшее оборудование; 

• отсутствие действующей поддержки на большую часть компонентов;

• недостаточное покрытие сервисов и оборудования системой мониторинга;

• переполненные хранилища;

• недопустимые тайминги резервного копирования (РК);

• наличие ошибок в системах и т.д.

Заказчик, естественно, не бездействовал последние несколько лет и проводил точечную модернизацию инфраструктуры по мере возникновения запросов и проблем в работе определенных ИС. Также вёл работу для поиска импортонезависимых решений в концепции «когда-нибудь нам на это придётся перейти». Такой подход привёл к интересной ситуации – в одном ЦОДе можно было увидеть такой антиквариат, как SUN Fire 280 или Superdome c Itanium второго поколения в составе рядом с новенькими Dorado и относительно свежими DL380 gen10. 

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

• определение факторов влияния на безотказную работу;

• составление ресурсно-сервисной модели;

• оценка рисков.

Давайте пройдемся по каждому пункту отдельно.

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

• ­состояние серверного оборудования;

• ­поддержка серверного оборудования;

• ­устаревший гипервизор;

• ­поддержка гипервизора;

• ­резервные копии;

• ­высокая доступность HA;

• ­состояние оборудования SAN;

• ­поддержка оборудования SAN;

• ­состояние оборудования СХД;

• ­поддержка оборудования СХД;

• ­состояние сетевых подключений;

• ­наличие репликации;

• ­проверка восстановления;

• ­наличие мониторинга и­др.

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

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

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

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

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

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

2. Просуммировать весовые значения актуальных рисковых событий для анализа соответствия ИТ-инфраструктуры требованиям, предъявляемым бизнесом к ее доступности и надежности со стороны ИС.

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

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

• определять первоочередные точки роста и слабые места эксплуатируемых компонентов ИТ-инфраструктуры;

• оперативно оценивать различные варианты стоимости модернизации ИТ;

• вести диалог с бизнесом, показывая объём необходимых изменений для обеспечения требуемых показателей непрерывности процессов.

Заключение

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

Но это уже совсем другая история.

*Статья была написана в соавторстве с @Alejanders