运维经验总结

这几天对这一年的运维工作做了一些总结，然后有一些思考，整理出来发一篇，希望2020年工作可以更轻松

多做计划

墨菲定律其实是一种心理学效应， 原文为：如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人会做出这种选择。根本内容是：如果事情有变坏的可能，不管这种可能性有多小，它总会发生

在运维工作中，这种情况很多，晚上做网络割接，心里一定会想，千万别出问题，结果网络切断了

服务器需要重启，一定会担心会不会起不来，结果就会起不来

担心网站挂掉，总会在半夜的时候挂掉

……

运维工作中，很多这种情况，总会有“意向到的意外”，所以需要有更多的plan

很多公众号写文章说使用某某监控某某架构不做救火运维，扯犊子呢，我就没见过不救火的运维

运维工作要保证可用性，所以很多意想到的可能性很小的事情，也需要提前做好计划来应对，这也是运维工作中要做的应急响应计划

一定有原因

运维工作中，很多时候会有很奇怪的故障或者问题出现

一个脚本从这个服务器复制到另外一个服务器就不能执行了

一份配置，在配置一样的两台服务器，却有一台不能用

上一秒还在检查的故障，突然自己好了

……

很多人在群里会这样问，觉得很神奇，反复对比两个环境，一模一样，其中一个就是不能运行，其实神奇，是因为你对这个东西不了解，你没有找到关键的地方，既然不能运行，肯定还是有不一样的地方

你可以去strace查看它的执行过程，你可以去抓包查看每个数据包对比，总能找到问题的关键，找问题的过程，是你熟悉这个知识的过程，找出问题的结果，是你对这个故障的一个宝贵经验，所以一定要去探索问题最根本的原因，即便最后你查不到最根本的原因

多做尝试

运维这个工作，就是个技术工人，技术高的就是高级运维，有自己技术创新的就是运维专家，初入门的，跟着师傅的，就是搬砖运维

初级技术工人，要成为专家，就是要不断的去做相应的工作，积累经验，经验积累到一定程度，就可以是专家，

很多人遇到问题喜欢群里、知乎、知识星球这些地方去问，比如监控用zabbix好还是 Prometheus好，还是open-falcon更好，系统用CentOS好用还是Ubuntu好用，k8s好用还是k3s更适合你

为什么不自己去搭建，去测试，抛开每个人的业务情况、系统配置不说，群里的人说的你就相信吗？有多少文技术文章是抄来抄去，错误都不改的。现在有虚拟机、有按量付费的公有云，花十几块钱、花一些时间把你想要了解的东西，搭建一遍，你会在这个过程中得到比你在微信群里得到的一个不一定对你来说正确的答案更多的东西

你想了解的东西也好，你维护别人的环境也好，处理故障也好，多去实践、尝试你的想法，在这个过程中，你会这个东西有更深入的了解，对你的技术提升有很大的帮助

别人说的不一定是对的

接上一个问题，你不去尝试，直接从搜索引擎或群里获得一个结果，对于运维这种环境复杂的情况来说，别人的结果是在别人的业务和配置情况下的一个结果，虽然很多情况下，我们都可以参考别人的配置、别人的脚本，改个参数就可以用，但只适合参考，很多时候，你去测试别人的配置，发现在你的环境下竟然是完全不同的结果

参考别人的，只是在自己解决问题，没有思路的时候，去找到一个方向，但是不要固化的认为别人这么配置就可以用，就得这么配置才是对 的 ，你按这种方式配置了，你一定是搞错了

程序为什么会有bug，就是因为开发的人没有想到这个问题，所以不管是官方的文档，还是有经验的人给你说的经验，你都只能当作一个参考，更重要的是去实践，勇于怀疑，并去探索验证

了解每个配置的意义

运维工作，基本就是用命令工具和中间件工具去支持和维护服务正常运行，天天在和命令打交道、天天安装配置各种中间件，每个命令每个中间件，每个开源工具都有自己的一套“说明书”，对每个参数都有详细的解释

在使用前尽可能去了解、学习并实践每个参数的意义，或者说作用，对你的工作效率或者说做出的运维工作会有很大的不同

