这里说的运维主要是指应用运维，非系统部的偏硬件和网络的运维
我不幸福
很多运维同学感觉自己很苦逼，感觉每天都在救火，给研发擦屁股，做一些重复工作，做一些对自己提升较小的事情，总结一句话，就是不幸福。
怎么幸福
工作中的幸福主要来自两点：
1、有成就感；
2、薪水到位；
而薪水到位与否很大程度决定于你的产出（如果你的老板不懂你们的工作，看不到本该看到的价值，那另当别论），而产出多少很大程度上和你的成就感是正相关的，所以要幸福，就要做有成就感的事情。
谈成就感
作为一个技术人员，成就感主要来自两点：
1、做的有价值
2、被别人认同
对于研发同学，比如写了一个framework，或者lib，同事都说好，并拿去用，这个时候是超级有成就感的；或者做的产品被市场认可，被同行认可，也是很有成就感的。
那运维同学呢？价值体现在哪里？
运维的价值
可以分对内的，和对外的。比如运维同学写了一些运维工具，大大提升了做某些事情的效率，得到周边同学的认可，这是对内的价值。这里，笔者更希望好好探讨一下对外的价值，运维这个角色，在公司的定位，对公司的价值。
多数公司在创业之初，是没有运维这个角色的，相关工作内容由所谓的全栈工程师、栈溢出工程师代劳。随着公司规模扩大，机器到几百台，会暴露出N多问题，比较直观的比如：
- 线上环境混乱不堪，OS发行版、系统参数配置、WEB服务器、启停方式、部署路径全凭各服务的研发人员的喜好和熟悉程度
- 监控各种不完备，很多故障都是后于用户发现，有些进程挂了好久才偶然发现或用户报障了才发现
- 出了故障排查费劲，甚至在线上调试
- 很多故障都是由一些低级问题导致，比如ulimit配置不合理，比如想回滚却发现忘记备份
- 服务器资源利用率低，很多机器根本没在用，甚至都找不到了，浪费了大量硬件成本
- 同时操作大量机器缺乏有力工具，线上权限要么混乱不堪，要么所有人有所有机器的权限
技术合伙人意识到：靠专注写业务逻辑的研发人员来解决这些问题是不靠谱的，需要设置一个新的职能团队来收拾这个烂摊子。
于是，运维团队应运而生，定位就是：解决上面提到的问题。换个说法：让研发只专注业务逻辑和架构设计，运维搞定剩下的。这样会带来以下好处：
- 产品更快得到验证：解放了研发人力，研发同学就可以全身心扑在产品开发上，迭代速度会变快
- 大幅提升服务稳定性：专业的人干专业的事，线上环境规范干净了，监控完备了，没有低级错误了，系统参数配置合理了
- 资产得到有效利用：资产专门有人在梳理，通过服务混部等手段提高利用率，再也没有机器在空转
用一句话来概况运维的价值：
花更少的钱，让产品更快迭代，更稳定运行
有些运维同仁概况了运维九字真言“安全稳定高效低成本”，说的非常到位。其中的安全，行文到此尚未介绍到，有些公司会把安全单拎出来成立安全部，有些就直接放在运维团队，这个看公司情况，如果公司体量大，个人认为，还是单拎出来会好一些。
目标拆解
安全、稳定、高效、低成本，怎么才能把这四大目标做好？应该做哪些事情来达成目标？笔者用一张脑图来梳理一下：
费了我好大力气的啊，希望对你有些用处 :)
