作者：京东零售 刘慧卿

一 前言

关于软件的高可用，是一个老生常谈的话题。“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。其计算公式是：可用率=（总时间-不可用时间）/总时间。

本文重点从落地实践的视角作为切入点，带领大家从协作效率，技术落地和运营规范几个方面来展现高可用的实施步骤和落地细节。为了方便理解，先来统一语言话术，看一下软件交付过程中的各个阶段，如下图：



 

为什么说软件的高可用会面临着诸多挑战呢？

总结一下，我们具体面临的问题如下：

二 协作效率保障

认知误区

从整个需求交付链路我们可以发现，随着链路的逐级递增，信息的传递链路分支就会越多，传递层级就会越深。这会导致两个问题：

这两个问题最终导致的结果，就是协作效率的降低。





 

一个没有实战经验的同学往往会认为增加人数，就会提高需求交付效率。其实这种想法不完全正确，具体关系参考下图：





 

这就像盖楼房，如果一个人按部就班的建设，需要100天完成。如果请了100个人来帮忙，能否用1天的时间完成房子建设呢？答案是否定的。

这里面有协作的成本，比如：团队默契（设计师，瓦工，泥工，水电工），岗位匹配，风险控制；

这里面有流程的依赖，比如：施工依赖于设计，软装总在硬装之后；

这里面有成本预算，比如：整个组织的人才梯度，规模大小（承建方，代理商，承包商）；

以上这些，都不是简单的通过人力铺设来解决的。

流程规范

提高协作效率的底层逻辑是通过减少交付链路层级，缩短信息传递链路，进而保证信息的准确性和传递效率。（组织建设层面的内容这里不做展开）

这就要求具有今日事，今日毕的行动力。组织层面这叫流程规范，个人层面这叫做事方法，责任心。

尽量避免将当下的事情拖延到下一个环节，否则就会影响后续链路的排期计划和交付效率，极端情况甚至会出现返工的情形。简言之，考虑清楚，不埋坑。产品需求对研发，研发设计对测试，测试用例对产品等各个交付节点都是如此，交付物一定是靠谱的。

三 技术落地保障

在需求响应周期中，高质量的落实架构设计，编码实现，安全上线，部署运营等生产阶段，是软件高可用落地保障的前提和基础。

架构设计

架构设计往往影响着系统的前期实现成本（即ROI）和后续运维难度，属于软件的顶层设计，这里面既包含宏观的设计方案，也包含落地细节里的范式约束。

邀请架构师参与：核心交易节点、重大需求改动邀请架构师参与，这是闭坑最直接有效的方式；

重视设计文档：方案描述清楚了，并取得相关利益者的认可，是走在正确道路上的前提。

容灾设计：要预留后路，提前想清楚，做好容灾设计。可回滚，可熔断，可重试，可降级。

鲁棒性设计：无状态设计，防重设计，幂等设计，数据一致性设计

编码实现

如果说架构设计是骨架，那么编码实现就是神经，血管和肌肉。前者决定了能走多稳，走多久，后者决定着走多快，走多远。落实到编码层面，就是代码的衰老腐败程度。

代码评审机制：代码评审不仅仅是发现系统中存在的问题这么简单。它是一种长期行为，是进行组织文化贯彻和传承的一种形式和载体。评审的过程中，明确了业务职责边界，设计与编码共识，优秀的标准导向等研发共识。相当于通过具象化的案例，给出针对性的指导，这些都是保证团队战斗力的基石。

研发过程中的很多问题，通过代码评审机制可以被发现和解决，比如：

安全上线

线上70%的故障都是由某种变更而触发的，其中相当一部分占比是不规范的上线引起的。所以安全上线这一环节至关重要。

部署运营

实现高可用的一个很重要的手段就是能力冗余。下面给出方向和思路，具体落地细节和策略，可以根据具体情况各自延展。

四 运营规范保障

运营规范

应急预案

高可用意味着对故障时间的容忍性差，意味着没有时间进行故障排查和修复，更没有时间打开代码进行漏洞排查。这就要求我们有一套完备的应急预案，这套预案能够解决大部分可预见的故障问题。

详细事故应急处理手册，可以参照下图：





 

规范达标

再好的流程和规范都需要有对应的机制来贯彻执行，否则就是镜中花，水中月，看着美好，实则没用。可执行，能度量，是按照目标变好的前提。所以这里给出一个《高可用达标定期自查表》的工具，辅助规范落地。

五 总结

本文从“高可用为什么存在着很大挑战？”的问题展开探讨，强调了需求交付过程中，协作效率的重要性，并指出了为什么要遵从“今日事，今日毕”的工作原则。又从架构设计，编码实现，安全上线，部署运营等几个方面，详细介绍了技术落地保障相关的指导规范和落地细节。最后又从上线后运营的角度，给出了应急预案三板斧，规范达标定期自查表等比较实用的运营保障工具。希望能够给读者带来帮助。