下一代智能化软件自发现和自愈能力

　　当谈AI人工智能的时候，我们更多谈的都是已经实现或具备了人工智能，自我学习能力的应用软件，而很少谈到传统的信息化软件，业务系统如何具备智能化特性。而今天这篇文章主要想谈下应用软件本身提供的交互能力和功能本身的智能化。从云计算PaaS平台说起
　　对于做过或使用过PaaS云平台的都比较清楚，PaaS平台一般具备一个关键能力，即中间件资源的动态调度能力。
　　简单来就是如果你的软件应用采用的Tomcat集群，PaaS平台就可以做到在空闲的时候只提供2个集群节点支持(基本高可用保证），在忙的时候提供4个甚至更多的集群节点支持。这个集群本身是动态扩展的，扩展的基础是资源负荷。
　　而资源负荷我们又可以进一步将其定义为CPU和内存在某个时间周期的负荷和利用率情况。比如利用率<10%，那么将缩减集群节点到最低配置，利用率>90%就增加集群节点等。
　　因此应用托管到PaaS平台，软件应用就具备了面向不同的并发场景下自我适应，弹性调度和动态扩展的能力，而这个过程不再需要人工干预。基于这个场景，我们回来来总结下，实现该智能调度的关键点包括了：预先定义和配置的资源调度规则和算法实时的健康相关性能数据采集数据采集计算和规则匹配，触发调度行为
　　具备了以上三点后基本就具备了最基本的动态资源扩展能力，也可以算作为最基本的软件智能能力。也就是说类似PaaS的动态资源调度能力并不是说PaaS平台本身的软件功能发生了变化，而是基于已有的软件功能实现了资源层面的动态满足。
　　类似的动态例子还大量出现在当前比较火热的AIOps智能化运维里面，也就是说传统的运维往往是需要人工去处理和分析问题，并基于问题分析结果做出人工的处理操作，比如设置限流措施，暂停某个资源使用等。
　　而新的AIOps的思路是系统基于预先设置的规则自动化的去采集数据，分析问题，然后自动化的进行相应的处理操作。但是这个处理操作更多的仍然是资源层面的，比如执行限流操作，或扩展资源等。
　　对于智能化运维可以参考我前面一篇文章：
　　谈AIOps基础-从自动化运维到智能化运维
　　也就是说传统的智能化运维只是将运维流程进一步的自动化和智能化，而不是说将软件本身的功能实现了自动化调整。软件功能层面的自发现和自愈能力
　　一个实现完成后的应用软件，是否能够具备在业务功能和需求上面的动态调整，自我适应能力，即在业务场景和业务需求变化下能够完成动态自我调节。如果要实现这点，基于PaaS资源调度的思路，可以看到我们在实现软件的时候需要考虑。
　　其一是软件应该基于SOA架构思路进行分层，即从底层的原子服务，到上层的组合服务和流程服务，从底层的资源层和服务层，再到上层的前端界面展现。
　　其二是软件的构建应该基于当前的低代码开发平台的思想，即软件最终的呈现应该是可以基于已有的各种能力进行组装出来的，这些能力可能来源于界面组件，代码片段，规则中心，原子服务等。
　　其三就是借鉴前面PaaS平台资源调度的核心思路，构建一个围绕数据采集分析，规则中心，规则执行中心三大核心要素组成的智能化管理和调度中心能力。
　　简单总结就是我们希望实现的软件智能化是：
　　一个智能化应用软件应该是可以自动的通过数据采集来分析用户的使用行为，并基于已有的预设规则做出自动化的优化和调整。
　　因此要实现软件的智能化关键还是业务规则剥离，能够灵活配置。其次就是我们要对各种业务场景下的输入进行分析，建立输入数据和预设规则之间的联动关系，或者说最优联动方式。基于这两者就可以基于已有的规则引擎或智能算法选择软件的执行路径并返回结果。
　　在这里并不是说软件应用能够自己突发奇想增加什么新的业务功能满足用户需求，而是对已有的功能如何更好的变更或优化来满足用户需求和使用场景。
　　一个智能化的软件应该具备自愈能力，即大部分的缺陷，大部分的软件变更或优化应该能够自我修复，而不是靠程序员进行代码修改和重新版本发布来完成的。
　　这个是我们希望软件应用智能化走出的第一步。智能化应用场景分析
　　软件的智能化应用场景究竟有哪些？
　　从当前应用软件发现趋势来看，个人理解首先需要做的就是易用性自我优化，Bug缺陷自我修复，已有功能自动化编排等几个关键场景。
　　易用性自我优化
　　简单来说就是一个好的应用软件应该能够自动采集和分析用户在界面的操作行为和用时数据，然后做出最佳的易用性优化调整。
　　这种数据的采集不是针对单个用户而是针对用户群体。
　　举个简单的例子，如果用户录入一个报账单据，但是在整个单据创建和录入过程中，需要选择具体的费用类型或科目信息，而系统通过数据采集发现一个报账单从录入开始到提交，有一半的时间居然花费在这个信息的检索和选取上面。那么系统就应该可以判断出，这个地方需要进行优化处理。
　　再比如，用户在使用软件系统的时候，系统通过后台日志数据采集分析，发现完成一个业务功能居然出现频繁的在多个业务功能界面间来回操作和切换。那么系统也应该判断出这些点是需要进行自我优化和调整的地方。
　　在一个表单录入的时候，我们发现我们原来预设的表单数据项录入顺序并不是客户实际录入顺序，那么我们的软件是否可以动态的基于用户的使用习惯，对表单录入数据项顺序完成动态调整？
　　当然我们可以根据用户的使用场景和使用习惯，基于不同的用户给出具体的功能编排和快捷进入，并且对不同功能页面间的连接进行重新编排等。我们也可以根据用户经常使用的查询功能和查询条件等进行分析识别，在用户每次进入的时候给出最优的查询组合等。我们可以提供类似当前互联网，电商应用常用的功能，给出用户在使用功能的时候最佳的猜测供用户选择。
　　如果基于上面谈的三个要素进行总结，那么整体思路如下：形成易用性规则和逻辑采集用户行为数据和日志数据基于规则匹配，对功能易用性和交互逻辑进行自我修复
　　能做到以上这些难不难？
　　对于上面这些点虽然有难度，但是个人理解远比机器学习和人工智能等简单，只是我们没有重视这块的智能化而已。或者我们认为即使投入开发人员去做易用性优化或变更，成本反而更低，这些都导致这块的智能化实现很难去推进。
　　Bug自我修复
　　对于Bug我们可以分为两类，第一类是业务规则逻辑上的Bug，第二类是技术类Bug，比如内存泄漏，性能问题异常等。
　　在应用系统的智能化演进过程中，对于第2类技术Bug完全可以实现智能化修复。当然这类Bug本身就应该在代码静态检查的时候发现并修复。还有一类往往是需要具体的业务场景，并发或数据量下才会体现出来的Bug，那么这些Bug需要的就是通过对抛出的异常进行分析后，进行自我修复。
　　只要能够找到技术类Bug的规律或者修复规则，那么就一定可以智能化处理。
　　如果一个技术类Bug有3到5种不同的修复方法，智能化的系统完全可以将其Clone回到一个测试环境，对每个解决方案逐个进行验证并确定最终的修改方案。
　　比如一个技术Bug导致单据提交出现技术类Exception异常，最终系统通过日志追踪可以查询到具体的问题根源，这个问题很可能是某个参数配置出现错误，或者是某个授权没有打开，那么就可以对这些信息在测试环境进行验证和确认。
　　传统的智能化往往只是应用系统帮助你提供错误日志记录，或者帮你做下异常日志的聚合分析，告诉你可能错误点在哪里，接下来还是人工来完成后续处理。但是智能化的应用除了问题自发现外，还应该具备自我修复能力。
　　性能自我优化
　　软件应用在后台运行中会发现某种业务场景或业务并发下会导致资源出现性能瓶颈问题，那么应用可以自动地分析出现性能问题的原因，并对软件应用代码进行优化和调整。当前大部分的APM应用性能监控或AIOps更多的还是发现问题，而不是智能化的自我解决问题。
　　举个例子来说。
　　当一个应用功能在进行查询的时候性能很慢，这个时候通过APM或服务链路跟踪往往可以采集到具体的时间消耗数据。那么就需要多这个耗时数据进行详细分析。
　　当分析的结果是大部分时间都花费在了Sql语句上面。那么就应该对Sql语句本身进行分析和诊断，看看是否可以进行优化，如果Sql语句本身没有问题，还需要考虑是否需要进一步对数据库关键表构建索引。
　　其次，当分析的结果是大部分时间花费在了应用中间件上，而且中间件集群CPU和内存负荷很大，那么就需要考虑是否是业务逻辑层代码有问题，如果业务逻辑层代码没有问题那么就需要考虑是否确实是业务并发量大需要进行集群资源扩展。
　　所有的内容都应该由系统智能化完成，而不是仅仅给出一个链路分析结果。
　　在Bug修复或性能问题优化过程中可以看到三要素内容如下：规则：知识树或问题诊断树的结构数据：基于APM，日志和服务链路性能采集执行：规则匹配后自动修改配置或打补丁
　　理想情况下，一个软件上线完成后基本能够做到不需要运维人员和监控人员，软件出现的问题或故障能够自动的进行分析，在分析后给出自动的解决措施并完成解决，或者给用户最佳的问题处理方式和流程。
　　即在我们传统软件运维监控的基础上，能够进一步做到出现问题也能够被自动修复和解决，而不需要人工干预。如果出现问题，在采用了类似重启等方式进行解决后，也能够对问题产生的根本原因进行深入分析，以对内部实现逻辑和机制进行优化和调整，从根本上避免问题的再次出现。
　　对于软件系统本身的自发现和自愈，通过和用户交互协同完成自我适应和智能化的自动优化，这个应该作为一个专门的细分方向课题进行研究。