正文：

从2010年支撑双十一最高交易峰值2万笔/分钟到2015年双十一的8.59万笔/秒，蚂蚁金服在技术架构和运维体系方面不断摸索实践所取得的成果。在这个过程中，以持续技术演进和创新来支撑互联网金融业务的飞速发展，服务互联网金融生态伙伴，助力更多中小型金融机构成功向新金融转型发展和创新，是蚂蚁金服在技术持续发展道路上所坚持的愿景。

蚂蚁金服长期致力于技术运维体系建设，有效保障历年双11的平稳运行，在大促当天业务量年年翻倍的基础上，持续保持系统可靠安全、无资金差错和顺畅的用户体验。兹通过本文就“互联网IT运维体系”这一主题，和各位致力于金融业IT信息化建设的同行朋友们分享蚂蚁金服在该领域的一些实践经验，以抛砖引玉互通有无。

蚂蚁金服整体运维体系构成

蚂蚁金服的运维体系由三个主要版块构成：运维架构、运维平台、组织机制 。

如下图所示：

通过一系列相互支持的分层元素的有机结合，形成一个完整的运维体系，来保障互联网金融业务的连续性。

(1)运维架构：奠定了架构基础，作用于IaaS层，目的在于通过一定的架构设计，使得基础设施能够达到高扩展性和具备快速容灾的能力；目前蚂蚁金服整体运维架构，采用的是自研的“异地多活架构”，与传统的“两地三中心”部署架构有所不同。

(2)运维平台：是互联网金融运维的重点设施。为了具备高效、安全、智能的系统运维能力，提高运维效率和保障系统稳定，蚂蚁金服基于运维平台化、数据化的设计理念，集合大数据计算和云计算的能力，形成了可控的金融级运维能力。其中包括金融安全风险控制能力、金融级业务连续性自动化保障能力等，并整体上形成了蚂蚁金融云PaaS解决方案。

(3)组织机制：作为运维体系的重要组成，组织机制保障了在运维过程中能够充分发挥运维架构和运维平台的强大合成能力，达成系统持续可用的最佳状态。

下面将结合双11大促的具体应用场景从三方面进行介绍：

1.“异地多活”的运维架构；

2.  金融级业务连续性与自动化保障；

3.  业务连续性能力的组织机制保障   。

“异地多活”的运维架

蚂蚁金服的运维架构定义了基础设施和应用系统等在IDC上的部署架构。随着蚂蚁金服业务的快速发展，传统以IDC为基础运维单元的“两地三中心”运维架构已经很难满足需求。当前蚂蚁金服已经演化形成“异地多活”的运维架构，以单元化机房（后面简称为LDC）为基础运维单元，以满足快速发展的互联网金融业务对基础设施扩展和容灾的高时效性、金融级安全性要求。

传统运维架构的部署模式，主要面临以下三个问题：

1、基于IDC的运维部署管理模式，在系统规模越来越大、复杂度越来越高的情况下，无论是网络、DB还是应用层面，其伸缩性能力无法持续提升，很难匹配各个层面的容量增长，将无法满足业务快速发展的要求。

如：“在应用服务器完成扩容之后，发现DB连接数和事务数又成为了瓶颈；等DB完成扩容，又发现网络带宽已经不够，需要对网络带宽进行扩容”；“当应用扩展到一定程度，DB的连接数成为突出瓶颈，对于传统的所有应用连接到一个DB分库上的架构部署模式，这个问题十分棘手”以上所面临的挑战，推进蚂蚁金服的运维架构向可按更小单元维度扩展的更优可伸缩方案演化。

2、对单元进行标准化建设的过程，即是对整体运维架构进行标准化的过程。单元标准化，需要保障每个单元的内部设施必须完全一致，标准化、可管理、可复制，而如何屏蔽各个IDC自身的基础设施差异性，是其中的一大挑战，这对整体运维管理提出了更高的要求。

3、传统IDC架构只能实现“两地三中心”的容灾架构，该架构模式下，异地容灾系统一般是“冷”的，其备份系统的功能完备性和切换时长均很难保障和控制，投入了大量建设成本，但可能会陷入“有而不敢用”的怪圈。在飞速发展的互联网金融应用场景下，要求运维架构上突破“两地三中心”的传统模式，向N+1“多活”的灾备方案演进，进一步提升故障恢复的体系性能力。

