简介：影响零碎稳定性的架构设计有哪些？一个可继续保障的研发运维流程机制是怎么的？如何造就团队技术人员的意识和能力？本文作者以团队技术负责人的视角，从三大技术因素和一个业务因素，分享在稳定性建设上的实践性思考和简要思路。心愿对同学们有所启发。

一 概述

本人以及率领的团队已经负责较多不同类型的互联网服务零碎，如几十万利用数 & 亿级流量的云计算平台、年营收将近千亿的广告零碎、亿级用户千万级日活的钉钉工作台零碎、亿级交易额的钉钉市场 & 交易系统、算法在线离线工程零碎等相干零碎或子系统，整体而言无重大故障，达到定级故障数也很少，线上稳定性保障在一个不错的水位上。阶段性总结下我从团队技术负责人视角做好稳定性建设的实践性思考和简要思路，为感兴趣的技术同学提供一个实际指南。

我的团队稳定性建设思路包含了 3 大技术因素：良好的零碎架构和实现、齐备的团队研发运维流程机制、技术同学良好意识和能力，以及 1 个业务因素：良好的研发项目管理。

二 良好的零碎架构和实现

1 架构设计

依据不同零碎业务特点、不同倒退阶段（零碎规模、团队规模）、不同零碎指标偏重性要求等，有很多不同的架构思路和折中考量，例如存储选型、服务化治理、中间件选型、中台零碎形象等。本文简要讲述会影响零碎稳定性的一些架构设计点以供参考，设计考量点具体内容可自行搜寻细看。

打消单点

从申请发动侧到服务解决返回的调用全链路的各个环节上防止存在单点（某个环节只由单个服务器实现性能），做到每个环节应用互相独立的多台服务器进行分布式解决，要针对不同稳定性要求级别和老本能力做到不同服务器规模分布式，这样就防止单个服务器挂掉引发单点故障后进而导致服务整体挂掉的危险。可能波及的环节有端动静获取资源服务(html& js & 小程序包等)、域名解析、多服务商多区域多机房 IP 入口、动态资源服务、接入路由层、服务逻辑层、任务调度执行层、依赖的微服务、数据库及消息中间件。

打消单点的策略：

• 在服务逻辑层采纳多运营商多 IP 入口、跨地 & 同地多机房部署、同机房多机器部署、分布式任务调度等策略。
• 在数据存储层采纳数据库分库分表、数据库主从备集群、KV 存储 & 音讯等分布式系统集群多正本等策略。
• 有分布式解决能力后，须要思考单个服务器故障后主动探活摘除、服务器增删能不停服主动同步给依赖方等问题，这里就需引入一些分布式中枢控制系统，如服务注册发现零碎、配置变更零碎等，例如 zookeeper 是一个经典利用于该场景的一个分布式组件。

数据一致性

在分布式解决以及微服务化后，相关联的数据会存在于不同的零碎之中，相关联的数据库表、数据存储、缓存等数据会因为架构设计或子系统抖动故障失败等起因，导致彼此数据呈现不统一，这也是一类稳定性故障。最简略的一致性，就是关系型数据库的同申请内同库相关联的多个数据表更新的一致性，这个可通过数据库的事务以及不同事务级别来保障。从架构层面，数据一致性也会依据业务特点，做强一致性、最终一致性的架构选型，不同选型依据 CAP 实践，也会带来可用性以及分区容忍性的一些折衷。

在做好 SLA 高的根底零碎选型、分布式事务中间件应用、幂等设计，针对性晋升好微服务自身 SLA 后，可依据不同数据一致性级别要求，思考通过音讯触发多零碎对账、定时调度对账、子流程失败后被动投递音讯提早重试、音讯生产失败后盘旋重试、数据库记录过程中状态后做定时调度扫描未胜利记录后重试、离线全量对账。缓存更新机制不合理也容易引发缓存和数据库之间数据不统一，个别在数据更新时思考并发更新时缓存删除优先或固定单线程串行更新策略。

