这是个理论且枯燥的话题，但很多人又不得不面对。

今天我以自己在小公司、百度、阿里的工作经历，结合同学在腾讯、小米等公司的状况，来说下运维技术在未来互联网的前景。

通过这篇文章，你会了解到小公司和大公司的运维状况对比，并能了解到各自的发展状况，但很多问题并不会细节化，因为写不下。

首先说下结论：我认为运维是非常有前（钱）途的，也是技术性越来越强的职业。
身边bat的同学，工作3年左右跳槽的，基本没有月薪少于20k的，多一点到40k左右，一般也都是技术负责人甚至直接带团队。

但是，运维累是一定的，做互联网的没有不累的，问题是累的同时，能不能学习或实践到更好的技术，来支撑你将来拿更多的钱，才是核心。

为何普遍感觉运维没有技术含量？

我自己在大公司和小公司都呆过，我认为主要是初级运维太多，而他们做的事很多根本不能称之为运维，总结如下几点：

1、运维自身缺少对目标充分的规划和实施拆分，导致很多工作无技术性。

运维是一定会做基础性工作的，例如部署服务、上线，甚至搬机器、重装系统等等。但运维肯定不能只做这些，因此在剩余时间如何做有利于运维技术提升的事，就尤为重要。

举个简单例子：当你和研发一起做一些事的时候，你在里面的定位是什么，怎么体现你的价值和技术能力？如果没有，基本就是在帮别人做贡献。

2、运维自身负责的点非常多，无法精通，无核心竞争力。

大的范畴包括：硬件、网络、操作系统、数据库、存储、开源软件；职责上要负责：各种功能的部署和调试，例如ldap、samba、nagios等；再细的分工还包括：压力测试、性能优化、内核参数调优、系统问题追查等。

很多运维因为要做太多不同层面的事，导致很多事都仅仅只是完成任务，缺乏深入的研究，当然可能也缺少深入研究的场景。

3、运维自身的总结、呈现不够，技术能力提升不足。

其实和第一点关联比较多，因为本身没有对目标充分的规划，再加上总结呈现也不够，对技术的提升就比较有限了。

举个真实例子，我认识一个人做运维7年多，期间在几家公司做过不少事且时间都不短，正常来说会有相当的积累。前段时间因为要帮他内部推荐到bat时review了他的简历，有几个感受：简历通篇都是描述性词汇，无数据支撑；项目工作都是叙事型描述，充斥着服务搭建、解决问题的字样，没有技术点；仅有的技术工作都是一笔带过，没有方案选型和技术能力体现，无法体现技术水准；

我自己面试过很多人，老实说这样的简历远远达不到及格分。当应聘公司拿到这样简历时，如何能快速了解到你就是公司需要的人？

4、运维在技术部门毫无话语权，技术上得不到应有重视。

在研发和测试的眼里，运维可能就是搬机器、重装系统、部署服务、掌握root权限这样毫无技术含量的职位，但也不得不承认，在很多公司，运维实际上就是这样。

实际上，不管是哪个职业，只要你做的不好，都没有前途。比如研发一般比较有前途吧，但很多研发人员做了差不多十年，最后还转型做其他职业了；我身边运维做到等级很高，跳槽出去到中小型公司就是运维总监的人比比皆是。

▼那么在BAT从事运维的同学们都在做什么？我从几个层面简单描述：

运维职能方面：

首先，BAT在运维上的分工更细，一般系统、数据库、应用运维这些都是完全分开的，因此在职能上可能更加专注，当然涉及的面肯定会窄。

工作职能上，运维主要在可用性、效率提升、成本控制这3个主要方面发力，并和公司、研发的目标密切关联，运维所做的绝大部分工作都是从这3个目标中拆出来的。

技术提升上，主要是以项目的形式，利用对服务的了解和技术方案，来解决共性问题。

▼技术工作方面：

以服务可用性为例，绝不仅仅只是处理报警，操作时小心些，写几个自动化工具这么简单，它包括了：

技术方案：预案执行是否足够清晰明确、速度足够快；监控是否能及时发现问题，避免客户投诉；服务出现任何问题，是否都有及时的方案止损和解决（例如机房异常的问题）；业务出现问题，是否有方案能够快速定位和恢复；

非技术方案：流程的控制（任何对线上的操作是否有记录、随时回滚、方便review），信息的披露（信息是否公开透明）。

▼做事方法方面：

数据说话。今年的可用性目标是保持服务基本稳定？还是保持服务可用性99.99%？还是保持99.99%基础上0运维事故，同时mttr小于20分钟？

严格按照既定计划安排工作、review、总结。有明确的工作实施拆分细则么，精确到什么时间维度，季度？月？周？日？多久review一次？

合纵连横，结合外部资源以更高的视角去解决问题，而不是停留在一个点上。下面有类似例子。

结合这些方面，可能BAT的运维同学才能够实现技术的快速提升，这是我所看到的。

▼最后说下运维的努力方向：

想要运维有前途，需要几个要素：

1、需要一个能够施展运维发展的平台，至少是一个有发展并有一定机器规模的业务。这里并不是必须要bat，而是选择一个适合你的。

2、了解和熟悉业务。

很多人不喜欢去处理问题，然后只想着做高大上的东西，这样的结果我不说你也明白，就是不接地气，做出来的东西没人用，等等。

所以我认为运维架构师必须是一个了解和熟悉业务的人，而且非常熟悉。我身边也遇到过这样的人，等级很高，平时也不处理什么问题，但关键时刻（比如出了问题），他就是能迅速找到关键点并解决之，并且某些细节比你还要了解，让你不得不佩服。运维是必须要做这样的人！

3、对运维技术和业务架构的发现和思考。

即使你每天重复在做上线、处理故障和问题、响应需求、开发和维护脚本，这些都没关系，重点是你是否有从所做的问题上看到业务和运维上的痛点，并利用已有的技术方案，处理和解决掉！

4、综合考虑问题，并以全局化视角去解决共性问题。

问题是很多的，也并不是说解决掉很多个问题就是牛人，问题的关键在于怎么解决问题的同时能体现你的全局视角和技术能力。

举个最简单例子，有台机器磁盘快满了，这肯定是个特别小的问题了，运维同学应该经常遇到，怎么处理呢？

如果你只是排查了磁盘占用，然后删除了数据或者调整了删除磁盘的脚本，那是最差的一档；排查了磁盘占用，确认是单机有问题还是批量机器都有问题，为什么在这个点报，确认清楚并能解决之，这就高了一档；排查了磁盘占用，彻底发现了磁盘增长的原因，但是发现磁盘增长不可控，现有的数据删除方式不能避免报警.那么有办法在保证重要数据保留正常的情况下让磁盘不报警么？然后以技术方案解决之，这就更高了一档。。。。。。这样的例子还有很多。

你会发现，运维，实际上就是利用你对系统、网络、硬件、规范、服务方面的熟悉程度，结合专业知识，用技术方案解决研发、测试解决不了或者不能单独解决的一系列共性问题，并能形成工具、平台、框架，最终能给运维部甚至公司创造价值，这就是个牛逼的运维。

在这个过程中所做的，不管是部署nginx、研究透了nginx的rewrite规则、写了牛逼的工具等等、把iptables用的滚瓜烂熟，这并没有卵用，这都只是为最终结果服务，而已。