重塑中小企业运维价值

作者序：

搞了好多年安全，一不小心掉入运维的“坑”里。

在摸索运维业务的路上，不断的踩坑，不断的爬出来。

我们的团队在成立公司的初夜解散，随后各奔东西。

也许，成长，总要经历过一些事情吧。

坑不断，踩还乱，离也愁，还是写点东西压压惊吧……

1、开篇写点什么呢？

运维，专业一点说叫做“可靠性支持工程师”，方言称为“背锅侠”。本篇小文不谈大企业，因为 BAT 企业总有专职人员做专职的事情，诸如：数据库管理员，系统管理员，桌面管理员，网络工程师等诸多岗位……

但在中小型企业里，“背锅侠”不光身兼数职，还要面对各种问题。

系统总要持续跟进及优化，“锅”总要有人背，运维的价值又何在？

话说企业使用了各种云来解决服务器运维的需求，是不是就不需要运维了？

作为与我一样背锅侠的你，是否也曾想着多考几个证书，来提升薪资？你的话语权是需要证书来获取？

还是能力来获取？

带着问题，我们来进行拆解和剖析，希望能让你有所收益。

2、为什么背锅侠总是我？

我也曾是小公司的一名“背锅侠”，从服务器采购，到背着服务器去机房上架；从给老板 PC 装系统，到公司内网布线；从软件性能测试，到写优化文档；我就是这么一个角色。

然而，运维的“背锅”总是相对于开发而言的，你越是在底层，你的技能越少，不能解决业务的痛点，没有话语权。这“锅”你不背，难道让老板背吗？

这里举个例子：某公司开发使用的技术栈为 Java，开发同学发布的是 war 包，Tomcat 容器，MySql 数据库。

需求完成后，上线发布，开发同学没有在测试环境测试（偷懒），只是在本机开发环境下功能正常，把 war 包交付给运维同学。运维同学修改配置文件后发布上线，奇葩出现了，某个文件上传功能调用即崩溃。

这时，运维同学在检查了各种目录权限及配置后，把这个问题反馈给开发。这时，开发同学为了避免加班，说：“这是你 Tomcat 容器崩溃，又不是我的应用程序崩溃。”运维同学很无奈，老板又不懂。这时解决方案是什么？

运维明知自己加班是徒劳的，可又该怎么办？如果运维去和开发吵架扯皮，一定是情商严重不足。这时候，老板信任开发。

运维同学在仔细查看 log 后，对比内网 git，发现开发同学打包时少了一个组件，运维手动打包，发布上线，问题解决。老板却认为这是运维应该做的。

上面这个例子在中小型IT企业中很常见，并非个例，“背锅”源于给开发“擦屁股”。如果我们不能扭转老板的思维，那就要让自己变得更有价值。

作为运维，如果你并没有 Java 技能，那就要学习，让这个岗位换个人做不了，提升个人技能。到更好的公司，你才有可能擦到更好的“屁股”。

但是，这是否与运维本身背道而驰？

问题与风险始终是存在的，面对问题与风险，我们更需要的是拥抱，而不是逃避。你可以为开发擦一次、两次、三次，但你并不能做永久的保姆。

3、再谈谈企业的需求与看法

企业到底需要什么？运维怎么做才能让老板满意，让团队满意？剖析这个问题，先学会换位思考。

如果你是老板，你认为运维应该做什么？我走访了一些中小企业老板，总结出以下几点：

1. 学习能力，精通企业业务，一听故障描述就能大致猜出故障所在；

2. 风险可控，这里的可控来源于3个方面，稳定、性能和安全；

3. 自我认知，找准自己的定位，别天天吵着累，这与自身能力有关；

4. 及时响应，遇到故障第一个冲到前线，这好像就是职责；

5. 优化能力，这一点可以归纳到第一点，说白了还是技能；

6. 沟通能力，学会提升自己的情商，遇到甩锅淡定面对。

下面不逐一展开说了，只着重说几点。

3.1 一个运维的学习能力

首先说学习能力，我认为更多源于自我技能与技能提升，在这个技能高于学历的时代，可是我还是没有找到合适我的工作（苦笑）。

一个靠谱能出活儿的运维到底需要具备哪些技能？ 首先你得会装系统（哈哈），系统装的多了，你才可能去写自动化的系统安装脚本；

好了，写脚本，BashShell 也许是我们每天面对的，但并不是全部；有些任务交给 Python 或其他的语言工具似乎更合适；

公司业务出故障了，你要去“擦屁股”，公司业务用什么开发？什么？你不会？怎么可能？至少要懂一点吧，好了，这个时候你可能接触到 PHP/JAVA 当然还有其他，等等；

