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

radiolbs 2019-06-20

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

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

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

效率

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

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

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

质量

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

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

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

成本

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

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

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

安全

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

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

总结

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

相关推荐