针对以上挑战和需求，蚂蚁金服提出了“LDC”架构，其核心思想是：把数据水平拆分的思路，向上提升到接入层、终端层，从接入层开始，把原来部署在一个IDC中的系统集群，进一步分成多个更细粒度的部署单元。该部署单元有以下三个特性：

1. 每个单元对外是封闭的，在一个单元内的系统调用链路和各类存储访问是局部化在本单元内的；

2. 每个单元的实时数据是独立不共享的；会员或配置类信息等对延时性要求不高的数据全局共享；

3. 单元间的通信统一管控，尽量以异步化消息进行通信；同步调用则通过单元间代理方案实现。

该架构解决了以下四个关键问题：

1. 由于尽量减少了跨单元交互和使用异步化，使得异地部署成为可能。整个系统的水平可伸缩性大大提高，不再依赖同城IDC；

2. 可以实现N+1的异地灾备策略，大大缩减灾备成本，同时确保灾备设施真实可用；

3. 整个系统已无单点存在，大大提升了整体的高可用性；同城和异地部署的多个单元可用作互备的容灾设施，通过运维管控平台进行快速切换，有机会实现100%的持续可用率；

4. 该架构下业务级别的流量入口和出口形成了统一的可管控、可路由的控制点，整体系统的可管控能力得到很大提升。基于该架构，线上压测、流量管控、灰度发布等以前难以实现的运维管控模式，现在能够十分轻松地实现。

2013年蚂蚁金服完成了同城LDC的落地，并顺利通过了2013年大促的考验。

2015年在同城LDC架构的基础上，进一步升级完成“异地多活架构”并成功支撑了2015年大促的全天平稳运行。

“异地多活架构”是指基于LDC的扩展能力，在不同地域的IDC中部署LDC单元，并且每个LDC单元都是“活”的，是真正承接线上真实业务流量的，在发生故障时，可以进行LDC单元之间的快速切换。

这比传统的“两地三中心”架构有更好的业务连续性保障。“异地多活架构”下，一个LDC对应的灾备LDC是一个“活”的LDC，日常就在承接真实业务流量，其稳定性和业务的正确性是一直被确保的。

以下是蚂蚁金服“异地多活架构”示意图：

除了具备更快速的故障应急隔离和恢复能力之外，基于LDC架构，蚂蚁金服还具备了“蓝绿发布”和“灰度发布”的可靠变更验证能力。在单个LDC单元内部，又分成A /B两个逻辑组，A/ B组部署的系统链路是完全相同的。日常情况下，调用请求按照对等概率随机路由到A组或B组 。当开启蓝绿发布模式时，上层路由组件会调整路由计算策略，隔离A组与B组之间的调用，A组内应用访问封闭在A组内，而不会去访问B组。

以上粗略概况介绍了蚂蚁金服的底层运维架构，对应于IaaS层次，重点阐述了从传统IDC部署架构模式到基于LDC的“异地多活”架构的升级演进。下面将基于运维架构，介绍运维平台的部分，即金融云PaaS层次。

金融级业务连续性与自动化保障

在2015年双十一当天，蚂蚁金服的支付峰值达到8.59万笔/秒，其中业务上关于支付工具和支付场景的规则达数百种，涉及的安全规则达上万种。不难想象，为了支持这些业务规模，需要管控的运维设备规模和程序代码变更频次的规模将是十分巨大的。（蚂蚁金服的十几个业务部门共计数百个业务，每周发一个版本，双11大促准备期间的频率更高）。

按照传统的方式很难高效、高质量地管理规模如此庞大的复杂系统，解决方案便是通过运维平台的建设，通过提供更高效、更安全、更智能的运维能力赋能于运维工作，从而支撑业务的快速稳定发展。

1. 高效 : 通过运维工作的平台化来提高运维效率。如系统监控平台、变更管控平台、动态资源管控平台、调度中心、注册中心等。

2. 安全： 基于自动业务验证平台和大数据运算规则，保障系统运行的稳定性与正确性。如数据核对中心、依赖管控平台、容量检测管控平台等。

3. 智能：基于大数据的分析和规则计算，进行智能化的运维管控。如自动故障分析处理系统、容量自动探测扩容系统等。

下面通过大促中的2个场景，也是日常运维过程中常见的两个场景（集群容量管理和故障应急处理），来整体介绍运维平台这三个特性的具体体现。

