我对运维的思考

我是一名Java后端研发工程师，在我的职业生涯中，曾做过一小段时间专业的运维，而后在一段很长的时间里兼任过运维职责，只不过职责范围在小和大之间来回奔跑。

一、Linux命令是基础，万变不离其宗

我所待的几家公司，或多或少要做运维相关的工作，其中Linux是最常用的，这个Linux包含Linux常用命令和操作系统(如Debian、红帽、Gentoo、Ubuntu、CentOS等)。其中我接触最多的就是CentOS和Ubuntu。

为什么说Linux命令是基础？

• 命令行界面以Linux命令作为基础，如果不会敲命令，也就无法使用(各种软件安装和问题排查都涉及);

• shell脚本就是由一条条Linux命令组合而来，掌握好Linux命令，你就可以写出各种各样的符合实际需求的脚本(服务监控、备份、项目部署等)。

另外再从另外一个角度来看，不论是专业的运维人员或开发人员都需要掌握Linux命令，只不过程度不一样，对于运维人员必须掌握牢靠，毕竟是吃饭的家伙，对于开发人员，开发写出来的项目大多是部署在Linux上(有一部分是Windows Server)，涉及生产环境的问题排查，必然需要熟知一些常用的Linux命令。

二、自动化

自动化这块对运维非常重要，自动化涉及最多的就是写一些shell脚本放在特定的目录归类好，按需执行。

现在有很多现成的软件可以将一些工作自动化如(jenkins持续集成(拉取项目、自动编译、发布等)、zabbix自动监控服务器CPU、内存、磁盘和JVM、MySQL等、Ansible轻松管理上百台服务器等)。

有人幽默地说:不擅长将工作自动化的运维不是好运维。

在我做运维相关的工作的时候，发现像部署或者一些软件的备份和安装就那么几条命令，敲来敲去，敲了N多遍，虽然可以复制粘贴，但是感觉还是太过麻烦，于是写一个shell脚本，只需一键执行即可。这样一来就可以节省更多的时间。

更多的时间可以用来思考更多，比方说现有的运维体系哪些不是很完善或者是之前遗留的哪些问题(不那么紧急但比较重要)可以现在来解决。
再或者对于一些软件它的一些设计原理和思想是什么，也可以研究研究。再或者是配置文件，为什么要这么配置，每个配置是什么含义。

在我做运维的时候，网上搜索安装和配置软件，基本上就是复制过来一步步来，但后来发现有一点不好的就是我对于为什么这样配置不知道，不知道意味着可能存在一些风险，运维人员要想进步成长，对一些软件不仅仅做到知其然，更要知其所以然(与我们研发人员写代码一样，不仅仅要懂业务逻辑和代码执行逻辑，同时也要知道所使用的库，底层是如何处理的)。

安装软件谁都会，但要说到软件的配置，如何配更合理更符合实际场景那就是一门比较深的功夫。

那么如何做到自动化呢？

要养成”懒”的习惯，就和研发人员写代码一样，发现多段重复的代码，于是将其抽取为一个方法进行调用(不用在复制来复制去，影响可读行，同时也增加代码行，代码行越多确实不便阅读)。运维人员经常使用Linux命令，在敲的过程中总会能够发现哪些是重复多次的，重复多次的就可以写成一个shell脚本。

自动化的好处有哪些？

最直接的好处就是:你动脑思考了，思考如何简化工作，提高效率。这样一来给你直接带来的就是实力的提升。

其它的好处就像上面说的，你可以有更多的时间来思考如何做的更好或者学习(我第一家公司的运维同事在自动化方面做的很不错，同时他的Linux功底也非常好，基本上工作做的特别快，效率也特别高，因此他有更多的时间去思考，去学习(业务或者技术层面)等)。

还有一个最重要的原因，如果你不擅长将工作自动化，最后可能会累的要命。累的代价就是身心疲惫和停止思考(人在非常累的时候写代码，非常麻木，根本不知道自己在做什么，只是在重复动作)。

三、要懂业务

在一些互联网公司，开发人员不懂业务的话，工作几乎没办法进行下去。对于运维人员来说，可以不懂。这是我曾经的看法。

后来经历多了，发现还真不是这样。什么样的业务决定使用什么样的架构(逻辑架构(如分层:数据访问层、业务逻辑层、表示层等)、开发架构(SDK和一些第三方库等)、物理架构(部署和运行)、系统架构等)，其中物理架构(操作系统、网络、服务器等)、数据架构(数据表设计、高可用、备份、复制等)。

根据合适的业务，选择合适的架构。对架构师而言非常重要，对于运维人员也同样如此。

