最佳运维实践了解一下

序言

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


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


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


运维的根本目标

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


运维的个人发展

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


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


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


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


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


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


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


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


从客户角度看运维

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


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


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


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


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

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

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

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

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

    

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


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


扯淡

     努力了才会绝望,其实。。。绝望也是对思想的一种磨砺,磨砺你的内心,看看你的内心是否坚定


    其实对于技术过度执着也不是好事,所谓的精通,如何才算精通?会搭建环境?会处理各种突如其来的故障?了解各种原理和配置?看源代码?分析每一个数据块?无底洞。。。


    何为完美的体验???


    用最复杂的架构解决最简单的问题,用最先进的技术解决最简单的问题。。。没有人,没有时间,没有精力。。。。其实又要扯到权衡上面,秀技术,要的就是复杂;而合适才是最重要的。。。。慢慢的演进然后就变成了复杂,而在演进的时候。。。又要保持简单。。。。


    复杂性。。。复杂度。。。呈线性增长。。。。懂的越多,复杂度越高,越来越难以触及完美的境界。。。心境不圆满,不能突破这个境界了。。。。


    浴火重生的方式总是最难的一种方式。。。我能怎么办,我也很无奈啊。。。还好,我躺在床上磨砺我的思想。


    天生的问题解决者,这道难题。。。还是很有难度。。。。无风不起浪。。。。浪不起来。。。。风又不来。。。


图片

    欢迎留言,谈谈你认为的运维的最佳实践是啥。。。。欢迎探讨


     欢迎留言,谈谈你认为的运维的最佳实践是啥。。。。欢迎探讨


猜你喜欢

转载自blog.51cto.com/15060545/2653267