运维职业生涯-白红宇

运维职业生涯

阅读量：5871 次

发布时间：2019-06-19

本文共 3466 字，大约阅读时间需要 11 分钟。

第一天：选择运维

运维值不值得干

对于没进入和刚进入IT行业的新同学来说，如果你在思考这个问题，说明你出身平凡，上流社会是不需要考虑这种问题的。当然，如果你考虑了，说明你还是屌丝中的进步青年。在过来人看来，这个就跟上大学一样，专业不是很重要，大学很重要。所以，选对行业和公司对以后还是很有帮助的，对于运维来说，目前互联网行业机器比较多，发展也比较好，我认为进入这个行业是不错的选择。选择完了，我们来看下运维职业发展的问题。

运维职业规划

说实话，我不太喜欢搞职业规划，扯淡居多，当然你可以不信，但确实有位大师也是这么说的，对于我这种只观大略的来说，大师的名字就别指望我记得了。在我看来，搞职业规划不如多去了解自己的兴趣！如果你对技术有兴趣，也选择了运维这个职业，我们再来看看运维怎么发展。

其实没太多说的，技术类的职业发展大同小异，基本会有管理线和专家线两条路，看自己兴趣了。所谓管理，就是leader，总监，VP，所谓专家，就是…,统称大牛，领导得给你面子，但活还得干。

运维的缺点

到目前为止，恭喜你已经成功成为运维攻城狮的一员了，我说下运维工作的缺点吧，这里妹子稀少，成天对着电脑，还尼玛只有文字的屏幕，有点逼格的可以搞黑底绿子，也就这样了。不要抱怨，要知道，你旁边的码畜也好不到哪去。没事去产品那逛逛，也许会有好看点的妹纸或者散发着雌激素的×××。当然，会找女朋友的一定不在这里找，得去女人堆找，质量高，选择面广，至于哪里是女人堆，请私信我。

第二天：开始运维

看来你已经接受运维的缺点了，让我们开始工作。

鸟瞰运维

古语有云：不谋全局者，不足谋一域。要想做好运维工作，了解下运维的全貌也是有必要的。让我们围绕一项业务的生命周期来了解运维工作的大概内容。

假设一个网站做完了，需要给用户使用，怎么办呢，我们需要上线，首先需要服务器，服务器放在哪？机架，机架放在哪？机房。服务器要对外服务，还需要网络，服务器上要运行我们的网站程序，需要操作系统，程序还需要保存数据到数据库，需要对外服务的web服务器，这样用户就可以访问网站了。在这之后，网站运营期这些软硬件都随时可能出问题，所以要进行监控，告警。网站也可能还有******，还需要考虑安全。业务发展过程中需要变更，网站下线后资源需要回收，这大概算是一个运维工作的最小原型了，实际情况也远比这个复杂，在一家大型的互联网公司，这些环节都是需要分工合作完成的，让我们看看一个大型互联网公司的运维部门基本组成。

先让我们记住一些关键词：上线，运营期，下线

服务器机架机房网络操作系统数据库 web服务器监控告警安全变更资源回收

上图只是标出了运维人员的组成，在实际的组织架构中，往往还包括产品，研发，质量，项目管理，大数据部门，因为大数据往往也属于基础设施，他们与运维共同组成更大的部门。

云计算与运维

从上面的图我们基本可以看出，运维工作需要的知识面非常广，小公司不可能招聘这么多的人来进行基础设施建设，但他们又需要这些产品和技术，于是就有厂商专门提供这种服务，成立了云计算公司，当然云计算的形式不只是图上的这些，但目前最激烈的战场就在基础设施这里，国外知名的像亚马逊，国内的有腾讯云，阿里云等等，他们的业务规模天然适合做基础设施云计算。所以运维要是能去云计算部门，算是去对了地方。

业务运维是个神马角色

业务运维也是运维，但为什么要单独来提，主要是因为我原来就是干这个的，另外，业务运维人员较多，与其他运维的工作也有不同之处。首先我们看看业务运维在工作中的定位。

