01
前言
在今年的敏捷团队建设中,我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢?由此我的Runner探索之旅开始了!
关于软件的高可用,是一个老生常谈的话题。“高可用性”(High Availability)通常来描述一个系统经过专门的设计,从而减少停工时间,而保持其服务的高度可用性。其计算公式是:可用率=(总时间-不可用时间)/总时间。
本文重点从落地实践的视角作为切入点,带领读者从协作效率、技术落地和运营规范几个方面来展现高可用的实施步骤和落地细节。为了方便理解,先来统一语言话术,看一下软件交付过程中的各个阶段,如下图:
图1 软件交付过程的各阶段
为什么说软件的高可用会面临着诸多挑战呢?
1. 从需求交付链路来看,要完成目标交付,需要产品,研发,测试,运维,运营等多方利益相关者的密切配合。有些项目需求,合作者有时能够达到上百人,每个人职责分工各不相同,但却相互配合依赖,任何一个环节出现纰漏,可用率就有可能受到影响;
2. 从时间角度来看,如果要达到全年99.99%的可用率,就意味着一年当中,允许有故障的时间为:365*24*60*(100%-99.99%)=52分钟,如果要达到5个9的可用率,允许故障的时间仅为5分钟,这差不多是发现问题后,重启应用的耗时;
3. 从迭代效率来看,不迭代,不上线,问题出现的概率一定会小很多。软件的迭代效率和可用率之间存在着负相关的关系,平衡好两者之间的关系,也会面临着不小的挑战。
总结一下,具体面临的问题如下:
1. 如何解决需求交付相关协作者多、链路长的问题?
2. 如何应对故障时间容忍度低的问题?
3. 如何在频繁需求迭代的现状下,保持可用率不受到大的冲击问题?
02
协作效率保障
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目标页面展示到屏幕。
2.1 认知误区
从整个需求交付链路可以发现,随着链路的逐级递增,信息的传递链路分支就会越多,传递层级就会越深。这会导致两个问题:
1. 信息传递效率降低;
2. 信息准确性变差。
这两个问题最终导致的结果,就是协作效率的降低。
图2 信息传递链路示意
图3 研发效率与人员数量的关系
这就像盖楼房,如果一个人按部就班的建设,需要100天完成。如果请了100个人来帮忙,能否用1天的时间完成房子建设呢?答案是否定的。
这里面有协作的成本,比如:团队默契(设计师,瓦工,泥工,水电工),岗位匹配,风险控制;
这里面有流程的依赖,比如:施工依赖于设计,软装总在硬装之后;
这里面有成本预算,比如:整个组织的人才梯度,规模大小(承建方,代理商,承包商);
以上这些,都不是简单的通过人力铺设来解决的。
2.2 流程规范
从整个需求交付链路可以发现,随着链路的逐级递增,信息的
提高协作效率的底层逻辑是通过减少交付链路层级,缩短信息传递链路,进而保证信息的准确性和传递效率(组织建设层面的内容此处不做展开)。
这就要求具有“今日事,今日毕”的行动力。组织层面叫流程规范,个人层面叫做事方、责任心。
尽量避免将当下的事情拖延到下一个环节,否则就会影响后续链路的排期计划和交付效率,极端情况甚至会出现返工的情形。简言之,考虑清楚,不埋坑。产品需求对研发,研发设计对测试,测试用例对产品等各个交付节点都是如此,交付物一定是靠谱的。
03
技术落地保障
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目标页面展示到屏幕。
在需求响应周期中,高质量的落实架构设计,编码实现,安全上线,部署运营等生产阶段,是软件高可用落地保障的前提和基础。
3.1 架构设计
从整个需求交付链路可以发现,随着链路的逐级递增,信息的架构设计往往影响着系统的前期实现成本(即ROI)和后续运维难度,属于软件的顶层设计,这里面既包含宏观的设计方案,也包含落地细节里的范式约束。
1. 流程保障
1)邀请架构师参与:核心交易节点、重大需求改动邀请架构师参与,这是闭坑最直接有效的方式;
2)重视设计文档:方案描述清楚了,并取得相关利益者的认可,是走在正确道路上的前提。
2. 设计保障
1)容灾设计:要预留后路,提前想清楚,做好容灾设计。可回滚,可熔断,可重试,可降级;
2)鲁棒性设计:无状态设计,防重设计,幂等设计,数据一致性设计。
3.2 编码实现
如果说架构设计是骨架,那么编码实现就是神经,血管和肌肉。前者决定了能走多稳,走多久,后者决定着走多快,走多远。落实到编码层面,就是代码的衰老腐败程度。
1. 流程规范
代码评审机制:代码评审不仅仅是发现系统中存在的问题这么简单。它是一种长期行为,是进行组织文化贯彻和传承的一种形式和载体。评审的过程中,明确了业务职责边界,设计与编码共识,优秀的标准导向等研发共识。相当于通过具象化的案例,给出针对性的指导,这些都是保证团队战斗力的基石。
3.3 安全上线
线上70%的故障都是由某种变更而触发的,其中相当一部分占比是不规范的上线引起的。所以安全上线这一环节至关重要。
1. 流程规范
2. 过程规范
3.4 部署运营
实现高可用的一个很重要的手段就是能力冗余。下面给出方向和思路,具体落地细节和策略,可以根据具体情况各自延展。
1. 网络
04
运营规范保障
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目
1. 运营规范
可监控:系统运行状况
可报警:异常情况能够通知到系统相关人员
可定位:出现问题后,能够快速定位问题原因
可修复:出现异常情况,能够在第一时间进行问题修复;
2. 应急预案
高可用意味着对故障时间的容忍性差,意味着没有时间进行故障排查和修复,更没有时间打开代码进行漏洞排查。这就要求有一套完备的应急预案,这套预案能够解决大部分可预见的故障问题。
1)流程规范:
恢复生产第一;排查问题第二。
详细事故应急处理手册,可以参照下图:
图4 事故应急处理
2)过程规范
再好的流程和规范都需要有对应的机制来贯彻执行,否则就是镜中花、水中月,看着美好,实则没用。可执行,能度量,是按照目标变好的前提。所以这里给出一个《高可用达标定期自查表》的工具,辅助规范落地。
图5 高可用达标定期自查表
05
总结
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目标页面展示到屏幕。
本文从“高可用为什么存在着很大挑战?”的问题展开探讨,强调了需求交付过程中,协作效率的重要性,并指出了为什么要遵从“今日事,今日毕”的工作原则。又从架构设计,编码实现,安全上线,部署运营等几个方面,详细介绍了技术落地保障相关的指导规范和落地细节。最后又从上线后运营的角度,给出了应急预案三板斧,规范达标定期自查表等比较实用的运营保障工具,希望能够给读者带来帮助。