最佳运维实践了解一下

序言

很多事，你不努力一下，你都体验不到绝望的感觉。。。哈哈，越努力越绝望怎么办。。。怎么办。。。哈哈

告警治理暂且告一段落，最近一周都没告警，感觉有点心虚。。。心慌慌。

时间多了，就容易思考，所以来讲述下最佳运维实践。

运维的根本目标

运维的根本目标用一句话总结就是：无运维。无论是从系统的角度来看，还是从技术的角度来看，还是从最终用户的使用来看，就是无运维，系统自动故障自愈，所有的技术的产出也是为了最终系统无须运维，从客户的角度来看，运维就是透明的，无须关心。

运维的个人发展

从个人的发展来看，其实主要的是技术运维，因为技术是最终的生产力，无论你使用的是python，还是各种中间件，nginx，httpd，tomcat，还是各种缓存，varnish，squid，还是各种数据库，mysql，pg，还是各种存储，块存储，对象存储，文件系统存储，最终的目标都是构建一个可靠性强，可用性高，可扩展性强，安全的，成本低的，规模化的系统。无论你学什么样的技术，你最终是为了运维系统。

那么从个人发展的角度来说，最大的价值在于哪儿？最大的价值在于能解决一切问题。无论是客户反馈的问题，还是系统的事件告警故障，总体来说，没有人会关心你采用什么手段来解决这个问题，每个人关心的只是你花费了多少时间来解决问题，无论你是自己去动手解决，还是调动资源来解决，每个人看的只是结果。

从个人发展的角度来说，最大的难点在于哪儿？最大的难点在于如何解决一切问题。你了解系统多少，你能掌握系统的请求，输入，输出，系统的每个组件的功能，系统的数据流，数据的存储，数据流向的日志，调试技巧，那么多的项目，那么多的产品，那么多的组件，那么多的模块，那么多的进程，那么多的线程，你如何用最少的时间投入达到最好的效果，这。。。才是你需要考虑的问题。

从个人发展的角度来说，起始点在哪儿？运维的起始点是对于新系统的好奇之心，想探寻数据的流向，想搭建测试环境，模拟故障。。。而对于大部分的运维来说，死在搭建测试环境的一步就太多了，没有现成的测试环境，搭建就是一件很痛苦的事，各种依赖，各种安装包，各种环境变量，各种后端服务，各种资源，在搭建上面就耗费了太多的精力，而搭建好之后，如何来模拟各种故障进行测试。。。模拟的场景，模拟的请求，模拟的测试。。。你如何来使用测试方法来模拟生产环境的故障，然后总结处理故障的逻辑，这个其实才是最根本的起点。你搭建了一个测试环境，本意在于磨砺你所掌握的理论，你所掌握的技能，但是，如果你不进行各种测试，不进行各种折腾，等到了故障的时候，你还是懵逼，如何在保持压力的情况下进行故障问题处理，成了一个最重要的素质。

其实看运维的最佳实践，也就是找出运维的复杂点在哪里。运维最复杂的地方在哪儿？每个人的场景不一样，有的人可能是不了解原理，出现问题用搜索；有的人可能记不住实际指令，每次出问题都要看一下man手册；有的人就牛逼了，出问题了过一会儿就自动好了。

可运维的系统很重要，如何去构建可运维的系统，那就要靠很多人的努力了。

一句话总结个人发展的运维的最佳实践：了解理论--搭建环境--模拟故障--解决问题--形成通用的解决问题的思路--继续模拟故障---优化--识别瓶颈--自动化运维

如果只是单纯的依赖测试就能获取运维经验，那么整个就不算是运维了，因为运维还是需要脑子的，突如其来的问题，各种突发性的事件和故障。

从客户角度看运维

传统运维是没事要运维干啥，有事运维干了啥。。。没事的时候是多余的，有事的时候是抗锅的。被动型运维是相当累人的。

客户看运维，想客户之所想，急客户之所急。能站在客户的角度思考问题这个就是最大的价值了。

在这里，你所用的技术可能是你所知道的百分之二十都不到，因为客户根本不看技术，你是否可靠？你是否值得信任？我的核心系统交给你，我是否可以依赖你？

信任，那么如何和客户建立信任？。。。这个问题就要留给你来思考了。。。

客户关心的无非是几个问题：

1、 系统每周的运行情况，例如SLA指标，事件告警故障数量

2、 系统的资源统计，例如分布式存储，还能存储多少数据，剩余空间多大，是否需要扩容

3、 故障影响范围，故障报告，本质原因，是否彻底解决，如何预防

4、 新上线一个系统，有什么好的建议，如何规划，如何做标准规范

有的时候，技术人员去汇报，去开会，看起来很浪费时间，不。。。就是浪费时间，但是却有巨大的价值，有的时候就和八二法则一样，用最小的成本能换取最大的回报。但是，作为技术人员，一般会用最大的复杂度去解决问题，因为。。。这样才能秀一把技术。

主动巡检，主动创造故障解决故障，这叫故障演练。。。。主动测试系统，主动进行高可用性测试。。。破坏系统，然后修好系统。。。如何主动才算主动，这又是一个度的问题，影响了生产的服务，主动抗锅！！！