本次分享的主题是云卓越架构：企业稳定性架构体系和AI业务场景探秘 ，由阿里云智能集团公共云技术服务部上海零售技术服务高级经理路志华分享。

 

在加入阿里云后，负责奥运、双十一、二十大等国家级的战略重宝项目，这期间积累了一些稳定性和重宝的经验，后来也服务了一些全球头部的企业客户，包括中国的一些头部互联网客户，目前在服务上海零售客户，有非常多的全球500强的客户，在服务这些全球500强的客户的过程中，发现有非常多的用云的稳定性的体系架构经验。

今天分享的主题是企业稳定性架构体系和AI业务场景的探秘。分享分为四个部分：

第一个部分是稳定性架构的设计

第二是稳定性保障体系和应急体系的建立

第三部分是在重大活动时，如大促或信用上线时稳定重宝策略的建立

第四部分是AI在企业中的应用场景。

 

一、稳定性架构设计

以终为始，要做一个好的稳定性架构设计，首先要明确如何定义一个好的稳性架构设计，一个好的稳定性企业架构设计应该包括可靠性，即在任何情况下，包括异常甚至故障的情况下，架构依然能够为业务提供连续的、稳定的服务，这要求架构具备高可用和故障恢复的能力。

另外一个是要具备可扩展性，在应对突发流量的时候，架构能通过水平或垂直的扩展，垂直是指增加CPU、增加内存，增加IO等，水平是可以增加虚机或增加水平的扩容手段来维护系统稳定性，应对突增业务流量，系统也要具备一些可插拔性功能的能力。

第三个是安全性，架构要保护业务数据不被未授权的用户访问到，同时系统提供的数据是机密的、完整的，可靠的和一致性。第四个方面是要具备可维护性，所有的发布都是有迹可循，在问题发生的时候，运维人员能够通过变更的记录快速找到并定位问题。

同时，系统的功能和升级要尽可能减少对业务的影响，这要求有灰度发布的能力。为了实现这四个目标，可以使用什么样的相应技术手段，首先可靠性和可扩展性是相辅相成的。

在基础架构层面，虚拟化和容器化技术以及负载均衡是实现整个高可用的基石，只有业务流量可以通过负载均衡分发到不同的虚拟机或容器上才能保证整个业务的高可用。

另外高可用集群和分布式存储是存储的高可用的基石。最近发生一些事件中，体感非常明显，做的好的客户他的核心业务、数据库存储中间件、卡夫卡相应的是中间中台服务都采用了高多可用区的高可用集群，在问题发生时，可以及时的通过HA切换，直接切到对应的可用区；而对于做的不好的客户，可能在单可用区中，他的业务就有可能产生中断，在基础架构层面，可能要重点注意一些资源选型，因为在日常的技术支持过程中发现很多客户，他的基础架构的选型并没有基于它的业务去考虑，导致了经常达到性能瓶颈，例如一些云防火墙，自建的云防火墙，它对网络流量要求比较高，建议采用网络增强型；

对于数据库存储，中间键卡夫卡这种相应的IO要求比较高，建议选用存储增强型；对于爬虫索引对于CPU要求比较高的，建议使用的计算增强型产品。

在服务层面，建议使用微服务的架构来减少各个服务之间的依赖，建议前面一定要挂一个API网关来做整个全链路请求追踪，当问题发生的时候，API网关也具有熔断，限流，降级等相应的功能，来规避相应的风险。

另外各个微服务之间的通信建议使用异步通信的，这样做的好处是某个服务出现性能问题的时候，不会影响整个请求的时间，如果说真的某一个服务发生了单点故障的时候，也可以临时通过异步访问缓存的机制来规避掉问题，服务建议是统一放到一个微服务注册与发现管理。

例如中心管理软件，比如云主业架构中提要求三个月轮转一次AKSK，那如果把这些AKSK都写到代码或者是配置文件中，会导致整个变更非常复杂，而且极易出错，通过统一的注册发现机制进行推送之后，整个运维的复杂度就降低很多。

