Как мы сделали собственную DCIM-платформу удобной и ускорили обслуживание клиентов

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

Существуют готовые решения таких систем, но нам они не подошли, поэтому несколько лет назад мы разработали свою DCIM-систему и назвали ее Racks (Рэкс). Три года назад мы уже рассказывали, как создавали ее и почему решили писать сами, а не оплачивать готовое решение. Но время идет, требования меняются, и нашему Рэксу тоже пришла пора вырасти. 

Меня зовут Вячеслав Литвинов, я руковожу направлением DCIM в отделе систем управления инфраструктурой Selectel. В этой статье поделюсь, как мы разработали новую систему учета оборудования и как работаем с ней сейчас.

Немного о нашей DCIM-платформе

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

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

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

Из монолитного Racks поначалу в отдельное приложение отпочковался фронтенд.  Затем и бэкенд был распилен на популярные нынче микросервисы. Этот процесс продолжается до сих пор: старый «бэк» потихоньку худеет и передает свои функции в отдельные микросервисы. Предполагается, что в итоге он сохранит за собой название  Racks и будет отвечать только за формирование интерактивных схем комнат. А сама DCIM-платформа обретет и новое имя, и новые возможности.

Новый концепт

Мы пересмотрели интерфейс и поняли, что необходимо улучшить взаимодействие пользователя с системой. Для этого на протяжении примерно трех месяцев разрабатывали прототип будущего приложения, опираясь на опыт оперативного персонала компании — главных пользователей приложения. Каждую неделю мы встречались со специалистами по проектированию интерфейсов, обсуждали макеты и прорабатывали разные сценарии для удобной работы в приложении. В качестве UI-системы использовали корпоративный UI-kit на базе Ant Design, который также используется в панели управления Selectel. 

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

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

Новая архитектура

Фронтенд

Когда макеты были готовы, мы приступили к разработке. Изначально фронтенд Racks был написан на JavaScript и HTML с использованием Bootstrap и jQuery, а также рендеринга на стороне сервера (SSR). 

Для реализации более устойчивого к ошибкам приложения мы стали использовать TypeScript. В качестве фреймворка был выбран Vue 3 в связке с Vite и Pinia. Для обеспечения более быстрого времени загрузки страницы было принято решение перевести рендеринг на клиент. А для верстки стоек мы использовали HTML, чтобы была возможность реализовать интерактивное взаимодействие с каждым элементом схемы.

Первая проблема, с которой пришлось столкнуться при переходе с SSR на SPA, — это зависание интерфейса при рендеринге более четырехсот стоек в комнате. Чтобы ее решить, мы реализовали рендеринг только видимой части схемы.
Большинство элементов сделали отдельными компонентами, чтобы их можно было переиспользовать и не плодить лишний код. Для большей оптимизации решили использовать defineAsyncComponent, чтобы в отдельных случаях компоненты подгружались асинхронно, только при необходимости их использования.

В планах по фронтенду — внедрить технологию PWA, чтобы пользователи могли использовать DCIM как мобильное приложение. 

Бэкенд

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

В коде проекта скопилось множество проблем.

• Из-за неудачной архитектуры нельзя было вызвать код, не подтянув в зависимости все приложение целиком. Складывалось ощущение, что все зависит от всего, и это затрудняло тестирование.
• В коде стали появляться модули и классы, которые отчасти дублировали старую функциональность и делали его более гибким, но удалить старый код мы не могли из-за очень больших затрат на рефакторинг.
• JSON-RPC вызывал много негатива у фронтенд-команды кастомными статус-кодами и дополнительной работой для тестирования и отладки в DevTools в браузере. Вследствие этого в Racks, помимо JSON-RPC, стали появляться эндпоинты, написанные в более удобном для фронтенда стиле REST.
• Получение обновлений на фронтенде было сделано через HTTP pooling, что излишне нагружало backend. 
• Для доступа к данным подсистемы учета мы ходили напрямую в базу данных. При обновлении версии подсистемы учета менялась и структура в базе данных и в Racks, приходилось подстраивать SQL под эти обновленные структуры (иногда это бывало очень болезненно).
• В процессе развития Racks некоторые JSON-RPC методы обрастали новой функциональностью и превратились в огромные супер-методы, которые делали очень много за один запрос. Поддержка таких методов и проблема с производительностью при запросе множества данных с разных источников, часть которых не была нужна для UI, также стали проблемой.
• Использование сомнительных и устаревших библиотек, например SQLAlchemy, сделали процесс обновления очень затратным. Также привязка к Flask-SQLAlchemy затруднила работу с базой данных Racks вне контекста Flask.

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

