企业IT传统运维将走向何方？

前言近两年，运维人需要面对不断涌现的新兴技术和架构转型的要求，例如企业上云、分布式、容器化、双中心双活等等。随着传统企业把更多的业务向线上化和数字化发展，IT运维也面临着业务模式改变随之而来的更多要求。做好运维，除了学好新技术，更需要从运维理念、运维方式和运维视角转变等方面去适应变化。以下是我个人的一些思考。

一、企业传统IT运维面临的挑战

我们的传统IT运维人员在运维工作上应该能体会到了三个明显的变化。

第一，运维对象越来越多

随着企业推进数字化转型，新增的应用系统越来越多;随着线上业务规模扩大，应用系统不断地进行细化拆分，组件的数量越来越多;随着微服务的推行，节点朝着小而多的方向迅速发展。现在，一套应用系统有几百台服务器，几百个容器已经是常见的事情。虚拟机和容器的爆炸式扩大增长，已经不是危言耸听，而是实实在在发生的现状。这要求着运维人员投入更多的精力来保障和运维系统。传统的运维模式，例如操作文档手工运维，脚本方式手工运维，按系统类型分类运维，大量个性化特殊化运维等等，随着规模的扩大，管理的难道呈指数级增加，运维管理能力也会达到极限。这个时候，运维人员面对各种工单往往应接不暇，焦头烂额，运维没有成就感。然而要投入更多的运维人力，又加大了沟通、培训和协调等的管理成本，堆人的路已经行不通。

第二，运维要求越来越高

IT规模小的时候，传统运维可能还可以停留在几台服务器的搭建，基础软件的安装，日常的变更维护等等，只要保证系统的安全稳定运行即可。但是，随着企业的规模发展，对运维也会提出更高的要求，例如几百台服务器规模化的部署，几千台大批量的操作，分钟级甚至秒级的敏捷资源供给，自动化的资源扩缩等。今年疫情期间，企业为了满足线上办公的需求，要求马上提供上百台远程桌面服务器供员工线上办公;企业频繁地开展线上秒杀活动，在活动期间需要批量部署上线大量的应用服务器，活动结束马上回收;近段时间，基金开户和销售火爆，很多基金公司的应用系统几近瘫痪，如何保证及时地提供资源。在这些场景下，依靠传统的资源管理和人工操作方式已经无法满足业务对运维服务的要求。

第三，运维服务用户越来越多

传统企业环境下，运维仅服务于研发，研发服务于业务部门，服务用户都比较单一。现在很多企业成立了多个研发中心和测试中心，还不断地扩大分支机构，分支机构又有独立的应用系统建设需求，同时也提供IT服务给第三方公司。在这种情况下，我们的运维人员需要面对各种各样的用户环境和多种多样的用户需求，首先沟通成本会非常高，其次也无法保证能够提供一致的运维服务，第三运维质量也因为人员差异而参差不齐。以上的三个变化，对于还没准备好的传统运维人员而言，将是巨大的挑战和压力。一方面业务迅猛发展，领导不断下要求给指标;另一方面，运维人手不足，工具跟不上，平台不给力。除了上面三个因业务发展带来的规模上的变化，我们的运维也面临着如何化解新技术的压力。例如自动化运维、可视化运维、智能化运维等各种平台和工具的引入，运维人需要选择，让平台能结合各种运维场景切实发挥作用;例如云计算、容器云、大数据、分布式、区块链和大量开源软件的应用，运维需要了解原理、部署排障、融合创新;例如系统高可用技术、双活中心技术等，运维需要将它们有效落地。这些技术，需要运维人员不断地学习和跟进。传统行业的运维人员，面对眼花缭乱的运维新技术，往往不知如何入手，陷入迷茫。

二、传统IT运维应该如何转变

