一点不懂到小白的linux系统运维经历分享

进入运维行业刚不到二个年头， 刚刚从大白变成小白。都说it行业是青春的饭。但是运维行业可不这么认为。运维工程师便是经验技术的积累，经历的过的沟沟坑坑都会融入你的血液，成为你的智慧。

二年前接触linux。越学习，越发现，原来操作这么灵活方便。下面就结合我走过的一些坑，给大家分享一下自己的一些想法与观点。结合之前一些老前辈的经验，我先简单描述一下，运维工程师的三个阶段，官方一点就是：初级，中级，高级。前一段进时间看过一篇文章，更形象生动的描述了这三个阶段：背锅侠、救火队长、未雨绸缪。

目前就职于一家为移动提供服务的集成厂商。负责二千多台机器的监控，还有一些主机的维护等等工作。自称调侃一下，目前我是介与背锅侠与救火队长之间。刚入职那会，遇到问题故障时，基本上没有自己的思路，到处抓瞎。还好我这个人脸皮够厚，见到人就问。刚开始，大家爱于情面，会给你的处理。但是时间久了，每个人工作量都是超负荷的。职场上，说白了就是利益的。还好自己的多一些心眼，与老同事关系打好。。。自己的也基本上也是转行业。 如果做不好，就得卷铺盖走人。老同事给了一些建议，技术不行。 可以先从业务产品下手，公司每周也有产品的培训。从这方面弥补技术的不足，然后尽块把项目上技术规范，运维流程了解。技术可以慢慢学习积累，这样基本上就可以先站住脚了。 想想也是，没有自己的思路，也没有自己的方法体系，想到那里就做到那里，因此我也是范不少低级错误。

   刚入职，又上一批新主机纳入监控。 新服务器接入要先准备一些前置条件，其中端口网络策略就是十分重要的。我用#telnet ip 端口 测试，都不通。 我呢也是信心满满，跟据之前老同事留下来的模版，填写的申请。谁知，由于之前没有核实清楚。一些基本的思路没有。大家能猜到我出的问题是什么呢？还好，我平时工作有习贯，抄送了之前老同事。 刚发没有多久，他找到了我。再三问我核实清楚了没有！！！ 听到这里，我也是心虚了。可是一想没有问题呢？  测试不通呢。 呵呵， 测试端口通不能，前提是服务器的服务开启没有开启。如果连开启都没有，再测试也没有。 这下要闹笑话了。 前辈又跟我说明了， 要么可以用#nc –l 端口 模拟开启，然后再测试端口策略。 听了他的建议，我连忙按他给的思路，都好好的检测了一下。 还好有些端口确实不通。 我又重新整理了遍，重新发了网络策略申请。

每个运维人员，都应该 有自己的工作流程或者也可以说，自己的一些规范。 每到一个新的工作环境中，要结合项目上的运维规范整合，形成自己的工作规范。这样工作起来，会越来越轻松。公司么，总想花少钱雇到质化价廉的人才。目前我们接触到服务器都是redhat7或者7以上。下面我来分享一下，自己的服务器运维的一些过往。 服务器优化， 一些基本包的安装。特别是redhat7以后，基本命令参数选项补全。它是依赖到bash-compele的包。这个可以大大方便你的命令输入。

服务器的一些内核参数调整：修改本地端口范围限制，修改/etc/sysctl.conf文件，在文件中添加如下行：net.ipv4.ip_local_port_range = 1024 65000请注意，本地端口范围的最小值必须大于或等于1024；而端口范围的最大值则应小于或等于65535。修改完后保存此文件。执行sysctl命令：# sysctl –p  这样端口的范围限制就修改了。修改用户进程打开的文件数限制，修改/etc/security/limits.conf，在文件中添加如下行：* soft nofile 65000;  * hard nofile 65000 用'*'号表示修改所有用户的限制；soft或hard指定要修改软限制还是硬限制；20480则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。修改/etc/pam.d/login文件，在文件中添加如下行：session required /lib/security/pam_limits.so;这是告诉Linux在用户完成系统登录后，应该调用pam_limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制)，而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值。修改完后保存此文件。执行修改ulimit值# ulimit -n 64000 ; #ulimit -u 64000:修改完后用户重新登录立即生效。

今天就分享到这里，有机会再分享。最后推荐新手啊小白啊，尽量选择别太厚的书。容易没有耐心。不错，有机会可以看看。