Технический учет, CMDB и ITAM — в основе успешного управления ИТ-ресурсами
Технический учет, CMDB и ITAM — в основе успешного управления ИТ-ресурсами

Наличие детальной информации об инфраструктуре помогает на 20-30% сократить время устранения проблем.


12:07 17.11.2020  (обновлено: 17:51 19.11.2020)   |   1549 | 

Рубрика Партнерский материал



Почему CMDB и ITAM недостаточно для решения задач по обслуживанию инфраструктуры ИКТ и чем тут поможет технический учет имеющихся ресурсов.

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

Автор — Сергей Довгань, технический директор компании «СДИ Софт»

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

Например, практики ITSM исходят из того, что ИТ-отдел — это подразделение, предоставляющее потребителям ИТ-сервисы. В рамках этой деятельности в базе данных управления конфигурациями (Configuration Management Data Base, CMDB) ведется учет, единицами которого выступают сами сервисы и объекты инфраструктуры, критичные для сервисов. Если какой-либо сервер не столь важен для бизнеса, то, с точки зрения ITSM, его можно и не учитывать.

Учет ИТ-активов (IT Asset Management, ITAM) направлен в свою очередь на измерение стоимости ИТ-ресурсов и предоставляемых услуг. В данном случае выделяются объекты внутри ИТ-ландшафта, которые стоят денег и существенно влияют на себестоимость инфраструктуры и услуг. И если патч-корд практически ничего не стоит, то его предлагается отдельно не учитывать. Кроме того, некоторые виды оборудования могут быть слишком сложны для учета (например, из-за их большого количества или частого перемещения) — их тоже учитывают упрощенно.

Однако специалисты, обслуживающие ЦОД, работают с ИТ-оборудованием, кабельными системами, инфраструктурами электропитания, охлаждения и поэтому нуждаются в детальной информации для организации ежедневной работы. Им важнее знать не то, сколько стоит конкретный ИТ-компонент, а как он устроен, где стоит и как подключен к другим компонентам. Эти технологические подробности если не целиком выпадают из систем учета, то почти всегда не полностью фиксируются в CMDB или ITAM. Характерный пример — патч-панели: обычно в CMDB их не вносят. Но при оказании услуг нужно понимать, как организована сетевая связанность.

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

Почему наличия CMDB и ITAM недостаточно

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

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

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

Таким образом, существующие централизованные системы (CMDB, ITAM) не обеспечивают необходимую для производственных задач детализацию. И это негативно влияет на совместную работу специалистов, оптимизацию и автоматизацию рутинных задач, планирование инфраструктуры. У людей, занимающихся поддержкой и развитием инфраструктуры, нет информации, достаточной для принятия решений.

Данная проблема не является специфичной именно для российских компаний. Но, например, в немецких компаниях она стоит не так остро благодаря известной педантичности и внутренней дисциплине. Когда несколько лет назад мы беседовали с ИТ-директором Volkswagen, он признался, что его единственный KPI — снижение операционных затрат на 5% в год в условиях роста компании. Число объектов в компании увеличивалось, но требование по сокращению затрат оставалось. Лишь полная автоматизация всех типовых ИТ-операций позволила справиться с такой задачей. А фундаментом для этого является полная информация обо всех ресурсах.

Коронавирус и человеческий фактор

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

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

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

С чего начать

Для начала надо признать наличие пробелов в знаниях об инфраструктуре, которые следует устранить. На рынке существуют специализированные системы, позволяющие справиться с этими задачами. Такие продукты бывают как узконаправленными (например, системы кабельного учета или системы управления сетями SDH/WDM/MPLS…), так и универсальными, способными охватить и ИТ-, и телеком- и инженерную инфраструктуру. Разумеется, комплексный вариант является хорошим решением для крупной компании, бизнес которой зависит от всех этих составляющих. В такой системе удобно вести детализированный учет всей инфраструктуры и взаимосвязей между ее элементами.

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

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

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

На что можно рассчитывать

Система технического учета не приносит прямой прибыли, и ее правильнее воспринимать как фундамент, обеспечивающий надежность. Чаще всего от заказчиков приходится слышать, что наличие детальной информации об инфраструктуре помогает на 20-30% сократить время устранения проблем. Зная, как устроена инфраструктура, удается быстрее решать типовые задачи. В этом случае эффект еще более выражен, чем при внедрении CMDB, — из-за детальности информации.

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

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

Движение в сторону интеллектуальности

Говоря о перспективах развития систем технического учета, нельзя обойти стороной современные веяния. Например, на производствах начинают реально применять средства дополненной реальности. Подобные технологии способны выполнять не только обучающую функцию. Их можно использовать и в «боевых» условиях: они могут диктовать последовательность операций, советовать, куда установить деталь, рекомендовать, на что обратить особое внимание. Ряд компаний предполагают задействовать возможности таких систем и в ИТ— скажем, реализовать сценарий, при котором оператор подходит к стойке, чтобы установить оборудование, а система уже подсвечивает место установки и порты для подключения оборудования на основании выданных нарядов. Мы участвовали пока только в пилотных внедрениях подобных систем.

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

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

Исходить из потребностей

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

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


Теги: Партнерский материал СДИ Софт