2017年9月23日阿里客户服务技术论坛

智能调度

一.让好用户遇到好客服

1.根据客户意图路由

2.根据模型最优匹配

3.数据赋能客服

　a.智能辅助咨询解答（方寸）

　　解决方案无需记忆，用户数据无需翻找

　b.智能辅助工单处理（瓦力）

　　系统通过机器学习客服处理工单，自动学习工单判定规则，输出判定结果

　　算法代替人工配置规则

　c.仿真培训机器人（黄冈密卷）

　　利用用户分层模型和客服能力模型进行最佳匹配

 

二.阿里客服系统的特点

1.用户视角

2.解放50%以上人力资源

3.服务万人如一

4.数据驱动

5.弹性服务，从容应对双11

6.功能组件化，快速接入

 

三.阿里客服工作台

　　来电弹屏、在线服务、工单中心、方寸、统计分析、坐席管理、仿真培训（黄冈密卷）

 

四.永恒的挑战

　　消费者（用户体验）－客服（成长/成就)—平台（效率/成本）

 

五.系统演进

　　ORM+MVC->RPC->MSA->DT

    All-In-One CRM NG

 

六.调度问题

　　输入：M个智体（客服|资源|...），N个任务（任务|作业|...)

　　输出：将N个任务指定匹配至M个智体

 

七.单机基于业务技能组分配

　　准实时，没有并发问题

　　调度策略静态，忙闲不均

　　性能：调度会成为性能瓶颈

 

八.分布式分片调度

　　分布式动态扩展

　　基于静态业务分配

　　独立的RPC服务

 

九.按业务部门分布式分片

　　支持横向动态扩容

　　可用性保障

　　分配策略还是hardcode

 

十.传统模式的痛点

　　用户：被安排，缺少人文关怀；技能不对常被转交，多次解释；长尾个性化诉求无法被满足

　　客服：小二能力固化；干好干坏一个样；没有榜样

　　平台：粗粒度（技能组）；重运营，基于经验配置；弱弹性；服务多样性被束缚

 

十一.弹性人力云

　　用户：减少等待；精准推荐；个性化服务体验

　　客服：全技能学习成长；服务主动性、积极性；用户问题和服务水平区分

　　平台：细粒度（多维特征）；轻运营，基于机器学习；强弹性，灵活调度；服务多样性自由扩展；FCR、AHT、SAT提升

 

十二.策略中心+算法

　　微服务拆分，和单一业务解耦

　　模型抽象、可扩展

　　算法结合

 

十三.客服画像

　　推荐最匹配小二

 

十四.系统是解决问题中迭代抽象出来的

　　围绕领域模型有：商业机会、快速反应、增加、混乱增加\放缓、重构

 

 

基于React的插件化SPA设计

一.什么是SPA

二.插件化的SPA

　　技术：为平台型系统而生

　　业务：平台业务要支持垂直领域

　　什么是插件化？为什么要做插件化？

　　信息架构、规范化、总控管理、赋能

三.插件动态加载

　　过去：本地打包，React Component、import、webpack

　　现在：线上动态引入，React Component、AMD

　　如何加载：Webpack->AMD(requirejs)

　　插件独立：版本管理&开发调试，libraryTarget

四.共享代码：Webpack loader

　　JS:require.config & Webpack externals

　　CSS:style loader

五.组件能力

　　跳转其它页面gotoPage

　　离开当前页面leavehook

　　是否处在当前页面isCurrentPage

　　组件之间通信

　　高阶函数(HOC)

六.皮肤

　　方案1：CSS使用预编译语言(Less)、使用{color}.variable.less

　　不足：线上统一编译，本地同步主题文件

　　方案2：使用class(btn-primary、btn-info、hightlight...）

　　不足：class较多，记忆困难

七.代码

　　AMD Module & React Component

　　Redux store & reducer & actionCreator

　　样式污染、z-index规范

　　统一类库及版本

　　性能：Component Diff、Stateless Component

八.工具

　　语法解析器：eslinter、postcss->lesshint

九.总控管理

　　插件异常隔离(try catch)

　　全局站点 监控(window.onerror crossorigin)

　　请求异常(hook XMLHTTPRequest)

　　国际化(react-intl)

　　...

十.总结

　　SPA让前端开发人员拥有页面架构更多的主动权

　　可利用IESM（信息架构、规范化、总控管理、赋能），架构插件化的SPA

　　插件化SPA，让开发者之间的协作更加容易，让系统有能力支持不同的业务场景

 

 

智能UI自动化测试系统

一.UI自动化你会想到什么？

　　技术：selenium、webdriver、css/xpath、关键字驱动、数据驱动...

　　问题：业务更新快，脚本维护成本高；脚本不稳定；项目周期短，没有时间投入...

　　挑战：页面不停变化，如何维护我们的脚本；关键问题是如何定位页面元素；无法解决适配&样式等问题

二.目前行业的通用解决方案

　　测试脚本->测试API&Step&场景->数据驱动(excel、xml)->页面元素(对象库)->页面

　　问题：复杂度较高；仍然无法规避页面元素调整带来的问题；适配，样式等问题仍然无法解决

三.目前行业的“智能”解决方案

　　原始页面、测试页面->“智能识别”（1.个性特征对比（白屏、空窗）；2.图片相似度对比（ORB、SIFT））->测试结果

四.智能UI测试方案主要特征

　　智能识别：可以识别未见过的错误；业务变更不受影响

　　低成本：对现有脚本改动小；业务变更不受影响

　　可进化：随着使用越来越智能；可以定制出特定的错误

五.智能UI测试方案介绍－系统架构

六.实现过程

　　多层神经网络

七.脚本编写

八.智能UI测试方案介绍－测试结果处理

　　脚本执行->模型判断->结果分析->后续处理

　　脚本运行&记录日志->日志监控&badcase更新->增量训练&优化模型

 

九.后续展望

　　更智能：识别更多类型的错误

　　更个性：识别特定类型的错误

　　更明确：识别准确的错误类型

 

 

复杂业务流程管控架构演变

逆向交易服务系统系统演变：

　　ORM：RULE ENGINE

　　MVC：CASE TASK ACTION

　　RPC：WORKFLOW

　　SOA：DDD EDA多终端

　　MicroService：DevOps敏捷开发快速部署

重要的状态变更发送事件

　　标准化事件格式

　　提供异步、同步消费方式

　　集成了重试机制

一致性

　　重试队列

　　并发加锁

　　异步监听

可用性

　　拆分

　　超时逻辑优化

　　客户端缓存

可靠性

　　服务分组

　　过载保护

　　规则缓存

思维决定软件设计，设计决定系统

　　产品需求->竟品分析（京东、亚马逊、其它真实用户体验）->业务语义阶段（用最贴近客观规律的方式去思考）->领域建模（沙盘演练）->工业标准（团队分工）