在应用层面，建议采用一些缓存的机制，使用缓存可以从缓存中快速读取数据，减少整个服务的请求时间，另外也会保护数据库性能，数据库也要做读写分离和分库分表，来保证核心库和核心表的性能。但内容分发层面，建议使用CDN做动静资源的分离，静态资源放在CDN上，客户在访问的业务的时候，可以就近的访问到CDN的节点上，减少整个访问的链路，提升整个RT的时间。也可以有效的分离出操作系统的负载，在开发层面，建议前后端使用MVC架构，这样有便于做动静分离。大量的业务逻辑可以放到controller层面做掉，就不用去访问数据库，从而提升数据库的稳定性。

静态的数据，比如说JS javascript、CSS样式文件，还有图片、视频等这种比较大的文件，建议一定要做压缩后再存储，也遇到过很多客户在业务突发的时候，由于相应的资源文件很大，导致把整个带宽充满，所以大的资源文件是要做压缩进行处理，另外代码中也要做相应的容错与重试机制，因为在网络中，公网中很容易出现网络的抖动，只有相应的重试机制可以规避掉这样抖动的问题。代码的发布也要经过CICD持续发布，这样可以确保在所有的版本变更都是有迹可查，发生问题时，可以快速的根据CICD的记录找到相应的版本进行回滚。

在安全层面，在底层数据传输的时候建议大部分客户南北向做的都非常好，都是统一公网出入口，前面挂了一个waf做安全的防护，但有一些客户东西向的流量是没有做防护的，就导致一旦他某一台内网的机器从内网的机器发出的攻击，是没有防护的，所以建议在网络规划的时候，一定要基于零信任网络去规划，其他的VPC一定是不被信任的，这样可以确保在设计的时候能保证每一个东西向的流量都过防火墙。

在数据安全层面，在数据传输时一定做完脱敏，加密之后再进行传输，要有防篡改，防注入的机制，一些客户他由于没在开发的时候没有考虑过防注入的情况，从而导致被黑客注入相应的信息返回一些敏感信息。应用安全层面，要确保所有的业务的服务和数据都是经过授权后的账号才能够访问，一般比较大型的企业都有自己的AD域，可以和云产品SSO进行整合，确保某一个用户离职之后，他所有授权全部在AD域中注销，就防止了有些散落的授权没有在用户离职的时候完全取消掉，从而导致了信息的泄露。所有访问都要有审计记录的审计，这样以便于后续一旦有任何问题可以通过审计，快速的定位到问题源，可维护性的基石是整个观测能力，建立完善的监控大屏，业务层的监控指标，基础架构层监控指标，保证发生问题时能够及时告警，然后及时定位到问题产生的原因，在日常生产中大部分的问题都是由于变更导致的，变更的可观测、可灰度和可回滚也是整个可维护的基石。微服务的划分也要注意一下是否依赖，微服务之间的依赖是否划分清楚，是否和平台进行了耦合，在问题发生的时候，微服务是否可以通过平台迁移来解决问题，这都是企业稳定性架构设计时需要重点考虑的。一个好的稳定性架构设计不仅仅是需要在运维层面做一些考虑，在整个设计、开发、测试和发布阶段都需要重点考虑。比如在设计阶段，最主要是先明确当前新上的这个系统到底需要满足多大的负载，以及他未来的规划，有些系统可能开始做的负载已经完全满足了，但并没有预料到后续有更大的业务流量，就导致这个系统最后需要完全的重构才能支持未来的规划。所以在系统上线初期，一定要做好相应规划的预测，架构和资源规划，以及冗余设计，重点在提资源规划的时候，有一个重点是开发和测试，生产VPC要进行隔离，很多开发测试的变更影响生产的问题，使用APC隔离掉就会减少问题产生的可能性，在开发阶段代码一定要是可读，可维护和可扩展的，在日常的支持过程中发生过很多次故障，在故障中很快就通过了arms或其他定位到问题，定位到具体的方法，但是由于代码不具可读性，新接手的研发根本没有办法快速的修改代码来解决问题，所以代码的规范是在开发阶段需要严格遵守的。

