一、金融级分布式架构面临的挑战和机遇

软件产品向分布式架构和微服务转型已经成为行业的共识。在架构的转型过程中，作为守门员的企业运维保障部门面临着巨大的挑战。这些挑战包括但不限于：1:产品需求变更频繁、软件开发速度也越来越快，但运维保障部门由于缺乏完善的保障措施只能通过控制发布次数来降低风险，使得业务更新速度下降。2: 从大型机器转移到PC服务器使得系统单机故障率更高，现有的容灾与FO机制能否支撑系统准确地运行仍存在疑问。3:从单体架构迁移到微服务架构要求系统进行全面的回归测试，这带来了巨大的测试工作量。4:，分布式系统中的一条调用链路可能横跨多个系统，问题排查变得非常困难。5:，对金融行业而言，解决分布式系统中的数据一致性问题也非常关键。

从另外一个角度看，企业运维保障部门也应看到分布式架构带来的机遇。在过去，单体系统发布新版本通常要求产品通过层层测试来保证新版本上线后不出问题。但分布式系统允许使用真实用户和流量实现线上验证以确保产品上线后出现问题带来的影响最小。分布式架构使灰度验证和快速发布成为可能。此外，从前只能在线下进行的模拟演练，现在可以随时在生产环境中进行。全链路压测还让获取真实流量成为可能，让我们能在每次大促时做到高枕无忧。

在过去十年中，蚂蚁金服的运维保障体系也经历了深刻的变革。通过抓住架构升级带来的机遇，通过技术和平台提升解决系统问题，运维保障部门做到了在架构升级的过程中平滑过渡，系统保持非常高的可用性的同时充分享受架构升级带来的收益。

二、蚂蚁金服技术风险保障体系

下图是蚂蚁金服的技术风险保障体系的总体设计图。在目标层，蚂蚁金服的运维保障部门力求做到99.99%的系统高可用、系统全年无重大资金安全故障，同时实现系统运维零成本。这些也是蚂蚁金服给客户的SLA承诺。治理层：与蚂蚁金服的团队、文化和制度相关。为了应对技术风险领域的挑战，蚂蚁金服组建了技术风险保障部门，聚焦于使用技术升级运维和质量保障手段以解决系统面临的技术风险难题。同时，蚂蚁金服建立了一系列制度保证系统内的任何变更都符合可监控、可灰度、可回滚的“三板斧”要求。在运营层：设置了四道防线。前两条防线即需求和研发包含了风险评审、自动化测试等常规内容。第三道防线通过灰度发布和蓝绿发布实现产品变更的验证和管理。第四道防线即系统监控，保证了系统在线上运行过程中具有最小的运行风险。最后一层是平台层：技术风险保障体系的目标、治理和运营层需要依赖平台层来实现，平台层包括业务监控、演练中心、预案中心和变更管控等各种技术平台。

三、TRaaS技术风险防控平台

蚂蚁金服将其构建技术风险保障体系的实践和经验沉淀下来，形成了TRaaS技术风险防控平台，开放给金融生态圈的所有合作伙伴。下图右侧的能力闭环展示了技术风险防控平台的核心方法论，分为三个部分。风险基线衡量了系统的风险保障能力，使风险保障人员了解系统的风险防控水平。监控/巡检、预案自愈以及演练属于第二个部分，确保系统在发生问题是能快速发现，定位和自动修复。此外，变更是系统风险的最大来源，蚂蚁金服对系统变更进行了严格的管控，确保所有变更都符合三板斧制度。

下面我们分别看一下这三个关键环节中，平台具体所做的事情。

风险基线

风险基线这部分核心要解决的问题是如何评估我们当前的风险保障能力，以及发现哪些地方存在风险隐患。所有做风险管理的同学都会面对一个问题：“风险分母到底有多大？”，这是一个理论上就无解的问题。

那怎么办呢，蚂蚁金服的实践经验是接受风险本身的未知性，但在平台中将已知的风险场景沉淀下来，确保未来不再犯类似的错误。通过对这些沉淀下来的风险场景的风险保障能力的自动检查，来对我们的风险保障能力做个打分，并且发现存在问题的地方。