简单分布式业务零碎或微服务化治理后，基于消息中间件的解耦是广泛形式，这时抉择一个确保本身不重不丢以及高 SLA 消息中间件十分重要，利用消息中间件本身的屡次盘旋重试根本能保障很高的最终一致性，数据一致性要求更高的，再配合不同级别对账机制即可。

强弱依赖梳理和降级

当服务依赖各类微服务时，防止强依赖（依赖服务挂掉会到本人服务挂掉），尽可能在对应服务呈现问题时做到主动降级解决（弱依赖）或者手工降级，降级后依赖服务性能部分去掉或做适合部分提醒，部分体验上有局部降级，但不会让主链路和整体性能挂掉。对于稳定性要求很好的要害零碎，在老本可承受的状况下，同时保护一套保障主链路可用的备用系统和架构，在外围依赖服务呈现问题能做肯定工夫周期的切换过渡（例如 mysql 故障，阶段性应用 KV 数据库等），例如钉钉 IM 音讯外围零碎就实现对数据库外围依赖实现一套肯定周期的弱依赖备案，在外围依赖数据库故障后也能保障一段时间音讯收发可用。

强依赖的服务越少，零碎整体根底稳定性就越高。局部非凡数据依赖多于逻辑依赖的零碎，做去依赖架构设计也是一个思路，将依赖服务数据对立整合到自有服务的数据存储中，通过音讯 或定时更新的形式更新，做到不依赖 或少依赖其余零碎，进而进步稳定性，但这样做也会有副作用：数据冗余可能会引发不同水平肯定工夫窗口数据不一致性。

热点或极限值解决

业务规模以及数据规模大的局部零碎，在零碎中会呈现数据热点、数据极度歪斜、大量大客户超过极限阈值应用等极限场景，例如超级大客户广告投放物料、广告点击展现数据、API 调用频次都是比一般客户大很多，如果依照客户维度分库分表，根本在物料更新、查问、报表查看等一系列的场景都可能导致单库抖动，这除了影响大客户本人外也会影响散布在该分库分表上所有一般客户。电商中极度畅销商品以及秒杀、企业 IM 中大组织群 & 大组织波及全员关注更新行为、微博等订阅类明星大 V 的信息公布等都是大量极限场景可能会引发整体零碎稳定性问题。因而，架构设计时，要剖析本人零碎中是否存在极限场景并设计对应计划做好应答。

极限场景中不同类型场景解决架构计划也不一样，可能的形式：

• 大客户从一般客户分库分表中拆出来隔离建库表，隔离享受专有资源以及独立库表拆分路由逻辑以及隔离服务逻辑计算资源；
• 大客户特定极限数据计算做预约计算以及预加载，在低峰期预约或提前优化实现；
• 秒杀零碎极限值能够思考外围逻辑简化 + 音讯解耦、同商品库存拆分独立交易、局部查问或解决 KV 存储代替关系型存储、数据提前预热加载、排队、限流策略等策略；
• 大组织 IM 场景设计适合读扩散或写扩散的策略，同时针对业务特点（不同人提早度不一样）做到不同人员体验平滑，或者为大组织或大 V 提供专属计算存储资源或专属查问更新逻辑。
• 在特定极限值零碎架构以及资源无奈满足的状况，产品侧以及技术侧要明确采纳最高阈值调用限度。

资金交易类零碎要认真思考资损的危险

交易系统对于数据准确性、一致性、资金损失等都是很敏感的，这一块在是否应用缓存、事务一致性考量、数据时延、数据不丢不重、数据精准核查和复原等须要额定架构设计考量。认真评估交易以及营销的全链路各个环节，评估其中呈现资损的可能性以及做好应答设计，例如减少多层级对账、券总额度管制、异样金额限度和报警等资损防控的考量等。不同档次不同维度不同时间延迟的对账以及预案是一个重要及时感知资损和止血的无效形式。全链路的过程数据要做好尽可能长久化和冗余备份，不便后续核查以及基于过程数据进行数据修复，同时尽量针对非凡数据失落场景提供疾速自动化修复解决预案（如交易音讯可选择性回放和基于幂等准则的从新生产）。

