阿里妹导读：双11的完美收官，2684亿的销售奇迹及顺滑极致的客户体验让双11背后的技术再次被推到风头浪尖。而双11技术热点话题，不得不提集团核心系统100%上云这一技术创举。
作为集团上云的底座产品，ECS承担了集团上云基础设施的重任，对如何保障集团上云的极致稳定性及性能需求，弹性计算管控团队做了长期的探索与实践，竹涧作为SRE参与了这场“革命”，接下来他将分享ECS管控SRE在落地稳定性体系建设中的探索及背后的思考。
前言SRE是什么？
SRE（Site Reliability Engineering）即网站可靠性工程，提及SRE很多人会联想到运维工程师、系统工程师，其实不然，SRE本质上仍然是软件工程师，下面我们从SRE的发展历史展开来进行介绍。SRE最早在十多年前Google提出并应用，近几年逐步在国内外TOP互联网公司都开始广泛应用。据笔者了解业界SRE落地成功的权威有Google、Netflix等，前者缔造了SRE，并奠定了其权威的地位，而后者将SRE的实践做到了极致，据官方曝露的信息，Netflix仅有的个位数的Core SRE支持了190个国家、数亿用户、数万微服务实例业务规模的运维。近几年随着DevOps的发展，SRE开始被大家熟知，国内的一线互联网公司如BAT、美团也都逐步从组织架构、招聘上均有体现。以阿里为例，不同的BU均有设置SRE团队，然而在不同的部门，SRE的职责划分却不尽相同，那么SRE究竟在做什么？
SRE的职责
SRE主要负责Google所有核心业务系统的可用性、性能、容量相关的事情，根据《Site Reliability Engineering 》一书提及的内容，笔者做简单汇总，Google SRE的工作主要包括但不限于如下：
- 基础设施容量规划
- 生产系统的监控
- 生产系统的负载均衡
- 发布与变更工程管理
- on-call（轮值） 与 Firefighting（紧急故障救火）
- 与业务团队协作，共同完成疑难问题的处理
- ...
而在国内，非常多的SRE部门与传统运维部门职责类似，本质来说负责的是互联网服务背后的技术运维工作。区别于传统的运维SRE，如何在业务研发团队落地SRE，我们做了一年多的探索与实践，笔者认为业务团队SRE的核心是：以软件工程的方法论重新定义研发运维，驱动并赋能业务演进。下文将重点介绍弹性计算落地SRE的一些实践及背后的思考。
一、为何要成立SRE？
面临的挑战
ECS作为阿里云最核心的云产品，对内承担了集团上云、云产品On ECS的重任，是阿里云经济体的基础设施；对外作为亚洲最大的云计算厂商，服务着遍布全球的大中小客户（包括各种专有域、专有云），而ECS管控作为核心调度大脑，重要性不言而喻。随着集团上云、云产品On ECS的进程加速，ECS的OpenAPI调用量达到了数亿/日，ECS峰值创建量达到了 百万/日，ECS管控调度系统在容量规模、极致性能、高可用性等方面，面临着一系列挑战：
- 数据库瓶颈，顶配数据库空间仍然无法支撑业务半年发展。
- 慢SQL数量爆发式增长，应用稳定性岌岌可危。
- 全链路预警信息最多每天200 ，系统隐患逐步暴雷。
- 工作流框架使用面临瓶颈，无法支撑业务三个月的业务体量，人工运维风险极高。
- 人工运维频率高，研发幸福感下降。
- 长尾请求严重影响服务质量，5XX错误持续走高，影响客户体验。
- 不一致性资源长期无法收敛，资损无法解决。
- ...
SRE应运而生
如何在保障业务高速发展的同时，构建系统高可用的稳定性体系，同时在性能与容量上支撑业务未来3-5年的发展是团队面临的重大挑战。在SRE团队成立之前ECS管控团队是按照业务域进行的团队划分如实例、存储、镜像、网络、体验、ESS、ROS等。而在上述组织架构下研发团队可以在垂直领域做到精深，但团队整体会缺少顶层的视角，很难从局部看到整体，进而看到全局。康维定律指出 “设计系统的架构受制于产生这些设计的组织的沟通结构”，简单来说可以理解为：组织架构=系统架构，当我们系统稳定性体系需要跨业务团队的顶层视角来构建的时候，最好的保障就是组织架构的落地，ECS SRE团队应运而生。
二、SRE做了什么？
前文简单介绍了Google SRE团队的职责包括容量规划、分布式系统监控、负载均衡、服务容错、on-call、故障应急、业务协同支持等，同时也简单描述了国内偏系统运维的SRE团队。而ECS SRE落地的探索过程中，吸取业界优秀经验的同时也结合ECS团队的业务及团队特色形成了一套独有的方法论及实践体系。对于此，笔者的观点是：没有放之四海而皆准的标准，需要我们不断探索的是与“当下、业务、团队“契合的方案，古语谓之“天时、地利、人和”。下文将整体上介绍ECS SRE团队在稳定性体系建设上所做的一些事情。
ECS SRE体系大图
2.1 容量与性能
前文提到ECS的OpenAPI调用量达到数亿/日，ECS创建峰值达到了百万/日，在此背景下，管控服务的容量与性能面临严峻问题，比如数据库容量面临枯竭、服务长尾请求频现等。随着集团上云、云产品On ECS的演进需求，以及整个云原生大环境的高歌猛进，未雨绸缪已然变成了迫在眉睫。以ECS管控核心的工作流引擎为例，在我们业务体量快速增长的背景下，工作流任务单表一个月的数据就达到了3T ，这意味即使是顶配数据库也无法支撑业务数月的发展。除了工作流，核心的订单、订购、资源表均面临相同问题，如何在业务高速发展的同时，保障业务延续性是我们面临的头号问题。为了解决当下的容量与性能问题，同时面向未来扩展，我们针对ECS自研的基础组建包括工作流引擎、幂等框架、缓存框架、数据清理框架等进行了升级改造，为了后续可以赋能给其它云产品或者团队使用，所有的基础组件全部通过二方包标准输出。
