Введение

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

Введение

Бизнес-функции

Сильная зависимость от качества данных

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

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

Другим примером является диаграмма процесса ETL данных карты Hello на рисунке ниже.Из рисунка видно, что данные карты Hello необходимо собрать (покупные данные), очистить (процесс первичного скрининга и тонкого скрининга), объединение (множество данных), загрузка (хранение данных в ES) и, наконец, через сервис SOA возможность запроса картографических данных предоставляется извне. В этой серии сложных ETL-обработок проблемы с качеством данных в любой ссылке приведут к аномальным бизнес-данным в Интернете.

Сильная зависимость от внешних сервисов

Еще одной особенностью алгоритмического бизнеса является его сильная зависимость от внешних сервисов.Как видно из приведенной ниже схемы архитектуры интеллектуальной системы обслуживания клиентов, система опирается на маркетинговые платформы, торговые платформы, платежные платформы, платформы учетных записей и центры контроля рисков внутри. Внешне он опирается на услуги преобразования голоса (интеллектуальные услуги IVR), услуги горячей линии (Heli) и Alipay. Любая аномалия в любой зависимой службе повлияет на бизнес-процесс интеллектуальной системы обслуживания клиентов.

Введение проблемы

Планирование смены мощности

Сцены

Сценарий 1: обратная связь от студентов, занимающихся заменой аккумуляторов, о том, что на объекте имеется большое количество транспортных средств без электричества, но алгоритм планирования замены аккумуляторов не требует выполнения задачи по замене аккумуляторов;

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

Поток обработки данных

Прежде чем анализировать причину проблемы, давайте сначала разберемся с процессом обработки данных в хранилище данных реального времени. Как показано на рисунке ниже, различные данные, такие как скрытые точки приложения, binlog и данные IOT, отправляют сообщения kafka в службу Flink хранилища данных через систему доступа для обработки данных и, наконец, сохраняют данные в ES для различных деловые стороны, чтобы позвонить.

Анализ причин

В сочетании с блок-схемой обработки данных на рисунке выше сценарии проблем анализируются по следующим причинам:

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

Причина 2: поскольку Flink может обрабатывать данные о мощности в соответствии с различными типами аккумуляторов, такими как автомобиль 591 первого поколения, автомобиль 371 второго поколения, автомобиль 668 третьего поколения, вагон 663 и т. д., а также потому, что транспортные средства, начинающиеся с 376, не входят в список логики обработки кода, аккумулятор этого типа транспортного средства по умолчанию установлен на 0. Таким образом, алгоритм решил, что 376 транспортных средств не хватает мощности, и передал задачу по обмену энергией одноклассникам по эксплуатации и техническому обслуживанию, но 376 транспортных средств на фактической площадке не испытывали нехватки электроэнергии.

Сложности офлайн-тестирования

На мой взгляд, сложность офлайн-тестирования в этих сценариях в основном связана с дороговизной:

1. Требуются специальные тесты производительности;
2. Сценарии тестирования чрезвычайно велики.Например,данные о транспортном средстве включают 10 тем сообщения, и каждая тема имеет различные подполя и подлогики.Сценарии тестирования могут быть очень большими. При этом поля сообщений будут гибко настраиваться, а изменения нужно отслеживать для тестирования в любое время;
3. Данные тестовой среды неполные, что делает невозможным моделирование достаточного количества тестовых данных в тестовой среде для проверки различных сценариев Flink.

Обновление данных сайта

Сцены

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

Поток обработки данных

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

Анализ причин

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

Причина 1: когда сторона приложения обновляет сайт, она одновременно вызывает метку обновления и интерфейс сайта обновления.Когда сначала вызывается интерфейс метки обновления, служба не отправляет сообщение MQ, поэтому служба батареи не может получить уведомление об изменении данных Данные сайта обратной связи по эксплуатации и техническому обслуживанию не обновляются. (проблема исправлена)

Причина 2: это проблема процесса.Старый процесс: 1. Обновите mongoDB, 2. Запросите, успешно ли обновлены данные mongoDB, и 3. Отправьте уведомление MQ. Проблема с этим процессом заключается в том, что mongoDB имеет структуру master-slave: после того, как данные записываются на главный узел, синхронизация данных подчиненного узла завершается, и возникает разница во времени. Когда данные записываются на главный узел, а обновленные данные не могут быть запрошены с подчиненного узла, сообщение MQ не отправляется, что приводит к задержке данных. Поэтому поток обработки данных изменяется на: 1. Обновление mongoDB, 2. Отправка уведомлений MQ. (проблема исправлена)

