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

《如何重塑中小企业运维价值》要点：
本文介绍了如何重塑中小企业运维价值，希望对您有用。如果有疑问，可以联系我们。

作者序：

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

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

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

也许,成长,总要经历过一些事情吧.

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

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%,小企业的资源就是这样省出来的.

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

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 补充个重点：日常演练

关于日常演练,据我所知,大多数的IT企业很少去做灾难的日常演练.因为“没时间、太忙”等等等等,可是你知道吗?如果不做灾难演练,当灾难来临,比如“rm –rf /”一个命令下去,虽然是手误,但多少都会让你惊慌失措.“我*,我竟然做了什么?”.

灾难演练与灾备同样重要,演练数据库被黑,所有表都被清空；演练“内网 GitLab 被删,如何恢复并通过日志找到线索”等等；演练突如其来的 DDOS,怎么应对以及做流量清洗.

在粮草丰盛的日子里,做好“弹尽粮绝”的准备.虽然你不可能把方方面面都做到提前预判,但至少会锻炼出来你敏锐的嗅探能力,比如在磁盘报警时,你有充足的时间可以更换磁盘.

我们曾遇到,在我们的测试机器(二手的服务器)上,磁盘(做的Raid 5)嘀嘀嘀响了一个多星期(在另一个办公室,我们不知道),直到被行政人员提醒,及时更换了硬盘.也就是这时候,才开始实施了监控.

因为在这之前,只是觉得这台服务器的磁盘写速度不如从前,但考虑到机器是旧的,就没有顾忌太多.但于此同时,某开发负责人“手误”,把自己 GitLab 的分支全删了,说来也奇怪,他自己竟然没发现(后来才知道,这家伙要离职,提前做好准备),因为我们有备份,及时给找回.

代码的压缩包不大,可以备份很多历史场景(每日备份),但对此,是因为之前做过演练,但仍然“防不胜防”.

• “日防夜防,家贼难防”

说起防,“日防夜防,家贼难防”,这是真的!看新闻曝光过某大型电商企业内部员工泄露了上亿条数据.但我之前的职业生涯却是遇到过的,公司的开发经理因为太善于内部政治斗争,被手下一个想要“上位”的家伙给害了.

这个想要“上位”的家伙是一名开发,比较有心,有次因为要使用技术负责人的 GitLab 的权限,让开发经理在这名开发的机器上进行登陆和操作,这家伙悄悄的记录了对方的密码(居然还是弱口令).

在之后的不到一个月时间里,他使用技术负责人的权限拷走了公司所有代码,并进行了日志清除.但他的水平确实比较 low,并不知道我们还对日志进行了二次备份.

在他个人与技术负责人发生正面的“政治斗争”时,用开发经理的权限删除了公司内网 GitLab 上的所有代码,并栽赃我们的开发经理.这时候,开发工作陷入停滞.老板急了,要求我们立即恢复.

可是,每个开发人员的机器上,都有自己正在撸的代码.所以,至少在1个工作日之内,影响并不是很大.我们用了半个小时,就发现了他的具体攻击过程,先改自己机器网卡的 MAC 和 IP(我们路由有记录,虽然我们在路由上做了 ARP 绑定,但也只是不能上外网),再然后,使用开发经理的帐号密码登陆 GitLab,删除所有代码,擦掉本机记录,然后再把网卡 MAC 和内网 IP 地址改回去.

我们向老板反馈,老板报警,至于后面的事,不用说大家也都明白了.很庆幸我们提前做过演练和对应方案,也很庆幸我们找到了直接的关键人,但更重要的是,这种家贼,确实难防.

为什么不能建立一种“公开、透明、可监控”的机制,来预防“家贼”事件的发生?这是值得很多企业去思考的一个问题.经济学上有一种叫做“逆向选择法”,也就是(似乎是行政HR的活儿)“员工的利己行为分析”.

员工具体会发生哪些“利己”行为,哪些才是对公司有伤和无伤的,我想每个不同的企业都有自己的判断与思考.

但往往,人是最不可靠的,特别是在企业正在迫切需要发展的阶段,企业到底需要“靠谱”的人,还是需要“可靠”的人?这个问题,你可以来发邮件找我撕逼,我打算在下一篇内容探讨这个问题.

4、结论

总之,一切问题的发生,总有其必然的原因.就是说,一切皆有“因果”.我们要拥抱所有可能发生的问题,在我们的能力的范围内,做好充足的预判及应对措施.

当然,“能力的范围”也会随着你的努力而不断的扩大.这当然是学习和提升的过程,是自我价值体现的过程,也是运维价值实现的过程!

另外,我要推荐另一篇文章,“互联网运维杂谈”公众号(waynewang_ops)发过的一篇文章“谈谈运维的价值和思路”,作者谦益(有兴趣的同学可以自己找一下).

小弟读的书少,你也许可以骗我,但我不一定会当真.最后,欢迎关于运维业务的探讨与撕逼,可以发邮件给我,stackworm@qq.com,可以找我好好的撕逼.

原文来自微信公众号：高效运维

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4289.html