专栏名称: 云技术实践
关注云计算,云技术,云运维,云存储,存储,分布式,OpenStack,SDN,Ceph,虚拟化,运维,分享在云计算/虚拟化/运维项目实施中的资讯、经验、技术,坚持干货。
目录
相关文章推荐
架构师之路  ·  又一篇10W+,它来了... ·  昨天  
架构师之路  ·  美团的产品经理,麻烦您进来看一下... ·  1 周前  
架构师之路  ·  数据库架构,1个github宝藏项目,3个小 ... ·  1 周前  
51好读  ›  专栏  ›  云技术实践

运维的价值和目标拆解

云技术实践  · 公众号  · 架构  · 2017-10-09 20:00

正文

这里说的运维主要是指应用运维,非系统部的偏硬件和网络的运维


我不幸福

很多运维同学感觉自己很苦逼,感觉每天都在救火,给研发擦屁股,做一些重复工作,做一些对自己提升较小的事情,总结一句话,就是不幸福。


怎么幸福

工作中的幸福主要来自两点:

1、有成就感;
2、薪水到位;


而薪水到位与否很大程度决定于你的产出(如果你的老板不懂你们的工作,看不到本该看到的价值,那另当别论),而产出多少很大程度上和你的成就感是正相关的,所以要幸福,就要做有成就感的事情。

谈成就感

作为一个技术人员,成就感主要来自两点:

1、做的有价值
2、被别人认同


对于研发同学,比如写了一个framework,或者lib,同事都说好,并拿去用,这个时候是超级有成就感的;或者做的产品被市场认可,被同行认可,也是很有成就感的。


那运维同学呢?价值体现在哪里?


运维的价值

可以分对内的,和对外的。比如运维同学写了一些运维工具,大大提升了做某些事情的效率,得到周边同学的认可,这是对内的价值。这里,笔者更希望好好探讨一下对外的价值,运维这个角色,在公司的定位,对公司的价值。


多数公司在创业之初,是没有运维这个角色的,相关工作内容由所谓的全栈工程师、栈溢出工程师代劳。随着公司规模扩大,机器到几百台,会暴露出N多问题,比较直观的比如:


  • 线上环境混乱不堪,OS发行版、系统参数配置、WEB服务器、启停方式、部署路径全凭各服务的研发人员的喜好和熟悉程度

  • 监控各种不完备,很多故障都是后于用户发现,有些进程挂了好久才偶然发现或用户报障了才发现

  • 出了故障排查费劲,甚至在线上调试

  • 很多故障都是由一些低级问题导致,比如ulimit配置不合理,比如想回滚却发现忘记备份

  • 服务器资源利用率低,很多机器根本没在用,甚至都找不到了,浪费了大量硬件成本

  • 同时操作大量机器缺乏有力工具,线上权限要么混乱不堪,要么所有人有所有机器的权限

技术合伙人意识到:靠专注写业务逻辑的研发人员来解决这些问题是不靠谱的,需要设置一个新的职能团队来收拾这个烂摊子。


于是,运维团队应运而生,定位就是:解决上面提到的问题。换个说法:让研发只专注业务逻辑和架构设计,运维搞定剩下的。这样会带来以下好处:


  • 产品更快得到验证:解放了研发人力,研发同学就可以全身心扑在产品开发上,迭代速度会变快

  • 大幅提升服务稳定性:专业的人干专业的事,线上环境规范干净了,监控完备了,没有低级错误了,系统参数配置合理了

  • 资产得到有效利用:资产专门有人在梳理,通过服务混部等手段提高利用率,再也没有机器在空转


用一句话来概况运维的价值:


花更少的钱,让产品更快迭代,更稳定运行


有些运维同仁概况了运维九字真言“安全稳定高效低成本”,说的非常到位。其中的安全,行文到此尚未介绍到,有些公司会把安全单拎出来成立安全部,有些就直接放在运维团队,这个看公司情况,如果公司体量大,个人认为,还是单拎出来会好一些。


目标拆解

安全、稳定、高效、低成本,怎么才能把这四大目标做好?应该做哪些事情来达成目标?笔者用一张脑图来梳理一下:


运维目标拆解

作者:秦晓辉

來源:简书

链接:http://www.jianshu.com/p/f1d831a9afaf

相关阅读:

高端私有云项目交流群,欢迎加入!

Kubernetes 1.8专注安全,在容器编排平台中稳居领导地位

Oracle宣布开源 Fn project

云管理平台实践指南

Optimus PB级数据迁移系统

Prometheus(普罗米修斯)用户档案:动态化特性加速weaveworks云原生程序的发展

附PDF下载:《迁移到原生云应用架构》第二部分