离线数据流

基于数据的搜寻举荐、机器学习算法零碎、数据产品等，外围性能依赖离线产出 或 增量产出数据，这类数据可能规模大、起源广、生产链路长，在整体生产和传输链路中，很容易呈现数据大量失落、局部环节失败、数据生产提早等状况，最终生产在线零碎也很难感知大量数据谬误进而导致故障。

针对离线数据流，要减少不同传输环节数据完整性校验、不同生产环节数据正确性校验、数据提早监控、数据生产失败监控、端到端数据正确性规定校验、数据谬误或提早兜底预案、数据回滚重刷工具等机制。机器学习类零碎还要思考离线特色和线上特色数据一致性，确保离线训练的模型，线上预测利用成果是统一的，因而模型上线时以及线上定期做离线和线上特色数据一致性核查。

其余异常情况解决

整体零碎架构，除了正向逻辑、性能、扩展性设计等外，要减少一个异样设计视角，穷尽思考各类异常情况以及设计应答策略。

2 容量评估设计

零碎设计整体至多思考应答 5 到 10 倍或近 1 到 3 年零碎规模增长，要保障后续通过减少机器资源等疾速形式能实现零碎程度扩容。例如分库分表的规模提前设计好提前量，防止长期数据库能力有余导致须要长期重构扩容（减少分库分表以及批改路由以及迁徙数据）；服务逻辑层设计持有数据状态导致无奈加机器做服务层扩容。互联网产品倒退变动较快，不肯定会如期暴发，容量架构设计上也要留神不要适度提前设计，防止提前复杂化引发研发效率以及机器老本问题。

针对线上流量峰值，倡议零碎常态放弃近期峰值 3 倍左右容量余量，上线前和上线后要定期做压测摸高，写流量可用影子表等形式做压测，压测可单接口以及模仿线上流量散布压测联合，依据压测后果优化架构或扩容，持续保持容量充裕。

对于可能超过零碎现有容量的突发峰值，限流策略是线上要配置的策略。入口侧入口流量调用、不同渠道服务依赖调用、对依赖服务的调用都要评估可极限调研的上限值，通过中间件等适合形式限度超过阈值调用，防止引发雪崩效应。特定业务零碎，对于超过峰值流量，能够通过音讯架构以及适合体验设计做削峰填谷。针对歹意攻打流量也要思考在入口层部署防 DDOS 攻打的流量荡涤层。

局部零碎峰值变动较大且须要继续尽可能承载保障，可思考引入弹性伸缩策略，预约 或依据流量变动触发零碎主动扩缩容，以确保以尽量小老本来自动化满足变动峰值。

3 运维方案设计

零碎要思考继续迭代公布变更以及线上运维的诉求，做到可灰度、可监控、可回滚。

可灰度保障及时在小流量状况，发现问题，防止引发大范畴故障。因而在做零碎任何变更时，要思考灰度计划，特地是大用户流量零碎。灰度形式可能有白名单用户、按用户 Id 固定划分后不同流量比例、机器分批公布、业务概念相干分组分比例（例如某个行业、某个商品、某类商品）等，灰度周期要和联合零碎危险和流量做适合设计，重要零碎灰度周期可能继续超过一周或更多。

监控项要系统性确认是否齐备以及放弃更新，可能监控项：谬误日志前端 js 谬误、用户体验到的性能和白屏率、接口成功率、依赖服务成功率、机器根底负载相干监控（CPU 利用率、cpu Load、内存、IO、网络等）、服务根底监控（端口、过程、状态探活、JVM full gc、OOM 等）、数据库负载监控、数据库慢申请、流量同比激烈变动。监控项的报警策略也要依据业务零碎特点以及监控项的特点，做不同报警策略设计，例如秒级 & 分钟级报警、错误率报警、谬误日志次数报警、间断出错报警等。外围监控可摘要一个监控大盘，一个大盘疾速判断服务稳定性状况。

