业务运维部门的岗位价值 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生成，脚本自动刷新的方式。这种安全隶属于运维流程的内在性，就好像软磁盘的故障率确定要高于光盘同样，这是一种物理的自然属性。

总结

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