我是一名Java后端研发工程师，在我的职业生涯中，曾做过一小段时间专业的运维，而后在一段很长的时间里兼任我运维职责，只不过职责范围在小和大之间来回奔跑。
我所待的几家公司，或多或少要做运维相关的工作，其中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和一些第三方库等)、物理架构(部署和运行)、系统架构等)，其中物理架构(操作系统、网络、服务器等)、数据架构(数据表设计、高可用、备份、复制等)。
根据合适的业务，选择合适的架构。对架构师而言非常重要，对于运维人员也同样如此。