面对各种业务上和技术上的新变化，传统的运维人员应该如何应对?运维工作充满了大量的简单重复劳动，运维工作如何突围?运维人员每天忙碌，承受压力，又不被认可，运维的价值在哪里?面对以上的三个问题，我认为，运维要从过去的被动式运维向主动型运维转变，从操作型向管理型转变，从背锅式运维向价值型运维转变。当企业的规模发展到一定程度后，运维要向运营转型，从技术支撑到价值输出。要实现这三个运维转变和向运营转型，我个人认为我们应该从三个方面去做出改变，分别为改变运维理念，改变运维管理方式和改变运维知识体系。具体如下：

第一、运维管理理念要改变。

业务在变，需求在变，运维也要对应着改变，最重要的是在运维理念上要首先做出改变。传统的运维工作，只要做好运维支撑工作就可以了，从来不关心业务情况。现在做运维，要将对运维的认识提升到业务层面，把自己从传统的支持中心向服务中心、价值中心转变，提升IT服务供给能力，满足企业业务的发展需求。运维部门过去一直认为是花钱堆硬件的部门，就是买买买，没有什么价值。但是，随着上文提到的三个明显变化的发生，光买硬件已经无法满足业务的需求。运维不光要做到能用，还要做到好用;不光只买硬件，更要充分运用各种软件和平台来提升运维服务能力。我们的运维理念要以业务价值为导向进行转变。那么如何实现以业务价值为导向呢?怎么做能够满足业务价值导向呢?我认为我们要改变过去被动接工单的运维模式，转变为以标准服务目录，场景化服务为接口呈现的主动对外方式。让运维提供的服务，从后台展现到前台，以明确清晰的方式让用户主动进行各种选择和使用。通过服务目录，运维工作也能够保证对外服务标准的一致性。同时，通过服务目录，运维的质量和主动性也有了抓手。服务目录好不好，用户满不满意，也是评价和测量运维工作做得好坏的一个标准。服务目录只是一个对外接口，其后台所承载的运维流程、管理平台、脚本工具，积累的技术和经验，是运维真正的内功。通过深入了解用户的需求，设计梳理运维服务目录;通过服务目录，优化各种流程、建设各种平台和选择各种技术。这样面对琳琅满目的技术，我们的运维人员也有了学习技术的方向和目标。

第二、运维管理方式要改变。

运维理念的转变，必然带来运维管理方式的改变，但是这个改变是需要至上而下进行，需要管理层主动推动。那么，运维管理方式要改变什么?我想，首先是要整合，把制度、流程和技术进行整合，把服务器、操作系统、网络和存储等进行整合;其次是建立服务治理机制，根据PDCA方法论形成运维管理闭环;第三是建立运维数字化，让运维一目了然;第四是完善智能监控分析体系;第五提升运维自动化和智能化水平。传统企业的运维我觉得有两个维度，竖向的应用系统维度，如具体应用系统的架构设计、应用变更、监控分析、故障切换、容量管理等等，和横向的专业平台维度，如服务器硬件、存储设备、操作系统、虚拟化平台、中间件、数据库、终端等等。运维管理方式，是采用竖向运维还是横向运维，需要与企业的IT规模和发展阶段相匹配的。这两种不同的方式也是分久必合，合久必分。企业IT规模小，竖向较合适，几个人共同承担了应用系统、服务器、网络、存储和基础软件等所有的运维工作，沟通路径短，效率高;然后，随着IT规模变大，一个人无法兼顾所有技术栈的运维，于是根据技术领域进行了细化分离，让专业的人做专业的事;现在，随着新需求的产生，又需要各专业领域的运维团队紧密合作，比如云计算，容器云，动态扩缩，自动化和智能化运维等，汇合了服务器、网络、存储和中间件等技术，需要各团队通力合作。这种新运维方式下，需要相应的组织架构调整和改变来支撑，比如成立虚拟的云团队。

第三，运维知识体系要改变。

