如何重塑中小企业运维价值(2)

这个例子的原型为：某中间件 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%,小企业的资源就是这样省出来的.

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

3.3 被逼出来的运维能力

• 甩“雷”的前提,是这个“雷”在你手里

运维的沟通能力,多半是被逼出来的.运维要面对的是负责人,程序员,老板,以及客户等等.你能说沟通能力不重要?我想,你不会傻到和程序员撕逼的时候来一句,“你就是写 Bug 的!”,你也不会蹬鼻子上脸冲老板喊一句“这不归我管!”.

当然,有些老板还会要求你去给他家里的 PC 机装系统,说“不急不急,抽你的时间”,你能说不去?个人沟通能力的锻炼,是你被磨圆的过程,情商有时候大于智商.

虽然我们没有把别人当傻子,但是有些傻子竟然是天生的,你不是他父母,当然这不能怪你.但有个原则,你要注意：“先别慌着说‘不’,甩雷的前提,是这个雷在你手里!”.

你总要把问题分析透彻,才可能指出痛点,才能有效应对,才能说清楚,哪些“雷”不归你管,才能有效甩“雷”.同样,这个过程也是自身学习与提升的过程,要学习的不全是技术层面,你说是不?

• 老板的任性

老板要不要可视化?我们说难听一点,可视化在一定程度上是“装逼”用的.比如说：老板看着订单曲线就很激动.但你能捂着老板的眼不让老板看吗?老板不会查 log,不知道各项参数的具体意思,就给他看图好了,毕竟一图胜千言嘛.

老板拿着这个可视化,还能去和客户“Tree New Bee”,为什么?

因为客户并不关心你的 log,只关心你们的企业能给他带来什么,但在这之前,客户要搞懂你到底在向他说些什么.

还有些情况,我们需要用到可视化,我们提交的周报、月报,提交给谁?老板也看不懂参数,需要开发经理去解释,但把可视化实现了,老板可以查看到实施的情况,实时的了解你的或服务器的工作状态,以及一些业务的实时情况,难道老板不喜欢吗?还是你不喜欢?

比如说,我们用 Grafana 实现了服务器的监控外,又实现了业务 API 的可视化,老板可以了解到,最近10分钟、或5分钟内,有多少人在线下单,多少钱进账,你看到老板嘴角的口水了吗?

虽然我做了 Grafana 的汉化并发在了 GitHub(好久没更新了,说来惭愧),但我们更希望有更多的人可以都去参与一些开源工具的汉化或者修复完善工作.

开源软件基于社区的更新和维护,如果你看到一个工具很久都没有更新了,你会选择吗?如果你不了解的话,我想你不会.

• 头脑风暴—技术范围内的“撕逼”

对了,我并不知道你的公司是否定期做分享,也就是内部的“头脑风暴”,大家可以在技术范围内尽情的撕逼(记得带上项目经理和开发同事,但别打人).

但我会,我带过的团队,第一就是要养成定期分享(包括故障反思)和撕逼的好习惯.记得曾有运维同事这样提到过,“我们现在的虚拟化方案太 low,ZeroVM 就不错”讲了一大堆如何好.

后来在实际测试时发现 Bug 过多,而且很久又没有更新,这个方案被否掉了.但这个同事后来转向 Docker,再后来他负责了公司虚拟化方案升级的大部分工作.

说这个例子,就是让大家知道,在中小型的 IT 企业,同样需要学习与研究(搭开源的盒子),面向适用自己企业的业务,也只有你最懂.

所以,中小企业的开发者和运维同学们,你们有必要和义务来做内部的定期分享,也就当锻炼自己,说不定什么时候碰到个大会,也能上去“Tree New Bee”,当然,内容干货才行.

3.4 补充个重点：日常演练

（编辑：ASP站长网）