云博士简介
云博士依托于海量数据分析、自然语义分析和云产品智能自学习等技术，面向用户提供了最懂云计算的智能问答服务，为阿里云用户提供秒级响应、多端触达的智能化服务体验。
业务背景
阿里云业务的快速发展，带来了云计算背后的巨大服务压力！如何为用户更快速高效把问题解决呢 ？我们在算法推荐上做了很多实验和突破，努力提升答案的命中概率，为用户的问题推送期望的知识点。后来我们逐渐发现：在用户使用云计算产品的过程中，很多时候只能看到问题现象，而经常有很多问题的现象是相同或者类似的，这时候即便我们推送答案的计算逻辑百分百正确，也不能解决用户的所有问题。因为这些从描述上来说几乎一样的问题，背后的原因多种多样，解决方案也千差万别。
通过查看大量的工单，我们看到售后工程师在解这些问题时，面对相同的“工单内容“，工程师们需要花费大量的时间，穿梭于不同的系统平台获取用户的线上实例数据，来解决这些看上去类似的问题。通过不断实验和讨论，云博士把这样相同现象的问题合并形成一类问题，并针对每一类问题分别建立了决策树，来替售后工程师更精准的解决用户问题，从而大大提升解决效率！将之前人工半小时才能解决的问题，在1秒内快速完成，整体提高了阿里云用户解决问题的体验。
阿里云工单案例
现象：无法远程 -> 原因：windows 3389端口问题!
现象：无法远程 -> 原因：ssh 22端口问题!
现象：无法远程 -> 原因：机器重启中!
以上的工单内容都是用户无法远程连接到自己的ecs，面对同样的语义，基于Q/A原理的任何算法都无法解上面的场景，但是云博士却针对性的给出了三个不同的解决方案，并且用户查看后主动关闭工单确认问题解决。那么问题来了，云博士是如何做到的呢？
问题本质
ecs无法远程这种问题现象对应的原因有很多种：ecs实例运行状态(启动中、关闭、关闭中等)、网络被黑洞清洗、主机的使用情况(cpu/内存/iops异常)等!
是不是表示我依次判断各个条件是否异常就可以了? No，比如应用被攻击导致网络被黑洞，同时可能cpu、内存、iops都会异常，故在判断各个条件是有先后顺序的，而且各个条件组合起来解决方案可能也不同。
谁知道这些判断的组合关系及先后顺序及对应的解决方案是什么？ 工作在不同业务线解工单的一线售后工程师们，对业务以及排查流程最了解。这些工程师知道这些现象背后具体的原因排查方法及对应的解决方案。但是他们很难打通并获取十几个系统平台的数据来自动解这些问题
传统解法
业务线的售后工程师作为需求方，给云博士的开发团队提需求，case by case的解类似的问题，但是这个方式有个弊端，每一个千人千面的场景都需要售后工程师+开发同学逐一区别攻克，这样会导致开发同学陷入了具体的业务场景里，不断去硬编码这些业务逻辑。那么有没有更好的方式来解这个问题？
千人千面解决方案
先来一张云博士简单的架构图，让大家对云博士有一个全景的认识!
云博士的千人千面能力作为语义分析的一部分，去帮助云博士解决那些语义相同但是答案不同的场景，并把这部分能力开放出来，让普通、不懂算法业务同学参与进来。
简单流程如下：
业务同学定义决策树，不同的千人千面场景定义不同的决策树（标准的bpmn流程图），并在叶子节点给出最终的解决方案,下面是远程无法连接部分决策树场景!
开发同学负责解析决策树，并打通各个平台获取支撑决策树的决策变量（针对远程无法连接的场景：cpu、mem、iops等）
总结
通过上面的千人千面解决方案，我们把耦合在一起的开发和业务需求最大限度的隔离，开发不需要关心if else的先后顺序、相关因素的组合关系、具体的解决方案是什么，只需要一套代码框架，做到了“一劳永逸“。对于业务同学，我们把“定制能力”开放给解工单的售后工程师，来方便的修改增加决策逻辑，更好的支持线上解决用户问题以应对各种各样的千人千面场景。