以上两点改变，更多的是从上而下的改变，做为运维人员也需要从自身出发进行改变，让自己的知识体系适应新的运维模式。那么运维人员要怎么做?我想运维人员要从架构视角、开发视角看运维，提升自主运维的核心技术能力。在运维知识体系和新技术落地上，twt已经给我们提供了很多资料和做了大量介绍。随着基础平台云化，容器化，以及分布式架构的逐渐应用，运维人员需要掌握的技术不再是单一的领域，而是需要多领域的融合贯通，对虚拟化、操作系统、网络、存储、监控、自动化工具和运维开发等都需要掌握。例如，我们的要求虚拟化团队，不光管理好平台，更要通过开发提升工作效率。运维人员的视角也要从更高的业务特性和开发人员需求出发，不局限于我有什么就用什么，而是要用户需要什么我们提供什么，并主动提升服务的质量和效率，主动地关注团队提供的专业服务是否满足用户需求，是否让用户满意和好用。例如，运维人如果去支撑和融入devops这个新的模式。

三、传统IT运维转向运营

我们说运维要向运营转变，为什么是运营而不是运维呢?首先来看一下运营的概念，运营是对运营过程的计划、组织、实施和控制，是与产品生产和服务创造密切相关的各项管理工作的总称。从另一个角度来讲，运营管理也可以指为对生产和提供公司主要的产品和服务的系统进行设计、运行、评价和改进的管理工作。从概念中，我们可以看到，运营是针对产品和服务，那么IT运营的产品和服务是什么呢?是的，就是运维，运营是对运维这个产品和服务的设计、运行、评价和管理。我们说金融科技的本质不是科技，而是服务，是从用户的角度出发看待问题，一切以用户满意为前提。IT运营也是如此，它将运维这件事，从用户的角度来思考，运维不是简单的技术支撑，简单的故障解决，简单的背锅任劳任怨，运维是要满足用户的需求，运维是运维人员提供的一个产品和服务。我们可以看到，如果给用户足够的便利，用户自己能解决大部分的问题。比如网上购物，购买理财，购买基金等等，只要操作简单便捷，老人也能轻易做到。运维也是如此，并不是运维非要做得苦逼，而是运维这个产品和服务不够便利。我们现在慢慢地看到很多公有云厂商，提供了非常多的便利服务，哪怕不懂运维的人，也能轻松地搭建出一套套监管控一体化俱全的应用系统来。作为传统IT运维人员，需要从这方面多多学习和转变。

四、最后

如果说过去的传统运维像经营一家大排档，客人看菜点菜，厨师依需求做菜。这种模式存在几个问题，一是客人其实也不知道要吃什么菜;二、不是每道菜，厨师都会做;三、菜做的好坏，客户是否满意，取决于每个厨师的手艺。所以，大排档模式只适应小规模经营，而开不成连锁店。到了一定的规模，我们的运维要像经营肯德基、海底捞等连锁店一样，无论面对多少客户量，我们用标准的流程，提供一致的菜式，一致的服务。我们用心于菜式的品类和质量，用心于服务的满意度。面对快节奏的变化，运维人员应该沉下心来，对外以做产品的心态做运维，追求用户极致的体验;对内建立标准的流程，打造高效的工具，让运维变得简单轻松。

一名运维小哥对运维规则的十个总结，收藏起来
对于运维而言，平台、工具、知识、经验，意识等都固然重要，其都在某种程度上决定了运维质量。而对于运维规则，也不可小觑，整好了也许会有四两拨千斤的效果哦！

作为一个IT小哥，在阅览技术书籍时，看到作者对运维规则的总结，反复阅读几遍后，发现其内容言简而意赅，质朴而真谛。些许认知是我自个儿明白，而无法用言语总结的；些许是让我自个儿从无知到认知的；些许是我想要做而目前作为一个运维小哥而无法做到的~

总之，阅览后如获珍宝。当然，作为一个运维小哥，以下内容及规则（涉及系统大体）自个儿能驾驭的是少之又少，但丝毫不影响我的向学之心！那是我的工作之心所向，那是我傲娇之心所追，更是对自己能力提升的同时而注重的自我升华。

以下是本人根据书籍内容及些许的自我认同而提炼出的部分精髓（至少自己是这样认为，^_^），个人感觉，有一部分适用于运维人员，而有一部分适用于技术管理人员。相信也存在许多像我一样的IT小哥哥小姐姐，所以希望做个分享，希望能让有需之人观后有感！为啥我要总结出这两种人群的适应内容呢？呃，毕竟，不想当将军的士兵不是好士兵~

