运维在不同的公司可能大不相同，因为不同公司的IT架构决定了你工作的不同技术着重点和复杂度。还有公司的IT发展水平，决定了你可能会经历的技术阶段。在公司里，运维部门的工作大致可分为以下几类：保障正常运行、解决各类故障、IT架构扩展、调优与安全。这些工作干好了，都是会产生巨大价值的。相反一旦出问题了，运维就变成众矢之的，人们会觉得都是运维没做好，指责声骂声一片。别的部门加班，他们可以说我们在开发写CODE，在修改数据库、在导数据……总之就是在创造价值。而运维部的加班则是灰溜溜的，因为运维加班一般都是因为系统出故障了。说起那些年你所经历的运维，我想大家都会有一番感慨吧，算了让我们与往事干杯，忘却各种滋味一醉解千愁！

一、救火式运维

    初入行时，曾在一个小公司工作过两年。公司主要做广告设计，上上下下一百多人，有设计部、技术部、行政部、市场部等部门。公司里统一配备台式机，实行域控管理。在域环境下，每个电脑都有权限设置，不能自己随意在电脑上安装与卸载软件，这下技术部可真有得忙了。那时候公司里用的是盗版的PHOTOSHOP、AUTOCAD、3DMAX，这些盗版软件非常不稳定，安装的时候需要算号与破解，而且装完用上一段时间就打不开了。技术部加上部门经理总共就6个人，每天一上班就没有闲下来的时候，不是甲的PHOTOSHOP打不开了就是乙的3DMAX提示注册失败了，你过去解决问题时旁边还有别的员工在喊“快来啊，我的AUTOCAD也打不开了，客户急着要图啊”，让你恨不得有三头六臂，时间长了连自己都骂“该死的盗版软件，真是被你害死了”。就这样每天折腾来折腾去，后来大家干脆把这些软件都装在C盘里做了个GHOST的C盘镜像(加密码)，并做成一键还原，谁的机子出问题了，直接过去输入密码一键还原，所有问题10分钟搞定。    公司为了省钱，除了服务器其他买的都是组装机，到了夏季高温时，拥挤的办公区里电脑经常会出现蓝屏重启，或是3DMAX软件渲染时直接死机无响应了。运维人员就像是救火队，哪里有问题就往哪里冲，刚搞好这台，那台又蓝屏了。炎热的夏季，办公区里到处是汗流浃背的“救火”运维人员，那真是飙汗的人生无需解释。后来公司老总意识到这样太影响工作效率，下血本全换成了商用台式机，又买了一批正版软件，这一状况才改善了很多。那时候还出现了一件比较让人头疼的事，公司里用的杀毒软件也都是盗版的，员工由于工作需要经常要用到U盘，而那时WINDOWS病毒又比较猖狂，比如冲击波、震荡波等。这些随便乱插乱用的U盘很容易传播病毒，03年比较严重时，整个公司的80%的电脑都感染了该病毒，那个倒计时关机的对话框至今让我记忆犹新，技术部连夜奋战杀病毒打补丁加固系统才最终让全部电脑恢复了正常。此后，公司里禁止使用私人的U盘，提供每天杀毒的公用U盘给大家使用，还建立了几台专用的文件服务器方便大家使用。    这一阶段，主要经历的是初级的救火式运维，这种运维管理办法使得工程师们疲于奔命，但仍不能保障IT系统的持续、稳定，也不能有效缓解运维人员的工作压力。

   