场景一（自动化容量管理）：通过自动化的全链路压测、自动化的容量模型计算、自动化链路收集、自动化的扩容来实现日常的系统容量管理。

大致的步骤如下：

(1) 首先，通过“全业务路径压测”的方式，探测系统的容量瓶颈点。基于 LDC架构，在全链路压测之前，为每个LDC单元创建“影子LDC”，其数据与提供线上服务的LDC单元天然隔离，但充分利用了真实服务器集群的容量能力，可以有效的对线上实际容量进行探测验证。

(2) 通过基于大数据分析的监控系统，动态收集系统的运行时性能指标。

(3) 根据业务链路和容量模型，进行容量的瓶颈点分析。

(4) 弹性伸缩，进行扩容/缩容：对于内部系统，会计算出最后实际需要扩容的容量，通过PaaS平台，一键进入扩容流程，经过审核后，自动进行系统弹性扩容。如果是合作伙伴的瓶颈，会进行流量控制，并且通知合作伙伴扩容。

在本场景中，通过应用大数据和智能决策技术，能够高效、安全完成弹性容量管理工作，实现精益化运维。

场景二（自动故障处理）：当故障发生时，监控系统通过对系统指标的监控，判定出受影响的业务和相关系统链路；通过大数据计算找到故障根因；结合变更和应急预案，直接提示应急方案，直至最后联动到应急平台，自动执行应急预案。

大致步骤如下：

（1）通过业务指标监控，快速发现有错误的业务；

（2）根据各个维度指标的计算，判定业务SLA的损失量是否达到需要启动应急预案的级别；

（3）根据业务管控策略配置，自动通知（旺旺、短信、电话等方式）相关人员上线进行应急处理；

（4）运维平台根据业务链路上系统依赖情况的梳理，绘制系统依赖图；根据系统链路图、错误数据、系统响应时间等数据，智能判断出错误源头，并根据变更管控信息，判断是否由于变更操作（线上发布、数据变更、网络变更、动态开关推送等）引起；

（5）根据变更信息和故障设备的应急策略，智能决策应急方案，发起人工介入审核应急处理流程，或者自动启动应急预案处理故障。

通过运维平台的建设，能够高效、高质量地完成复杂的应急工作，并为知识积累提供载体，使运维质量和效率不再依赖于个人的经验和智慧，使所有运维人员都可以胜任高效的日常运维。

业务连续性能力的组织机制保障

在组织机制保障，蚂蚁金服构建了三道信息科技风险管理防线。

除此之外，蚂蚁金服还根据互联网金融的人员、组织特征，构建了多层次的组织机制保障体系，以保障整体架构规划实施、制度规范能够很好地在一线团队落地，保障从规划到执行的高质量落地；并且一线团队的实际问题可以反馈到上层架构组织和管理层，反作用于运维架构和运维平台的持续优化发展，进一步推进系统架构和运维水平向更高级别演进发展。

未来是云时代

随着业务和运维架构平台的不断发展，除了本身平台能力朝着更高效、更安全、更智能方向提升之外，还尝试把运维平台和人员组织进行“云”化，能够快速支持蚂蚁金服集团内部业务发展，为业务团队快速具备DevOps运维能力赋能。

蚂蚁金服在精粹提炼多年技术沉淀的过程中，研发了“蚂蚁金融云”技术平台。该平台深度浓缩了蚂蚁金服对未来金融系统IT运维发展方向的沉淀总结。整个平台体系从应用运行时、弹性服务、基础服务、交付管理等几个方面，对整体从研发到运维的技术平台进行整合。   

该平台不仅为研发人员提供了一套标准研发模型，也为运维人员提供了一套标准运维模型，这套基于金融云技术的体系，使得架构更替对研发人员更透明，也屏蔽了很多技术复杂性，让整体架构更容易管控和进行可靠运维，大大提高了对创新业务的快速支撑能力。

这一技术平台的强大支撑，在蚂蚁的理财业务、保险业务、芝麻信用、网商银行等多个创新区域得到了验证。通过基于“蚂蚁金融云”的运维体系，帮助我们在快速创新的过程中不断降低成本。随着蚂蚁金服“互联网推进器”计划的推出和实施，蚂蚁金服希望在5年内助力1000家中小型金融机构向新金融转型升级。

互联网金融IT系统的运维建设之路，后续期待和各位同行更多的交流和一起大力推进发展

（readygo原创）

