在很多情况下，运维占到软件成本的大块，专业的运维人员更是不好找。这样的人需要熟悉操作系统、网络以及数据库。而运维又是一件很苦逼的事情，成了算是软件写得好，研发团队的功劳；败了就得彻夜坚守岗位提供支持，不可控的因素太多。是上游团队的软件质量太差吗？
我在 09 年的时候曾经到过局方，呆了挺长一段时间，既是开局，也做运维的工作，和运维的工程师朋友一起蹲机房、守夜、切设备，知道其中无比的苦楚。很多情况下，版本的更迭、割接，都要在凌晨完成，需要仔仔细细地测试；不幸失败了还需要立即回滚，然后陪着项目组等领导骂，等新版本或者补丁到来，再重复熬夜的这段过程……
不如大胆一些，解雇你那些抱怨不止、喋喋不休的运维人员吧，这件事就让程序员来完成！实际上，我在这篇文章里面已经说了：
让程序员做更多种类的事。为什么有人说小公司锻炼人？在小公司，条件并不那么齐备，很多事情都需要程序员自己做，自己去澄清需求、自己做设计、自己搭建环境、自己测试，甚至自己上线、自己维护（这件事情在我们团队被称为 “自己吃自己狗食”）。
除了给程序员以锻炼，带来的好处是什么？
- 不会再有那么多人抱怨傻叉的版本质量了，因为再烂的软件，也是自己拉的屎。骂自己或者自己团队，何必呢？
- 极大减少所谓的 “一线” 和 “家里” 的沟通成本。让那些扯皮的事情躲得远远的吧。
- 解决问题的人很容易就可以是熟悉问题，甚至是制造问题的那个人，他将是解决那个问题最合适的人选。
大致的原理很简单，程序员借由一些工具、平台，实现在远程的情况下实施运维工作，包括监控、急救、修正、记录等等。
如果需要减少运维人员，并不是所有项目都可以做到的。那么什么类型的项目容易实现呢？
- 相对开放的网络，没有过高的安全性要求。这里所说的 “开放”，并非指要把整个系统暴露在互联网环境之下，而是说，可以提供相对宽松的接入渠道，便于程序员以远程访问的方式来定位和解决问题。如果你是一个现场研发的强力支持者，那么你可能需要稍稍改变一点思路。不是只有在你眼皮底下工作的人才是敬业的。
- 没有太多硬件的约束。软件上的措施，相对好操作，如果涉及硬件，而且又是特定要求的硬件，譬如必须要在某局方更换硬盘，遥远的程序员呆呆地看着，就显得无能为力了。
- 强大的平台和工具支持。这在下面会提到。如果没有它们，相当于把苦逼的工作从运维人员转移到了程序员身上，没有从实质上解决问题。这样的平台和工具不是任意的，需要时间和技术的积累。
程序员不是专业的运维人员，所以如果把运维工作原原本本地交给他们，他们应该很难做好。如果我们设法简化、改善运维工作，让它简单到程序员也可以凭借自身的特点去完成（就如同计算器的入门门槛要远低于算盘一样），解雇这些专业的运维人员，也是可能的：
- 选用一个云平台去代替那些复杂的保障方案，代替那些脚本横行的双机和集群工具。国内外许多厂商都提供了云主机服务，而且成本明显有愈来愈低的趋势。
- 提供一套机制，可以让程序员把版本、patch 方便地部署到生产环境上。这是一件极大影响工作效率的事情，不要指望程序员可以和和气气地把补丁准备好，拷贝到跳板机上，再上传到生产环境中。通常，我们需要一套编译和部署系统，这套系统允许程序员在测试或者本地环境下完成环境准备、对问题的修复和验证，再方便地将修正替换到生产环境中。仔细想想，拥有这样一套机制才是困难的事情，据我了解，能做到的公司屈指可数。
- 完备的监控系统。很多公司都有自己成熟的监控系统，包含消息通知机制。针对特定的项目，可能需要定制少量特殊意义的监控脚本。让程序去获取和观察这些结果，而不是人。不过，懒惰的程序员肯定很愿意去完成这样的程序，减少自己苦逼的劳动。
有了这些，让程序员来维护你发布了的产品吧。因为出了问题而获知这个不幸消息的程序员，严重的问题会让他在不情不愿中马上行动起来。你在第一时间看到的是解决实际问题的重现、分析、修正和测试，而不是打电话扯皮或者报告领导，或者汇报所谓的 “安抚客户” 工作。程序员都是做实事的人，这个过程越是让他们痛苦，质量的提高越有希望，程序员越能够发现改进的办法。
由上可见，让程序员来代替专业的运维人员其实并不容易做到。我确信在人力资源充裕的中国当下，这件事情似乎显得还没那么迫切。另一方面，相较于让程序员去干专业黑盒测试的活儿，运维的工作似乎更难做。但无论如何，这是一个恒定的趋势，人的劳动力会越来越值钱，机器需要替我们做更多的事情。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
×Scan to share with WeChat
