Привет, Хабр! Меня зовут Дмитрий, я старший системный инженер в дата-центре Selectel, работаю с серверами и клиентским оборудованием.

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

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

Проблемы инженера при замене дисков

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

Ручная сверка атрибутов

У каждого вида накопителя, будь то HDD, SSD или NVME, есть атрибуты S.M.A.R.T., по которым мы анализируем их состояние. Есть базовые параметры дисков от разных вендоров и параметры конкретных моделей.

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

Приведу пример атрибутов:

Атрибут Media Wearout Indicator (233) содержит процент износа SSD-диска. При значении VALUE больше 10 диск модели Intel является исправным.

На моделях Micron данный атрибут отсутствует. Здесь будет проверяться атрибут Percent_Lifetime_Remain (202) также по значению VALUE.

На моделях Kingston выполняется проверка по атрибуту Life Left (SSDs) or Temperature (231).

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

Неактуальный источник информации

Аренда выделенных серверов в Selectel и отказ от них — автоматизированные процессы. Когда клиент сдает ресурсы, платформа переходит в процесс очистки, тестирования и предоставления машины другому клиенту. На этапе очистки выполняются скрипты затирки накопителей с обращением в базу для проверки по показателям S.M.A.R.T.

Сотрудник клиентского сервиса, который проверяет показатели S.M.A.R.T., сверяет их с информацией в базе знаний в Confluence компании. Она дублирует данные, которые заносятся в GitLab сотрудниками из отдела выделенных серверов. Внутренняя база знаний обновляется не всегда синхронно, после того как вносятся изменения в GitLab. Это приводит к дополнительным затратам времени на диагностику диска.

Необходимость своевременного выявления гарантийных случаев замены

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

Идея создания бота в Telegram

Все описанные проблема хотелось решить — так появилась идея создать бота на базе API Telegram. Я захотел написать бота, который будет выдавать вердикт по накопителю на основе показателей S.M.A.R.T. и ссылаться на то же место, что и скрипты затирки при автоматизированном процессе.

Ранее мы уже писали на Хабре, как работаем с дисками в дата-центрах →

Как работает бот

Итак, сотрудник клиентского сервиса получает обращение от клиента. Например, о падении производительности, ошибках или выходе из строя накопителя. При первичной диагностике специалист запрашивает показатели S.M.A.R.T., копирует полный вывод или модель накопителя (если клиент прислал не текст, а скриншот) и отправляет в Telegram-бот.

Далее реализуется один из трех сценариев:

• Если загружен полный вывод S.M.A.R.T., бот выдает отчет в виде параметров, по которым произведена проверка, и вердикт: «Диск исправен!» либо «Неисправен!».
• Если отправлена только модель, бот сообщает параметры, по которым необходимо проверить диск.
• Если диска нет в базе, выводится сообщение о том, что запрашиваемая модель не найдена. В таком случае проверка проводится по базовым параметрам накопителей. Так сотрудник может понять, требуется ли замена накопителя в рамках пороговых значений.

Как пользоваться ботом

Запускаем бота.


Приветствие пользователя

Вот пример вывода S.M.A.R.T. SSD-диска, по которому бот сканирует модель и значения атрибутов.

=== START OF INFORMATION SECTION ===
Model Family:     Intel S4510/S4610/S4500/S4600 Series SSDs
Device Model:     INTEL SSDSC2KB960G7
Serial Number:    PHYXXXXXXXXX960CGN
LU WWN Device Id: 5 5cd2e4 14f05fa72
Firmware Version: SCV10150
User Capacity:    960,197,124,096 bytes [960 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
TRIM Command:     Available, deterministic, zeroed
Device is:        In smartctl database 7.3/5319
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat Jan 28 11:01:34 2023 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   099   099   000    Old_age   Always       -       4
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       38712
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       26
170 Available_Reservd_Space 0x0033   099   099   010    Pre-fail  Always       -       0
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       1
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
174 Unsafe_Shutdown_Count   0x0032   100   100   000    Old_age   Always       -       19
175 Power_Loss_Cap_Test     0x0033   100   100   010    Pre-fail  Always       -       2790 (253 3591)
183 SATA_Downshift_Count    0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error_Count  0x0033   100   100   090    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Drive_Temperature       0x0022   080   080   000    Old_age   Always       -       20 (Min/Max 14/20)
192 Unsafe_Shutdown_Count   0x0032   100   100   000    Old_age   Always       -       19
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       20
197 Pending_Sector_Count    0x0012   100   100   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       6455641
226 Workld_Media_Wear_Indic 0x0032   100   100   000    Old_age   Always       -       6675
227 Workld_Host_Reads_Perc  0x0032   100   100   000    Old_age   Always       -       44
228 Workload_Minutes        0x0032   100   100   000    Old_age   Always       -       2322510
232 Available_Reservd_Space 0x0033   099   099   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   094   094   000    Old_age   Always       -       0
234 Thermal_Throttle_Status 0x0032   100   100   000    Old_age   Always       -       0/0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       6455641
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   Always       -       5091949
243 NAND_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       12194491

В ответном сообщении бот отправляет вердикт в виде отчета:


Слева — отчет с выводом параметров для неисправного SSD-диска. Справа — для исправного накопителя.

Техническая реализация бота

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

Для внутренних проектов мы, как и наши клиенты, используем облачную платформу. Для маленького проекта с ботом я выбрал облачный сервер с 2 ядрами vCPU, 4 ГБ ОЗУ и 10 ГБ сетевого диска SSD. Этого вполне достаточно для развертывания мини-приложения.


Выбранная конфигурация сервера.

Также я подготовил проброс VLAN для внутренней инфраструктуры. Выделять публичный IP-адрес не потребовалось.

Серверная часть приложения

Для развертывания приложения с окружением использовал docker-контейнер. Приложение написал на node.js, а для взаимодействия с Telegram API взял node-telegram-bot-api.

Логика обработки сообщений

На основании данных S.M.A.R.T. бот выделяет модель накопителя, id атрибута и значения VALUE, RAW_VALUE. По модели накопителя бот находит в базе и сравнивает пороговые значения атрибутов, а после выносит вердикт диску.

Результаты внедрение бота

Главное в создании бота — не процесс, а то, к каким результатам приводит его реализация. В нашем случае это рост эффективности работы инженера. Telegram-бот – не панацея от всех проблем с обработкой данных S.M.A.R.T., но он позволяет быстро выявлять основные дефекты накопителей.

Изменилось ли время обработки обращений?

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

Как работа с ботом повлияла на выявление неисправных комплектующих в рамках гарантийного обслуживания?

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

На что еще повлиял бот?

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

Возможно, эти тексты тоже вас заинтересуют:

→ Первая «зеркалка» от Polaroid, робот-пылесос iRobot, гомеопатия начала XX века и кое-что еще: новые находки на барахолке
→ 6 книг по MySQL для старта работы и погружения в технологию
→ Как работают объектные хранилища: OpenStack Swift

Что нужно доделать в боте

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

Сбор фидбэка через бот

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

Расшифровка информации со скриншотов

Иногда клиенты отправляют параметры S.M.A.R.T. скриншотом, или же они представлены в KVM-консоли без доступа по SSH. В таком случае приходится обрабатывать информацию в ручном режиме. Для скриншотов хочу добавить автоматическое считывание текста и расшифровку сообщений.

Автоматизированная диагностика как сервис

Также такое решение по обработке вывода S.M.A.R.T. кажется полезным и для клиентов компании. Рассмотрим возможность его интеграции в виде сервиса в панели управления.

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