华为云高可用架构设计提升云上业务稳定性

来源：华为云确定性运维专刊（第四期）

      Q： 李老师您好，您能给大家简单介绍下您一天的工作吗？

      A： 我每天的工作日程主要是分成这几类，最主要精力是华为云现网的技术方案优化。华为云现网有数百个服务，我们在为每个服务做它的高可用档案建模，正向的去测算每个服务可用性的一个数学期望值。

      我们会不停的审视它的新特性上线，新站点部署之后可用性的数学期望值到底是在增加还是在减少。对于这种有明显短板的，我们会是针对性的去做它的优化方案，把方案在服务中落地，去构筑它的前端的架构竞争力，这个就是冰山下的隐性质量，可能是我们花费精力最多的事情。

      除此之外，我们还会定期审视现网发生的事件，基本上每周我们都会例行分析上周现网出现过哪些事件，对于爆炸半径大，影响多个服务的这种事件，会重点去看我们前端设计在哪些地方是有遗漏和缺失的，去补我们的监控能力和高可能架构设计能力。
      还有一些不定期的事项，如果现网出现影响比较大的WarRoom，较多业务受到影响，这个时候我们可能会直接参与到WarRoom里去指挥应急恢复。主要就是这三类的工作。

图：华为云SRE首席架构师李浩在GOPS全球运维大会上分享

      Q：谈一谈您对SRE的理解？华为云是如何逐步把SRE整体架构搭建起来的？

      A：SRE是站点可靠性工程师的缩写，主要职责和目的是为保障现网的稳定和业务连续性，让它在客户使用的过程中高质量。华为云从成立的那一天就组建了SRE团队，目的是为了维护华为云整体质量。华为云在软件开发上选择的是devops路线，华为云有很多个服务，这些服务分别去开发上线和运营，但是谁对整体质量和现网的表现负责呢？这就要求需要一个角色或者一个团队对华为云的综合质量去负责，所以华为云在成立的第一天就把SRE团队也同步建立起来，并明确质量职责，看护整个现网的质量。
      2015年华为云正式对外发布，早期华为云的SRE还是聚焦于做偏被动的事情，因为当时环境的问题也比较多，更多的是做现网的试点恢复，做变更，跟传统运维类似。后面随着华为云业务规模的增长，无论是服务器的规模还是客户的数量，都是指数级的增长。在这种增长的情况下，我们发现，在后面等问题出现了之后再去修复，这个远远满足不了业务发展的诉求。所以华为云除了在运维的这一端去做自动化，另外一个很重要的变化就是开始积极的介入到云服务开发的前端，把华为云后端的运维经验和运维遇到的问题及诉求带到前端的云服务开发设计过程中，参与架构的设计、方案的制定，直接在云服务前端，把很多高可用的特性和能力预埋进去。基于广义的全生命周期的质量管理，从运维后端走向前端的开发设计，建立一个质量的大循环，通过这个大循环不断的提升整个华为云，从架构的健康度到开发的健康度，交付的健康度，到最后运维的健康度等等一系列的健康度能力，最终来实现华为云质量从根本上的一个提升。

       Q：您认为华为云在整个SRE领域，它的这种独特性和领先性是怎么样的？

       A： 我觉得相对业界比较独特性的，是华为云的高可用架构。华为云会更多的参与到云服务架构设计过程中，在前端构筑高可用能力。华为云的SRE不仅仅是后端的运维，而且是包含了前端云服务的高可用设计，通过参与前端的高可用设计来直接在华为云的被运维对象的架构设计的前端，预埋了这种可恢复性和爆炸半径控制能力，这样让华为云的现网就算出现非预期的，不在预案范围内的问题，也有手段隔离它的影响，快速的恢复业务。华为云高可用架构提了三点，包括爆炸半径的确定性、恢复时间的确定性和故障率的确定性，我觉得华为云最大的优势是确定性的恢复能力。大家都知道，很多导致现网重大事件的问题也都是非预期的。华为云提通过架构设计，采用黑盒方式去恢复各种未知的故障。之前我们采用的是白盒的方式，是case by case的针对故障点去做修复，这种方式存在两个问题，一是时间不可恢复，二是故障点太多了不具可行性。所以确定性恢复故障的核心理念就是黑盒切流，盲切业务的方式来恢复所有的未知故障。这种切流有好多层级，比如华为云有些服务是采用region切流，有的是AZ间切流，有的是多集群间切流等，整个大的理念就是出了问题，不要做定界定位，只要发现哪个业务入口它的黄金指标有受损，只要把有受损的故障单元的流量切到其它的业务承载体上就能把这个故障恢复，所以华为云通过这种设计规避了故障定位定界的时间，也规避了要去对每一个故障点或者说每一个故障类型去做业务处理的这个事情。最后得到的结果是，任何未知的问题华为云都可以通过业务盲切的方式来恢复，所以华为云的故障恢复时长现在跟友商比，实际上是有个显著的优势。

      另一个比较特殊的就是华为云SLA评估机制。华为云服务对外都有一个SLA的承诺，是对外的一个商业承诺。简单的说就是终端的赔多少钱，但是服务到底能不能实现SLA的承诺，在华为云它不是通过现网问题的事后度量来的，不是说中断了之后统计中断时长，这样来统计现网的可用度。实际上在华为云的云服务架构设计阶段，华为云就有一套SLO的评估方法，通过业界的RBD模型的一个方式，基于大量的统计数据，华为云知道机房的可用度、硬件的可用度、网络单台设备的可用度，知道软件bug出现的概率、变更导致中断的概率，基于这些大量的现网统计数据，就可以通过RBD的理论计算，在这个服务上线前就能推算出它的现网的可用度的数学期望值情况。

      华为云为建这个模型，会出一套评估规范，基于这个规范，在服务的设计阶段就知道它的SLO有没有达到设计要求。比如华为云内部至少设计要求是达到4个9，有的甚至是5个9甚至更高，它的服务架构设计能不能支撑它的服务上线之后达成4个9，华为云实际上在设计阶段就通过华为云整套评估方法，可以测算出它的SLO的期望值。华为云的主动运维比例是远高于传统运维的，华为云在SRE上，接近一半的时间在做这种主动的风险预防，我们会对现网所有的服务架构建可用性档案，对它的故障模式和出现条件建立规则。比如，华为云发现某个服务因为部署在同一柜里面，结果这个柜出问题后该服务就会受影响，基于这种经验，华为云制定出规则，所有服务不能只单柜部署，必须跨柜部署。当然，这只是一个例子，有的甚至还要求跨region部署等等。这些规则定好之后，华为云会通过系统，在现网去扫描所有软件服务对这个规则的遵从性，如果不遵从，就会通过日常提前的风险整改，消除风险。华为云会投入大量的时间在隐患的消除和排查上，来解决华为云现网的风险。我想，这些方面可能就是华为云SRE的独特性和领先性。

       Q： 能否举一个例子，如果现网出现一个突发状况，华为云是怎样的一个处理过程？

      A：华为云在某个站点出了一个机房的制冷的问题，是我指挥恢复的。监控系统里面会监控到某个站点机房高温。当时高温刚刚开始的时候业务还没受到影响，温度值上扬，我们就已经监控到了这个温度不正常的上升，并立马就会启动WarRoom。华为云有一个7×24小时的监控中心，监测到这个异常之后自动拉起WarRoom，所有可能受影响的服务都会加入电话会议，组成WarRoom对这个事件进行联合恢复。一般在WarRoom里面首先我们会检查各个服务的各种异常，比如说像我们的机房高温，当时各个服务的业务还是正常的，但是我们的服务器，我们的机房都监控到了温度的上升。我们一方面紧急联系现场的机房管理员确认温度上升的原因，快速确认是供应商的智能设备故障了。所以我们紧急在外面去买干冰资源，因为不能确认供应商多长时间能恢复，但是为了保证业务的连续性，把干冰调入机房，准备做强制制冷。

      另一方面，因为没有制冷设备的情况下，机房热量很大，温度在干冰来之前上升当中我们的警戒线。为了防止持续性的高温引起磁盘消磁导致数据丢失，我们紧急把机房可以倒换到的业务立即倒换到其他机房，然后主动把倒换后处于备用状态的关键存储设备关机下线，做数据的保全，降低机房的发热量同时也避免机械硬盘损坏。

      干冰调拨到位之后，我们通过干冰对供水的管线进水口降温，不依赖供应商的冷控设备，供应商制冷设备恢复正常后再把我们的所有的设备再重新拉起恢复了业务。整个故障时间大概持续了4个小时左右，但是客户感知非常轻微，因为大部分业务实现了成功的切换。通过我们WarRoom的指挥让客户感知的影响比实际的故障的时长要短得多。

       Q：云上客户如何借鉴华为云经验提升自身业务稳定性？您对用好云、管好云有何建议？

       A：华为云SRE在这方面的经验，可以供大家参考，主要是两个方向：第一个方向是向前走。参与到被运维的这些云服务前端的架构设计过程中，落地一些标准化的高可用架构，实现确定性爆炸半径，确定性故障率和确定性恢复时长，从一个纯运维的角色变成了类似于软件架构师和软件工程师的角色，这是通过向前走的方式来提升运维能力。华为云在架构设计上要能跟云服务对上话，推动这些高可用能力的落地，才能在源头上构筑华为云的质量。
      第二个方向是向下走。向下走是什么？华为云运维好多工作都是靠人去做的，但是随着规模和服务的增加，人的精力总是有限的，且重复率是比较差的，所以华为云要把在运维后端的能力沉淀到运维平台里面去。比如硬件故障基本已经不需要人去立即干预了，而是通过故障自愈的系统，把人工处理能力全部用一个编排引擎，把处理动作都编排进去。现网如果出现一个故障告警，华为云会自动识别这个硬件属于哪个服务，调用该服务的一些隔离或者业务牵引的一些接口，针对该服务的恢复预案做硬件故障的恢复，让业务立即恢复正常。针对坏的硬件，会每周批量替换一次，把大量的专家经验和能力沉淀到系统里，让系统自动帮华为云干活。
      总结一下，一是往前走，参与被运营对象的架构设计，前端构筑这种高可用的质量；二是往下走，把人的专家经验和运维的能力沉淀到运维平台里面，并固化到平台里变成组织资产，来支撑现网的快速发展。因文章篇幅有限，期待下一次的分享。