对于运维而言，平台、工具、知识、经验，意识等都固然重要，其都在某种程度上决定了运维质量。而对于运维规则，也不可小觑，整好了也许会有四两拨千斤的效果哦！

以下内容是本人摘录技术书籍内容，同时加上了些许个人感知及个人言语，不喜勿喷哦！

1、勿重复劳作

不要重复劳动力，也不要什么都从外部获取，如工具、代码、框架等。需要考虑的是在合适的时间以合适的成本切入，投资回报率也是需要考虑的。

一般来说，每个公司都存在重复造轮子的现象，而且许多人都热衷于此，可能需要用这样的项目来证明自己，而却忽略了投入/产出比这个重要的指标。如果能够充分利用社区的成果，利用公司已有的成熟框架，那么可大大加快自己的项目进度，因此，为什么非要自己做一个呢？也许有些人考虑的是重复造轮子，可以真正锻炼到团队，毕竟一个从头开始的项目，所积累的经验往往比一般项目多得多，有助于个人的成长和公司后续项目。

2、允许出错

人非圣贤，孰能无过，运维也是如此！出错并不可怕，关键是要建立机制，让错误能够尽可能快速地被修复，限制错误影响的范围，同时要归纳总结，从错误中让个人成长，让组织成长。

当然，允许出错并不表示事无巨细，均可犯错。允许出错是建立在大体层面上已尽可能的完善了整体制度，规范了运维流程等情况下出现的无可预知的错误！

只要存在硬件载体，就必然伴随着各种各样的故障。有时为了追求高可用性，设计复杂的架构，或者准备过多的冗余设施，往往会导致解决方案的成本剧增，而解决方案的复杂性，也会为后期的改造及维护增加难度。国内众多公司都号称可用性高达99.99%，甚至高精度的小数点后面多加好几个9。然而，某巨头企业的云产品导致小公司数据丢失，某巨头企业应对活动日出现页面异常等等场景，让我们情不自禁的感叹~~

3、设置备用

备用角色在运维工作中可能只被人看到日常运维的价值，而当主要角色因事请假、过度劳累、因故离职等时期，备用角色价值凸显，他可让正在进行的项目不被打断，正在进行的工作不陷入被动。高效培养备用角色，其需文档、流程和规范的支持，故运维规范等也是重中之重！

4、定位瓶颈

不监控，无运维。此话说明监控的重要性，对于一些资源的争用，通过监控系统能够直观的反映。而对于一些隐藏较深的资源瓶颈和系统瓶颈，往往需要利用工具，靠经验去分析和判断。作为运维，需要有意识的尽可能地通过监控系统去发现问题，让监控系统变得越来越智能，越来越少地依赖于人的经验。

高级工程师和初级工程师有一个很大的区别，高工知道如何去定位瓶颈所在。他们不仅知道如何使用工具，还知道何时、何地、为什么要使用这个工具。这样，才可能在问题爆发之前，就定位到瓶颈所在。

当然，定位瓶颈，单一化的运维知识可能满足不了需求，因为数据可能要经过很多环节，如本地电脑、浏览器、DNS服务、负载均衡设备、应用服务器等。

所以，应该尽可能的涉猎不同领域的多元化的知识。

5、重视工具/平台

许多互联网公司都有基础平台的技术部门，专门负责开发基础平台、工具和服务，提供给各个应用研发团队使用。但这往往是一个短期内难以见到效益的事情。对于业务规模不大的公司来说，更多的时候是在做一些技术储备的事情。基础平台部门往往是伴随着公司的高速发展而壮大的，研发出来的产品如果没人用，自然就得不到改进，然后就更加没有人使用，如此恶性循环。其情境往往考验高层的决心，考虑是否需要继续坚持保留适当比例的底层平台开发人员呢？

应用软件的研发和平台工具的研发毕竟是不一样的，如果基础不牢，可能造成更大的业务风险。所以长远来看，使用部分人力（高素质的工程师）做平台和工具，其实是节省成本的！