比如Dockerfile中，ADD和COPY，你要不了解的话，会觉得，都是往容器里面加文件，无所谓，那你觉得人家开发设计的时候，为啥要设置两个参数呢，他闲的没事干，玩呢？

你发现你COPY构建的镜像比别人ADD构建的镜像要大，因为你COPY把压缩包放进去，还需要RUN去解压，而ADD直接解压了

当你去下载个包，然后再通过COPY复制进去的时候，人家早就通过ADD加载链接的方式直接打包进去了，当然这里更推荐再打包的时候用curl或wget去下载远程文件

所以说，要尽量去了解更多配置项和参数的作用或意义，很大程度上能提高你的效率

思路很重要

运维过程中，经常遇到各种各样，摸不着头脑的问题，而且很多时候，你所看到的问题，并不是你所看到出现问题的这个中间件或者工具引起的，报错日志也不会给到直接的错误原因，这个时候你去排查问题，就是看你思路的时候

你需要根据你的经验及知识，去理清思路，根据自己的思路去检查、排错、尝试，而不是像无头苍蝇一样，胡乱的尝试，很多人根据别人的建议胡乱尝试，最后把系统重要组件卸载，服务器挂掉，这种例子很常见

他能知道你什么情况吗，他能比你更了解你的环境吗，你需要有自己的思路，自己去思考问题可能的原因，否则你连搜索引擎你都不会用

比如你的网站，使用nginx前后端分离，请求的时候，提示跨域，你去搜索引擎怎么搜？ ”nginx跨域如何配置“，搜出来一堆，然后你按照别人的配置， 在 nginx配置文件中添加了add_header，允许所有跨域请求，结果发现request_header中根本都没加上这个header，然后你开始查”nginx跨域配置不生效“，结果别人各种方法，加在http里面，加在server里面，加在location里面，你跟着尝试了一遍，发现仍然没有效果，最后你才发现，你的静态资源加了CDN，CDN那边没做跨域处理

你要自己先脑子里有个你自己系统的拓扑图，你可以脑子里，也可以画出来，然后你感觉哪里会引起目前的问题，你去解决，不是跟着别人的思路去尝试

持续关注新技术

我是做互联网运维的，不是传统的运维(那种机房看监控的)，对于互联网的快速发展，大家是有目共睹的，各种开源项目不断涌现，各种新的开发语言应接不暇，好多人调侃说，学不动了，是真的学不动了，新出一个东西，有些人还没听说，就已经过时了，这就是互联网速度

但是，不要做井底之蛙，我的建议是持续关注新技术，不管是开发的也好、产品相关也好、网络相关等等，现在信息时代，获取信息很方便，你可以每天上下班的时间，去订阅一些公众号，把一些娱乐的新闻换成这些技术公众号，你可以不去详细学习每个出来的新技术，但是你要知道有这些新的技术，为啥？

这又接上面一个话题了，思路，为什么出个故障，别人定位问题很快，你半天定位不到问题，别人处理问题的时候花样百出，你只能花式百度，关注各种新技术，能让你的视野更开阔，定位问题的时候，能够更全面的去思考，而不是仅限于你自己管理的那个中间件上面

新的技术，一定是为解决就得痛点而诞生 的 ，所以，当你不断得关注新的技术的时候，你会发现很多你之前遇到的问题，你可能花了好长时间，费了很大的成本才解决的问题，别人一个命令就搞定了

比如我之前搭建ffmpeg去处理图片，大家都知道，CentOS系统的源码库的项目都很旧，更新没有ubuntu那么快，这也是为什么服务器都选CentOS系统，选Ubuntu少的原因，因为旧的相对来说要稳定一些，在CentOS7还好，ffmpeg已经可以yum装到2.8的版本吧，大概，但是CentOS6的话yum只能到0.6的版本，很多格式不支持，怎么搞，编译安装，最开始我用了半周的时间去搞这个，因为他要的以来太多了，以来版本还不能又差，但是现在怎么样，我写个dockerfile，用alpine系统，把最新的4.x的ffmpeg装进去，然后docker run一条命令我就可以剪辑音视频

所以，你可以不去学习每个新的技术，但一定要关注新的技术

新技术不要急于上生产

接着上面一个话题，你要持续关注新的技术，但是在生产环境不要急于引入新技术，为什么？