正文：

从2010年支撑双十一最高交易峰值2万笔/分钟到2015年双十一的8.59万笔/秒，蚂蚁金服在技术架构和运维体系方面不断摸索实践所取得的成果。在这个过程中，以持续技术演进和创新来支撑互联网金融业务的飞速发展，服务互联网金融生态伙伴，助力更多中小型金融机构成功向新金融转型发展和创新，是蚂蚁金服在技术持续发展道路上所坚持的愿景。

蚂蚁金服长期致力于技术运维体系建设，有效保障历年双11的平稳运行，在大促当天业务量年年翻倍的基础上，持续保持系统可靠安全、无资金差错和顺畅的用户体验。兹通过本文就“互联网IT运维体系”这一主题，和各位致力于金融业IT信息化建设的同行朋友们分享蚂蚁金服在该领域的一些实践经验，以抛砖引玉互通有无。

蚂蚁金服整体运维体系构成

蚂蚁金服的运维体系由三个主要版块构成：运维架构、运维平台、组织机制 。

如下图所示：

通过一系列相互支持的分层元素的有机结合，形成一个完整的运维体系，来保障互联网金融业务的连续性。

(1)运维架构：奠定了架构基础，作用于IaaS层，目的在于通过一定的架构设计，使得基础设施能够达到高扩展性和具备快速容灾的能力；目前蚂蚁金服整体运维架构，采用的是自研的“异地多活架构”，与传统的“两地三中心”部署架构有所不同。

(2)运维平台：是互联网金融运维的重点设施。为了具备高效、安全、智能的系统运维能力，提高运维效率和保障系统稳定，蚂蚁金服基于运维平台化、数据化的设计理念，集合大数据计算和云计算的能力，形成了可控的金融级运维能力。其中包括金融安全风险控制能力、金融级业务连续性自动化保障能力等，并整体上形成了蚂蚁金融云PaaS解决方案。

(3)组织机制：作为运维体系的重要组成，组织机制保障了在运维过程中能够充分发挥运维架构和运维平台的强大合成能力，达成系统持续可用的最佳状态。

下面将结合双11大促的具体应用场景从三方面进行介绍：

1.“异地多活”的运维架构；

2.  金融级业务连续性与自动化保障；

3.  业务连续性能力的组织机制保障   。

“异地多活”的运维架

蚂蚁金服的运维架构定义了基础设施和应用系统等在IDC上的部署架构。随着蚂蚁金服业务的快速发展，传统以IDC为基础运维单元的“两地三中心”运维架构已经很难满足需求。当前蚂蚁金服已经演化形成“异地多活”的运维架构，以单元化机房（后面简称为LDC）为基础运维单元，以满足快速发展的互联网金融业务对基础设施扩展和容灾的高时效性、金融级安全性要求。

传统运维架构的部署模式，主要面临以下三个问题：

1、基于IDC的运维部署管理模式，在系统规模越来越大、复杂度越来越高的情况下，无论是网络、DB还是应用层面，其伸缩性能力无法持续提升，很难匹配各个层面的容量增长，将无法满足业务快速发展的要求。

如：“在应用服务器完成扩容之后，发现DB连接数和事务数又成为了瓶颈；等DB完成扩容，又发现网络带宽已经不够，需要对网络带宽进行扩容”；“当应用扩展到一定程度，DB的连接数成为突出瓶颈，对于传统的所有应用连接到一个DB分库上的架构部署模式，这个问题十分棘手”以上所面临的挑战，推进蚂蚁金服的运维架构向可按更小单元维度扩展的更优可伸缩方案演化。

2、对单元进行标准化建设的过程，即是对整体运维架构进行标准化的过程。单元标准化，需要保障每个单元的内部设施必须完全一致，标准化、可管理、可复制，而如何屏蔽各个IDC自身的基础设施差异性，是其中的一大挑战，这对整体运维管理提出了更高的要求。

3、传统IDC架构只能实现“两地三中心”的容灾架构，该架构模式下，异地容灾系统一般是“冷”的，其备份系统的功能完备性和切换时长均很难保障和控制，投入了大量建设成本，但可能会陷入“有而不敢用”的怪圈。在飞速发展的互联网金融应用场景下，要求运维架构上突破“两地三中心”的传统模式，向N+1“多活”的灾备方案演进，进一步提升故障恢复的体系性能力。

