Ошибки, как ни старайся их избежать — спутник любого инфообмена. Человек может опечататься, канал — разорваться, сервис — зависнуть. А значит, очень важно узнавать об ошибках первым и вовремя их устранять. Всем привет, меня зовут Антон Баташов, я руководитель отдела интеграции и технической поддержки в компании XWAY, и в этой статье мы поговорим об алертах: зачем они нужны, какие бывают и как с их помощью настроить полноценный мониторинг инфообмена с маркетплейсом.
В то время как корабли бороздят просторы Вселенной…
В свое время я учился в военной инженерно-космической академии, факультет радиоэлектроники, кафедра бортовых информационных телеметрических систем. Для непосвященного звучит круто и совсем непонятно, поэтому приходилось все это объяснять с помощью одной ассоциации.
Представим руку, внутри которой есть набор нервных окончаний, передающих в мозг обратную связь о состоянии каждого пальца, каждого сустава. Порезали палец — чувствуем боль. Берем что-то в ладонь — ощущаем тяжесть. С космическим аппаратом все очень похоже, только роль нервных окончаний выполняют датчики, которые сигнализируют о том, открылись ли солнечные панели, заработал ли прибор, какие у него сейчас параметры. Так, например, с Земли отправили команду, космический корабль ее получил и обработал, и обратно направил телеметрию — информацию о своем состоянии.
К чему эти воспоминания? Любая современная информационная система, особенно высоконагруженная — сложный набор серверов, кластеров, большого количества воркеров, сервисов и параллельно решаемых задач. Как и космический корабль, все это нуждается в постоянном контроле — мониторинге состояния.
В нашем случае мы говорим об инфообмене с маркетплейсами, в котором, помимо данных о товарах, ценах, скидках, заказах и прочем, присутствует и «телеметрия» — любое IT-решение обкладывается большим количеством алертов и логов. Первые — оповещают о неприятных событиях и ошибках (упал сервер, не выполнилась команда). Вторые — позволяют выяснить, что и где пошло не по плану, чтобы в дальнейшем исправить ситуацию.
Простите, а почему так мало?
Бывает так, что ошибок вроде бы нет, но обмена информацией не происходит. Такие ситуации надо отслеживать, потому что они могут привести к большим проблемам. Представим, что у интернет-магазина на маркетплейсе за определенный промежуток времени есть среднее число заказов. Если в какой-то момент их количество резко уменьшается, то, даже если нет никаких сообщений об ошибках, — это серьезный повод проверить, все ли в порядке.
Автоматизировать отслеживание помогут алерты пороговых значений: мы запускаем таймер и начинаем считать события, например, заказы. Если достигли порога, сбрасываем счётчик и начинаем новый отсчет времени. Если таймер отработал, а порога не достигли — срабатывает алерт.
То, что не случилось — тоже важно
В нашей системе алерты настроены на все события, которые происходят в процессе инфообмена с маркетплейсом. Если клиент попытается обновить цены, но ошибется и некорректно составит запрос, ему вернется сигнал об ошибке, которую можно исправить, отредактировав и повторно запустив обновление.
Но что, если на стороне клиента оказались неправильно настроены ключи доступа? Скажем, они поменялись в системе — ведь в целях безопасности их необходимо регулярно менять. Кто-то из клиентов свой ключ обновил, а кто-то забыл. Тогда запрос к методу обновления цен будет остановлен на уровне сервера авторизации и не попадет внутрь системы! Механика логирования и алертов просто не запустится: раз нет события, нет обращения к соответствующему обработчику, некому увидеть ошибку и сообщить об этом. А значит, клиент остается в неведении и думает, что все идет хорошо, хотя на самом деле торгует по неактуальным ценам.
Как это выглядит изнутри: магазин работает, инфообмен происходит — заказы оформляются. Но при этом в течении заданного промежутка времени, например, часа — не происходит обмена по стокам.
На помощь приходят алерты. Они отслеживают события, которые не случились: в нашем примере мы запускаем таймер, обнуляющийся при обновлении цен. Если таймер отработал до конца, а обновления не произошло — отправляется сообщение об ошибке.
Проверяй за проверяющим
Любая IT-структура огромна и состоит из множества связанных компонентов. Продукт развивается, растет, в него добавляются новые возможности. Разумеется, существуют тесты и испытательные стенды, которые позволяют отловить большинство ошибок. Но всегда существует вероятность что-то недосмотреть. Кроме того, в процессе работы система тоже изменяется — как минимум, обновляются базы данных, и добавляются новые клиенты.
Для того чтобы убедиться, что все компоненты и сервисы работают именно так, как задумано — одних алертов внутри системы недостаточно. Внутреннее ядро, основной сервер, следит за корректной работой всех процессов. Кроме того, мы ставим микросервис на отдельном сервере, который проверяет, что заказы с маркетплейса: а) попали в коннектор, б) улетели в учетную систему.
Таким образом, удается избежать ситуации, когда мы не забрали заказ в коннектор или забрали, но он не дошел до 1C. Мы видим, во сколько он попал в систему и во сколько попал в 1С. Если на маркетплейс заказ попал давно, а в коннектор только что — время увеличивается, а значит, в инфообмене что-то идет не так.
Резюме
Организация инфообмена с маркетплейсом помогает отслеживать то, что происходит, и что должно было произойти, но не случилось. Кроме того, важно постоянно мониторить пороговые значения основных параметров, а также проверять работоспособность всей системы с помощью отдельных микросервисов. С вами был Антон Баташов, жду ваших вопросов в комментариях, либо в Telegram @anton_batashov.
