这个题目很大,我只是简单说补充一些浅显的想法。
系统故障是常态,系统正常才是异常状态。
考虑一下,一般复杂的分布式系统需要满足下面的条件才能正常工作:
一、a、b、c、d、e等其所有的系统组成部分均工作正常
二、这些组成部分之间的连接都正常
按照目前微服务化的潮流,一个系统有上百个服务相互依靠、相互调用都不稀奇。
这种情况下系统出现故障的概率很高,此时系统正常运行简直就是灵异事件。
面向故障设计
design for failure
使用稳定性设计的一些思路和工具,在设计阶段提高系统正常运行的概率,
如冗余、限流、降级、超时、熔断、隔离、自动扩容等等技术。
至于这些五花八门的技术措施,谁能保证不遗漏?
使用检查单,虽然有一定作用,但是针对每个系统究竟需要采用哪些稳定性设计,需要具体问题具体分析。
如何验证系统设计实现了稳定性需求呢?有效的测试。
面向故障测试
良好的单元测试,可以检查出模块内部的逻辑错误,但是很难发现较大尺度上的设计问题。
这时需要在测试阶段引入故障注入、甚至自动故障注入。
故障注入的实现方式:
1、通过代码注入,修改被测试的服务与外部交互的接口代码,来模拟各种故障。
类似热补丁(monkey patch)之类的技术可以实现这种方式。
2、通过无侵入的专门制造故障的服务,自动模拟各种故障:网络不通、访问超时、数据库宕机、磁盘慢等等。
最变态的当属netflix的chaos monkey,随机制造各种混乱而且是在线上环境。以攻为守的典范!
面向故障运维
出现业务故障时,胡子眉毛一把抓,按照业务调用链条,逐一排查各个服务。
单单确认故障点,就得花半天的功夫,累的头晕眼花,不能快速恢复服务和定位故障。
99.99%的SLA就只是嘴上说说,当不得真。
这时全链路跟踪系统可以帮助我们减轻应对故障的烦恼。
全链路跟踪系统的实现思路可以参考Google的Dapper论文和 netfix的zipkin系统。
通过全链路跟踪,可以快速发现性能瓶颈点和故障点、清晰地看到各种服务的依赖关系和服务质量(QPS等)
故障事后分析
故障事后分析的目的是找出根本原因,总结改进措施,通过责任人落实改进措施。
至于相关人的责任是否追究,如何追究,需要看事情本身的性质。
某些公司事后分析的流程:
遇到严重的线上bug,都责令相关人员,让开发人员做RCA(根本原因分析)。
RCA分析还有模板文档,规范了按照一二三四五等等步骤如何分析。
目前看起来像模像样。
但是做RCA十分费时间,不给相关人员做RCA分析的充裕时间,那么开发人员手头的其它任务因为这个RCA而延迟,
如果其他任务延迟,开发人员要么自己加班完成延迟的任务、要么接受延迟的事实,接受负面的考核。
而且分析的结果一般都是增加一些管理流程,相当于开发人员自己给自己戴紧箍咒,自然不热衷,
结果开发人员一般就是走一下流程而已,
而主导分析的相关人俗套的思路是:我们是不是缺乏一个流程来把控?如何增加一个检查点?是不是相关人员的质量意识不够,态度不端正?如何加强员工的责任感?
作为喜欢用技术解决问题的人,我自己的观点是:
管理思路和流程,最终要体现在技术解决方案上。
首先要考虑如何将通过技术改进。
只有技术不到位时,才需要依赖精细的流程管理和各种流程的人工检查、checklist。
另外技术不到位,还需要考虑是否可以使用简单的替代技术,实现管理思路的落实。
各种checklist满天飞,是把希望寄托在最容易犯错的人上。
如果做一个事情,给你一个检查单,上面有一百零八个检查点,仅通过人工点检,
这既不不科学的做事方法,也是对人的耐心和责任心的极大的考验!
人只能引导,最好不要考验。
题外话
知道需要该做一些事情 和 知道怎么做这些事情,存在巨大的鸿沟。
遑论真真正正、切切实实完成这些事情。
领取专属 10元无门槛券
私享最新 技术干货