分布式系统之故障管理

这个题目很大,我只是简单说补充一些浅显的想法。

系统故障是常态,系统正常才是异常状态。

考虑一下,一般复杂的分布式系统需要满足下面的条件才能正常工作:

一、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满天飞,是把希望寄托在最容易犯错的人上。

如果做一个事情,给你一个检查单,上面有一百零八个检查点,仅通过人工点检,

这既不不科学的做事方法,也是对人的耐心和责任心的极大的考验!

人只能引导,最好不要考验。

题外话

知道需要该做一些事情 和 知道怎么做这些事情,存在巨大的鸿沟。

遑论真真正正、切切实实完成这些事情。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180404G1QSSD00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券