最近一段时间回顾了一下我这些年一直在做的运维工作，慢慢理顺了一些东西。
我对运维的理解至今一共经历了四个阶段，分别用四个词来表述：
- 稳定
- 效率
- 标准
- 目标
第一阶段 - 稳定
此时我刚毕业入行，经常听同行说起某服务器几十万一台，一块服务器硬盘几万，每天几百万交易量，几千万用户等等词汇。
而我做为一个月薪2千的小年青来说，内心自然是极慌的，经常想的是要是我弄出啥问题可咋办啊。
还有就是，
当年信息封闭程度也很高，开源共享精神也比较弱，很多资料都不好找。
很多职场上的老人都藏着掖着，可能也和自己也找不到专业重心，去问前辈也不知道该问什么。
比如直到我第一次去机房摸到第一台机架服务器前一直觉得服务器很神秘。
还记得第一次进行上线变更，其实就是把某个非核心业务的脚本改个参数，然后重启一下服务就可以了。因为是内部业务系统，下班后也就没有用户了。
我还战战兢兢地在无人的办公室等到晚上10点才开始操作，当时内心特别激动。
而且经常听别的部门或公司又又发生了什么重大故障，或者是被攻击了，造成多大影响什么的，觉得非常可怕。
于是这一阶段我的感悟是：
线上稳定性是第一位的，把运维(自己)定位成保镖的角色, 业务中断就等同于雇主被干掉了，其它花活再好也无意义。
在这种思想的影响下，做起事来小心谨慎，力求稳定，每一项变更都反复求证可能的影响和应对措施。
优点就是项目线上基本不出啥问题。
缺点就是这一阶段似乎没学到啥真东西，因为不会真东西所以做事又更小心了，恶性循环。
业务上几乎是个透明人, 别人总喜欢绕开你去做事情。
第二阶段 - 效率
后来工作逐渐忙了起来，如何忙呢？
有一段时间独自干一个项目的运维，有几百台物理机，硬件、系统、应用、业务等几乎啥都要干。
这还能一味地稳定吗？
于是开始追求效率！
基本原则就是"能批量的批量，能并行的并行，能自动化的上自动化，能异步的都异步"。
经常都是，上午发现问题，中午出方案，下午做测试，晚上就上线。
举几个代表事项
- ansible 和shell脚本 搞得算是比较熟了；
- python 搞得还算可以，以往的手工报表都尽可能的改为了自动化报表；
- 任何工具或命令，都想着下次能不能复用，可能会复用的都进行留存。
这一阶段我的感悟是：
效率才是一位的，别人三天能干完的活你一天干完，或者是3个人做的活你一个人做完，这才是能力，才有价值，才能涨薪。
优点是这阶段确实涨薪很快，而且因为胆子大起来了也学到了很多东西。
缺点就是人为造成故障有点多，多是某些线上变更考虑不足所引发的故障，报告写得手软。
第三阶段 - 标准
再后来因为同时负责好几个项目，而且环境差异较大等原因，干起活来总是觉得哪里不对，效率也提不起来了。
仔细琢磨下发现因为环境不同，所以很多东西都不能复用，做了大量重复性的工作。
例如一个相同功能的脚本，不同的项目, 主机, 不同的阶段等都需要去多次修改。或者是不同项目需要的文档其实差异项很少，但又经常重复写。
然后我似乎发现了关键点: 标准化
于是我力推标准化，例如
- 主机标准化: 规格，分区，系统配置等；
- 应用程序标准化: 版本，部署路径，日志路径，运行用户和权限，启动脚本等等；
- 日志标准化: 集中存储，统一日志格式，引入ELK集中展示等等；
- 监控系统改造为统一接入, 并只使用 http 方式获取数据；
- 这阶段恰逢项目上云转型，容器方面的标准化等等
- 推动 GITOPS 概念落地；
这一阶段我的感悟是：
标准化才是第一位的，有标准才有效率，才可能稳定。
而且线上故障是难免的，如果没有标准环境，排查起来也会非常耗时；
而且千奇百怪的环境，新同事很难短时间上手，也很难举一反三。
优点就是几个项目线上真稳定了不少，因个人原因造成的故障减少很多，故障排查效率也有明显提升。
缺点就是因为不符合预想的标准，拒绝了很多优秀的方案进入。这段时间对个人能力提升似乎很有限，而且感觉工作效率提升并不明显。
第四阶段 - 目标
后来的工作逐步更倾向于实施类运维工作，因为一些原因我对运维的理解又加深了，例如
- 完全无故障是不现实的，而且客户其实对稳定性要求不那么高，只要关键时候别出事就行；
- 事情是干不完的，客户的需求其实一直会变，会有各种要求出来，效率很重要；
- 旧标准也是一种标准，很难撼动的，特别是客户的环境，更重要的还是去适应；
- 时间节点很重要，一项功能如果不能在最需要它的时候上线，价值就会大大折扣；
于是我目前的理解是: 目标才是第一位的；
如果没有明确的目标，人就会做很多的无用功，这部分无用功又大大增加了不稳定性和降低了效率。
这个目标当然是按时按质的交付客户所需要的目标，而不能是偷奸耍滑、蒙骗客户随便包装些垃圾去交付；
对于日常的运维工作也是一样的；
- 线上绝对不可能完全不出问题，只不过我们尽力将可用性提升到 99.9999999999% 去；
- 当前需要的才是最合适的，以前引入的很多方案都属于高射炮打蚊子，自己费很大力不说，还没有啥产出；
- 目标驱动，没有有价值目标的事情最终都会变成磨洋工；
- 与目标无关的事情，尽量不要去碰，保持专注；
对目标的理解
这个目标并不只是局限于把客户要求的活或老板要求的活干完。
因为一般来说干完这个活马上就会来下一个活，解决一个问题以为能松口气，其实新问题已经来了。如此下去活就真是干不完了；
这个目标应该是客户或老板为什么要做这个项目，他们期望的最终效果才是目标。
应该直奔目标去做事，而不是喊一声走一步，这样自己就不能控制节奏，干起事来就会非常累；
举个例子：
一般场景下，
上级说: 我们要上一个服务，你调研一下吧；
此时就要一次性搞明白最终需求。
如: 是要解决什么问题？背景是什么，如果顺利那么预期上线时间，周边的配合人群，风险点什么，可以协调的资源等等问清楚。
再做几份预案，中途因为某些不可解因素影响时，立马再切换备用方案。
最后达到一种效果:
老板或客户交代的问题，一次性搞定，并且也很难挑刺。
对自己也是件好事，
例如一百件事情，你一件一件的干，就会觉得事情很多，咋就没完没了；
但如果合并为一件事情，即统一为一个目标，人就会觉得事情也没多少了，也就会轻松很多了。
明确了目标更容易和外部进行协作，如和研发人员，测试人员配合时，只要目标达成了一致，很多事情就会非常顺利，并且也更容易获取老板和客户的资源支持。
在我写完这篇文章后，我看到了一篇文章，也是一位运维同行描述的职业经历和觉醒历程，有异曲同工之处，推荐给大家也看看。
https://mp.weixin.qq.com/s/QWz7Gb1tReUByLHzL_MRYg
