故障自愈了解一下

    一转身，一阵风，一个世界。。。。在你一转身的时候，是更加魅力，还是。。。

    我以为别人尊重我，是因为我很优秀，逐渐。。。慢慢的明白了，别人尊重我，是因为别人太过于优秀，太过于卓越。

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

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

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

    何为故障自愈：一个服务出现了问题，例如进程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。。。。