Когда железки знобит: мониторинг NFC-модулей банкоматов
Привет, Хабр! Меня зовут Павел Слюсарь, и я занимаюсь в компании Т1 Сервионика развитием технологий для автоматизации сервисного обслуживания различных железок, в том числе банкоматов.
Во многих инженерно-технических сферах существует понятие «мониторинга». В ИТ же есть «просто мониторинг», обычно подразумевающий отслеживание поведения ПО и его влияние на пользовательский опыт, и «технический мониторинг» — наблюдение за работой оборудования. Мы уже вкратце рассказывали, как следим за самочувствием банкоматов (см. список статей чуть ниже). А теперь поделимся своим опытом отслеживания состояния конкретных компонентов «денежных роботов» — NFC-ридеров.
Наши предыдущие статьи про банкоматы и железки:
Как устроен наш технический мониторинг
Как написано в нашей документации:
Технический мониторинг — это комплекс работ по отслеживанию состояния УС, обнаружению сбоев, удалённому управлению и формированию заявок на восстановление работоспособности, направленный на повышение функциональной и КТО-доступности.
Тут нужны пояснения на человеческом языке.
УС — это «устройство самообслуживания», в народе называемое банкоматом. Оно представляет собой сложный программно-аппаратный комплекс, обеспечивающий безопасный, непрерывный и удобный набор онлайн-сервисов, от приёма наличных до электронных платежей и генерирования персональных предложений клиенту.
КТО — это «комплексное техническое обслуживание». За него отвечает целая система (СКТО), разработанная нами самостоятельно. С её помощью мы:
обнаруживаем и диагностируем сбои в банкоматах;
организуем полный цикл восстановления и проводим проектные работы;
автоматизируем и оптимизируем процессы разрешения инцидентов;
обмениваемся информацией со всеми участниками процесса и координируем их работу.
То есть СКТО — наша центральная система мониторинга жизненного цикла банкоматов. Она собирает и обрабатывает информацию из всех источников и обеспечивает полный цикл работ по устранению сбоев. Вот верхнеуровневая схема работы СКТО:
В нашей системе технического мониторинга используется несколько важных понятий:
Инцидент — сущность, возникающая в процессе работы банкомата или проектирования, требующая разрешения или полного завершения плановых работ. Инцидент можно обнаружить датчиками или средствами событийного мониторинга, он может быть назначен с помощью обращения или запланирован.
Событие — сущность, возникающая при любых изменениях внутри инцидента: создание, инициирование или закрытие заявки, изменение статуса внутри заявки, готовность инцидента к закрытию и т. д. Событие не имеет длительного жизненного цикла, оно возникает, регистрируется и обрабатывается.
Заявка на проведение выездных или удалённых работ — сущность внутри инцидента, присвоенная конкретному исполнителю. У неё есть набор атрибутов: тип, регламентное время, статус просрочки, текущее время выполнения и многое другое.
УС (банкомат) — конфигурационная единица. У неё есть набор атрибутов: технические параметры устройства, место его установки и условия обслуживания.
Робот — модуль внутри системы, автоматизирующий конкретную операционную функцию и облегчающий работу операционных специалистов. Роботов у нас много, и мы даём им индивидуальные имена: Инна, Илана, Катюша, или, например, Маруся, которая контролирует софт. Так повелось, потому что было неудобно произносить и писать: «Что за изменение было в роботе принятия первого решения в части автоматической обработки модуля классической обработки инцидентов?». Гораздо проще сказать: «Как изменился Валл-И?». Поэтому у каждого робота есть имя со своей историей. Валл-И был первым, его запуском со стороны бизнес-аналитики занимался сотрудник по имени Валентин, которому также вспомнился милый персонаж из мультфильма.
Этапы разрешения инцидента
Жизненный цикл любого инцидента с точки зрения его обработки состоит из четырёх этапов:
Создание — момент, когда какая-нибудь система или человек определяет, что возникла проблема с банкоматом, и необходимо зарегистрировать инцидент. Основные источники информации — обработка изменений датчиков УС на хосте, события по проблемам основного и резервного канала связи, транзакционный мониторинг, событийный мониторинг, обращения и проекты.
Принятие первого решения (ППР) — период, когда диагностируют инцидент (что за сбой, в каком банкомате, какие события в журналах, какие инциденты параллельно открыты и т. д.), пытаются восстановить удалённо и инициируют первую заявку на восстановление. В нашей системе есть много роботов класса ППР.
Инфообмен — период с открытия первой заявки и до закрытия последней. В основном участники обмениваются статусами и дают комментарии. В нашей системе есть только один робот класса инфообмена.
Закрытие — момент, когда оцениваются итоги выполненных работ, проверяется закрытие заявок, состояние узлов банкомата, наличие ведомых инцидентов и их статус, прохождение транзакций. В нашей системе есть только один робот класса закрытия.
Автоматическая обработка инцидентов
Мы внедрили автоматический механизм обработки претензий на основе СКТО, событийного мониторинга и поставщика событий. Этот механизм работает в онлайн-режиме 24×7. За событийный мониторинг отвечает Джарвис — это модуль в СКТО для принятия первого решения. На вход он принимает поток событий разных типов. Под каждый тип создаётся профиль, определяющий необходимую повторяемость события, инцидента над событием, и последующую обработку. При срабатывании профиля Джарвис создаёт инцидент, проводит удалённый сброс ошибки на банкомате, и при необходимости создаёт заявку на выезд инженера. Далее подключается Инна — модуль инфообмена.
Примеры профилей:
»3 претензии за два дня». Если к работе какого-либо банкомата за 48 часов накапливается три претензии, система останавливает его и создаёт срочный инцидент. Затем инициирует заявку на разбор логов и SLM-заявку. После выполнения работ запускает банкомат и закрывает инцидент.
»2 претензии за 14 дней». После проведения работ на каком-либо банкомате система ещё две недели отслеживает претензии к его работе. При достижении двух штук система создаёт обычный инцидент, инициирует заявку на разбор логов, эскалацию и SLM-заявку. После выполнения работ запускает банкомат и закрывает инцидент.
»4 претензии за месяц». При достижении четырёх претензий к работе банкомата система создаёт обычный инцидент, инициирует заявку на разбор логов и SLM-заявку. После выполнения работ запускает банкомат и закрывает инцидент.
NFC-технология в банкоматах
Банкоматы становятся всё «умнее» и удобнее благодаря внедрению новых технологий. Одна из них — NFC (Near Field Communication), или ближняя бесконтактная связь. NFC позволяет выполнять различные операции без физического контакта с устройством. Для этого в банкоматах используют NFC-ридеры.
NFC-ридеры — это устройства для чтения информации с мобильных устройств или банковских карт, оснащённых NFC-чипом. Ридеры способны обмениваться данными на расстоянии до нескольких сантиметров. То есть вы можете снимать и переводить деньги, оплачивать услуги — и всё это без вставки карты. Достаточно поднести мобильное устройство или карту к соответствующей панели банкомата. Так быстрее и проще.
Вид изнутри
В темноте этот модуль может подсвечиваться, чтобы не промахнуться
Конечно, у NFC-модулей тоже бывают сбои. Причём особенность в том, что модули передают достаточно мало диагностической информации и их не отследить по «плохому статусу». Поэтому мы сделали сервис для выявления выявить недиагностируемых сбоев в технически исправных банкоматах. Он отслеживает аномалии транзакционной нагрузки по NFC-операциям в конкретном банкомате. В основе сервиса лежит машинное обучение. Он раз в час анализирует устройства с аномальным транзакционным поведением, а потом отправляет события Джарвису. Тот создаёт инциденты, и далее робот АО ППР Валл-И подключается для разрешения инцидента. Одним из интересных вызовов стал мониторинг банкоматов, в которых совершается мало NFC-операций и их прогнозирование было затруднено.
Результатом работы сервиса стало отслеживание в круглосуточном режиме отклонений в работе модулей. С самого начала мы добились автоматизации на уровне более 70%, а количество удалённо устранённых сбоев превысило 80%.
А вообще, связанные с NFC инциденты — это малая часть нашего технического мониторинга. Так, раз в 3–5 минут (в зависимости от источника) мы проверяем состояние датчиков узлов оборудования на хосте, ключевых инвентаризационных параметров устройства, состояний от агентов различных клиент-серверных систем. В сумме это около 200 состояний в сети размером около 20 000 устройств. Или до 55 миллиардов проверок в месяц. По итогам проверок создаётся около 300 000 инцидентов ежемесячно, которые, в свою очередь, создают около 430 000 сигналов по изменениям состояний УС, заявок, инцидентов и обрабатываются с 80-процентным уровнем автоматизации. Но об этом мы расскажем вам в другой раз.