二、项目式运维     之后跳槽来到一家互联网公司，该公司不大不小三百来人，主要做系统集成和项目运维。来应聘的时候，可能给面试官留下的印象比较好，结果比较幸运的被外派到一家著名外企做项目运维。这家外企的运维体系很好，有一线7*24的监控和二线的运维排错以及三线的厂商技术支持。我当时做的是二线运维，每天一上班先打开邮箱，看邮件根据邮件的警示级别进行轻重缓急的故障先后处理。每次处理故障前，都要写详细符合规范的故障记录单并附上解决步骤，报批后才能操作，真的感觉很规范和严谨，让我觉得很有一流大企业的范儿。在解决故障之余，不忙的时候我就看看他们共享的一些技术文档，从初始的项目构建、系统实施、性能测试和各种服务器、网络设备、存储的资料以及故障的累积记录都比较全，我仿佛进入了一个巨大的知识宝库。每天完成例行工作和故障处理后，我都如饥似渴的看技术文档上网查资料，试图更多的了解这个复杂庞大的系统，它的每一处精妙配置和细节都让我揣摩良久，就这样我慢慢弄懂了它的运行机制和整个系统架构。再后来我又花了一个多月的时间把它的故障累积记录都研究了一遍，对照以往的故障问题处理文档认真学习了一遍，我感觉自己充实了很多也自信了很多，对一些故障的处理我能准确的记得以前是如何做的现在还需要如何改进，文档的细致和精确的命令让老外对我刮目相看，他们也更加信任我提出的技术解决方案。    由于业务的快速发展和系统的功能增加，后面跟着他们的工程师做一些新项目的部署和实施、性能测试、数据迁移、系统扩容等，也学到了很多项目经验和架构技术。他们在技术上的细致和严谨性，让我很是佩服。通常一套程序都会先在试运行环境进行测试，再放到检验环境进行稳定性测试，最后才拿到生产环境进行上线，这样的程序运行起来真的是很稳固了。每月还有一次项目运维分析会议，会上通过各位技术人员的交流，问题的细节也清晰明朗化，很多时候也打开了思路。在这个外企我学到了很多，也见识了一流的技术人才，虽然他们不是和我一个国度，但在技术上我佩服和尊敬他们。因为是外包性质，我们是乙方，在别人的公司里驻场上班，我始终找不到一种归属感，有时候面对甲方还必须要委屈和迁就，面对客户的挑剔和领导的弱势，我想最终不可能融入那里的，后来我离开了这家外企。

  这一阶段，主要经历的是项目式运维，或者叫外包式运维。这种运维是以项目及结果为导向的，比较多的是受制于甲方的IT管理体系和设计，甲方的要求会在很大程度上决定你的工作重点和方向，因此运维人员是缺乏话语权和主创性的。

三、ITIL标准化运维        离开外企后，我进入一家集团公司工作。这里正在推行ITIL标准化运维，说到ITIL其实已经不再是一个新生事物，随着企业业务的复杂化和IT应用系统的拓展，运维的标准化和流程化是必须的。     相对于传统运维，实施ITIL必先从理念上进行改变。那么如何在企业里推行ITIL运维呢？ITIL运维体系下如何做好运维工作呢？我恰好经历了这一阶段，也亲身体会了其中的变革过程。     在中国的企业里，做什么事必须有领导的支持。首先是自己要学习领悟ITIL理念，然后是说服公司高层领导，最后让中层管理者在认识上达成一致。ITIL给企业带来的变革不仅在IT层面，而且也体现在经营管理层面。比如原来组织内部的人员和岗位，从一定程度上可能都不适合ITIL架构，需要先把大家的岗位打散，然后再定岗定角色安置人员，这可以算是组织结构的大调整。当然在岗位调整过程中，有些人员可能和位子不太搭配了，就做调换，挑选合适的人来做。这样的大调整，没有领导的支持基本是没法做的。在不少企业中，往往囿于组织结构变革的压力，采用了硬往ITIL上面靠的办法。说到底，还是领导的支持力度不够。     在实际工作中，你还会发现，每个公司本身往往都有多年的历史沉淀，如果完全按照ITIL的理想标准去做，可能根本就行不通。如何把ITIL最佳实践标准的理想和公司运营的实际状况去磨合，这将是我们应该花费更多时间和精力去考虑的。比如一个明显的问题--公司人员专业化细分。按照ITIL的要求，职员角色划分得越细、越清晰越好。这样做的有利之处在于容易避免工作中的扯皮。但实际上一个公司的运维部根本没有那么多人，很多时候都是一个人身兼多重角色和多个职务。这种详细的职责划分和专业分工也只有在公司业务达到相当规模后，才会产生规模效应。纯粹按照理想的标准去做，不现实也不可能。最后我们采取了折中的办法：人员少，职务多，只有暂时一个人身兼多个职务。随着人员的扩充，逐渐把多重角色分出去。实施ITIL标准化运维一年后，公司运维人员增长了近一倍。 　　再一个人员考核的问题也比较多。按照ITTL顾问制定的考核标准，要对公司员工进行细致的考核。从定性到定量，每个人的考核要素都很齐备。以现场运维工作人员为例，就包括一次性问题解决率和客户对运维工程师工作质量的评价等。如果人员分工做不到那么细，一人身兼多重角色，也为量化考核带来了难题。虽然各种管理工具能够给出一些量化的数据，但具体到某个员工的考核，系统工具也不能完全反映一个人的各种角色所完成工作的成绩和质量，但工程师做过的这些工作并不应该被抹煞。 　　在过去，无论是对网络的维护还是服务器、数据库的运维管理，工程师的经验往往最重要。好多故障的处理也多是“救火”，治标不治本。每一个技术问题，其实都会有多种解决方法。甲和乙两个工程师的解决方法可能完全不同，但结果可能都挺好，客户都满意。如果这两位工程师跳槽了走了，解决问题的办法也就随之流失，新来的员工还要重新摸索重新熟悉环境。如果有统一的流程和事件管理及事后的案例积累和知识库的建立，就可以不管谁来做，都能按照这个流程和规范来走。这样即使公司有人员流动，但流程一致确保了整个运维服务质量的稳定。　　     在运维工程师解决问题的过程中还可能会涉及到变更管理和配置管理。比如说，一个服务器的性能较差，可能会引起很多问题，换内存、换硬盘、调试系统的问题可能频繁发生。这些就会带来系统变更。而如果找到了真正原因，对服务器进行了参数配置变化，就涉及配置管理了。 　　对于企业来说实施ITIL，将有助于最终实现完善的服务管理。在ITIL的各个流程管理中，可以直接与企业各个业务部门相互作用，实现对业务功能及流程进行重新设计，降低成本、缩短周转时间、提高质量和增进用户满意度。但ITIL的流程固化，人员分工也固定，感觉运维的灵活性多多少少会有些损失。问题在于，一个工程师在一个岗位上干得久了，就会有一定的职业倦怠感，而轮岗就会更不适应了。同时精细的分工会导致一个问题的处理会需要多个部门和多个人员的参与，无形中延长了处理问题的时间。