可回滚：新增性能减少配置开关，当线上呈现问题时，可通过敞开性能开关，疾速下线最新降级 或局部有问题性能。针对不同出错场景，有配置驱动一些预案，例如降级对某个服务的依赖、提供适合性能保护中布告、切换到备用服务等预案，在特定问题呈现时，能够疾速做线上止损和复原。公布性能留神提前思考呈现问题时疾速回滚步骤，局部常常公布留神对回滚步骤做演练。

4 平安设计

数据以及利用平安问题一旦呈现可能很致命，肯定要加以思考。平安是一个比拟业余畛域，惯例在针对业务零碎经典平安场景做好考量的同时，尽量引入业余平安技术同学评估。所有资源拜访须要适合鉴权，防止越权拜访；防 Sql 注入等攻打，做参数合法性校验；资源耗费频次管控，如短信资源等；用户防骚扰，设置用户告诉、弹屏等触达阈值和频次；敏感信息过滤或脱敏等。

5 高质量的代码实现

适合实现和经典性实际是十分重要代码品质保障的形式，大量线上问题还是由大量代码细节考虑不周全和经验不足引发的。这方面考量不同语言都会有本人一些最佳的实际，例如 Java，能够参考《Java 开发手册》。比拟通用保障形式是分支笼罩齐备的单元测试、线上引流回归测试、齐备回归测试用例等测试品质保障措施。

三 团队研发运维流程机制

稳定性波及团队所有不同程度同学、所有零碎、研发所有环节、线上时时刻刻，单个同学是无奈保障好的，必须建设团队流程机制来可继续保障。

次要流程机制如下：

• 技术 Review：不同体量设计安顿教训更加丰盛同学 Review，架构师、主管、内部架构师的 Review、定期零碎整体 Review 等。
• 代码 Code Review：建设标准和规范，通过 CR 认证合格同学执行 code review 动作。
• 单测：不同危险的零碎设定尽量高的行笼罩 & 分支覆盖率规范，简单逻辑类谋求 100% 分支笼罩。
• 回归测试：继续积攒回归用例，在上线前和上线后执行回归动作；上线火线上引流测试也是一种模仿测试形式，端类型零碎还能够用 monkey 工具做随机化测试。
• 公布机制：设计公布准入和审批流程，确保每次上线公布都是通过精密设计和审核的，上线过程要做到分批、灰度、反对疾速回滚、线上分批察看（日志确认）、线上回归等外围动作。建设公布红线等机制，不同零碎设计适合公布时段以及公布灰度察看周期。
• 团队报警值班响应机制（报警群、短信、电话）：确保报警有适合人员即时响应解决，团队层面可定期做数据性统计通晒，同时建设主管或架构师兜底机制。
• 定期排查线上隐患：定期做线上走查和谬误日志治理、告警治理，确保线上小的隐患机制化发现和修复。例如在钉钉针对企业用户早晚顶峰的特点，设计早值班机制，用于高峰期第一工夫应急以及每天专人花肯定工夫走查线上，该机制在钉钉技术团队继续践行多年，无效发现和治理了钉钉各个线上零碎的隐患。
• 用户问题解决机制：Voc 日清、周清等。在钉钉也经验 Voc 周清到日清的继续机制精进。
• 线上问题复盘机制：天内、周内问题及时复盘，确保针对每个线上问题做零碎和团队精进。
• 代码品质抽查通晒：定期抽查团队同学代码，做评估和通晒，激励好的代码，帮忙不好代码的改善。
• 成立稳定性治理专门 topic：适合同学每周做好稳定性过程和精进。
• 定期压测机制：定期机制化执行，核查线上容量状况。
• 日常演练机制：预案演练，模仿线上故障的不告诉的突袭演练晋升团队线上问题应答能力。