针对以上挑战和需求，蚂蚁金服提出了“LDC”架构，其核心思想是：把数据水平拆分的思路，向上提升到接入层、终端层，从接入层开始，把原来部署在一个IDC中的系统集群，进一步分成多个更细粒度的部署单元。该部署单元有以下三个特性：

1. 每个单元对外是封闭的，在一个单元内的系统调用链路和各类存储访问是局部化在本单元内的；

2. 每个单元的实时数据是独立不共享的；会员或配置类信息等对延时性要求不高的数据全局共享；

3. 单元间的通信统一管控，尽量以异步化消息进行通信；同步调用则通过单元间代理方案实现。

该架构解决了以下四个关键问题：

1. 由于尽量减少了跨单元交互和使用异步化，使得异地部署成为可能。整个系统的水平可伸缩性大大提高，不再依赖同城IDC；

2. 可以实现N+1的异地灾备策略，大大缩减灾备成本，同时确保灾备设施真实可用；

3. 整个系统已无单点存在，大大提升了整体的高可用性；同城和异地部署的多个单元可用作互备的容灾设施，通过运维管控平台进行快速切换，有机会实现100%的持续可用率；

4. 该架构下业务级别的流量入口和出口形成了统一的可管控、可路由的控制点，整体系统的可管控能力得到很大提升。基于该架构，线上压测、流量管控、灰度发布等以前难以实现的运维管控模式，现在能够十分轻松地实现。

2013年蚂蚁金服完成了同城LDC的落地，并顺利通过了2013年大促的考验。

2015年在同城LDC架构的基础上，进一步升级完成“异地多活架构”并成功支撑了2015年大促的全天平稳运行。

“异地多活架构”是指基于LDC的扩展能力，在不同地域的IDC中部署LDC单元，并且每个LDC单元都是“活”的，是真正承接线上真实业务流量的，在发生故障时，可以进行LDC单元之间的快速切换。

这比传统的“两地三中心”架构有更好的业务连续性保障。“异地多活架构”下，一个LDC对应的灾备LDC是一个“活”的LDC，日常就在承接真实业务流量，其稳定性和业务的正确性是一直被确保的。

以下是蚂蚁金服“异地多活架构”示意图：

除了具备更快速的故障应急隔离和恢复能力之外，基于LDC架构，蚂蚁金服还具备了“蓝绿发布”和“灰度发布”的可靠变更验证能力。在单个LDC单元内部，又分成A /B两个逻辑组，A/ B组部署的系统链路是完全相同的。日常情况下，调用请求按照对等概率随机路由到A组或B组 。当开启蓝绿发布模式时，上层路由组件会调整路由计算策略，隔离A组与B组之间的调用，A组内应用访问封闭在A组内，而不会去访问B组。

以上粗略概况介绍了蚂蚁金服的底层运维架构，对应于IaaS层次，重点阐述了从传统IDC部署架构模式到基于LDC的“异地多活”架构的升级演进。下面将基于运维架构，介绍运维平台的部分，即金融云PaaS层次。

金融级业务连续性与自动化保障

在2015年双十一当天，蚂蚁金服的支付峰值达到8.59万笔/秒，其中业务上关于支付工具和支付场景的规则达数百种，涉及的安全规则达上万种。不难想象，为了支持这些业务规模，需要管控的运维设备规模和程序代码变更频次的规模将是十分巨大的。（蚂蚁金服的十几个业务部门共计数百个业务，每周发一个版本，双11大促准备期间的频率更高）。

按照传统的方式很难高效、高质量地管理规模如此庞大的复杂系统，解决方案便是通过运维平台的建设，通过提供更高效、更安全、更智能的运维能力赋能于运维工作，从而支撑业务的快速稳定发展。

1. 高效 : 通过运维工作的平台化来提高运维效率。如系统监控平台、变更管控平台、动态资源管控平台、调度中心、注册中心等。

2. 安全： 基于自动业务验证平台和大数据运算规则，保障系统运行的稳定性与正确性。如数据核对中心、依赖管控平台、容量检测管控平台等。

3. 智能：基于大数据的分析和规则计算，进行智能化的运维管控。如自动故障分析处理系统、容量自动探测扩容系统等。

下面通过大促中的2个场景，也是日常运维过程中常见的两个场景（集群容量管理和故障应急处理），来整体介绍运维平台这三个特性的具体体现。