另外比较多的问题是是否做了防御式编程，平时遇到过很多输入了一些错误的数据，直接把整个系统搞崩的情况，经常在开发的时候，每一个方法是否接触了所有的异常，如果没有接触，一个异常可能就把整个系统搞崩。

在性能方面，最主要关注算法和数据结构的性能，因为平时的运维过程中也发现很多客户由于一些异常的数值，导致陷入了死循环，或者不停的创建线程，或者在线程中不停的做方法调用，导致整个CPU都被打满，系统夯住。要么是有一些内存的泄露，比如一些对象，一些数组，数据列表等没有及时释放，这种累加起来之后，就会把整整体的内存打爆，这种情况它的系统也就处于不可用的状态，所以在开发时重点要关注算法和数据结构的性能优化，测试阶段的功能测试方面要多增加一些异常测试，尤其是超出边界值的设置，因为正常边界值的测试测试都已经很完善了，但有一些测试，它是不做超出边界值的测试，由于开发没有做异常处理和防御式编制成就导致一个错误的数值就把系统导崩的情况，这要重点注意。

性能测试要注意两个点，第一个是在预期负载内，系统的性能是否是稳定的，第二是全链路是否进行过压测，因为很多单的功能节点是没有问题的，但是可能全链路某一个中间节点的问题会导致整个系统的崩溃。在测试阶段要比如宿主机宕机，网络中断，存储IO号相应的故障注入来确定系统是具备完善的容灾能力的，在发布阶段建议发布一定要有这种灰度发布，比如蓝绿部署，只部署一两台机器先发布，或者是基于有一定标签的客户发布，确保这样的客户或物理机上的服务的客户，他的部署是没有问题的，再逐步扩大相应的部署范围，在部署前一定要建立好相应的实时机制，实时监控机制，这样有任何问题可以快速的通过告警来发现问题，也要先建立好回滚机制，回滚机制中回滚的步骤是什么，决策人是谁，触发的条件是什么，也要先完善清楚，尤其是回滚步骤一定要清楚，因为很多在应急时没有做好回滚预案，有一些DNS切了，但数据库的同步链路没有反向切的情况，导致生产数据丢失，所以在发布任何一个系统前，一定要做好相应的回滚步骤。

 

二、稳定性保障和应急体系

一个再好的稳定性架构，也需要相应的保障体系和应急体系来保持它的运转。

整个稳定性保障体系为三个域：

第一个是预防域，是否有高可用的架构，有相应的监控告警和压测演练来确保能够预防相应的故障。

第二个是支撑域，是否有变更的管控，可以快速的回滚，是否有容灾、切流、限流、熔断，是否有完整的风险预案来应对问题，决定是否在故障时能够快速的恢复直解。

故障预是整个一级保体系中最重要的域，在故障发生的时候，是否有相应完善的应急协同机制，能够让所有人移动的快速加入到对应的会议中，在会议中所有人的第一要素是快止血，在会议中不要讨论变更可能不会导致这个问题，这个问题的责任人不应该是我或者是恢复诊断，因为不一定能够解决这个问题，先按照原先预定的风险预案，预定的变更回滚恢复止血，所有人的第一要素是止血，让业务恢复正常，恢复正常之后再做相应的故障复盘。

1-5-10应急体系，如何实现1-5-10，其实是很难的一件事情，实现一分钟发现，前面要做很多全链路的监控覆盖，包括相应的任何一场指标都要及时的告警，也可以借助后面讲能力做一些风险的预测，能够在一分钟发现。第二在5分钟定位问题，最终要素是把所有的研发，测试、运维，还有故障负责人全部拉到在线会议里，需要应急协同产品的支持，需要钉钉teams等等群语音功能的一个移动组件来帮助实现把所有人拉到会议的能力，70%的运维问题，故障问题都是由于变更导致的，所以在故障发生的时候，第一个因素一定要有运维去查当时有没有变更，另外根据的风险预案，比如临时的增扩容资源，临时的扩展pod，增加pod等等，增加熏机能不能快速的解决问题，如果能够快速的恢复业务，先让业务恢复，争取再继续排查的时间，在脑海中一定要有一个印象，防二次伤害。见过很多客户在临时的控户资源或临时的回本变更之后，问题虽然暂时解决，但是根因没有找到很有可能这个问题会再次发生，比如一些MySQL并没有定位到为什么会有这样MySQL，如果只是临时扩容的数据库，后面还会被充满，所以防二次伤害在整个故障止血之后，一定把故障保持一个高区间处理的状态。一个再好的体系和架构都需要人来支持，如何让人时刻保持一个高的安全生产的意识，就需要运营和规范流程的支持。