流程机制要和团队同学共创达成统一后，配合建设 topic 负责人机制，对流程机制执行度和执行成果要做好过程监测和通晒，建设明确数字化规范和掂量机制（例如钉钉技术团队针对线上问题设定 1 -5-10 规范，1 分钟响应 5 分钟内定位 10 分钟内复原），同时建设对应奖惩机制。流程机制也要依据零碎状态进行精简或精进，确保流程机制可执行性和生命力。

四 技术同学意识和能力

人的意识是最重要的，业余能力能够锤炼造就。如果意识有余或松散，好的能力以及机制流程也会形同虚设。

永远要对敬畏线上，敬畏客户体验。面向线上的稳定性战术上能够基于业余度锤炼后自信，但策略和思维上必须继续如履薄冰、三省吾身。线上稳定性保障是作为技术人本人业余度的谋求和必须放弃初心，始终保持敬畏。不因为业务忙碌、集体情绪状态、团队是否器重而有变动，只有职责在，就要守护好。技术主管以及零碎 owner 要有继续感知稳定性隐患和危险，放弃锐度，集中性以及系统性查差补漏。

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

每个报警不要放过，每个报警及时响应解决

疾速定位和疾速复原是集体以及团队业余能力积淀，但疾速报警响应是每个敬畏线上敬畏用户体验的技术同学能够做到的。

在监控齐备和继续前提下，每个报警及时处理即能够升高故障影响范畴，也会继续缩小小的隐患。报警一些小的实际技巧：报警依照方向收敛报警群，建设报警天级值班机制，报警短信手机设置为触动模式（不打搅同空间家人或敌人状况下，本人第一工夫感知），主管要订阅报警作为团队报警兜底解决人，报警响应好的同学和不好的同学要数据化褒扬和批评。

从团队角度，报警及时响应必须配合报警治理进行，否则过多有效报警也会让有责任心的同学变得麻痹。所以必须管制有效报警的数量，例如单利用有效报警（不须要线上问题进行定位以及修复解决的）不要超过 5 条，集体维度有效报警天级别不超过 10 条。

线上问题要复盘，不管是否为定级故障，不管问题大小

小的线上问题也要复盘，复盘筹备度能够低于定级故障，但都须要思考反思以及落实优化 Action。小的线上问题就是将来线上故障的先兆。咱们团队周会上都会有一个环节，上周如有线上问题则会安顿对触发人做复盘。

谬误日志要器重

要定期分析线上谬误日志，隐患的问题是藏在谬误日志中的。咱们当初技术团队会有早值班机制，每个方向每天都有一个技术同学走查线上，以发现线上隐患问题为导向，走查监控大盘、谬误日志、用户反馈，通过这个例行机制，很好地防微杜渐。

每个用户反馈要器重，定位到根本原因

一个用户反馈背地必然有多个理论线上问题，只是这个用户无法忍受，晓得反馈门路以及对这个产品有酷爱 或强依赖才抉择反馈的。彻底定位一个 voc，就是修复了一类线上问题。而且到用户反馈的水平，这个线上问题就曾经有肯定水平用户体验影响了。咱们当初技术团队有一个 voc 日清机制，针对线上 voc 问题对用户做好日内响应回答，也是一个不错对于这个意识的数字化掂量。

2 能力造就

单个技术同学集体技术以及稳定性保障能力是团队在每个稳定性工作上拿到后果的执行者和根底，因而技术主管器重辨认不同同学集体劣势和有余，针对性做工作安顿以及造就锤炼。只有线上意识上足够器重，能力对于大部门技术同学是能够造就的。

团队内同学因为入行工夫、历史教训等各方面起因，对于以后零碎稳定性保障能力是有强弱的差别的，对于集体是失常状况，但对于团队而言，不能因为团队个别同学能力上存在有余而引入团队层面稳定性保障危险。须要主管很好相熟以及判断同学能力段位，在负责零碎和模块、流程机制束缚、辅导人等方面做好差异化安顿。例如校招同学 X 个月不做线上公布，前 X 个月公布有师兄协同公布机制，并发高 或资金交易等等危险高的零碎让更加有教训的负责。同时设计造就机制，能力以后有余但有后劲的同学，能够安顿由经验丰富的同学领导以及提供一些进阶实操门路，依照节奏从易到难逐步承当更高风险的零碎职责。

