基础组件升级：通过对ECS管控自研的业务基础组件进行架构升级来应对业务未来的规模化发展。
- 工作流引擎：14年ECS团队自研的轻量工作流引擎，与AWS SWF类似， 18年改造后支持数亿级工作流创建，我们当前还在做一些框架可用性、容量与性能相关的优化。
- 轻量幂等框架：通过注解自定义业务幂等规则，通过轻量持久化方式支持业务幂等。
- 数据异步清理框架：通过注解配置业务数据清理策略。
- 缓存框架：通过注解支持业务定义缓存命中与失效规则，并支持批量。
性能优化：多维度的性能调优策略来提升管控整体服务的性能指标。
- JVM调优：通过不断调整优化JVM参数来减少其FGC次数及STW时间，缩短服务不可用时间，提升用户服务体验 。
- 数据缓存：核心链路多级缓存，减少数据库IO，提升服务性能。
- SQL性能调优：通过优化SQL执行效率提升业务性能。
- 核心链路RT优化：业务优化保障ECS核心创建、启动链路性能。
- API批量服务能力：批量的服务能力，提升整体服务性能。
2.2 全链路稳定性治理
稳定性体系化建设是我们在过去一年摸索中最重要的一环，对此笔者的心得是：稳定性治理一定要有全链路顶层视野，从上至下进行细分。下文将简单介绍一下ECS管控稳定性治理体系。
1）数据库稳定性治理
数据库是应用的核心命脉，对于ECS管控来说，所有的核心业务全部跑在RDS之上，如果数据库发生故障，对应用的损害无论从管控面或者数据面都是致命的。所以，SRE做的第一件事情就是守住核心命脉，对数据库稳定性进行全面的治理。首先，我们先来看一下ECS管控在规模化业务下，数据库面临的问题：
- 空间增长过快，无法支撑业务近期发展需求。
- 慢SQL频发，严重影响应用稳定性。
- 数据库变更故障率高，DDL大表变更引起的故障占比高。
- RDS性能指标异常，数据库各种性能指标异常。
- RDS报警配置混乱，报警信息存在遗漏，误报的情况。
对于数据库的问题我们的策略是数据库 业务两手抓，单纯优化数据库或者业务调优效果都不是最佳的。比如典型的数据库大表问题，占用空间大，查询慢，如果单纯从数据库层面进行空间扩容，索引优化可以解决短期问题，当业务规模足够大的时候，数据库优化一定会面临瓶颈，这个时候需要业务调优双管齐下。下面简单介绍一下优化思路：
- 数据库占用空间大问题，两个思路，降低当前数据库占用空间，同时控制数据空间增长。我们通过归档历史数据释放数据空洞来达到数据页复用，从而控制数据库磁盘空间增长；但是delete数据并不会释放表空间，为了释放已经占用大量空间的大表，我们业务上进行了改造，通过生产中间表轮转来解决。
- 慢SQL频发问题，数据库优化与业务改造两手抓。数据库层面通过索引优化来提高查询效率，同时减少无效数据来减少扫描行数；应用层面通过缓存降低数据库读次数、优化业务代码等方式减少与规避慢SQL。
- 数据库变更故障率高问题，管控流程增强，增加Review流程。DDL变更类型多，由于开发人员对数据库的专业性与敏感度不够导致数据库引发变更增多，对于这类情况，我们针对DDL变更增加了 检查项列表与评审流程，控制数据库变更风险。
- 数据库性能指标与配置问题，以项目方式推进数据库健康度提升，统一管控数据库预警配置。
- 慢SQL限流与快恢的探索。慢SQL严重情况会导致RDS整体不可用，当前我们正在探索如何通过自动/半自动化的方式限流慢SQL来保障数据库稳定性。
下图是ECS在数据库稳定性治理上的几个探索。
2）监控预警治理预警对于问题与故障的发现至关重要，尤其在规模化的分布式系统中，精准而及时的监控可以帮助研发人员第一时间发现问题，减少甚至避免故障的发生。而无效、冗余、不精确的低质量报警不仅耗时耗力，影响SRE on-call人员幸福感，同时也严重影响故障诊断。ECS管控预警质量不高的因素主要包括：
- 数量多，平均每天100 ，峰值200 ，信噪比低。
- 渠道多，大量重复报警，干扰大。
- 配置异常，存在预警丢失情况，风险高。
- 损耗人力，预警反复出现导致处理预警需要投入大量人力，人效低。
- 黑屏操作风险高，大量黑屏操作增加生产运维风险，风险高。
针对上述情况，我们的策略是针对预警进行体系化整理，实现预警的真实性、准确性、精确性、高质量。我们的打法大概分了以下几个步骤：
- 删除无效报警，清理监控平台历史无效的预警，提高预警真实性。
- 优化预警配置
- 统一预警接收人，保障预警只投递到正确的接收人。
- 优化预警等级，设置合理的预警级别。
- 划分预警渠道，按照预类型与严重程度进行渠道划分，如致命预警电话预警、严重预警短信预警、普通预警钉钉预警等。
- 自动化一切人肉干预的预警，反复需要人工参与解决的报警通过自动化方式来解决。比如大量业务日志导致磁盘存储空间不足，可以通过优化log rolling策略实现自动化。
3）故障诊断
关于故障恢复我们有一个1-5-10的理想模型，意思是1分钟发现问题，5分钟定位问题，10分钟恢复问题。1分钟发现问题依赖于前文提到的高质量的监控预警体系，5分钟定位问题则依赖于系统的故障诊断能力，如何基于已有的预警信息实现故障快速诊断面临一系列挑战：
- 系统调用链路长，从控制台/OpenAPI到底层虚拟化/存储，RPC链路调用链路大概有10层以上，依赖系统30 ，业务串联难度大。
- 系统间依赖复杂，ECS管控自身有多层架构，同时与集团订单、计费等系统相互依赖。
- 影响面分析困难，无法量化故障影响面。
在故障诊断体系的建设上，我们初步划分三个阶段：
- 全链路Trace模型建立，通过TraceID打通调用调用链路，实现业务串联。
- 核心应用场景故障诊断模型，针对当前业务核心链路以及以往故障的高频场景进行诊断模型训练，由点到面的突破。
- 故障影响面模型，自动分析故障影响用户、资源、资金，方便故障快速恢复及故障善后。
4）全链路SLO
没有100%可靠的系统，对于终端用户而言99.999%和100%的可用性没有本质区别。我们的目标是通过持续迭代优化保障用户99.999%的可用性服务体验，而现状是终端用户发起的行为会经过一系列中间系统，任意一个系统可靠性出现问题都会影响客户体验。而全链路各个节点的稳定性如何衡量是我们面临的问题，对此我们开始了全链路SLO体系建设，主要策略如下：
- 识别上下游依赖业务方，签订SLO协议。
- 建设全链路SLO可视化能力。
- 推进上下游依赖促成SLO达标。
5）资源一致性治理
根据分布式系统CAP原理，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）无法同时满足。ECS管控作为规模化的分布式系统面临同样的问题：资源一致性问题，具体表现在ECS、磁盘、带宽等在ECS管控、订单、计量等多个系统存在数据不一致问题。分布式系统为了保障系统可用性，通常会牺牲部分数据实时一致性，转而通过最终一致性来解决。针对ECS的技术架构及业务特性，我们对保障资源一致性的策略如下：
- 数据驱动，首先建立全链路可视化对账体系，所有不一致资源全部数据化。
- 财（钱）、产（资源）两个抓手，从资源和资损两个角度来度量一致性问题。
- 离线（T 1）与实时（一小时对账）两种方式，及时止损。
2.3 SRE流程体系建设
ECS在 近百人并行研发& 核心应用每日发布&全年数千余次发布 的背景下，可以做到故障率每年下降的关键因素之一，就是有一套相对完善的研发与变更流程保障。下文将简单介绍ECS SRE在研发与变更流程体系上所做的的一些探索。
研发流程：整个软件生命周期研发流程规范升级。1）设计流程与规范从软件工程角度来看，越早引入问题带来的人力消耗和经济损失就越小。没有被良好设计的系统后续在维护阶段投入的成本要远高于前期设计的投入。为了把控设计质量我们在设计流程与规范上做了如下探索：
- 加强前期设计，统一设计模版。（完整的设计应该包括架构设计、详细设计、测试用例、横向设计、监控预警、灰度方案、发布方案等）
- 线上（钉钉直播）& 线下并行模式进行设计评审。
2）CodeReview升级之前ECS的CodeReview主要在GitLab平台，其主要问题是gitlab与阿里内部持续集成相关组件集成不够稳定、另外无法设置准入卡点，Aone CodeReview平台很好的解决了与Aone实验室的集成问题，并且提供了代码合入的卡点配置功能，另外我们定义了一套ECS管控的CodeReview流程，如下所示：
- 统一研发规范，包括（开发环境规范、编码规范on 集团开发规约 等）。
- CodeReviw checklist
- git commit 关联issues，做到代码与需求/任务/缺陷关联，可追踪。
- 静态扫描无Block。
- UT通过率100%，覆盖率不低于主干（重点关注UT覆盖率）。
- 代码规范符合阿里巴巴代码规约。
- 业务关键点Review。
- MR要提供标准报备信息，说明变更内容。
3）全链路CI标准化我们将ECS管控所有核心应用按照标准模式统一迁移至标准CI平台，大幅提升CI成功率，减少频繁人工干预造成的人力损耗。我们的方案如下：
- 标准化CI接入方式，标准化CI pipeline：
- prepare environment
- run unit tests
- run coverage analysis
- ...
- UT并行运行模式改造，提升UT运行效率。
4）全链路日常/隔离环境打通ECS部署环境复杂度极高，具体表现在部署架构复杂、部署工具多样、依赖多（几乎依赖了集团和阿里云所有的核心中间件及应用），在近百人并行研发的模式下 稳定可靠的全链路日常环境是研发效能与质量的基础保障。全链路日常环境的改造无法一蹴而就，我们当前等构建路径大致如下：
- 全链路容器化，同时支持日常环境与隔离环境。
- 第三方服务依赖Mock。
- 全链路测试环境打通。
5）预发环境使用规范预发环境与生产环境使用相同的数据库，很容易出现预发测试影响生产服务稳定性的问题。在预发与生产无法数据隔离的情况下，我们的短期方案是通过标准化流程来提升预发布代码质量，尽可能减少或规避此类问题发生。
- 预发等同于生产，一定要在CI通过、日常基本验证通过后才可以部署预发。
- DDL及大表查询需要Review后才可以上预发，避免预发慢SQL导致RDS稳定性，进而影响生产环境。
6）FVT发布准入每天凌晨通过运行基于OpenAPI的功能性测试用例集，来验证预发布代码的稳定性，是日常发布准入最后一道防线，FVT 100%通过率极大保障了ECS核心管控每日发布的成功率。7）无人值守发布的探索当前发布模式是发布前一天晚上值班同学基于Develop分支拉取release发布分支部署预发，发布当天观察FVT 成功率100%通过后通过Aone进行分批发布，每批暂停观察业务监控、预警、错误日志，在该模式下核心应用每日发布大概占用0.5人/日。为了进一步提升人效，我们在自动化发布流程上进行来一些探索：
- 流水线自动部署预发。
- 自动发布准入校验，通过判断FVT成功率根据业务规则进行自动发布。
- 无人值守发布，理想的发布模型，持续集成及相关发布准入卡点全部通过后，自动化进行发布。
