故障自愈了解一下

故障自愈

越努力越孤单,好像这是一个宿命。。。

追求卓越从而导致不合群,慢慢的孤独久了就习惯了。。。

其实一个服务,一个进程,一个线程都是一样的,当一个服务能做到故障自愈,那么就会被人遗忘,一个自我能管理的服务是最好的,是最让人省心的。

何为故障自愈:一个服务出现了问题,例如进程hang住,进程假死,那么监控程序发现服务出现问题,从而采取相应的措施,可能是重启进程,也可能是重新加载进程。。。那么问题来了,你如何判断这个服务除了问题,而定位到这个问题,这个则有变成了更加棘手的问题。

一个服务出现问题,可能有千百种可能,而尽快恢复服务是最关键的,那么如何尽快的恢复服务,如果采取了这种故障自愈的机制会不会导致隐藏了一些问题的发现,从而导致一些BUG一直存在于系统中?

用最简单的方式来演示故障自愈,以下是故障检测脚本:

以上是一段测试nginx的服务是否正常的脚本,主要就是通过发送http请求到nginx,如果nginx给与200响应码,那么就表示服务正常,如果不是。。。那么采取的动作就是重启nginx服务,记录的日志如下:

在上面的测试中,采用手动停止nginx进程来模拟测试,发现可以正常启动,从而达到服务可用的目的。

在故障自愈中,主要有两个方面需要重点考虑:

1、 如何判断服务出现了故障,在上面的例子中,主要是通过发送http请求来进行判断,可能会有误判么?如果此时nginx负载很重,来不及响应http的请求连接怎么办,请求连接超时怎么办?判断几次才算是服务不可用,3次?七次?判断的间隔时间是多久,3S?还是7S?

2、 服务故障了,应该采取什么动作?重启服务?重启服务器?清除缓存?杀掉进程让supervisor服务自动拉起?

其实,没有银弹。。。没有标准,例如判断请求的超时,多久才算超时,要根据你的业务量来计算,可能凌晨业务量很少,出现故障了,基本上是服务挂了;那么如果业务高峰,没来得及响应。。。那么整个中间不可用的时间是多少S?根据SLA来设定这个指标也是不错的。。。

鼓吹无运维

鼓吹无运维来源于。。。devops,因为差不多所有的服务都可以做到故障自愈,所有的服务都无须运维干预,那么慢慢的就可以无运维了。

在写程序的时候,你就考虑到了监控的指标项。。。。在程序上线的时候,你就考虑到了如何进行高可用。。。在程序上线的时候,就已经有了故障自愈,那么还要运维干啥。。。看日志?谁都会。。。。写程序的更加了解应用的架构。。。

梦想是美好的,现实是骨干的,所以故障自愈也不是一步到位的。。。

如果我发送的包你没有拒绝。。。但是也没有响应。。。我该采取什么动作???

是否能做到故障自愈?是否在一转身的时间。。。变得更加完美。

self-healing。。。。so beautiful。。。。

本文分享自微信公众号 - SRE运维实践(gh_319dd73ec076)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-06-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券