具体到平台中的做法是：第一步，先获取到所有和风险相关的实体的元信息，包括应用，服务，网络，容器，物理机等各个层次的风险实体，并将他们通过业务链路或部署拓扑关联起来。第二部：将风险知识沉淀为风险模型，一个风险模型的内容可以用一句话来概括当XXX类型的风险实体具备XXX属性时，必须有XXX，XXX。。。。的风险保障措施。这里的保障措施包括监控，巡检，核对，预案，演练等一系列能力。有了第一步，第二步获取到的信息，我们可以获取到一个相乘的笛卡尔集。在这个集合中可以清晰的看到，基于我们已有的风险知识沉淀，我们当前的技术风险保障水位如何，哪些地方是存在隐患的。针对每个风险点，风险揭示关注系统是否有完整的风险保障措施，以及对保障措施不完整的风险点应当如何处理等问题。风险揭示为一线风险防控人员包括业务负责人和架构师等都提供了监控视角，以评估系统的风险防控能力，应对当前系统的风险防控问题。总的来说，将风险防控经验沉淀为风险模型，辅以完善的系统元信息和保障机制，风险揭示平台提高了系统发现风险的能力。

风险处理

风险处理平台对接各种监控系统获取监控报警信息，再将收集到的监控信息聚合为风险事件。对于业务报警信息或单机报警信息，在聚合为风险事件后，处理平台提供标准的分析引擎（同时支持自定义引擎）帮助提供异常链路，相关变更，主成分等各种辅助定位信息。在有了对应的信息后，给用户推送自动的应急自愈预案，或手工的业务应急预案。最后，在问题解决后对整个故障进行复盘，将一些新产生的风险知识沉淀到风险基线中去，最终实现闭环。

变更管控

蚂蚁金服的内部统计数据显示，80%的系统生产故障都来自于代码变更，因此变更管控对技术风险防控而言至关重要。大规模系统内往往包含着几十乃至上百个变更来源，一旦线上发生问题，很难第一时间找到对应的变更，变更本身的质量也很难有效控制住。变更管控平台利用变更接入API整合所有系统变更，使变更可见。同时，变更管控平台还提供了变更编排，变更灰度检查，变更预检，变更结果监控等能力。确保所有生产变更都符合可灰度，可监控，可回滚的三板斧原则。同时，通过提供变更关联，以及变更回滚来加快线上问题处理速度。

其他SaaS服务

上面所讲的整体体系，大家可能会感觉特别重，整个体系实施起来的组织成本，技术成本都还是比较高的。这点上确实如此，要想系统性的对技术风险进行托底保障，确实需要一套相对比较重的体系和机制来。对于一些小型企业，或者说想解决一些特定领域的问题的客户，技术风险防控平台还提供了一些轻量级的SaaS服务，包括全链路压测、资金安全监控、流量仿真测试、高可用巡检以及智能监控等。这些服务都可以在蚂蚁金融科技的公有云或专有云平台上轻松获取，快速提升某一方面的能力。

四、蚂蚁金服技术风险防控能力实践

下图是我这边摘抄出来的一些内部运行数据，可以让大家更有体感的去感受蚂蚁金服技术风险保障体系是怎么运作的。

第一张图是1218红蓝大攻防的数据，在蚂蚁内部，有一支专门负责搞破坏的技术蓝军，他们每天所做的事情就是不停的对系统进行攻击，注入，制造高可用和资金安全故障。以此来检验我们的发现机制，应急机制是持续有效，不断保鲜的。蚂蚁金服在执行红蓝攻防演练时做到了每5分钟产生超过500个故障场景，同时保持每周超过200次故障场景演练。

第二张图是今年双11大促前，我们所做的技术保障工作。为了应对双十一大促的流量高峰，蚂蚁金服进行了长达三个月甚至更长时间的全链路压测、预案验证以及线上巡检炎症。高频率的故障场景演习以及高时长的大促技术备战使得蚂蚁金服具有极强的防御能力。

第三张图摘自技术风险保障周报，这里能看到的是蚂蚁金服技术风险防控团队在日常工作中也不在断优化系统的风险防控能力。蚂蚁金服通过将容灾仿真演练、高可用常态演练、资金安全常态演练以及自愈检查等纳入每周，每天都要做的事情，以此保证蚂蚁金服系统能够持续稳定安全地运行。