业务运维部门的岗位价值 V2

http://segmentfault.com/a/1190000002890102
之前写了一个版本，不够简练

业务运维部门有四个方面的岗位价值，按照实现的难易程度排序

1. 效率
2. 质量
3. 成本
4. 安全

效率

这是最容易实现，也是能够输出最大的价值地方。现在的竞争，更多的是 time to market 的竞争。谁能更快地把新版本推向市场，谁能最快地完成bug修复谁就更有可能赢得竞争。运维是版本交付到用户手里的关键一环，运维的效率也会对这个交付速度产生影响。效率带来的收益不是省了运维几次登陆跳板机的麻烦事，其收益是节省了版本交付的时间，时间才是收益可以无限大的东西。

时间 * 单位时间收益 = 总收益

单位时间收益取决于业务的价值。只要业务足够高价值（比如百度搜索），那么节省了一秒也是宝贵的。

质量

质量对于运维来说的是提供反馈。及时提供指标，提供数据给研发侧，告诉真实的用户体验。提供数据报表给产品侧，用户的实际使用情况。这种反馈的数据可以指导模块的性能优化，长期的架构调整，业务的模式转型。但是因为反馈只是提高质量其中的一环，所以运维可以输出的价值会受到一些限制。

反馈及时和有效性 * 响应速度 * 响应的价值 = 总收益

一般故事都是这样的，运维通过监控发现xx情况下有卡顿现象，研发及时发布新版本修复性能问题，用户非常开心，忠诚度提高等等成为收益。这个反馈环中，反馈及时和有效是一个因素，强有力的研发侧才能体现出反馈的价值，要不然反馈再多再及时，也是然而并没有什么卵用的。

成本

成本优化是最直接的收益，也是想象空间最小的收益。运维可以通过性能调优，架构推荐等方式节省对资源的开销。也可以通过混布进程，消峰填谷提高资源的利用率。白天机器用来跑web服务器，晚上同一台机器空闲下来可以跑批量日志统计。

减少的机器数 *　机器单价 = 总收益
减少的带宽Mb * 每 Mb 单价 = 总收益

这种收益的问题是，上限摆在那里。如果业务优化得好，很多创业公司（比如当年的douban）可以用很少的pc服务器支撑很海量的业务。如果机器本来就不多，优化能优化到哪里去？所谓成本优化大都是大公司吹气球吹上来之后，再去做的事情。而且优化也不一定靠技术手段，行政指令对于屯机器的情况有的时候更管用。

安全

安全的收益是负的。安全做得越好，就亏得越少。安全做得越差，可能一天就把本都亏没了。比如携程出的故障，持续十几个小时的业务中断，这就是大亏特亏了。平时在安全方面的投入都是无影无踪的，都是负收益，管用的时候也只是让出问题的时候，大问题变小问题，小问题变没问题而已。

安全最重要的是 build security in，所谓安全内建。安全性是运维流程所产生的内在属性，如果一个公司所有的发布都是手工编辑配置文件，手工上传覆盖，手工执行命令生效。这样的安全性肯定是要低于基于docker的版本管理，配置文件通过CMDB生成，脚本自动刷新的方式。这种安全隶属于运维流程的内在性，就好像软磁盘的故障率肯定要高于光盘一样，这是一种物理的天然属性。

总结

越关键的业务（停机的单位损失越大）越可以体现运维的价值。运维是一个平时很难出成绩的岗位，也是一个很难独自产生收益的岗位。运维的产出基本上趋于一次性（比如时间的减少和成本削减）。长期来看运维提供的价值集中于最后一点，安全上。对于公司来说，给运维部门的钱相当于上保险，不指望有多少收益，只求不要出事。