网站建设 中企动力福州阀门,在某网站被骗钱该怎么做,苏州建设厅网站,我要免费开网店简介#xff1a; 无论是一个域#xff0c;一个BG#xff0c;还是一个站点#xff0c;虽然范围有大有小#xff0c;对象有所不同#xff0c;但其高可用的理念都是相通的#xff0c;今天将自己对高可用的一点点思考以及总结的【nPRT公式】分享给大家。 我是乐羊#xff0…简介 无论是一个域一个BG还是一个站点虽然范围有大有小对象有所不同但其高可用的理念都是相通的今天将自己对高可用的一点点思考以及总结的【nPRT公式】分享给大家。 我是乐羊一个热爱风险防控的人之前参与过蚂蚁Glocal多个站点从0到1的建站和高可用建设目前正在参与蚂蚁大安全的高可用建设。无论是一个域一个BG还是一个站点虽然范围有大有小对象有所不同但其高可用的理念都是相通的今天将自己对高可用的一点点思考以及总结的【nPRT公式】分享给大家。
本文采用“高可用是什么为什么要高可用怎么做高可用为什么这么做软件风险又在哪里”的逻辑来介绍。
一 高可用是一种控制风险的能力
高可用是一种面向风险设计使系统具备控制风险提供更高的可用性的能力。
二 为什么要高可用
对于一个公司而言“为什么要高可用”可以完整理解为“公司为什么要做系统高可用”。以公司为对象从内看包括人软件物硬件物从外看包括客户股东社会从自身看包括公司。 高可用的大前提所有事物都不是100%可靠的
所有事物都是变化的唯一不变的是变化。所有变化的都不是100%可靠的。结论所有事物都不是100%可靠的。
内因人、物都不是100%可靠的
从人的层面人都是有可能犯错的。从软件层面软件都是有可能有BUG的。从硬件层面硬件都是有可能会坏的。
从概率学角度分析凡是有可能会出错的只要变化次数足够多最终出错的概率会无限趋向于1。
外因无高可用对外影响面是很大的
从客户角度无高可用客户服务可能会中断。从股东层面无高可用股价可能会下跌。从社会角度无高可用社会秩序可能受影响。
根因本质控制风险
从公司自身角度控制风险保障公司价值避免伤及根本。
三 如何做高可用
如何做高可用本质上就是如何控制风险。
1 风险相关概念
风险指未来会发生危害的一种可能性但实际未发生记为r。故障指已发生或正在发生危害的一种事实是风险变现实的结果。风险概率指一个风险变故障的概率。用它来表示风险触发为故障的难易程度记为P(r)。故障影响范围指在单位时间内一个故障造成的危害影响记为R(r)。故障影响时长指一个故障持续的时间记为T(r)。故障影响面指一个故障影响范围乘以故障影响时长的总和。这里用故障影响面来表示故障总的危害程度记为F(r)。风险期望指每个风险变故障的概率乘以每个风险变故障后的故障影响面的总和。这里用风险期望来表示风险的潜在危害程度记为E(r)。
2 风险期望的公式
根据上节的定义可以推导出风险期望的公式如下 r代表风险风险期望会随着风险的数量n和每个风险的P、R、T下降而下降简称nPRT公式。
注如果要引用该公式请注明出处。3 控制风险的4大因素nPRT
减少风险数量n
从源头远离风险做到与风险载体无连接无关系那么该风险概率就是0也不关心该风险发生后的故障影响面是大是小完全不关心。
例如重大节日活动施行全站封网变更的数量就会得到一个明显的下降就是典型的减少风险数量。例如系统A完全不依赖Oracle那系统A就不用关心Oracle的任何风险哪怕美国总统突然紧急宣布Oracle立即立刻禁止在中国使用系统A也无所谓。例如最近新冠大流行人传人很可怕如果你今天选择不上班不出门那你今天就不用担心被外面的行人和同事传染。
降低风险变故障的概率即增加风险变故障的难度P
把风险当成一个对象看待给它层层设卡增加风险变故障的门槛和难度不要再让“不小心多了一个空格或字符系统就挂了”这种惨案轻易出现。
例如人员B要对系统C进行变更可以对人员B增加变更认证考试对变更内容要求线下或仿真测试对变更内容进行CR系统C提供变更效果预览能力类似监控模式或试运行万一人员B想恶意变更搞破坏还可以增加非同人复核系统C可以增加防错设计进行保护等等。例如以新冠为例带口罩勤洗手多通风等就可以降低染上新冠的概率。
减小故障影响范围R
以大拆小将一个整体拆分成N个小的个体每个个体之间进行相互隔离单个个体出问题仅影响单个个体实现小而美。
例如分布式架构就是这个的典范集中式一损俱损分布式一损即N分之一损。例如以新冠为例网格化管理各省或市间的流动进行限制跨省必须核酸隔离14天有效控制新冠的传播范围。
缩短故障影响时长T
故障影响时长由故障发现时间和故障止血时间决定所以要早发现早止血。
发现方式分为事前的预警事后的告警。尽可能朝事前预警去做给止血争取时间甚至将风险扼杀在摇篮中。
止血方式分为切换回滚扩容降级 or 限流BUG修复等。故障出现时第一优先原则为快速止血如切换、回滚、扩容严禁去定位根因当无法快速止血时以少流血为第二优先原则如降级、限流。
止血效率自动 vs 人工 一键化 vs 多步操作。尽可能用自动化去代替人工操作若人工操作时尽量实现一键化提升止血速度。
例如对于容量水位可以在警戒线之前划一条预警线提前预警从容应对。例如分布式应用集群任何一台应用服务器有问题时负载均衡会通过心跳检查自动把有问题的应用服务器剔除将请求转发给其他热备份冗余的服务器上。例如以新冠为例但由于每个生命都是独一无二的没有办法切换也没有办法回滚也不能降级涉及人道主义只能对症下药慢慢治疗。
4 高可用架构设计的7大核心原则
根据nPRT公式在高可用架构设计时有以下7个核心原则
少依赖原则能不依赖的尽可能不依赖越少越好n
由于所有事物都不是100%可靠的当2个事物之间有了关系那么就会相互影响就互为对方的一个风险一个出问题可能会影响另外一个。我们统一用依赖来泛指这里的“关系”。
例如一个系统同时依赖OracleMysqlOB三种关系型数据库少依赖原则是改成仅依赖最成熟稳定的OB不依赖Oracle和Mysql。
什么场景适合多依赖
当引入依赖n变大可以减小PRT中的一个或多个且使E(r)整体下降时。
例如为解决DB风险引入分布式缓存只要2者不同时挂的时候依然可用。
弱依赖原则一定要依赖的尽可能弱依赖越弱越好P
事物a强依赖事物b一旦b出问题时那么a也会出问题一损俱损。
所以任何强依赖都要尽可能的转化成弱依赖可以直接降低出问题的概率。
例如交易核心链路在交易成功后要要给用户发放积分权益交易核心系统需要依赖积分权益系统好的方式是采用弱依赖使用异步化的方式这样积分权益系统不可用时大概率不会影响交易核心链路。
分散原则鸡蛋不要放一个篮子分散风险R 打散拆分成N份避免全局只有1份否则一有问题影响范围就是100%。
例如所有交易数据都放在同一个库同一张表里面万一这个库挂了此时影响所有交易。例如将自己所有的钱买了同一只股票万一这只股票是乐视就惨了。
均衡原则均匀分散风险避免不均衡R 最好N份中的每份都是均衡的避免某个份额过大否则过大的那份一有问题就影响范围过大了。
例如xx应用集群有1000台但由于引流组件BUG导致所有流量引到了其中100台上面导致负载严重不均衡最后因负载无法扛着全面崩溃。类似重大故障已经发生了多次。例如将自己所有的钱买了10只股票其中一只占比99%万一这只股票是乐视就惨了。
隔离原则控制风险不扩散不放大R 每份之间是相互隔离的避免一份有问题影响其他的也有问题传播扩散了影响范围。
例如交易数据拆分成10库100表但是部署在同一台物理机上万一某张表有一条大SQL把网卡打满了那10库100表都会受影响。例如将自己所有的钱均分买了10只股票每只都占10%但10只都是乐视系的。例如古代赤壁之战就是一个典型的反面例子铁锁连船导致隔离性被破坏一把大火烧了80w大军。
隔离是有级别的隔离级别越高风险传播扩散的难度就越大容灾能力越强。
例如一个应用集群由N台服务器组成部署在同一台物理机上或同一个机房的不同物理机上或同一个城市的不同机房里或不同城市里不同的部署代表不同的容灾能力。例如人类由无数人组成生活在同一个地球的不同洲上这意味着人类不具备星球级别的隔离能力当地球出现毁灭性影响时人类是不具备容灾的。
隔离原则是一个极其重要的原则它是前面4个原则的前提。没有做好隔离前面4个原则都是脆弱的风险很容易传播扩散开破坏前面4个原则的效果。大量真实系统故障是因为隔离性做得不好导致的如线下影响线上离线影响在线预发影响生产一条烂SQL影响整个库或整个集群等等。
分散均衡隔离是控制风险影响范围的3个核心原则。打散拆分成N份每一份都是均衡的且相互隔离一份有问题影响范围为1/N。
无单点原则要有冗余或其他版本,做到有路可退T
快速止血的方式是切换回滚扩容等回滚和扩容属于特殊的切换回滚指的是切换到某个版本扩容指的是将流量切换到新扩容的机器上。
切换得有地方可切才行所以不能有单点这里特指强依赖的单点弱依赖的可以降级要有冗余备份或其他版本单点会限制整体的可靠性。
假设单点的可靠性假设是99.99%它要提升到99.999%是非常困难的但是如果无单点而是依赖2个1个挂掉没有关系只要不同时挂就行那整体可靠性就是99.999999% 会有质的提升。
单点故障会导致无法快速止血拉长整个止血时间去单点至关重要。这里的单点不仅仅指的是系统节点也包含人员如订阅告警的人应急的人等等。
对于重要数据节点必须满足无单点原则否则极端情况下可能造成数据永久丢失永远无法恢复重要数据节点满足无单点原则后保障数据一致性比可用性要求更重要。
例如一个商户仅支持一个支付渠道就是典型的单点万一这个支付渠道挂了就不能支付了。例如一个家庭的所有收入仅依赖父亲一个的薪资收入万一这个父亲病了就没有收入了。
无单点原则和分散原则的区别
当节点无状态的情况下打散拆分成N份每份都是相同的功能互为冗余即节点无状态情况下分散原则和无单点原则等价满足一个即可。当节点有状态的情况下打散拆分成N份每份都是不相同的每份都没有冗余需要针对每份再做冗余即节点有状态情况下既要满足分散原则又要满足单点原则。
自我保护原则少流血牺牲一部分保护另外一部分PRT
外部的输入都不是100%可靠的有时候是无意的错误有时候甚至是恶意的破坏因此针对外部输入要有防错设计给自己多一些保护。
极端情况下可能无法快速止血可以考虑少流血牺牲一部分保护另外一部分。例如限流降级等。
例如大促峰值期间一般会提前降级掉很多功能同时限流主要是为了保护峰值绝大部分人的交易支付体验。例如人体在失血过多或疼痛过度时就会触发休克现象这也是一种典型的自我保护机制。
四 软件风险在何方
前面介绍了控制风险的方法回到软件系统这个领域它的风险又在哪里
以软件系统为对象从内看包括计算系统和存储系统从外看包括人员硬件上游系统下游系统以及隐含的时间。 由于每个对象都是由其他对象组成的因此每个对象还可以继续往细分解理论上可以无限分解下去上面的分解方式主要是为了简化理解。
1 软件系统风险的来源
风险源于有危害的变化一个对象的风险来源于所有跟它有关系的对象的有危害的变化。因此软件系统风险的来源分为以下7大类
计算系统变化运行变慢运行错误
系统运行所依赖的服务器资源如CPUMEMIO等应用资源RPC线程数DB连接数等业务资源业务ID满了余额不足业务额度不够等的负载等都会影响系统运行的风险期望。
存储系统变化运行变慢运行错误数据错误
系统运行所依赖的服务器资源如CPUMEMIO等存储资源并发数等数据资源单库容量单表容量等的负载和数据一致性等都会影响存储系统运行的风险期望。
人的变化变更出错
变更人员的数量安全生产意识熟练程度变更的数量变更的方式等都会影响变更的风险期望。
由于变更的人多变更的次数也多导致变更成为蚂蚁所有故障来源里的TOP1这也是为什么“变更三板斧”这么出名的原因。
“变更三板斧”正确的排序应该是“可灰度可监控可应急”可灰度代表的是R可监控和可应急代表的是T。
思考如果变更三板斧让你再加一板斧你觉得应该是什么硬件变化损坏
硬件的数量质量使用年限保养等都会影响硬件的风险期望硬件损坏会影响上层软件系统不可用。
上游变化请求变大
请求分为3个维度由无数API汇集而成的网络流量由无数KEY请求组成的APIKEY。
网络流量过大会造成网络堵塞影响网络通道中的所有网络流量请求。API请求过大会造成对应服务集群过载影响整个服务机器上的所有API请求甚至往外传播。KEY请求过大俗称“热点KEY”会造成单机过载影响单机上所有KEY请求甚至往外传播。
所以大促保障的时候不仅仅是关注核心API的容量保障还需要考虑网络流量和热点KEY。
下游变化响应变慢响应错误
下游服务的数量服务等级服务可用率等影响下游服务的风险期望。下游响应变慢可能会拖慢上游下游响应错误可能会影响上游运行结果。
时间变化时间到期
时间到期往往被人忽视但它往往具有突然性和全局破坏性一旦时间到期触发故障会导致非常被动所以要提前识别尽早预警如秘钥到期证书到期费用到期跨时区跨年跨月跨日等。
例如2019年日本运营商软银因证书到期引发3000w用户长达4小时通信中断。
以上每一大类风险都可以基于nPRT公式进行逐一分析处理。2 风险的数量一生三三生万物
任何一个事物既是由其他事物组成的又是其他事物的组成部分无限循环下去一生三三生万物风险的数量是无穷无尽的。
向内看内含内可以无限小下去当原子粒度的问题传播开时也可能影响软件系统的可用性就像100纳米的新冠病毒就可以影响人体的可用性一样。
向外看外有外可以无限大下去当太阳系毁灭软件系统的可用性自然就不复存在。
虽然风险无穷无尽但是只要我们对风险多一些了解根据控制风险的一些理念和原则还是可以更好的降低风险期望。
谈一谈敬畏之心
我们对世界的认知是有限的这也让我们少了许多恐惧同时也让我们少了一些敬畏之心。我们真正要敬畏的不是处罚条例而是我们不知道的以及我们不知道我们不知道。
五 结束语
所有事物都是变化的。所有事物都不是100%可靠的。因此才有了风险风险是不可见的可见的是故障。风险是不能消灭光的但是可以远离可以减少。故障是不可避免的但是可以推迟可以缩小影响范围缩短影响时间。
nPRT公式不仅仅适用于软件系统风险也适用于其他风险领域希望对大家有用。
作者开发者小助手_LS
原文链接
本文为阿里云原创内容未经允许不得转载