硅谷的一些公司，让优秀的人去做平台和工具，并提供最好的待遇，给予足够的尊重，对于他们的衡量标准也应该不同！

6、分工明确

大规模的系统架构体系的维护，离不开训练有素的工程师，他们需要有许多知识、经验和技巧，也必然分工明确，如开发运维平台的、专门数据操作的、性能调优的、源码优化的等等。优秀的团队可能还有项目经理、质量管控、文档编者、成本分析、培训教育等各个专业领域的人，不同岗位的人员在自己的专业领域发挥优势，各司其职，才能使整个项目的光彩洋溢地淋淋尽致~

7、善于分享

应该多参与业内技术交流，对于一些问题，也许有些公司能有更好的解决方案，如果你分享了经验，同行们也会分享经验。从某种角度上看，两者是竞争者的关系，但是如果需要发展，就要看看业内的竞争对手在做什么，要跳出公司的格局去看待技术和管理问题。

同时，参与业内的技术论坛不仅仅是关注行业技术趋势的一种手段，也是一种招聘方式，通过认识更多人，扩大影响力，吸引更多人加入自己所在公司。自我人脉扩展的同时也充实了公司的发展，何乐而不为呢？

8、重视例会

许多管理者忽略了周会与例会的重要性。若长期不重视，整个团队就可能变得松散，没有凝聚力。

周会的一个重要作用是讨论分工。随着机器规模的扩大，人员的增加，团队管理者都需要分工明确，责任到人，才能促使员工尽可能的恪尽职守。

周会也可讨论彼此的工作进度、交流未完成工作的对策、互相了解团队成员的工作状态、传达上层领导的指示、交流技术与分享等等~~~

总之，每个人的工作饱和度及个性等差异化，如果没有有效的沟通，关系可能就会像从果核中慢慢腐烂到表皮的水果，彼此互有抱怨。因此，固定一段时间进行正式的交流并成为习惯是值得推荐的沟通方式，同时也可使得同事关系融洽，人员氛围优升~

9、绩效束缚

关键绩效指标（KPI）是指用于评测组织中与关键目标或关键成功因素，许多公司到了一定规模后，都把KPI考核作为一项主要的管理工具。

而事实是绩效是一种工具，人却是复杂的，管理人更是一件复杂的事情，要想面面俱到，很难靠绩效这个工具来简化所有的问题。当然，很多东西量化之后，就显得比较好管理。对于产品经理、运营人员、销售人员等等而言，量化指标，往往是看的见的数字。而对于运维及部分职位，可能就很难有一个量化指标！

绩效的设计应该是帮助个人发展，帮助员工赢的尊重的，而不是用于桎梏个人的。当个人的价值观和企业的价值观起些许冲突时，但凡一个好企业，往往具有包容性；而当冲突严重时，同时个人又不能妥协时，可以考虑换个环境，避免继续在一起的双方损失。

在书《赢》中，管理大师杰克·韦尔奇运用绩效造就了伟大的文化，而不容忽视的背景是，他花了许多年创立了坦诚沟通的企业文化。如果没有坦诚、没有沟通、绩效可能会成为破坏企业文化的杀手。在推动工作进展的时候，不是去考虑对公司是否真的有帮助，而是主要去考虑自己的绩效，是一个非常不好的倾向。自己现有的工作成果，工作输出，决定了自己后续的工作方向~~~

10、优化设计

应该有意识地优化流程设计以提高工作效率和服务质量。随着公司业务的发展，运维部门也会随之扩张，如果缺乏合理的流程或缺乏高层次的人才，那么往往会出现一个问题：人数增多了，效率反而下降了！因为随着公司规模的扩大，所管理和维护的资源急剧膨胀，出于安全和其他因素考虑，设计了各种各样的流程，以便得到正确的执行结果，但有时这些流程可能会导致效率下降，部门内部的沟通成本也越来越高，这都需要运维人员对流程本身建立反馈和优化的机制，有意识地不断优化流程！

良许最近经常在视频号直播分享程序员相关的干货，反响不错，欢迎大家关注一波良许的视频号，以免错过最新分享！

责任编辑：庞桂玉来源： 良许Linux