在运营层面，要有安全生产的周会、月会，有相应完善的培训，另外要不定期举办一些预案的预演，然后包括红蓝对抗，网断容灾演练，季度年度要有相应的红黑榜，做的好的给重赏，做的不好的重罚，这样大家才能把安全生产时刻印到脑子里，做到润务无声。

在规范层面，一个是先上岗规范，一个是大促封网规范，因为在日常支持过程中发现很多的运维问题都是由新人对系统不熟导致的，新人如果要上岗运维系统，一定要经过严格的培训以及相应的能力评估之后才能上岗，另外一个是封网，在企业中做的会比较少，但是在日常的重保过程中会发现在重保过程中发生的问题大部分是由于重保前的一些变更导致的，因为在重保的时候，会做很多的手段，风险都已经巡检过了，在重保之前的一些变更很容易把新的问题引入进来，阿里巴巴在618双十一大促之前，会提前做柔性封网，除非非常紧急的安全的变更才会引入，而且这个变更的引入一定要经过所有技术负责人的综合评审才能变更，提前三天会做一个硬性封网，在大促前三天，所有的变更都不再通过了，也要建立相应的故障应急流程，通告流程，新的业务上线有监控流程，来保证整个稳定性的体系。

 

三、重大业务活动的稳定性保障

养兵千日，用兵一时，花大精力做稳定性的架构，应急体系的建立，最终关键的时刻，需要做一些稳定性重保，比如业务的大促或者新游的上线等，这个时候遇到问题的可能性会远远高于日常的业务。

一般在提前大促的时候分为五个阶段，首先开始时候要和业务对齐目标，规划的时候要规划好需要的业务资源，做一些风险巡检。护航准备阶段要做相应的全链路压测，根据压测结果不停的优化。护航保障阶段会有作战史，或者在线的作战史，这样确保所有的相关人员都进行支持，护航结束会有相应的总结。

在重宝护航的时候，要有一个概念是所有的监控、巡检、压测、防护都是要做全链路防护，在业务的任何一个节点都有可能出问题，只有全链路的防护才能保证业务重保的成功。

这个是上海零售为618客户做了一个重宝护航的节奏，时间非常长，提前两个月，因为涉及到全链路的压测，资源的预留，资源的上量等，所以整体的时间是尽早开始，越早越好。现在也有客户开始做双十一的保护，在护航启动阶段，要和客户业务方对整个护航的业务需求，今年做的比较特殊的一点，整体虽然日常的销售量预期不如往年那么高，但有一个特殊的系统，比如临期快销这个产品，发现它的日常的业务量比往常要高很多，因为最近消费降级，所以这个业务流量高，预计今年618的业务流量也会远远高于平常，所以把QPS调高了平时的三倍，实际上后来发现618真的是产品的系统，它的QPS比往常高了二点二倍左右。

在护航需求确认阶段，一定要确立好基于历史经验梳理相应的需求，要基于日常的一些需求去看有没有可能突发的一些业务需求，如果预估不准，会对整个系统设计后面产生一系列的影响。

