本文采用“高可用是什么，为什么要高可用，怎么做高可用，为什么这么做，软件风险在哪里”的逻辑来介绍。
高可用是一种控制风险的能力
- 高可用是一种面向风险设计，使系统具备控制风险，提供更高的可用性的能力。
为什么要高可用
- 对于一个公司而言，“为什么要高可用”可以完整理解为“公司为什么要（做系统）高可用”。
- 以公司为对象：
- 从内看包括：人，软件（物），硬件（物）
- 从外看包括：客户，股东，社会；从自身看包括：公司
- 高可用的大前提：所有事物都不是100%可靠的
- 所有事物都是变化的（唯一不变的是变化）。
- 所有变化的都不是100%可靠的。
- 结论：所有事物都不是100%可靠的。
- 内因：人、物都不是100%可靠的
- 从人的层面：人都是有可能犯错的。
- 从软件层面：软件都是有可能有BUG的。
- 从硬件层面：硬件都是有可能会坏的。
- 从概率学角度分析，凡是有可能会出错的，只要变化次数足够多，最终出错的概率会无限趋向于1
- 外因：无高可用，对外影响面是很大的
- 从客户角度：无高可用，客户服务可能会中断。
- 从股东层面：无高可用，股价可能会下跌。
- 从社会角度：无高可用，社会秩序可能受影响。
- 根因（本质）：控制风险
- 从公司自身角度：控制风险，保障公司价值，避免伤及根本。
如何做高可用
- 如何做高可用，本质上就是：如何控制风险。
风险相关概念
- 风险：指未来会发生危害的一种可能性，但实际未发生，记为r。
- 故障：指已发生或正在发生危害的一种事实，是风险变现实的结果。
- 风险概率：指一个风险变故障的概率。用它来表示风险触发为故障的难易程度，记为P( r )。
- 故障影响范围：指在单位时间内，一个故障造成的危害影响，记为R( r )。
- 故障影响时长：指一个故障持续的时间，记为T( r )。
- 故障影响面：指一个故障影响范围乘以故障影响时长的总和。这里用故障影响面来表示故障总的危害程度，记为F( r )。
- 风险期望：指每个风险变故障的概率乘以每个风险变故障后的故障影响面的总和。这里用风险期望来表示风险的潜在危害程度，记为E( r )。
风险期望的公式
- 根据上节的定义，可以推导出风险期望的公式如下：
- r代表风险，风险期望会随着风险的数量n和每个风险的P、R、T下降而下降，简称nPRT公式。
控制风险的4大因素（nPRT）
1.减少风险数量，n
- 从源头远离风险，做到与风险载体无连接，无关系；那么该风险概率就是0，也不关心该风险发生后的故障影响面是大是小，完全不关心。
- 例如：重大节日活动，施行全站封网，变更的数量就会得到一个明显的下降，就是典型的减少风险数量。
2.降低风险变故障的概率（即：增加风险变故障的难度），P
- 把风险当成一个对象看待，给它层层设卡，增加风险变故障的门槛和难度，不要再让“不小心多了一个空格或字符，系统就挂了”这种惨案轻易出现。
- 例如：以新冠为例，带口罩，勤洗手，多通风等就可以降低染上新冠的概率。
3.减小故障影响范围，R
- 以大拆小，将一个整体拆分成N个小的个体，每个个体之间进行相互隔离，单个个体出问题仅影响单个个体，实现小而美。
- 例如：分布式架构就是这个的典范，集中式一损俱损，分布式一损即N分之一损。
4.缩短故障影响时长，T
- 故障影响时长由故障发现时间和故障止血时间决定，所以要早发现早止血。
- 发现方式分为：事前的预警，事后的告警。尽可能朝事前预警去做，给止血争取时间甚至将风险扼杀在摇篮中。
- 止血方式分为：切换，回滚，扩容，降级和限流，BUG修复等。
- 故障出现时第一优先原则为快速止血（如切换、回滚、扩容），严禁去定位根因；
- 当无法快速止血时以少流血为第二优先原则，如降级、限流。
- 止血效率：自动 vs 人工 ；一键化 vs 多步操作。
- 尽可能用自动化去代替人工操作，若人工操作时尽量实现一键化，提升止血速度。
高可用架构设计的7大核心原则
- 根据nPRT公式，在高可用架构设计时有以下7个核心原则：
1.少依赖原则：能不依赖的，尽可能不依赖，越少越好（n）
2.弱依赖原则：一定要依赖的，尽可能弱依赖，越弱越好（P）
- 事物a强依赖事物b，一旦b出问题时，那么a也会出问题，一损俱损。
3.分散原则：鸡蛋不要放一个篮子，分散风险（R）
- 打散拆分成N份；避免全局只有1份，否则一有问题影响范围就是100%。
4.均衡原则：均匀分散风险，避免不均衡（R）
- 最好N份中的每份都是均衡的；避免某个份额过大，否则过大的那份一有问题就影响范围过大了。
5.隔离原则：控制风险不扩散，不放大（R）
- 每份之间是相互隔离的；避免一份有问题影响其他的也有问题，传播扩散了影响范围。
6.无单点原则：要有冗余或其他版本,做到有路可退（T）
- 快速止血的方式是切换，回滚，扩容等；回滚和扩容属于特殊的切换，回滚指的是切换到某个版本，扩容指的是将流量切换到新扩容的机器上。
7.自我保护原则：少流血，牺牲一部分，保护另外一部分（P&R&T）
- 外部的输入都不是100%可靠的，有时候是无意的错误，有时候甚至是恶意的破坏，因此针对外部输入要有防错设计，给自己多一些保护。
软件风险在何方
- 以软件系统为对象，从内看包括：计算系统和存储系统；从外看包括：人员，硬件，上游系统，下游系统；以及（隐含的）时间。
- 由于每个对象都是由其他对象组成的，因此每个对象还可以继续往细分解（理论上可以无限分解下去），上面的分解方式主要是为了简化理解。
软件系统风险的来源
- 风险源于（有危害的）变化，一个对象的风险来源于所有跟它有关系的对象的（有危害的）变化。因此，软件系统风险的来源，分为以下7大类：
1.计算系统变化：运行变慢，运行错误
- 系统运行所依赖的服务器资源（如CPU，MEM，IO等），应用资源（RPC线程数，DB连接数等），业务资源（业务ID满了，余额不足，业务额度不够等）的负载等都会影响系统运行的风险期望。
2.存储系统变化：运行变慢，运行错误，数据错误
- 系统运行所依赖的服务器资源（如CPU，MEM，IO等），存储资源（并发数等），数据资源（单库容量，单表容量等）的负载和数据一致性等都会影响存储系统运行的风险期望。
3.人的变化：变更出错
- 变更人员的数量，安全生产意识，熟练程度，变更的数量，变更的方式等都会影响变更的风险期望。
- 由于变更的人多，变更的次数也多，导致变更成为蚂蚁所有故障来源里的TOP1，这也是为什么“变更三板斧”这么出名的原因。
- “变更三步曲”正确的排序应该是“可灰度，可监控，可应急”；可灰度代表的是R，可监控和可应急代表的是T。
4.硬件变化：损坏
- 硬件的数量，质量，使用年限，保养等都会影响硬件的风险期望，硬件损坏会影响上层软件系统不可用。
5.上游变化：请求变大
- 请求分为3个维度：（由无数API汇集而成的）网络流量，（由无数KEY请求组成的）API，KEY。
- 网络流量过大会造成网络堵塞，影响网络通道中的所有网络流量请求。
- API请求过大会造成对应服务集群过载，影响整个服务机器上的所有API请求，甚至往外传播。
- 热点KEY请求过大会造成单机过载，影响单机上所有KEY请求，甚至往外传播。
- 所以保障时，不仅仅是关注核心API的容量保障，还需要考虑网络流量和热点KEY。
6.下游变化：响应变慢，响应错误
- 下游服务的数量，服务等级，服务可用率等影响下游服务的风险期望。下游响应变慢可能会拖慢上游，下游响应错误可能会影响上游运行结果。
7.时间变化：时间到期
- 时间到期往往被人忽视，但它往往具有突然性和全局破坏性，一旦时间到期触发故障会导致非常被动，所以要提前识别，尽早预警，如：秘钥到期，证书到期，费用到期，跨时区，跨年，跨月，跨日等。
- 例如：2019年日本运营商软银因证书到期引发3000w用户长达4小时通信中断。
风险的数量：一生三，三生万物
- 任何一个事物既是由其他事物组成的又是其他事物的组成部分，无限循环下去；一生三，三生万物，风险的数量是无穷无尽的。
结束语
- 所有事物都是变化的。
- 所有事物都不是100%可靠的。
- 因此才有了风险，风险是不可见的，可见的是故障。
- 风险是不能消灭光的，但是可以远离，可以减少。
- 故障是不可避免的，但是可以推迟，可以缩小影响范围，缩短影响时间。
- nPRT公式不仅仅适用于软件系统风险，也适用于其他风险领域，希望对大家有用。
思考：
- 如果“变更三步曲”让你再加一曲，你觉得应该是什么？
标签：风险,为什么,100%,可用,本质,故障,影响,变更 来源： https://blog.csdn.net/woaijssss/article/details/114293680
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。