四、开放式运维

    随着应用复杂度的发展和大数据的洪流，云计算和虚拟化将会是一个趋势，不管是公有云、私有云还是混合云，整个IT业的发展都面临巨大的机遇和挑战，当然云计算时代的运维也面临许多新的变化。          首先在云计算时代，有的企业会有自己的数据中心，构建企业内部的私有云;有些企业则会全部租用公有云，不建立自己的数据中心;还有的大型企业既拥有自己的数据中心，同时也应用外部公有云。在这种混合IT系统运行环境下，运维无疑将变得更为复杂，也给IT系统的维护和管理带来了诸多挑战。例如对异构平台的虚拟机的管理，包括其性能和容量管理等都更为复杂。       另外向云的迁移将会改变很多IT运维人员的工作职责，部分IT基础设施运维和数据中心日常管理的工作会都转移到云服务商那里。IT运维人员将会逐步转移到对业务的理解和供应商管理，确保可以根据业务部门的需求，交付高质量、低成本的IT服务。在大多数企业内部，以往的运维工作比重有可能降低，而对于整体IT的策划和执行能力，对于供应商合作伙伴的正确评估、管理等更高层的工作比重将会增加。IT运维将会投入更多时间关注业务、对供应商的评估和管理，而不再像以往那样花费大量精力来考虑存储容量、系统配置和优化等。

    最后一点，云计算的时代需要开放式运维，也要求运维工程师需要更广阔的知识面，比如如何选择存储？各种存储的特点是什么？各种虚拟化系统的特点是什么？业务刚开始上线的时候，如何为未来的横向扩展做好准备？Hadoop这个东西究竟适不适合我们？等等?这一切都需要我们去学习和思考。再有就是必须能够与产品技术团队紧密配合，对开发流程有深刻的了解，并且在需要的时候，自己也能抡起袖子上阵写代码，这样才会实现快速的迭代部署。不要怕跨领域，身为运维，就得像什么都懂的神仙。企业雇用每一个员工都是为了创造价值，越能够贴近企业的核心价值，才越能够成为企业中被重视的人。

    一切都在不断地发展变化，运维唯有变才能更好的适应未来的变化，从而提高自身的价值和增强企业的竞争力。

    让我们热情的拥抱变化吧，开放式的运维需要我们的思维像视野一样开阔！