前言：海恩法则和墨菲定律

海恩法则

· 事故的发生是量的积累的结果。

· 再好的技术、再完美的规章 ， 在实际操作层面也无法取代人自身的素质和责任心 。

薛定谔的猫

“薛定谔的猫”告诉我们，事物发展不是确定的，而是量子态的叠加。

墨菲定律

· 任何事情都没有表面看起来那么简单 。
· 所有事情的发展都会比你预计的时间长 。
· 会出错的事总会出错。
· 如果你担心某种情况发生，那么它更有可能发生 。

蝴蝶效应

世界会因一些微小因素的变动，而发生很大的变化。

熵增原理

“热力学第二定律”（熵增原理）告诉我们，世界总是在变得更加混乱无序。

警示我们，在互联网公司里，对生产环境发生的任何怪异现象和问题都不要轻易忽视，对于其背后的原因一定要彻查。同样，海恩法则也强调任何严重事故的背后都是多次小问题的积累，积累到一定的量级后会导致质变，严重的问题就会浮出水面。那么，我们需要对线上服务产生的任何征兆，哪怕是一个小问题，也要刨根问底：这就需要我们有技术攻关的能力，对任何现象都要秉着以下原则：为什么发生？发生了怎么应对？怎么恢复？怎么避免？对问题要彻查，不能因为问题的现象不明显而忽略 。

个人学习实践和总结笔记：

架构设计的愿景就是高可用、高性能、高扩展、高效率。为了实现架构设计四高愿景，需要实现自动化系统目标：

1. 标准化。

2. 流程自助化。

3. 可视化：可观测系统各项指标、包括全链路跟踪。

4. 自动化：ci/cd 自动化部署。

5. 精细化：监控平台、数据分析精细化。

要实现这些，在中小型公司，架构师可以 hold 住，而在大企业/大厂里面，虾兵蟹将是无法搞定的，至少是 vp 级别来推动。

整个自动化体系需要多平台、系统、工具来解决各类场景的自动化执行，各个平台之间要相互联动形成体系化，而不是相互脱离，各自发展。目前还没看到一站式平台可以串接需求、设计、开发、测试、发布、运维等，而高可用系统架构设计要从产品、开发、运维、硬件等全方位去统筹综合考虑形成一体化。

本文着眼整体，全局规划、分层设计，提供一个稳定性建设总体规划的参考。如果缺什么补什么，没有总体规划的建设，后面做出的系统往往是相互割裂，定位不清、无法持续集成，最后就是沦为一堆零散工具而无法形成体系（个人拙见,仅供参考）。紫色部分是我们最近半年主要关注和建设的部分：

可用性

所谓业务可用性(availability)也即系统正常运行时间的百分比，架构组/SRE 最主要的 KPI (Key Performance Indicators 关键业绩指标)。对于我们提供的服务（web/api）来说，现在业界更倾向用 N 个 9 来量化可用性，最常说的就是类似“4个9(也就是99.99%)”的可用性。

故障时间=故障修复时间点-故障发现（报告）时间点

服务年度可用时间%=（1-故障时间/年度时间）× 100%。

1.2 故障的度量与考核

对管理者/部门而言：可用性是产品的整体考核指标。对于研发工程师而言：使用故障分来考核：

考核指标可以使用故障分度量：故障分=故障时间分钟* 故障级别权重。

1.3 服务分级

如果是一个分布式架构设计，系统由很多微服务组成，所有的服务可用性不可能都是统一的标准。

为了提高我们服务可用性，我们需要对服务进行分类管理并明确每个服务级别的可用性要求。

高可用系统的架构设计，要从产品需求、代码开发、运维部署、故障管理等系统全生命周期进行全方位去考量和设计，核心思想就是：

• 故障事前：故障预防，总结经验，做到有智慧的绕开问题。

• 故障发现：及时发现，通过完善观测平台及时发现问题吧。

• 故障恢复：快速恢复，做好应急预案降低故障影响。

• 故障总结：复盘总结故障问题，层层剖析问题产生的原因，由表及里分析问题发生的本质。

高可用系统的架构设计思想包括但不限于：

2.1 系统设计

• 产品层面：主要是故障发生后的兜底策略等。例如生成式大模型考虑远程代码执行漏洞，设计时尽量避免将用户输入内容作为代码部分进行执行，如需执行，需要将服务部署在经过安全隔离的环境中。

• 代码架构：系统都是研发人员设计和编码写出来的，因此首先要对研发层面有一个代码架构规范，例如编码规范、如果代码架构设计不足，就会造成影响全局的架构设计。同时借助代码分析工具，分析代码可能存在的 bug 或者安全漏洞，例如对于业务设计需要将用户输入内容作为代码部分进行执行，需要应用程序做安全防范。

• 做好容量规划和评估：主要是让开发人员对系统要抗住的 QPS 量级有一个基本认知，方便后续进行合理的架构设计和演进。

2.2 故障预防

• 应用层面的高可用预防：主要是负载均衡、弹性扩缩容、异步解耦、故障容错、过载保护等。

• 数据层面的高可用预防：主要是冗余备份（热备，冷备）、失效转移（确认，转移，恢复）等。

• 模块变更机制预防：核心模块变更、新数据集、模型上线、流程变更、新模块、核心 sdk 变更等上线的规范化与审批。

• 模块健康度系统：查询系统健康状态，如调模块调用情况、资源使用情况、进程情况、服务处理状态等，快速判断故障模块是否异常。我们健康检查系统是通过拉取各个运营系统（容量系统、变更系统、监控系统等）的模块各项指标数据，结合历史故障数据，分析模块可能存在的异常。

2.3 故障发现

• 运维层面发现：主要是发布测试、监控告警、容灾、故障演练等。

• 完善报警治理：四五星报警周期治理，优化指标报警方式，完善新指标，提高报警的准确率、可靠性、时效性。

• 故障大屏：全面了解整个业务的健康状况。

2.4 故障恢复

• 制定《故障管理规范》

• 做好故障应急预案，建设大招平台：针对特定故障建立相应应急预案，在出现故障后使用相应的应急预案进行快速恢复，最大程度降低影响范围。

• 切流系统工具：可用区/IDC 出现故障问题，可以切流到其他可用区。

2.5 故障总结

• 故障复盘：复盘总结每个故障问题，层层剖析问题产生的原因，由表及里分析问题发生的本质。

• 故障汇总：进行故障分类、定级、影响等，如果系统组够大当然需要故障管理系统来管理。