开发交付的就有问题，好，问题在哪里？如何测？要给出应对的解决方案吧！服务器被攻击了，你要顺藤摸瓜找到应对措施吧？不知道如何攻击你还谈什么防御？安全攻防渗透入侵总要懂一点……

好了，你都懂一点，但好像什么都不专精……等等，谁说的？给我一个星期，练一下增删改查和公司开发环境配置，我就转岗去做开发了！OK！没问题！可是，公司到底是要运维的，学习能力与自身技能似乎本来就不矛盾；

噢对了，还有一句话这么说，一个靠谱的，能出活儿的运维，一定可以承担起架构的角色，运维本身就是在搭开源的盒子，就像堆积木一样，运维当然知道什么组件用在什么地方是最合适的。你们猜这句话谁说的？

当然，这是我说的。比如说，某些业务，用到了5台 apache，我们做过优化，同样配置的主机，2台 Nginx 就足够了，为企业降了3台服务器，省了钱。这难道不是具体的运维价值体现吗？

3.2 运维要有风险可控意识

风险可控：稳定、性能、安全。

• 稳定

稳定可控，举个例子：某个业务服务每隔3天就要重启，每天都在夜间23:30重启，问题的具体现象为，每隔5天就崩溃，但你并不知道为什么会崩溃。

首先，这并非稳定，如果你能通过合理的配置，把3天重启改为3周或30天。至少在一定程度上提高了稳定性。

这个例子的原型为：某中间件 Bug，内存无法自动释放。起初的现象是每隔5天应用崩溃，后来审计这个开源的中间件，一段内存垃圾回收机制有问题，遂改之，大并发测试，再后来30天也没有出现过崩溃，一直稳定运行了2年，直到业务替换。

• 性能

什么叫性能，企业要你来是提升性能还是降低性能？提升能提升多少？性能如何把控？服务器硬件我们要留多少冗余，多少报警？你当真做过思考吗？还是到点下班，之后撩妹吃饭喝酒睡觉手机关机？

上面提到5台 apache 的业务，使用2台 nginx 支撑，还有冗余，这是由于瓶颈落在了应用程序本身的机制上。

那么，你也许会说，如果落在了磁盘 IO 或网络 IO，不是照样不能精简吗？对的，有些钱省不掉，但关键是，如何让企业把钱花对，这才是你的价值体现，不是吗？

• 安全

终于要说一下安全了，我做了十多年的渗透，多少还是有那么点发言权的。我们结合企业自身来思考一下，安全是否属于测试的范畴？我想在某些场景下是的。

比如，我们在公司内部，拿到上级部门的授权（比如老板，技术负责人），公司业务对我们而言，可以做白盒，也可以做黑盒。而渗透，只是一种黑盒测试的方法，仅此而已。

那么，漏洞又是什么？漏洞源自于程序员写的 Bug。企业不可能要求所有的开发都是大神，所有的程序员也不可能不犯错。有些环节，还是会疏忽的。

我就遇到过，一个做了6年的 Java 技术经理，公司业务的有些核心组件是他实现的，信誓旦旦拍着胸脯带着讥讽的语气告诉我，“你测试也是浪费时间，绝对没有问题，你要能找到漏洞给你加薪……”

我当时很想抽他的脸，但我还是天真的信了他的话，因为我知道，绝对没有“绝对”。当我用调试器（Fiddler）改了上传请求，把 WebShell 扔服务器上时，拿到的居然是 root 权限，连提权都省了。

然后转过头来给运维团队的同志们解释为啥不能怕麻烦，不要用 root 帐户启动容器（Tomcat）。那哥们儿傻脸了，但我依然给足了它面子，这点我还是懂的。

虽然最终问题提交并解决了，但加薪不是因为这个，是因为从那之后多了个活儿，就是渗透测试（黑盒），还好白盒部分我们不管，是开发人员自己搞定的。

• 再谈：资源配置

当年公司的官网自己买了服务器挂在 IDC 的机房，两个官网，用了两台。我发现，这两台服务器简直就是浪费，因为基本没有流量。

虽说一个用于演示，一个用于生产环境（所谓的生产也是演示）。但有够扯的，两台服务器，每年托管费用就将近2万，老板花钱也是心疼的，因为他的钱也不是天上掉的。

我们后来使用了 RedHat 原生的虚拟化方案 KVM，把开发经理要求的“必须是单独的主机”的要求给 K.O 掉。下架一台机器，拉回来，我们做测试机用。

线上机房从原先 100Mbps 的出口降配为 10Mbps，即便这样，加上远端备份，加上自身业务，资源的占用也不到50%，小企业的资源就是这样省出来的。

当时老板很高兴，为企业省了钱，拉着大家去聚餐，说大家要感谢运维同学云云。当然，具体事情要具体分析，并不能一概而论。