对运维的一些思考

随着网站流量越来越大，故障发生的频率也越来越高。怎么能减少故障的时间呢，加快故障处理速度？
当业务发生问题之后，运维能做什么？
运维在平时除了日常的变更工作，还有做什么工作帮助业务发现问题，解决问题？
运维开发团队又能为业务和运维提供哪些服务，解放运维的工作，帮助业务减少问题的出现？

对以上问题，在总结故障之后，得出自己的一些思考

故障前

总结之前的故障，发现更多的情况是业务方并没有按照运维提供的标准做事。
我的理解，运维在日常的变更工作之外，最重要的事情就是制定标准。只有标准化一切，否则自动化运维更是无从谈起
具体的标准有哪些呢？

硬件规格
操作系统
基础配置
中间件版本，使用规范
代码规范
部署路径
日志路径
如何监控，监控哪些指标（非常重要）
….

等等等等，只要能想到可以标准化的事情，全部做到有标准，有规范。对我们的团队来说可能是处在有标准，但是没有和业务共识。所以如何将标准落地，如何拉进运维和业务开发的距离非常重要。个人认为，运维一定要离业务很近，和业务开发穿一条裤子，才能保证所运维业务的稳定，以及更加快速的处理问题。这就像业务开发必须离需求很近，运维开发要离运维很近一个道理

故障前运维还能做什么？比如，故障的预案，有了预案就需要故障的演练，甚至在新业务上线之前，如何评估容量，压力。这些都需要运维从自己的多年经验的角度和开发一起做这些事。

故障中

当故障发生之时，运维又能做什么呢？协助开发排查问题，用自己的经验通过蛛丝马迹快速定位问题。用各种强大的自动化系统如日志，监控，tracing等系统快速解决问题。

不过我认为，除非真的是运维本身的问题，比如网络，服务器磁盘等问题，如果真的是业务开发自己的代码bug，在故障中，查找问题之时，运维还是很难帮助到开发排查问题的。

真正要做到的还是在故障前落实标准

故障后

我觉得不论运维还是开发，对每一次故障都要有刨根问底儿的精神。故障的原因究竟是什么？为什么会发生？如何避免？以后遇到的解决办法是什么？开发和运维要做到一起复盘一遍。不是为了甩锅，是为了让系统更健壮，故障不在发生。

这里我觉得有两个关键点很重要：

用事实说话：分析故障原因不能靠猜，要用事实来说话，当时每个节点的日志是什么？对应故障发生时间有什么变更操作，记录是什么？等等
故障报告很重要：详细的故障报告书写，沉淀成为知识库。对后人，对自己都是有很大的帮助

运维开发能做啥？

运维开发团队做什么事情才能算是真正帮助到运维了，才能算是一个有意义有成就感的团队，我的理解有如下几点

对标准

通过一系列的自动化运维系统，帮助运维落地标准。比如集中的PAAS层约束中间件使用标准，发布系统约束开发代码标准，完备的监控系统（很重要）约束监控规范等等

对运维的日常工作

开发团队的存在就是为了解放运维的生产力，不管哪个系统我自己总结就是需要有流畅的体验，说起来简单，但是要是想让运维，甚至开发们有这种体验，做起来还是有很长的路要走的

对外提供的服务

运维开发团队和运维也会对开发去提供基础的一些服务，比如PAAS层的一些服务，发布等等。运维的系统可能量不会很大但对于这些系统来说以下两点尤为重要

高效问题的提供服务
准确的数据

每个系统做到以上两点以及可以及格了

其他

说了几次监控很重要，因为他是真的很重要，我们把监控叫做运维之眼，运维能不能睡好觉，监控至关重要。这里只想说一点，每个业务最好去定义自己的关键指标，而关键指标必须保证能告警。这个指标可能是url，可能是qps。总之需要运维和业务一起商量确定