Автор: Xianyu Technology - Baiye
Обзор
Как интернет-компании, мы имеем дело с деньгами более или менее каждый день. стабильность,Потеря активов, безопасность — это непреодолимая основа нашего бизнеса и систем. В любом случае потери капитала компания понесет потерю капитала, и даже компания не может позволить себе сумму компенсации за определенную потерю капитала, и она мгновенно обанкротится. В дополнение к финансовым потерям, инциденты с потерей капитала могут также спровоцировать инциденты в сфере связей с общественностью, создать кризис доверия пользователей к компании и поколебать массовую базу компании. Поэтому теперь каждая команда, особенно бизнес-группа, занимающаяся платежами, будет уделять большое внимание предотвращению и контролю потери активов. Хотя работа по предотвращению и контролю потери капитала в настоящее время является самой сложной проблемой, для ее решения нет большого решения, но благодаря вкладу, практике, анализу и обобщению каждой команды все еще накапливается некоторый опыт и методология. В этой статье представлена общая методология предотвращения и контроля потери активов и ее практика в торговой системе Xianyu.
Определение потери активов
Определение потери активов:Потери капитала — это любой ущерб, вызванный дефектами конструкции продукта, неправильным внедрением продукта или ошибками в работе сотрудников и т. д.Компанияиликлиент компаниистрадать прямо или косвеннопотеря средств. Исходя из этого определения, нам необходимо сосредоточиться на следующих ключевых моментах:
• Причины потери капитала: дефекты конструкции продукта, нестандартная реализация продукта и ошибки в работе сотрудников. • Последствия потери капитала: прямые или косвенные потери капитала для компании или ее клиентов.
В широком смысле, если средства после функционирования системы не соответствуют средствам, ожидаемым бизнесом, это считается событием потери капитала. В процессе устранения неполадок с потерей активов, если средства все еще находятся в системе компании, с ними легче иметь дело, и в конечном итоге они не приведут к фактическому повреждению активов. Однако, как только средства переходят из системы компании в руки пользователей, компания должна оплатить убытки, причиненные пользователям.Если пользователи получают прибыль, компании труднее восстановиться. Таким образом, отток средств с участием пользователей находится в центре внимания предотвращения и контроля потери активов.
Общая методология предотвращения и контроля потери активов
• Все случаи потери активов вызваны людьми, поэтому центр предотвращения и контроля капитала должен быть сосредоточен вокруг людей. • Все бизнесы реализуются через приложения.После завершения бизнес-операции данные остаются позади. Следовательно, наращивание потенциала, связанное с предотвращением и контролем потери активов, должно осуществляться вокруг приложений и данных. •Проблема потери капитала, особенно вызванная техническими причинами, сама по себе является ошибкой.Я считаю, что все знают, что ошибки не могут быть полностью устранены.Всегда будут ошибки, которые будут пропущены в Интернете и вызовут проблемы, а некоторые приведут к сбоям в бизнесе. Проблемы с взаимодействием с пользователем могут вызвать серьезные проблемы со стабильностью, некоторые из них могут иметь лазейки, которые могут быть использованы пользователями, а некоторые могут привести к потерям капитала. Таким образом, проблема потери капитала не может быть полностью устранена. Хотя проблема потери капитала не может быть полностью устранена, мы все же можем использовать некоторые методы и средства, чтобы максимально избежать проблемы потери капитала до запуска продукта (Способность уклонения), если это происходит после запуска продукта, это должно быть вовремя обнаружено (Открытие), с которыми можно разобраться своевременно после обнаружения (аварийный потенциал) для уменьшения убытков и воздействия, вызванных событиями утраты активов. • Для риска потери активов нам необходимо инвестировать специальные ресурсы (организационные гарантии) для предотвращения и контроля, связанных с предварительным контролем, и нам необходимо сформулировать соответствующие нормы и системы для обеспечения того, чтобы каждый выполнял их в соответствии с соответствующими нормами и системами, избегание части риска. В то же время нам также необходимо раскрывать и раскрывать ситуацию с рисками, а также инвестировать ресурсы в целенаправленное развертывание возможностей предотвращения и контроля рисков.
Определение и методология потери активов представлены выше. В методологии упоминаются три возможности, необходимые для предотвращения и контроля потери активов:Возможность уклонения, возможность обнаружения, аварийная возможность, нижеследующее посвящено процессу строительства возможностей обнаружения Xianyu в режиме реального времени.
Откройте для себя общую идею наращивания потенциала
Наращивание возможностей обнаружения, в основном вокругпроверка данныхЧтобы построить, чтобы найти проблему противоречивой деловой информации и средств. Для возможностей обнаружения ключевыми показателями являются охват и своевременность.покрытиеОн представляет проблему того, может ли быть обнаружена проблема потери активов.Если проблема потери активов не покрывается соответствующей возможностью обнаружения, как только она возникает, вызванная потеря становится непредсказуемой.старениеОн представляет собой период времени для обнаружения проблемы потери капитала.Предполагая, что событие потери капитала вызывает потерю капитала в размере 100 000 в час, тогда сумма потери капитала может быть меньше, если она обнаружена на один час позже, чем на один день позже.2,3 миллиона, если это 1 миллион в час, это23 миллиона. Если производительность в реальном времени соответствует реальному времени и имеет возможность слияния в реальном времени, можно даже добиться нулевых капитальных потерь.
техническое образование
Xianyu имеет много режимов транзакций: обычные C2C, B2C, инспекционное сокровище, покупка сокровищ, переработка, консигнация и т. возможность обнаружения потери активов во времени? Во-первых, давайте кратко представим две платформы, созданные Али для предотвращения и контроля потери активов:
• Платформа MAC: Платформа проверки данных, которая может сравнивать текущие результаты двух разделов SQL и выдавать сигнал тревоги, если есть разница. Недостатки: не в режиме реального времени; слишком частый запуск sql вызовет дополнительную нагрузку на базу данных. • Платформа BCP:проверка данных в режиме реального времениПлатформа может подписаться на данные каждого промежуточного программного обеспечения, а затем настроить скрипт для сравнения данных в режиме реального времени, а также имеет возможность оповещения.
Поскольку BCP может выполнять сравнение и сигнализацию в реальном времени, то для нас полезно использовать BCP для этой возможности.Что нам нужно сделать? Стандартизируйте источники данных, унифицируйте конфигурацию BCP и унифицируйте сценарии BCP. Пока можно достичь стандартизации и унификации, можно значительно сократить время и затраты на обучение для всех, кто занимается предотвращением и контролем потери активов.
Анализ данных
•модель проверки
•Сертификат: он представляет бизнес-ваучеры этого бизнеса, такие как транзакционный заказ и платежное поручение.Бизнес-ваучеры фиксируют источник бизнеса, участников и информацию, связанную со средствами.•Реальный: реальный, он представляет фактический поток средств. Входящие и исходящие счета Alipay, входящие и исходящие счета банковских карт
•модель бизнес-правил
• В нашей системе часто имеется множество различных бизнес-правил, поэтому необходимо проверить, соответствует ли работа бизнес-правил ожиданиям. Чтобы привести простой пример, нам нужно нарисовать x% от суммы заказа в качестве платы за проверку, а плата за проверку должна быть распределена между платформой и инспектором в соответствии с определенным процентом.Когда любой из этих трех процентов настроен неправильно, или в коде есть ошибка. Просчет приведет к проблемам с капитальными потерями для платформы и инспектора.
простое резюме: Примените эти две модели, наша ссылка для проверки данныхСсылка для проверки подтверждения, а доказательство и факт генерируются бизнес-правилами. По сути, это можно стандартизировать из процесса сделки: каждый бизнес должен иметь «справку» о информации о заказе, то есть заранее рассчитать расчетную сумму каждой стороны в соответствии с бизнес-правилами, и поставить информацию о заказе. ; когда поток транзакций переводится в тот, который нуждается в расчетном состоянии, удерживая заданные нами ожиданияСумма расчета (сертификат ожидаемой суммы)**, перейдите на расчетную платформу для проверкиФактическая сумма расчета (actualAmount)**, когда ожидаемая сумма != фактическая сумма, должна быть проблема на стороне бизнеса или на стороне расчета.
Архитектурный дизайн
Мы также только что проанализировали его. Нам нужно сравнить ожидаемое количество и фактическое количество. Следующий шаг — реализовать это с технической точки зрения. Весь процесс сравнения должен быть стандартизирован, легко закрывающийся и отслеживаемый. С точки зрения технической реализации, нам нужно сделать слой BCP более легким, потому что это всего лишь инструмент, и для проверки нужно написать скрипт, а сам скрипт не так просто проверить и поддерживать; пока у нас есть сверка данные в унифицированном формате, унифицированный интерфейс согласования, то сценарий BCP может быть полностью согласованным, новому бизнесу нужно только скопировать и вставить на уровне BCP и изменить получателя сигнала тревоги для предотвращения и контроля потери активов в реальном времени.
Внедрение системы, задействованное в архитектуре:
• Служба обработки транзакций: код, связанный с транзакцией, находится здесь, и он также будет получать сообщения MQ, отправленные процессом выполнения мидл-офиса •Мидл-офис транзакций: общая логика обработки выполнения заказа, выполнение заказа — это создание заказы, доставка, завершение транзакции и т. д. Когда каждый этап выполнения будет завершен, будет отправлено сообщение MQ для уведомления бизнес-стороны • BCP: упоминается много раз, платформа для проверки данных в реальном времени и оповещения • Платформа расчетов : Согласно бизнесу и правилам, деньги действительно распределяются, как правило, между платформой или поставщиком услуг.
Вы можете сосредоточиться на потоке данных, я хотел бы отметить два момента:
•
данные в едином формате: после получения сообщения о выполнении контракта от Zhongtai мы можем проанализировать унифицированные данные из информации о заказе в соответствии с настроенными правилами сверки, а затем отправить их в BCP. Самое простое понимание, я хочу получить ожидаемую сумму расчета expectAmount. подсказки:
• Правила размещаются на платформе динамической конфигурации, такой как ducc • Парсинг данных может включать регулярные выражения, такие как MVEL, с регулярными выражениями он будет более гибким и способнымобложкабольше бизнеса
•
Единый интерфейс согласования: Поскольку у нас уже есть данные в унифицированном формате, формат нашего интерфейса также может быть определен.Что должен сделать интерфейс, так это перейти на расчетную платформу, чтобы проверить фактическую сумму расчета, фактическую сумму, а затем сравнить, равна ли ожидаемая сумма. к фактической сумме и сообщите BCP, если она не равна. Не ждите, просто позвольте BCP вызвать полицию.
Суммировать
В этой статье в основном описывается процесс создания возможностей обнаружения потерь капитала в режиме реального времени.В настоящее время 9 предприятий, включая Xianyu Inspection Treasure, Purchase Treasure и C2B consignment.С технической точки зрения, предотвращение потерь капитала и контроль на самом деле является бизнес-вопросом.То же самое: вы должны сначала абстрагироваться от проблемы и, наконец, использовать технологии для ее решения, и вы должны хорошо использовать возможности существующей платформы, а не повторять колесо. Реализация схемы в основном включает:
•
Абстрактируйте проблему и создайте полную ссылку для проверки сравнения;
•
Используйте выражения MVEL для анализа данных заказа, чтобы добиться более высокого охвата;
•
Используйте платформу сравнения в реальном времени (BCP) для сравнения данных и оповещения;
•
Платформа сравнения в реальном времени (BCP) пишет сценарии для использования обобщающих вызовов для отладки интерфейса, избегая внедрения каких-либо бизнес-пакетов;
•
Унифицированный интерфейс согласования использует режим стратегии для настройки стратегии в соответствии с типом согласования.
Недостаточно иметь возможность обнаруживать, нам также нужны полные возможности предотвращения и чрезвычайных ситуаций, чтобы предотвращение и контроль потери активов могли стать системой и позволить предприятиям безопасно работать на канале капитала.