护航规划阶段主要是做整个业务链路的梳理，架构的梳理，重点注意做全链路的资源风险巡检，比如所在自建的一些的宿主机上有没有相应的存储的软件、硬件相应的异常，提前要做巡检，另外这个系统有没有安全漏洞，防止这些黑客拿前两个月的漏洞来攻击系统。最重要一点是做库存预留，因为在618，双十一这种重大大促的时候，所有客户都是有相应资源需求的，很容易出现争抢争抢的情况，一定要确定好到底需要多少资源和商务报备，引入相应的机型，对于一般小的机型是没有问题的，但是对于像GPU或者超过64核大的机型，提前要做预留，库存有可能不足。

在护航准备阶段，做了两轮全面的压测，第一轮把测到一些问题，做一些架构性能的优化，直到第二次测没有任何问题，才结束护航准备阶段，这个阶段也会做一些系统扩容、限流、熔断、降级这种相应的升级手段的演练，确保在重保时相应的应急手段能够生效。要确保所有的安全风险加固，资源预留已经全部准备完毕，在护航当天会组织相应的作战室，把所有的研发、开发、测试和运维人员都拉到相应的作战室，确保一旦有任何问题大家能够及时的应急处理。

在护航保障阶段，还有一个比较重要的是每日监控复盘，发现有一些当天比较小的异常的指标，并没有产生任何生产的问题，但如果不通过监控复盘看到这个异常指标，很有可能在第二天带来更大的麻烦。

护航总结阶段，在整个重保过程中，护航的措施是否是正常有效，压测是否准效，包括在整个重保护航过程中，如果发生了任何问题，长期的价格优化和代码更改，责任人是谁，什么时间完成整改，要落实到人，落实到时间，确保整个优化的方案能够落实下去。

 

四、AI在企业中的应用场景

这一部分面向未来在大模型在企业中的应用场景，在企业中主要是针对客户中有哪些相应的角色，具有哪些流程，这些流程对应有哪些优化的可能。

比如对开发可以使用智能编码，客服可以基于企业的知识库创建相应的知识库问答，营销层面可以使用文身图或者图中图生成相应的创意的广告，财务可以基于历史的财务报表，根据财务的需求生成相应的chat BI智能报表，法务也可以基于法务历史的合同来看一下当前的合同是否存在问题，比对合同的正确性。在运维层面，最主要是通过AIOPS来提升整体的运维性能，做一些风险的预测。

AIOPS能够解决运维中的稳定性，效率成本的核心问题。在运维层面最大的帮助，第一个是把海量的报警进行收敛，运维有很多种误报警，大家处理起来非常麻烦，AI可以基于大模型进行收敛，另外可以基于历史数据的实测分析来进行故障的预测，预测到故障可以通过相应的智能体，甚至自己写脚本去做一些资源的配置更改，或者资源的扩容，做一些自愈能力的建设。

效率方面可以通过智能变更、性能优化，建一些智能体助手，比如客服的运维的开发测试助手，来降低对应的成本。把这些结构化和非结构化的数据采集到统一的数据平台中，比如SLS日志系统，对采集到的日志系统进行清理和预处理，清理和预处理的步骤一般包括格式统一，去图缺失值处理，缺失值处理这块重点注意，因为后面的很多模型的幻听都是由于没有设置缺失值导致的，对这些这些数据进行深入的分析，提取对运维决策有价值的信息，如统计信息、实序信息等，把这些输入给自己的模型，利用Transform架构或者其他模型，因为这种模型它的参数量很大，能够学习到数据中深层次的或者非线性关系，利用这种数据可以做一些日志的分析和时间序列的预测，即异常行为值偏离正常值行为模式的预测，基于这些训练好的模型，对实时的监控数据做一些识别出偏离正常行为的模式，比如异常检测，故障预测，潜在故障的分析。

基于模型的输出，可以做一些智能决策智能体，比如企业中用ITS比较多，可以自动的对接ITS的API，生成自动的企业运维工单，甚至启动一些应急的机制，包括结合自动化写自动化脚本去更改，增加配置水平扩容的相应资源，实现通过AIOPS治愈产品问题的能力。最关键的一点是模型要经过持续性的学习与改进，要不断的反馈，它的决策是否正确，从而帮助模型不断的进化，通过AIOPS模型进化，可以更好的提升整体的AIOPS运维的稳定性。