业务运维往往和项目组组成一个虚拟的组，所以需要了解业务，同时又需要和基础设施部门对接，相当于业务和基础设施之间的纽带，也就是说，业务运维不仅需要了解大量的基础设施技术，还需要与人沟通的能力，是一个需要综合能力的工作。

业务运维的工作内容

上面对运维的介绍相对笼统，还是不容易理解，运维到底干的都是哪些事。我们还是围绕一个项目来介绍。

一．开发阶段运维宣导

做过软件开发的都知道，以前应用都基于操作系统，但互联网应用则是基于云，也就是图中提到的基础设施，由于专业分工的关系，开发人员对这些基础设施并不一定全部了解，基础设施有什么好处，有什么限制，使用上有什么规范，所以需要培训，可以起个好听的名字，运营规范宣导。项目开发阶段运维也需要介入，跟踪项目进展，最好是能对项目的物理架构提供一些建议，很多问题越早发现越好，互联网公司虽然大牛众多，但也不是每个项目组都有大牛把控，如果不加限制，后期维护将非常困难，对产品，对运维都没什么好处。（有的部门在产品开发阶段会有委员会进行评审，委员会成员既有研发也有运维）

二．项目接入前检查

在项目开发快完成的时候，运维需要及时介入对项目进行可运维性评审，比如了解项目的物理架构，配置文件管理，部署，变更复杂度，可用性，容量，容错处理，可监控性等等，尽量排除一些问题。

另外还需要根据项目的发展规划，重要级别等，申请相应的基础设施资源，在申请阶段还需要考虑物理部署的问题，这个阶段如果做的好，会给后期的运维带来很大的方便。验收完成后运维也需要根据项目情况提供相应的SLA。

我曾在一线互联网公司的多个部门呆过，发现即使在这么大规模的公司，发展也极不平衡，有的部门在产品上线前期就做了大量的工作，而很多部门的运维只是被动的上线，什么再难也要顶上，人肉战术，疲于奔命。我想这应该是管理上权利与责任不对应的问题，在互联网的世界里，线上的产品就是公司的生命线，运维对线上负责，也应该有相应的权利，这样才能更好的保证线上业务的稳定。

很早以前运维过一个项目，半路接手的，数据库IP地址分散在几十个文件中，有配置文件，脚本，代码，而具体修改点竟有上百处，这还是我自己调查的，其他地方有没有开发都记不清，大家可以想象项目乱到什么程度了，我也终于理解前面的哥们为什么不干了，也感慨如此规模的公司竟然也有这样的项目。所以这就是前期控制的重要性，我想我遇到的问题在许多公司仍然存在，不少兄弟应该有同感吧。

三．项目接入

如果前期工作都做的很好的话，这个阶段的工作不难，自动化强的很轻松，自动化弱的无非耗点体力，总之难度不大，这里不多说。

四．运营阶段

项目上线后，随着业务的发展，可能需要扩容，上新版本，也可能会遇到各种问题，这个阶段都是常规打法，记住变更需要慢慢来，一般称为灰度发布，这个做法其实很容易理解，比如我国要改革开放，改革开放到底行不行，不是谁说了算，先拿深圳搞个试点，行了再逐步开放其他城市，这么做无非就是避免大规模失败。

如果遇到故障，不仅需要排查，还需要记录，一般称为事故管理。

如果遇到奇怪的问题不能解决，也需要记录，一般称为问题管理。

如果需要变更线上环境，也需要记录，一般称为事件管理。

五．业务下线

不多说，过程是愉快的。

六．总结：

在我看来，如果把运维工作按照项目上线分成三个阶段的话(上线前，上线，上线后)，那么上线前是最重要的阶段，正对应了那句话，好的开始是成功的一半。

这里给出一张运维工作和ITIL的对应图，完整的ITIL比这个要复杂，实际的运维工作也比这个要复杂，但这张图也基本涵盖了运维工作的核心内容。