你看政府单位，为什么系统还在用winxp、win7，是win10不好用吗，还是他们没钱换，都不是，是稳定，更换风险系数高

互联网时代，我们都讲快速交付，很多项目，都是demo的时候就交付使用了，然后边使用，边迭代，但是，这有个问题就是，增加了软件或者项目的不确定和不可控性，不说那么高端的东西，就说我们用的很多开源工具，很多刚上线觉得很好的工具，你觉得应该上到线上，提高工作效率，没几天，你发现，别人开发了同类型的项目，是大厂开发的，比这个要更好，你怎么办，天天换吗？

有大厂开源了个项目，你觉得应该没问题，大厂的项目，后期很多又很多人维护，很多人使用，Tengine中间都一度不更新了，你觉得还有什么是不可能的吗？

况且，觉得你有能力作为开源项目的第一批踩坑者吗？你有能力，你觉得公司有成本陪你踩坑吗？在网上没有任何别人经验可以借鉴的情况下，你能处理你用于生产环境的这个新技术的故障吗？

不是不可以上生产环境，是需要等别人坑踩实了，你在上，你可以在测试环境去学习，去了解，不要再给自己找不必要的麻烦，你可以问问你自己，是不是很多时候的加班，都是自找的，明明之前的项目架构很稳定，非要改个中间件，引发了一系列问题，加了一个月班，还被老板骂，下班健个身不好吗？

极简主义

不管是做架构、是做优化、写脚本、写管理后台、做服务器管理，最好极简化

为什么要极简化呢，因为复杂的架构或脚本，会让运维处理故障更加困难

最近DevOps很火，带动Jenkins很火，自动化构建发布，于是很多运维就开始着手把自己的项目进行一个改造，本身就是小公司，原本就2台服务器，一台web，一台数据库，项目用git直接发布，也很省事

然后通过gitlab+jenkins一通改造之后，服务器成本加了两台不说，还搭了好几个加班，jenkins他又不熟悉，每次发布出问题，都要等他处理半天，有时候拖延了发布时间，最终还是用git发布上去

有时候架构简单点也是好事，不一定非要复杂，运维工作中，最重要的是实用，实用才是王道

当然该要添加优化的时候，还是要添加，但是不要盲目，比如你想session存redis，本身项目也不大，那你单redis节点就够了，redis也够稳定，也不会经常掉线，你完全没必要去搭建个redis sentinel模式

再一个极简就是，服务器上不要放太多乱七八糟的东西，很多人备份会在web目录下存放打好的tar包，不说你占用资源，备份的时候备份文件大不说，从安全角度，你这是”开源“了啊，你是怕别人不知道你写了多少bug吗？

数据最重要

对于一个公司来说，数据是最重要的东西，所以数据库是重中之重

从两个方面来说：数据的安全性和数据的可用性

作为运维人员，这两个问题是一定需要去考虑的，数据的安全性来说，可能不光涉及到运维的环境，及安全运维的防护工作，还涉及到开发的代码安全，需要做代码安全的审计，但从运维的角度来讲，需要通过一些常见能做的手段去保障数据的安全，当然是根据业务及成本考量的，不能说你就一个几千块的网站，上个几十万的防火墙，这肯定没必要

单从运维来说，要做到运维规范，配置规范，异常请求日志检测及告警、权限最小化、web数据库分离，数据库安全模式等常见方式，根据不同的业务情况有所不同，更多的可以关注公众号，加好友探讨

数据的可用性，是运维日常工作中接触更多的，解决方案就是备份，备份的方式很多种，快照、脚本备份、异地备份、实时备份、热备、冷备等等，根据自己的需要选择

备份有个问题就是，要确保备份的可用性，所以要经常定期去做数据可用性检查，用测试环境或预生产环境，去测试数据的可用性

还有一个就是运维操作的可恢复，很多运维命令是危险的，比如rm -rf，echo >，drop等，没有人是不犯错的，所以，除了敲下回车键的等待1s，做个检查外，最好的方式就是操作前的备份，对于心里没底的事情，更是要谨慎操作，因为有些时候，你的一个回车，是一个公司不能承担的

最后

以上就是今年的一些总结吧，可能写的不是那么好，但是都是一些谏言，与各位运维朋友共勉吧，2020，早点实现运维自动化