Сложности офлайн-тестирования

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

согласованность данных

Сцены

Отзывы студентов по тестированию активов, как обеспечить согласованность и своевременность процесса синхронизации данных?

Процесс синхронизации данных

Процесс синхронизации данных актива показан на рисунке ниже.После того, как данные актива сохранены в базе данных (БД), обновленные данные необходимо синхронизировать с ЭС в режиме реального времени, а ЭС предоставляет сервис запросов SOA извне. В этом процессе синхронизации 1. Как мы обеспечиваем правильную синхронизацию ежедневных десятков тысяч и миллионов изменений данных из БД в ES? 2. Как контролировать надежность сервисов синхронизации в режиме реального времени? Когда возникает проблема со службой синхронизации, можете ли вы быстро предупредить и вовремя остановить потери?

Зависит от надежности службы

Сцены

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

сервисная зависимость

Из диаграммы архитектуры зависимостей службы ASR видно, что служба преобразования голоса в текст ASR для Ping An является внутренним вызовом системы службы, не полученным через доступ к интерфейсу, поэтому мы не можем отслеживать его с помощью кода состояния интерфейса и ответа интерфейса. время. В то же время в бизнес-сценарии есть обычный сценарий, в котором голос не может быть преобразован в текст, поэтому невозможно напрямую судить о том, недоступна ли услуга, исходя из того, что содержимое ответа интерфейса пусто. Поэтому необходимо ввести метод семантического анализа: «Проверить результат ответа через конкретную схему ввода», чтобы эффективно судить о доступности услуги.

в заключении

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

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

решение

Цель мониторинга

Онлайн-мониторинг обычно преследует две цели:

1. Улучшите способность воспринимать онлайн-проблемы, быстро обнаруживайте и локализуйте проблемы
2. Сведите к минимуму влияние онлайн-проблем с минимальными затратами

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

Мониторинг объектов и сценариев

Мониторинг качества данных

Объект мониторинга

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

Сцена наблюдения

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

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

Для анализа качества одного источника данных мы фокусируемся на измерении библиотечной таблицы на уровне поля (поле не пусто, поле уникально, диапазон значений поля, формат и точность поля и т. д.), уровне таблицы (объем данных колебания). Обеспечение качества осуществляется в двух аспектах.

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

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

Семантический мониторинг интерфейса

Объект мониторинга

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

Сцена наблюдения

С точки зрения мониторинга доступности услуг сценарии мониторинга в основном делятся на три типа:

1. Доступность службы, в основном отслеживание того, работает ли служба и является ли возвращаемый код состояния нормальным;
2. Время отклика, в основном для контроля полного времени отклика на сервисный вызов, если время отклика превышает пороговое значение, срабатывает сигнал тревоги;
3. Семантическая правильность в основном контролирует содержимое или поля ответа службы, такие как: а) Соблюдаются ли определенные правила, например, отслеживание возвращаемого поля цены, правильность формата (числовой формат, точность длины и т. д.). б. Контролируйте, являются ли ключевые поля действительными. Например, наш сервис сильно зависит от данных определенного поля внешних сервисов. Как только обновление внешнего сервиса вызывает изменения в ключевых полях, на которые мы полагаемся, таких как логическая корректировка, корректировка последовательности и т. д. , нужно быстро воспринимать и своевременно с ним справляться.

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

Идеи дизайна платформы мониторинга

функциональный модуль

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

1. Модуль данных и услуг: в основном отвечает за чтение различных объектов мониторинга данных и запрос различных типов услуг;
2. Модуль политики правил: требуется поддержка настраиваемых правил аномального мониторинга, настраиваемых стратегий оповещения, стратегий мониторинга для любого периода, настраиваемых уровней оповещения и правил экранирования и т. д.;
3. Модуль обратной связи по сигналам тревоги: он в основном реализует управление каналами сигналов тревоги (индивидуальные, групповые, электронная почта и т. д.), процесс управления сигналами тревоги, стыковку и улучшение системы рабочих заданий, а также реализацию замкнутого цикла мониторинга и реализации улучшения сигналов тревоги;
4. Базовый функциональный модуль: в основном включает в себя управление пользователями и полномочиями, управление конфигурацией задач, управление группой сигналов тревоги и информацией о сигналах тревоги, информационную панель данных, отображение отчетов и другие основные функции;

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

