在很多情况下,运维占到软件成本的大块,专业的运维人员更是不好找。这样的人需要熟悉操作系统、网络以及数据库。而运维又是一件很苦逼的事情,成了算是软件写得好,研发团队的功劳;败了就得彻夜坚守岗位提供支持,不可控的因素太多。是上游团队的软件质量太差吗?
我在 09 年的时候曾经到过局方,呆了挺长一段时间,既是开局,也做运维的工作,和运维的工程师朋友一起蹲机房、守夜、切设备,知道其中无比的苦楚。很多情况下,版本的更迭、割接,都要在凌晨完成,需要仔仔细细地测试;不幸失败了还需要立即回滚,然后陪着项目组等领导骂,等新版本或者补丁到来,再重复熬夜的这段过程……
不如大胆一些,解雇你那些抱怨不止、喋喋不休的运维人员吧,这件事就让程序员来完成!实际上,我在这篇文章里面已经说了:
让程序员做更多种类的事。为什么有人说小公司锻炼人?在小公司,条件并不那么齐备,很多事情都需要程序员自己做,自己去澄清需求、自己做设计、自己搭建环境、自己测试,甚至自己上线、自己维护(这件事情在我们团队被称为 “自己吃自己狗食”)。
除了给程序员以锻炼,带来的好处是什么?
大致的原理很简单,程序员借由一些工具、平台,实现在远程的情况下实施运维工作,包括监控、急救、修正、记录等等。
如果需要减少运维人员,并不是所有项目都可以做到的。那么什么类型的项目容易实现呢?
程序员不是专业的运维人员,所以如果把运维工作原原本本地交给他们,他们应该很难做好。如果我们设法简化、改善运维工作,让它简单到程序员也可以凭借自身的特点去完成(就如同计算器的入门门槛要远低于算盘一样),解雇这些专业的运维人员,也是可能的:
有了这些,让程序员来维护你发布了的产品吧。因为出了问题而获知这个不幸消息的程序员,严重的问题会让他在不情不愿中马上行动起来。你在第一时间看到的是解决实际问题的重现、分析、修正和测试,而不是打电话扯皮或者报告领导,或者汇报所谓的 “安抚客户” 工作。程序员都是做实事的人,这个过程越是让他们痛苦,质量的提高越有希望,程序员越能够发现改进的办法。
由上可见,让程序员来代替专业的运维人员其实并不容易做到。我确信在人力资源充裕的中国当下,这件事情似乎显得还没那么迫切。另一方面,相较于让程序员去干专业黑盒测试的活儿,运维的工作似乎更难做。但无论如何,这是一个恒定的趋势,人的劳动力会越来越值钱,机器需要替我们做更多的事情。
文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》
×Scan to share with WeChat