Для упрощения развития и поддержки проекта было принято решение распилить бэкенд Racks на микросервисы, каждый из которых будет ответственен за свою область и по возможности не связан с остальными микросервисами. А для того, чтобы проблемы с кодом в Racks не повторились, мы посчитали разумными доводы Роберта Мартина и стали пробовать писать новые микросервисы на «чистой архитектуре».
При переходе на новые микросервисы договорились использовать следующую стратегию: быстро писать веб-сервисы с четкими REST-эндпоинтами, которые будут проксировать запросы в Racks. Так команда фронтенда могла начать перенос нового клиентского интерфейса на более удобные эндпоинты. Далее планировали полностью вынести оставшуюся функциональную часть из Racks независимо от фронтенд-команды. Таким образом, мы вынесли модуль генерации отчетов из Racks в микросервис Reports, а учет и сдачу клиентам KVM-девайсов — в сервис IP-KVM. Также мы вынесли в микросервис Tools набор простых разнородных функций, которые логически нельзя было отнести к какому-либо определенному микросервису.

Проблему с http-pooling и доставку real-time обновлений данных до фронтенда мы решили с помощью добавления в кластер опенсорсного сервиса Centrifugo, который очень хорошо справляется с множеством WebSocket-соединений.

Чуть позже были уже с нуля написаны микросервисы MMS (для учета технического обслуживания оборудования в дата-центрах) и Cables (для учета кроссировок), а также служебные сервисы Versions (для публикации информации о релизах) и Profile (для просмотра посетителей и отправки им уведомлений).

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

Инфраструктура

Здесь тоже произошли большие изменения. Мы подняли новый отдельный кластер Kubernetes и спрятали микросервисы за Istio, настроили мониторинг и логирование каждого микросервиса, добавили кэширование некоторых данных в Redis и стали использовать Kafka в качестве брокера.

Новый интерфейс и новое название

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

Чтобы облегчить сбор обратной связи, мы добавили возможность оставить для нас комментарий, пожелание или предложение прямо из интерфейса. Далее каждое сообщение фиксировалось в Jira, затем прорабатывалось на уровне бизнеса и разработки, а после — перерастало в пользовательские истории.

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

В течение года у пользователей была возможность работать одновременно в двух сервисах. Мы добавили кнопки для быстрого перехода между Racks и Axion, так как первый работал стабильно, а второй — в режиме тестирования. Однако в основном полезный функционал разрабатывался только в новой системе, для Racks мы больше не выкатывали ничего нового. 
В мае 2024 года настало время полностью отказаться от фронта Racks (Goodnight, sweet prince), выпустить первую полную версию Axion и перевести пользователей на новое приложение.

Как выглядит Axion сейчас

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

Для сравнения. Вот как выглядела схема комнат в старом интерфейсе:

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

В новой версии приложения также появилась возможность гибкой фильтрации стоек по услугам, клиентам, статусам, тегам и особенностям.

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

В Racks можно было проверить электропитание только в разрезе стоек. Но что, если необходимо посмотреть распределение электроэнергии по силовым шкафам? 

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

Если выбрать определенную силовую панель, на схеме вы увидите подключенные к ней стойки, а также сможете получить подробную информацию по потребителям в табличном виде.

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

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

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

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

Когда отчет сформирован и готов для скачивания, пользователю приходит уведомление. 

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

MMS

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

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

В связи с этим в октябре прошлого года в Axion появился новый сервис — MMS.  

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

Также можно посмотреть календарь работ — в таком формате сотрудникам оказалось проще всего их воспринимать.

Учет кроссировок

Еще один важный сервис, который совсем недавно стал частью Axion, называется Cables, или сервис учета кроссировок. Как и MMS, учет кабельных соединений годами велся в Google-документах, отчего сами электронные таблицы превратились в бесконечную портянку сырых данных по кабелям, точкам терминации кабелей, лейблам, датам и исполнителям. Само собой, здесь пользователи сталкивались с такими же проблемами, что и в разделе MMS. 

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

После создания мы видим в списке кроссировку в статусе «Планируется».

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

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

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

Какой результат мы получили

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

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

Что планируем сделать еще 

Идей у нас очень много: только для MMS планируем реализовать журнал работ, работа с ЗИП, подрядчики, чеклисты обходов, инциденты, окна для обслуживания и многое другое. Кроме того, в Axion со временем появятся: 

• дашборд — персонализированная страница пользователя с возможностью добавлять различные виджеты;
• помощник установки оборудования — инструмент, с помощью которого инженер может определять наиболее удачные места для установки оборудования, опираясь на заполненность стойки, остаток мощности и наличие свободных сетевых/силовых портов;
• управление сотрудниками, благодаря которому можно будет назначать определенные роли, видеть статистику по обработке тикетов/звонков/писем, а также успехи и KPI для каждого сотрудника;
• режим обучения и интерактивный режим для создания объектов на схеме из интерфейса Axion;
• таймтрекер для утилизации рабочего времени, проведенного за работой. 🙂

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

Мы видим, как улучшаются процессы: там, где вчера еще что-то делалось руками, теперь работает автоматизация и экономит время сотрудникам. А самое прекрасное в этой истории, что на ней развитие системы не заканчивается. Увидимся в следующей части!