同时懂业务对于运维人员排查问题也是很有帮助的，因为懂流程，懂流程意味着可以重现，重现问题过程中，打开对应的日志，这样一来能准确的定位到问题，看是因为服务器的原因还是某个开发人员代码写的问题(服务器的原因通常那段程序执行需要更多的内存，服务器内存可能不够;代码的原因通常是一些判断逻辑不是很完善导致程序没有按照正常流程走)。这样就能减少运维背锅的概率，也能有理有据的反驳。

四、要有一套完整的运维机制

曾看过李鹏写的《IT运维之道》这本书，大部分忘记了，但其中提到的IT运维四要事，至今印象还比较深刻，做运维的朋友，可以读一读，曾经在创业公司读这本书的时候，受到一些启发运用到实际中，提高效率不少。
这本书总结了IT运维的四件要事。我觉得讲的很不错。同时这四要素可构成一套完整的运维机制。四要素如下:

1.按运维原则做事

• 事前:讲计划、重承诺;
• 事中:讲规范、重控制、有反馈;
• 事后:重效率、能应急、有保障。

2.掌握服务平衡

• 主动服务:服务者发起运维服务;
• 受理服务:用户提出运维需求。

3.落实整体运维

• 软件支撑系统;
• 应用系统;
• 计算机硬件设备;
• 机房和环境。

4.贯穿服务流程

• 事件流程;
• 问题流程;
• 配置管理流程;
• 变更流程;
• 发布流程。

上述四要素每一个部分要细说，都可以讲很多内容。由于我运维经历很有限，上述四要素并没有全部接触。但对于我感触最深的是第一点按运维原则做事和第四点贯穿服务流程。这四要素大家可择需而取。在我的职业生涯中，涉及到运维相关的工作，如果我有权把控的话，基本上会按照第一点来做(其实不仅仅是运维，开发也一样)。

五、适当了解前后端

早年软件，以Java开发为例，基本上JSP+SSH之类的或者JSP+SSM等之类的框架。基本上Java代码+前端HTML+CSS+JS混合一体。如果代码写的不是那么优美，看起来很难受。
如今，基本上都是前后端分离。
前端三大主流框架Vue.js、React.js、Angular.js等。
这三大框架基本上都体现了前端模块化的思想。作为运维人员部署方面也很简单，要么服务器有node.js环境，要么让前端人员本地编译好，将生成的dist目录里的文件打成zip包直接上传到nginx对应的目录解压即可。总而言之，运维人员得了解。

为什么要适当了解前后端？

最基础的就是针对请求的响应码，要识别一些常用的响应码，利于排错，同时作为运维人员也要擅长浏览器调试。因为像有的公司做的项目是需要现场实施的，实施人员通常是运维，去客户公司部署项目，确定项目是否部署成功，通常要结合一些前后端相关的知识。记忆比较深刻的是在第一家公司的时候，有一次运维同事和技术总监跟着去客户公司调设备，技术总监之所以带他去也是让其熟悉这个环境，同时也让他熟悉一些Java代码(Client-Server通信)，因为回头就得他一个人来客户公司调，要求他能看懂这部分Java代码。不能排除有的时候运维不仅仅是捣鼓一些服务器上的东西，可能还要求熟悉一些前后端代码之类的。大家可以去Boss直聘上瞄一眼，中高级运维，基本上都要求至少熟悉一门编程语言，可以是Java，也可以是Go和Python。不过近年来Go和Python是比较多(Python做自动化运维是非常合适的)。当然了，基本上学计算机的，大家接触了编程语言不可能只有一个。

六、总结

记得之前在公众号看过一篇文章《远见|美团王慧文清华演讲:社会最稀缺的是π型人才》，这篇文章提到了社会最稀缺的是”π型人才”。

“π型人才”并不等于是全才(也不能等于什么都了解、什么都不精)，只是不给自己设限(不把自己圈在特定的地方，简单的举例说明，我既是一名Java程序员，又是产品的创造者之一，同时我也可以是一名业余作家)。

我的前三家公司经理级别的领导基本上都符合这样的。

第一家公司的技术总监

之前公司是没有运维的，他独立负责整个公司的运维。不仅仅这样，如果项目急的时候，他也要上阵写Java和一些前端代码。平时他也是主要写后端代码和做数据库设计方面的。

第二家公司的项目经理

他早年做过程序员，后来做产品经理，再后来运营总监等。

第三家公司的技术经理

他是一名后端程序员，后来不知由于什么原因做起来前端。我和他在一起工作的时候，发现他每天和我们一样，除了开产品会就是在写代码或者是做少部分管理工作。

结合我这些年的工作经验来看，无论是开发、测试、运维等，它们都共同涉及一个点，那就是工作的”原则”(包含工作的方法论),每家公司的研发流程不一样，但工作的原则是可以复用的。