能力造就形式有技术 Review、代码 CR 和辅导、参加团队稳定性保障机制、安顿适合师兄领导、过程中主管领导、逐步承当更高职责等。代码层面，对于 Java 同学来说，《Java 开发手册》是一个很好的实践性指南，超出代码格调，提供了日志、异样解决、汇合等库应用、数据库设计、分层设计等多个晋升代码品质的实际做法，咱们本人团队所有 Java 研发同学都会 100% 通过阿里云上阿里巴巴代码认证考试，同时团队有一个团队内新人品码机制，同时钉钉大技术团队层面有一个品码会机制，这些都是不错地造就同学写出好代码的造就形式。

好多小团队、大团队、公司都有很多不错晋升稳定性机制和案例，积极主动参考学习以及联合本人业务零碎思考践行，是本人晋升重要门路。架构上高可用以及架构相干经典书籍自我学习，从实践上做系统性认知也是有必要，相干书籍网上有很多举荐，例如《高性能网站建设》、《大型网站零碎与 Java 中间件实际》等。

大量的同学在主管和团队尽可能帮忙和辅导后在稳定性性保障的意识和能力上继续不能达标，这类同学要做好阶段性高风险零碎隔离以及动摇做汰换。对业务、客户体验、团队内其他同学负责，及时汰换他以升高这一块稳定性危险。

五 良好的研发项目管理

从教训看，线上零碎大部分故障是由新的变更引入和触发的，变更是业务和产品迭代演进形式，因而不可能没有变更，但咱们能够对变更我的项目做适合品质治理，进而无效进步线上稳定性。

项目管理的四因素：工作范畴（需要）、工夫（交付工夫）、品质、老本（人 & 机器资源等），简称 STQC，这四个因素是互相关联的和制约的，造成一个项目管理品质治理铁三角，一个因素变动就会影响到其余因素，因而要保障好品质就必须要思考怎么治理好其余三个因素。

此外，咱们能够进一步了解我的项目胜利的因素，以终为始聚焦思考如何晋升理论影响胜利的品质，胜利的我的项目不仅取决于我的项目自身从开始到完结的执行过程，还取决于开始前和完结后的致力。胜利的我的项目应该取决于三个阶段的致力：

• 我的项目开始前必须“理解什么是客户的胜利”，只有客户胜利了我的项目能力胜利；——了解客户真正的需要。
• 我的项目执行中可能“负担客户胜利的责任”，按要求实现承诺的工作。
• 我的项目完结后能“帮忙客户实现价值”，只有客户说我的项目胜利了才是真正的胜利。——帮忙客户实现业务指标、用户价值指标、商业价值指标。

品质治理铁三角

互联网产品迭代速度很快，推崇疾速推出、疾速试错、疾速占据市场先机，交付工夫的快是互联网产品、业务同学对于研发团队显性的要求，而交付品质和线上继续稳固则是一个隐性需要，产品业务默认研发团队应该做到，但往往在工夫、老本等方面没有给予显性思考，这一块就须要研发项目管理同学被动评估考量进来，有本人业余判断和保持。

了解好真正的客户需要和交付后客户价值的实现，能够帮忙在四因素抵触的时候适合取舍需要来保障工夫和品质，以及和业务产品 & 客户基于客户价值实现争取时间、资源来保障品质。项目管理角度稳定性保障根本动作包含确定和充沛了解帮忙客户胜利的需要范畴、管制好需要变更、预留品质保障环节工夫、动静管控交付预期工夫、争取短缺人力以及机器等老本资源。进阶动作：在提前理解和了解甚至独特参加制订业务策略和策略根底上提前布局需要范畴和研发节奏 & 人员排兵布阵 & 架构布局、深刻了解业务根底上帮助做需要取舍和优化。

作者：开发者小助手_LS
原文链接
本文为阿里云原创内容，未经容许不得转载