场景一（自动化容量管理）：通过自动化的全链路压测、自动化的容量模型计算、自动化链路收集、自动化的扩容来实现日常的系统容量管理。

大致的步骤如下：

(1) 首先，通过“全业务路径压测”的方式，探测系统的容量瓶颈点。基于 LDC架构，在全链路压测之前，为每个LDC单元创建“影子LDC”，其数据与提供线上服务的LDC单元天然隔离，但充分利用了真实服务器集群的容量能力，可以有效的对线上实际容量进行探测验证。

(2) 通过基于大数据分析的监控系统，动态收集系统的运行时性能指标。

(3) 根据业务链路和容量模型，进行容量的瓶颈点分析。

(4) 弹性伸缩，进行扩容/缩容：对于内部系统，会计算出最后实际需要扩容的容量，通过PaaS平台，一键进入扩容流程，经过审核后，自动进行系统弹性扩容。如果是合作伙伴的瓶颈，会进行流量控制，并且通知合作伙伴扩容。

在本场景中，通过应用大数据和智能决策技术，能够高效、安全完成弹性容量管理工作，实现精益化运维。

场景二（自动故障处理）：当故障发生时，监控系统通过对系统指标的监控，判定出受影响的业务和相关系统链路；通过大数据计算找到故障根因；结合变更和应急预案，直接提示应急方案，直至最后联动到应急平台，自动执行应急预案。

大致步骤如下：

（1）通过业务指标监控，快速发现有错误的业务；

（2）根据各个维度指标的计算，判定业务SLA的损失量是否达到需要启动应急预案的级别；

（3）根据业务管控策略配置，自动通知（旺旺、短信、电话等方式）相关人员上线进行应急处理；

（4）运维平台根据业务链路上系统依赖情况的梳理，绘制系统依赖图；根据系统链路图、错误数据、系统响应时间等数据，智能判断出错误源头，并根据变更管控信息，判断是否由于变更操作（线上发布、数据变更、网络变更、动态开关推送等）引起；

（5）根据变更信息和故障设备的应急策略，智能决策应急方案，发起人工介入审核应急处理流程，或者自动启动应急预案处理故障。

通过运维平台的建设，能够高效、高质量地完成复杂的应急工作，并为知识积累提供载体，使运维质量和效率不再依赖于个人的经验和智慧，使所有运维人员都可以胜任高效的日常运维。

业务连续性能力的组织机制保障

在组织机制保障，蚂蚁金服构建了三道信息科技风险管理防线。

除此之外，蚂蚁金服还根据互联网金融的人员、组织特征，构建了多层次的组织机制保障体系，以保障整体架构规划实施、制度规范能够很好地在一线团队落地，保障从规划到执行的高质量落地；并且一线团队的实际问题可以反馈到上层架构组织和管理层，反作用于运维架构和运维平台的持续优化发展，进一步推进系统架构和运维水平向更高级别演进发展。

未来是云时代

随着业务和运维架构平台的不断发展，除了本身平台能力朝着更高效、更安全、更智能方向提升之外，还尝试把运维平台和人员组织进行“云”化，能够快速支持蚂蚁金服集团内部业务发展，为业务团队快速具备DevOps运维能力赋能。

蚂蚁金服在精粹提炼多年技术沉淀的过程中，研发了“蚂蚁金融云”技术平台。该平台深度浓缩了蚂蚁金服对未来金融系统IT运维发展方向的沉淀总结。整个平台体系从应用运行时、弹性服务、基础服务、交付管理等几个方面，对整体从研发到运维的技术平台进行整合。   

该平台不仅为研发人员提供了一套标准研发模型，也为运维人员提供了一套标准运维模型，这套基于金融云技术的体系，使得架构更替对研发人员更透明，也屏蔽了很多技术复杂性，让整体架构更容易管控和进行可靠运维，大大提高了对创新业务的快速支撑能力。

这一技术平台的强大支撑，在蚂蚁的理财业务、保险业务、芝麻信用、网商银行等多个创新区域得到了验证。通过基于“蚂蚁金融云”的运维体系，帮助我们在快速创新的过程中不断降低成本。随着蚂蚁金服“互联网推进器”计划的推出和实施，蚂蚁金服希望在5年内助力1000家中小型金融机构向新金融转型升级。

互联网金融IT系统的运维建设之路，后续期待和各位同行更多的交流和一起大力推进发展

（readygo原创）