Когда железки знобит: мониторинг NFC-модулей банкоматов

Привет, Хабр! Меня зовут Павел Слюсарь, и я занимаюсь в компании Т1 Сервионика развитием технологий для автоматизации сервисного обслуживания различных железок, в том числе банкоматов.

Во многих инженерно-технических сферах существует понятие «мониторинга». В ИТ же есть «просто мониторинг», обычно подразумевающий отслеживание поведения ПО и его влияние на пользовательский опыт, и «технический мониторинг» — наблюдение за работой оборудования. Мы уже вкратце рассказывали, как следим за самочувствием банкоматов (см. список статей чуть ниже). А теперь поделимся своим опытом отслеживания состояния конкретных компонентов «денежных роботов» — NFC-ридеров.

Наши предыдущие статьи про банкоматы и железки:

• Ставим банкоматы в лютый мороз, жару, метро и на вездеходы (о неожиданных технических трудностях, возникающих при установке банкоматов в самых разных, подчас очень необычных местах)

• Починяем банкоматы: чиним железо и софт (о буднях инженеров, обслуживающих банкоматы. Поверхностно затронули тему мониторинга)

• Опять починяем банкоматы (продолжение интересной темы, в том числе и про мониторинг)

• Звоните Кузе: как мы написали FAQ для инженеров (про голосовую автоматизацию)

Как устроен наш технический мониторинг

Как написано в нашей документации:

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

Тут нужны пояснения на человеческом языке.

УС — это «устройство самообслуживания», в народе называемое банкоматом. Оно представляет собой сложный программно-аппаратный комплекс, обеспечивающий безопасный, непрерывный и удобный набор онлайн-сервисов, от приёма наличных до электронных платежей и генерирования персональных предложений клиенту.

КТО — это «комплексное техническое обслуживание». За него отвечает целая система (СКТО), разработанная нами самостоятельно. С её помощью мы:

• обнаруживаем и диагностируем сбои в банкоматах;

• организуем полный цикл восстановления и проводим проектные работы;

• автоматизируем и оптимизируем процессы разрешения инцидентов;

• обмениваемся информацией со всеми участниками процесса и координируем их работу.

То есть СКТО — наша центральная система мониторинга жизненного цикла банкоматов. Она собирает и обрабатывает информацию из всех источников и обеспечивает полный цикл работ по устранению сбоев. Вот верхнеуровневая схема работы СКТО:

В нашей системе технического мониторинга используется несколько важных понятий:

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

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

• Заявка на проведение выездных или удалённых работ — сущность внутри инцидента, присвоенная конкретному исполнителю. У неё есть набор атрибутов: тип, регламентное время, статус просрочки, текущее время выполнения и многое другое.

• УС (банкомат) — конфигурационная единица. У неё есть набор атрибутов: технические параметры устройства, место его установки и условия обслуживания.

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

Этапы разрешения инцидента

Жизненный цикл любого инцидента с точки зрения его обработки состоит из четырёх этапов:

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

2. Принятие первого решения (ППР) — период, когда диагностируют инцидент (что за сбой, в каком банкомате, какие события в журналах, какие инциденты параллельно открыты и т. д.), пытаются восстановить удалённо и инициируют первую заявку на восстановление. В нашей системе есть много роботов класса ППР.

3. Инфообмен — период с открытия первой заявки и до закрытия последней. В основном участники обмениваются статусами и дают комментарии. В нашей системе есть только один робот класса инфообмена.

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

Автоматическая обработка инцидентов

Мы внедрили автоматический механизм обработки претензий на основе СКТО, событийного мониторинга и поставщика событий. Этот механизм работает в онлайн-режиме 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-процентным уровнем автоматизации. Но об этом мы расскажем вам в другой раз.