Иерархический дизайн системы

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

Практический эффект

Введение в платформу тестирования алгоритмов

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

1. Панель данных: в основном используется для отображения трех основных сведений: а) распределение рабочей группы, б) индикаторы ключевых данных о выполнении задачи (совокупные и текущий день), в) динамическое отображение основных или нештатных результатов отчета о задаче. Я надеюсь, что на диске с большими данными всю основную информацию можно будет увидеть с первого взгляда;
2. Управление задачами: в основном используется для задач, связанных с управлением задачами, таких как просмотр задач, создание, редактирование, запуск, получение журнала выполнения, отображение состояния выполнения и т. д.;
3. Отчет о мониторинге: в основном используется для отражения данных мониторинга всех задач, таких как введение информации о задаче, отображение данных мониторинга в различных формах, напоминание об аномальном значении и т. д.;
4. Управление аварийными сигналами: он в основном используется для сводки всех проблем с аварийными сигналами и реализует полный процесс обработки аварийных сигналов, таких как уведомление, подтверждение проблемы, улучшение подачи рабочих заданий и улучшение отслеживания процесса посадки. Наконец осуществите контроль с обратной связью;
5. Коррекция данных: в основном используется для обеспечения возможности исправления и исправления аномальных данных, обнаруженных при мониторинге.В то же время из-за высокого риска исправления данных требуются такие функции, как управление полномочиями и откат данных;

Тематические исследования

Мониторинг качества данных

Введение

По состоянию на конец февраля 2021 года платформа мониторинга качества данных имеет доступ к 8 задачам мониторинга данных, соответственно, от платформы алгоритмов, цепочки поставок и служб аккумуляторов. Всего мы обнаружили 18 проблем, из которых 61% были обнаружены при офлайн-тестировании, а 39% — при онлайн-мониторинге.

Тематические исследования

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

Планирование смены мощности

Метод сравнения данных

Согласно процессу обработки данных хранилища данных в реальном времени, источником данных является скрытое сообщение, о котором сообщает kafka. Метод внешней службы заключается в предоставлении запроса es. Внутри компании есть другие команды, которые используют тот же источник данных для предоставления внешних сервисов, таких как сервис OssMap команды автосервиса. Поэтому мы используем данные запроса ES хранилища данных в реальном времени и данные интерфейса SOA одежды OssMap транспортного средства (в качестве эталона) для проверки качества данных хранилища данных в реальном времени.

Здесь некоторым студентам может быть любопытно, можно ли напрямую сравнивать данные ES хранилища данных и данные OssMap?

Ответ - нет. Здесь есть два основных отличия: 1. Своевременность 2. Различия в логике обработки данных.

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

Различия в логике обработки данных: в основном это проявляется в том, что разные сервисы имеют разные методы обработки одного и того же содержимого сообщений. Например, метка транспортного средства ALERT_OVER (вне зоны обслуживания) возвращает 8 в ES хранилища данных и возвращает 101 в сервисе OssMap костюма транспортного средства.

Так как же разрешить эти два различия?

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

if (Math.abs(车辆A的数仓电量 - 车辆A的OssMap电量) > 2) {
  触发告警；
}
else {
  认为两个服务的电量匹配，不告警；
}

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

анализ проблемы

Для сценария мониторинга качества данных планирования переключения питания мы обнаружили в общей сложности 8 ошибок, из которых 4 были обнаружены при автономном тестировании и 2 — при онлайн-мониторинге.

В зависимости от типа проблемы ее можно разделить на две категории: 4 проблемы с логикой обработки данных, на которые приходится 67%, и 2 нефункциональные проблемы, на которые приходится 33%.

Нефункциональные проблемы:

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

Логические проблемы обработки данных:

1. Неверное условие фильтра, например, транспортное средство, въезжающее и выезжающее со станции, должно фильтровать транспортное средство с метрикой: "Bike.In.Site", но isinsite=0; запрос ES должен фильтровать логику транспортного средства со StationGuid, но не СитиГид;
2. Пропуск требования относится к пропуску определенных полей статистики данных, пропуску определенных статистических правил и т. д.;

