В ИТ есть несколько видов учета, которые нередко неоправданно смешивают. Часто говорят о сервисно-ресурсных моделях, но потом перескакивают на финансовые модели и учет активов, да и само понятие «ИТ-актив» очень размыто, поэтому важно понимать, ради чего ведется учет. Например, практики ITSM исходят из того, что ИТ-отдел — это подразделение, которое предоставляет сервисы потребителям и ведет учет в базе данных управления конфигурациями (Configuration Management Data Base, CMDB) [1]. Единицами такого учета выступают сами сервисы и объекты инфраструктуры, критичные для сервисов. Если какой-либо сервер не очень важен для поддержки бизнес-процессов, то с точки зрения ITSM его можно и не учитывать.
Учет ИТ-активов (IT Asset Management, ITAM) направлен, в свою очередь, на измерение стоимости ИТ и предоставляемых услуг. В данном случае выделяются объекты внутри ИТ, которые стоят денег и значимо влияют на себестоимость инфраструктуры и сервисов. И если патч-корд практически ничего не стоит, то его предлагается отдельно не учитывать. Кроме того, некоторые виды оборудования могут быть слишком сложны для учета (например, из-за их большого количества или из-за частого перемещения), поэтому их тоже учитывают упрощенно.
Однако специалисты, обслуживающие ЦОДы, напрямую работают с ИТ-оборудованием, кабельными системами, инфраструктурами электропитания и охлаждения и поэтому нуждаются в детальной информации для организации своего ежедневного труда. Им важнее знать не «сколько стоит», а «как устроено», «где стоит» и «как соединено». Чаще всего эти технологические подробности целиком выпадают из систем учета, а если и фиксируются в CMDB или ITAM, то почти всегда лишь фрагментарно. Характерный пример — патч-панели, сведения о которых обычно в CMDB не вносят. Но при оказании услуг нужно понимать, как организована сетевая связанность.
Все эти подходы — части управленческого учета, но применяются в разных областях. Технический учет и ITSM схожи, так как в их основе лежит идея того, что для предоставления сервиса важно понимать, от каких ресурсов он зависит, и четко представлять, как эти ресурсы организованы. Однако в ITSM-системах картина сильно упрощена: ресурсная модель строится с точностью до сервера, хотя понятно, что под этим «сервером» подразумевается достаточно большое содержание и существенное окружение, информация о которых необходима для обеспечения реальной работы.
Почему это важно
Практика многих российских предприятий, неплохо реализовавших процессы ITSM, показала, что в случае аварийных ситуаций часто возникают проблемы «мелочей». Например, система мониторинга выдает сообщение о «падении» сервиса, и специалисты, начиная разбираться, выясняют, что проблема — в сетевой связанности между площадками. Система мониторинга и CMDB помогают локализовать слабое место, однако обнаруживается, что достоверной информации о том, как реально организовано кабельное соединение между площадками, нет. Возможностей CMDB для устранения неполадок не хватает: уровень упрощения в этой базе хорош для локализации проблемы с точностью до ответственного подразделения или сотрудника, но не позволяет получить детальную картину участка и подсказать, где искать проблему.
Приступая к работе с новыми заказчиками, мы часто видим, что CMDB у них построена и активно используется в реальной работе, но фактически в ней описана лишь верхушка ИТ-инфраструктуры и не предоставлена информация для людей «в поле» — огромная часть этого айсберга остается невидимой. Идею внедрения CMDB поддерживают энтузиасты, которые считают, что с ее помощью удастся объединить всю информацию об инфраструктуре, хранящуюся в различных источниках. Но потом выясняется, что в систему попадают и учитываются лишь очень крупные объекты: сервисы, экземпляры ПО, базы данных, серверы и т. п. А сетевое оборудование, компоненты серверов и систем хранения, кабельные системы, каналы связи, инженерные системы выходят за рамки CMDB — их централизованный учет сложен и затратен. В итоге проект ITSM у многих сотрудников служб эксплуатации вызывает разочарование.
При решении инцидентов или планировании развития специалисты вынуждены опираться на неструктурированные данные: бумажные документы, документы виде pdf-, visio- или DWG-файлов, которые хранятся в разрозненных источниках и плохо организованы. К сожалению, на эту проблему часто закрывают глаза, и ее приходится решать в рамках отдельных подразделений. Но для обеспечения нормальной работы ИТ-инфраструктуры требуется взаимодействие сотрудников разных отделов: сетевикам неплохо знать не просто, как устроена сеть, но и в каких местах подключены конкретные серверы, где именно расположено оборудование, как организовано электропитание и охлаждение и пр. И эта информация нужна в электронном структурированном виде для быстрого поиска, сравнения, анализа.
Таким образом, существующие централизованные системы (CMDB, ITAM) не обеспечивают необходимую для производственных задач детализацию, что негативно влияет на совместную работу специалистов, оптимизацию и автоматизацию рутинных задач, планирование инфраструктуры. У людей, занимающихся поддержкой и развитием инфраструктуры, нет информации, достаточной для принятия решений.
Данная проблема актульна не только для российских компаний. Однако, скажем, в немецких компаниях она стоит не так остро благодаря педантичности и внутренней дисциплине сотрудников. Например, ИТ-директор Volkswagen в свое время признался, что его единственный KPI — снижение операционных затрат на 5% в год в условиях роста компании. Число объектов в компании увеличивается, но требование по сокращению затрат остается, и, чтобы справиться с такой задачей, требуется полная автоматизация всех типовых ИТ-операций, фундаментом которой является исчерпывающая информация обо всех ресурсах.
Человеческий фактор и кризисы
Проблемные ситуации часто вызваны человеческим фактором: сотрудники увольняются, идут на повышение, переводятся на «удаленку» и пр. — и оказывается, что некому решать проблемы. Поэтому знания таких специалистов необходимо переносить в систему технического учета и делать их достоянием всей организации. Компании, имеющие подобные системы, даже в условиях кризисов продолжают работать без изменений, планируя деятельность без обязательного физического присутствия конкретного сотрудника на площадке.
Вместе с тем именно в кризисы компании начинают ощущать, что им не хватает детальной информации об организации инфраструктуры. И они сталкиваются с необходимостью консолидации и оцифровки разрозненной первичной информации в рамках единого решения.
Для начала надо признать наличие пробелов в имеющихся данных об ИТ-инфраструктуре. На рынке представлены специализированные системы, позволяющие справиться с задачей сбора и хранения детальной информации. Такие продукты бывают как узконаправленными (например, системы кабельного учета или системы управления сетями IP/SDH/WDM/MPLS…), так и универсальными, способными охватить и телекоммуникационную, и инженерную, и ИТ-инфраструктуру. Разумеется, для крупной компании, бизнес которой зависит от всех этих составляющих, хорошим решением станет комплексный вариант — интегрированная система ведения детализированного учета всей инфраструктуры и взаимосвязей между ее элементами.
В большинстве компаний отдельные технические подразделения собирают собственные данные, но чаще всего они разрозненны, плохо структурированы и не слишком достоверны. Наиболее сложно проводить аудит информации, сохраненной в PDF-, DWG-, visio-файлах, а иногда и просто в виде текста в нарядах на проведение работ. Но, тем не менее, все эти данные надо актуализировать, оцифровать и свести воедино.
Как правило, при первичной загрузке и выверке данных число выявляемых ошибок впечатляет: даже если специалисты добросовестно ведут учет, погрешностей, связанных с человеческим фактором, выявляется очень много. Каждый случай приходится проверять на месте. Всегда выявляется проблема несоответствия данных из кабельных журналов реальному положению дел. Например, обнаруживаются кабели, подключенные одной стороной к медному порту, а другой — к оптическому. Более того, часто обнаруживаются порты, к которым подключено более одного кабеля. Нередки случаи, когда предоставляются данные об оборудовании, которое физически не может уместиться в имеющейся серверной стойке, да и о количестве стоек в своих ЦОДах компании зачастую имеют приблизительное представление. Фактически при первичной загрузке приходится проводить и частичный аудит ИТ-инфраструктуры – наведение порядка требует аккуратности и времени.
.jpg)
На что можно рассчитывать
Система технического учета явно не приносит прямой прибыли, и ее надо воспринимать как фундамент обеспечения надежности эксплуатации ИТ-инфраструктуры — наличие детальной информации об инфраструктуре помогает на 20–30% сократить время устранения проблем. Зная, как устроена инфраструктура, удается быстрее решать типовые задачи.
Другой эффект — скорость изменений. Если необходимо быстро предоставить услугу или провести изменения в ИТ-инфраструктуре, то очень важно, насколько оперативно можно спланировать действия и насколько безошибочно они будут выполнены. Система технического учета позволяет быстрее и качественнее планировать изменения и исключать коллизии. С ее помощью можно не только составить план необходимых технических операций, но и забронировать ресурсы, что особенно актуально, когда работу одновременно ведут несколько сотрудников. Известно, что причиной многих инцидентов являются работы по модернизации инфраструктуры. Для снижения вероятности возникновения неполадок следует сформировать и выдать линейным специалистам список детальных нарядов с четким описанием работ. Такой подход снижает время простоя ключевых сервисов, а грамотное планирование и четкое исполнение работ минимизируют риски отказа или повреждения устройств при проведении изменений, сокращают общую продолжительность работ.
Повышение прозрачности информации об инфраструктуре, создание «цифровых двойников» становятся для многих компаний важным фактором, подтверждающим готовность к цифровой трансформации.
Движение в сторону интеллектуальности
Сегодня на производствах начинают реально применять средства дополненной реальности, технологии искусственного интеллекта, которые помогают выполнять необходимую последовательность операций, советуют, куда установить деталь, рекомендуют, на что обратить особое внимание. Ряд компаний предполагают задействовать возможности этих систем и в ИТ — например, реализовать такой сценарий: оператор подходит к стойке, чтобы установить оборудование, а система подсвечивает место установки и порты для подключения оборудования на основании выданных нарядов.
Искусственный интеллект способен помочь и в первичном сборе данных. Получение информации из плохо структурированных источников и ее выверка — крайне неблагодарное занятие даже для опытных специалистов. Оцифровка данных, хранящихся в аналоговом виде, сложна, требует ручного труда, и технологии из арсенала ИИ здесь могут помочь.
Еще одно направление развития — использование средств автообнаружения (discovery) для аудита инфраструктуры и верификации данных. Многие компании хотят реализовать интеграцию с такими решениями, позволяющими проводить сверки в технической системе. В идеале они должны производиться оперативно: например, после установки оборудования очень полезно запустить автоматическую проверку и подтвердить, что операция выполнена корректно. Руководители хотят, чтобы ИТ-процессы были не только регламентированы и автоматизированы, но и обеспечивали автоматические проверки.
Исходить из потребностей
Разумеется, при выборе конкретной платформы следует ориентироваться на конкретные задачи, и иногда нет потребности в консолидации технического учета на основе единой системы. Однако часто встречается ситуация, когда в компании проводится серия конкурсов по выбору отдельных систем: сначала — учета площадок, далее — учета оборудования на площадках, затем — учета IP-адресного пространства и т. д. В итоге выясняется, что все эти системы собирают данные для поддержки единого технологического процесса по предоставлению услуг заказчикам. Однако единого решения, где все эти данные будут объединены, не создается. Поэтому необходима «дорожная карта», в рамках которой специалисты могут скоординировать свои технологические потребности и принять решение о выборе единой платформы или, возможно, нескольких специализированных систем, но с одним «зонтиком» над ними. Подразделения должны четко понимать границы и «устройство» того участка, за который они отвечают, чувствовать локоть соседа, иметь возможность работать согласованно и рационально.
***
Иногда требуется быть «ближе к земле», но нельзя забывать, что «дьявол кроется в деталях» и, например, отсутствие сведений о маршруте прокладки кабеля между ЦОДами может свести на нет инвестиции в ITSM-проект. Для выполнения рутинной работы ИТ-подразделениям необходимы инструменты технического учета, аккумулирующие детальную информацию об инфраструктуре и формирующие фундамент обеспечения надежности эксплуатации ИТ-конфигурации предприятия.
Литература
1. Заурбек Алехин. Управление конфигурациями и изменениями // Открытые системы.СУБД. — 2001. — № 7-8. — С.50-56. URL: www.osp.ru/os/2001/07-08/180310 (дата обращения: 21.11.2020).
Сергей Довгань (sergey.dovgan@sdisoft.ru) — технический директор, компания «СДИ Софт» (Москва).
