服务稳定性机制建设

一 概述

平台架构团队稳定性建设思路包括了3大技术要素：合适的系统架构和实现、完备的团队研发运维流程机制、技术同学良好线上意识和能力，以及1个业务要素：良好的研发项目管理。

二 合适的系统架构和实现

2.1 架构设计

根据不同系统业务特点、不同发展阶段（系统规模、团队规模）、不同系统指标侧重性要求等，有很多不同的架构思路和折中考量，例如存储选型、服务化治理、中间件选型、中台系统抽象等。

2.2 消除单点

从请求发起侧到服务处理返回的调用全链路的各个环节上避免存在单点

2.3 数据一致性

在分布式处理以及微服务化后，相关联的数据会存在于不同的系统之中，相关联的数据库表、数据存储、缓存等数据会因为架构设计或子系统抖动故障失败等原因，导致彼此数据出现不一致，这也是一类稳定性故障，缓存更新机制不合理也容易引发缓存和数据库之间数据不一致，一般在数据更新时考虑并发更新时缓存删除优先或固定单线程串行更新策略。

2.4 强弱依赖

当服务依赖各类微服务时，避免强依赖，强依赖的服务越少，系统整体基础稳定性就越高。部分特殊数据依赖多于逻辑依赖的系统，做去依赖架构设计也是一个思路，将依赖服务数据统一整合到自有服务的数据存储中，通过消息 或定时更新的方式更新，做到不依赖 或少依赖其他系统，进而提高稳定性。

2.5 流控降级

尽可能在对应服务出现问题时做到自动降级处理（弱依赖）或者手工降级，降级后依赖服务功能局部去掉或做合适局部提示，局部体验上有部分降级，但不会让主链路和整体功能挂掉。

2.6 容量评估

系统设计整体至少考虑应对5到10倍或近1到3年系统规模增长，要保障后续通过增加机器资源等快速方式能实现系统水平扩容。例如分库分表的规模提前设计好提前量，避免临时数据库能力不足导致需要临时重构扩容（增加分库分表以及修改路由以及迁移数据）；服务逻辑层设计持有数据状态导致无法加机器做服务层扩容。互联网产品发展变化较快，不一定会如期爆发，容量架构设计上也要注意不要过度提前设计，避免提前复杂化引发研发效率以及机器成本问题。

2.7 运维方案设计

系统要考虑持续迭代发布变更以及线上运维的诉求，做到可灰度、可监控、可回滚。

2.8 安全设计

所有资源访问需要合适鉴权，避免越权访问；防Sql注入等攻击，做参数合法性校验；资源消耗频次管控，如短信资源等；用户防骚扰，设置用户通知、弹屏等触达阈值和频次；敏感信息过滤或脱敏等。

2.9 高质量代码实现

比较通用保障方式是分支覆盖完备的单元测试 、线上引流回归测试、完备回归测试用例等测试质量保障措施。

三 完备的团队研发运维流程机制

稳定性涉及团队所有不同水平同学、所有系统、研发所有环节、线上时时刻刻，单个同学是无法保障好的，必须建立团队流程机制来可持续保障。

3.1 技术Review

不同体量设计安排经验更加丰富同学Review，架构师、主管定期系统整体Review等。

3.2 代码CodeReview

3.3 单元测试

3.4 回归测试

持续积累回归用例，在上线前和上线后执行回归动作；上线前线上引流测试也是一种模拟测试方式

3.5 发布机制

上线过程要做到分批、灰度、支持快速回滚、线上分批观察（日志确认）、线上回归等核心动作。

3.6 应急响应机制

3.7 定期排查线上隐患

定期做线上走查和错误日志治理、告警治理，确保线上小的隐患机制化发现和修复。

3.8 用户问题处理机制

日清、周清

3.9 线上问题复盘机制

天内、周内问题及时复盘

3.9 日常演练机制

预案演练，模拟线上故障的不通知的突袭演练提升团队线上问题应对能力。

四 技术同学良好的线上意识和能力

人的意识是最重要的，专业能力可以锻炼培养。如果意识不足或松懈，好的能力以及机制流程也会形同虚设。

永远要对敬畏线上，敬畏客户体验。不因为业务繁忙、个人心情状态、团队是否重视而有变化，只要职责在，就要守护好。技术主管以及系统owner要有持续感知稳定性隐患和风险，保持锐度，集中性以及系统性查差补漏。

4.1 团队对线上敬畏的一些具体体现和要求

1. 不放过每一个报警，每个报警及时响应处理。

2. 错误日志要重视。

3. 用户反馈要重视，定位到根本原因。

4.2 能力培养

五 良好的研发项目管理

从经验看，线上系统大部分故障是由新的变更引入和触发的，变更是业务和产品迭代演进方式，因此不可能没有变更，但我们可以对变更项目做合适质量管理，进而有效提高线上稳定性。

项目管理的四要素：范围、时间、质量、成本，形成项目质量管理的铁三角，一个变动，影响其他要素。

成功的项目取决于三个阶段：

1. 开始前必须“了解什么是业务方的成功”，只有业务方成功了项目才能成功。----理解业务方真正的需求

2. 项目执行中按要求完成承诺的工作。----兑现承诺，赢得业务方信任。

3. 项目结束后“帮助业务方实现价值”，----只有业务方说项目成功了才是真正的成功。