Обновление данных сайта

Метод сравнения данных

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

анализ проблемы

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

В зависимости от типа проблемы ее можно разделить на две категории: 7 логических проблем обработки данных, на которые приходится 64%, и 4 нефункциональные проблемы, на которые приходится 36%.

Нефункциональные проблемы:

1. Проблемы с потреблением и отправкой сообщений, такие как сбой потребления сообщений, сбой отправки сообщений, вызванный механизмом обновления APP, упомянутым выше;
2. Проблемы параллелизма.Например, данные сайта внутри платформы алгоритма хранятся в Redis, но поскольку механизм параллельной блокировки не используется, данные при обновлении перекрывают друг друга;
3. Проблема синхронизации обновления данных.Например, когда город добавляет новый сайт, Redis хранилища данных обновляет информацию о сайте (автономное обновление каждый день), но не обновляет информацию о городе. В результате, когда интеллектуально диспетчеризованный центр обработки данных обращается к запросу (с запросом идентификатора сайта и города), данные о транспортном средстве на сайте не могут быть найдены;

Логические проблемы обработки данных:

1. Значение неверное, это довольно распространенная проблема, и данные получены не из того поля;
2. Логические ошибки обработки данных, такие как фильтрация устаревших грязных данных, но в логике есть ошибка, и другие основные данные фильтруются вместе;
3. Пропуск требования относится к пропуску определенных полей статистики данных, пропуску определенных статистических правил и т. д.;

согласованность данных

Метод сравнения данных

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

1. Как обеспечить правильную синхронизацию всех данных при ежедневных десятках тысяч, миллионах изменений данных? О: Мы регулярно запрашиваем все данные обновлений из базы данных активов, а затем сравниваем их с данными в ES, чтобы обеспечить согласованность всех синхронизированных данных;
2. Как контролировать надежность сервисов синхронизации в режиме реального времени? A: Мы сравниваем данные в БД и ES в режиме реального времени с помощью высокой частоты (минутный уровень) + легкий вес (проверка только одного последнего обновления данных), чтобы сделать вывод о надежности служб синхронизации;

Семантический мониторинг интерфейса

Введение

По состоянию на конец февраля 2021 года платформа семантического мониторинга интерфейса имеет доступ к 2 задачам мониторинга данных: одна из платформы алгоритмов, а другая из цепочки поставок. Всего мы нашли 1 онлайн-проблему.

Тематические исследования

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

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

Метод семантического мониторинга интерфейса

Для этого сценария, который требует семантического мониторинга интерфейса, мы используем активное обнаружение + семантический анализ:

Активное обнаружение относится к высокочастотным (на уровне минут) вызовам услуг преобразования голоса в текст Ping An;

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

анализ проблемы

По состоянию на март 2021 года мы обнаружили, что служба преобразования голоса в текст Ping An была недоступна 3 раза. Причина в том, что после изменения службы горячей линии (Heli), на которую полагалась система обслуживания клиентов, было отправлено слишком много недействительных записей, что сделало службу ASR недоступной.

Метод доступа к платформе

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

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

Со стороны спроса требуется всего четыре шага для реализации задачи онлайн-мониторинга:

1. Стыковка по требованию: после предварительной подготовки документов по стыковке по требованию сообщите требования стороне платформы;
2. Написание сценария правила мониторинга: в соответствии с шаблоном проекта Python сценария мониторинга напишите правила сравнения нескольких источников данных (полностью автономные, неограниченные)
3. Проверка сценария: после того, как gitlab отправит сценарий правила мониторинга, можно выполнить тест сравнения данных в тестовой среде, чтобы проверить сценарий правила мониторинга;
4. Задачи онлайн-мониторинга: после завершения автономного теста вы можете подключиться к онлайн-задачам мониторинга, обратить внимание на выполнение задач мониторинга на платформе и получить обратную связь о тревоге через канал тревоги;

будущий план

В будущем мы построим функциональную платформу мониторинга бизнеса из следующих трех измерений:

Дополнить существующие возможности:

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

Развитие деловых возможностей:

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

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

Совместное творчество и совместное творчество:

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

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