|
引述
因为本人喜欢研究一些哲学东西，在做运维工作中，我就想把运维工作进行一些归纳和演绎，抽象出运维行业的一些通用理念，寻找运维的未来方向，所以今天给大家分享我的一些探索。分享的内容目录如下：
作为哲学历史爱好者，其中乐趣也很多，并非像我们学得那么枯燥。不同的流派、哲学家对世界的认知实践差别很大。例如孔子讲仁义礼智信，老子讲道可道，非常道，大道自然。亚里士多德说哲学是科学，而不是感觉、经验和技术。
由此可见，同是哲学圈子里混的，但其认知实践可以说是风马牛不相及，但也都各有道理。同样道理，对于我们干运维工作的同行，其传统运维与互联网运维有很多共同之处，但也有相隔千山万水般的鸿沟。
话说两人相遇，发现彼此都是干运维的，感觉找到了知音。运维有着共同的痛点，如下图所示：
激动之余，A问B运维咋做的?B答，IOE *)*&*&，A茫然了。然后A说，互联网运维
%￥……&%&，然后B也茫然了。彼此互相茫然了，感觉原来同是运维，却不知对方说啥。。。。无法沟通的感觉。。。。
这种现象很奇怪，同样是搞运维的，但感觉是完全两个世界的运维，但其实也不奇怪。在这个世界，但凡存在的都是有其存在的道理。天上飞的，水里游的，各有各的生存之道。运维的世界那么大，我们有必要走一走看一看。
因此，我们有必要探讨一下运维冰火两重天的二元世界。
概述
近一年，关于传统运维与互联网运维的探讨越来越多，在运维体系快速变革地环境下，运维未来的走向，便成为运维行业的关注点。
那么：
到底什么是传统运维体系?
什么是互联网运维体系?
他们的特点，异同在哪?
从哪里来到哪里去?
本文将从以下角度探讨两大运维体系。
1.商业封闭式系统架构 vs 开源系统架构探析
2.传统运维 vs 互联网运维探析
3.去IOE运动探析
4.运维自动化探析
5.运维发展趋势探析
1、商业封闭式系统架构 vs 开源系统架构探析
每个单位组织的IT环境，不论大小复杂度，总会有个系统架构层次。有了这个架构体系，那所有的运维事情大体都围绕着这个系统架构上的每个元素及整体进行运维保障工作。
运维体系架构从某种角度可以划分为如下两种：
A. 商业封闭式系统架构(IOE架构)
B. 开源系统架构
通常我们会将围绕商业封闭式系统架构(IOE架构)的运维视作传统运维，将围绕开源系统架构的运维视作互联网运维。
就上述两种运维体系，下文做一些辨析。
1.1 商业封闭式系统架构(IOE架构)
典型的即以使用IOE(IBM、Oracle、EMC)产品软硬件为主要元素的系统架构。
IOE架构以纵向扩展为特点，通过增加CPU、内存、扩展柜、冗余备件等方式来提高处理能力及稳定性。
该架构的处理能力主要取决于单台(套)设备(系统)的最大扩展能力，很难通过增加设备(系统)数量来增加处理能力，换句话说该架构很难通过扩大集群规模的方式来解决问题。
随着纵向扩展的规模增大，它的实施技术难度、管理复杂度以及隐患风险都会成比例大幅上升。基于IOE架构的典型企业如：金融业、电信业、能源业、交通运输业。IOE典型的系统架构如下图所示。
典型IOE架构图
上述为IOE型系统架构，其服务器多使用小型机、大型机(还有以往的中型机);数据库系统往往会使用Oracle;存储则多使用知名品牌的中高端存储阵列、带库等设备。服务器与存储之间多使用SAN存储网络。
这些服务器、存储等硬件本身往往就是双冗余的，线路连线也都是双冗余的，而且设备性能指标往往非常好，例如一台普通中端的Power
7系列服务器可以轻松划分出若干个系统分区或者一二十个虚拟机系统。
1.2 开源系统架构
典型的即以使用廉价PC服务器，开源产品技术为主要元素的系统架构。
开源系统架构以横向扩展，分布式部署为特点。常通过向集群中增加单机设备资源解决存储空间、性能以及稳定性问题，其集群规模可以小到两三台PC服务器，也可以大到上万台。
对于数据库，可以通过分布式集群方式解决数据库扩展性的问题。另外非结构化数据库及分布式文件系统在处理非结构化数据的存储与使用方面也很灵活方便。
基于开源系统架构的典型企业如：以BAT(百度、阿里、腾讯)为代表的众多互联网企业。
开源系统架构如图所示：
典型开源系统架构图
上述开源系统架构中使用了CDN和反向代理以提高网站性能。
例如我们的服务器可能部署在北京，对于北京及周边用户来说访问是较快的，而对于远离北京的用户访问则感觉较慢，因为数据传输时间比较长。
对于这种情况，常常使用CDN解决，CDN将数据内容缓存到运营商(或自建CDN)的机房，用户访问时先从最近的CDN机房获取数据，这样大大减少了网络访问的路径。
对于反向代理，当用户请求到达时首先访问反向代理，反向代理服务器将(如：Varnish)缓存的数据返回给用户，如果没有缓存，才会从源站服务器获取，这也减少了获取数据的成本。
当然对于海量访问请求，或庞大集群架构，则就需要分多层，综合运用上述负载均衡以及代理(反代理)，同时可能需要引入Zookeeper等功能以协调(服务)任务调度。
从上述架构简析中，我们便会感知到两种运维体系的巨大差异。
俗话说隔行如隔山，现如今就算都是运维这一行，也可谓千山万岭。对于上述基于IOE架构的传统运维体系，对比基于开源架构的互联网运维体系，可以说是当前两大运维阵营。
2、传统运维 vs 互联网运维探析
一个奇怪的现象
传统运维圈子通常高度认可商业闭源产品。而对开源产品及其技术则很谨慎，很少采纳，甚至认为很多开源产品不上档次。
而互联网运维圈子通常高度青睐开源产品、技术、理念。而对商业闭源产品则比较排斥抵触，再好也不买。
差异可见一斑
传统运维圈子和互联网运维圈子各有特点，同是运维行业，但也有很多差异之处。关于传统运维与互联网运维的不同差异，本文总结了如下几点差异，并在下文进行阐述。
架构差异
工作内容差异
知识体系差异
面向对象差异
运维人员差异
体制理念差异
2.1 架构差异
传统运维:
如前文所述，传统运维多是围绕以IOE架构及其产品体系进行运维，在性能、数据库、中间件、HA高可用、灾备、存储等环节通常大量采用商业闭源的软硬件产品及其解决方案。
这些方案的特点是通常纵向扩展能力极强，横向扩展能力很弱。商业案例成熟稳定，方案组合重度耦合，讲究两地三中心这种典型的重量级、集中式运维管理方式。
这种架构体系具有大量成熟的商业案例，有完善的存储保护机制，容错机制，数据库也讲究强一致性。另外IOE架构后面通常有强大的MA维保支持体系，甚至MA人员常年驻场。
互联网运维:
互联网运维通常是围绕开源产品、技术解决方案进行运维。在负载性能、数据库、中间件、集群高可用、灾备、分布式存储、自动化部署等环节通常大量采用开源的软件产品及其技术解决方案。
硬件通常使用廉价的X86服务器，甚至白盒产品。
这种开源解决方案通常纵向扩展能力很弱，横向扩展能力很强。有大量社区、行业成熟案例。方案组合灵活，讲究分布式存储、负载集群、轻量级、模块化、去中心化的运维管理方式。
另外互联网系统架构通常缺少MA维保支持。开源产品更新换代甚至消亡的风险较大。
2.2工作内容差异
由于架构体系的不同，面向对象、运维理念等差异(相关内容见下文)，从而导致工作内容也会有诸多的差异性。如下列举两种运维体系的工作差异。
传统运维
通常自建机房IDC，自主维护IDC，从机房风火水电全是自己做。
需要了解很多业务背景知识、逻辑关系、用户环境，基于业务环境的运维工作比较复杂。
注重内外部审计工作，通常会有一些政策性地安全大家查。
通常会组织协调厂商完成信息系统项目建设，IDC维保，故障协调处理等工作。
上传下达公司各种任务、活动。
完成工作日报、周报、月报、年报。
处理各种汇报材料及行政通知类公文等文档。
建立可靠的网络、存储和服务器的备份体系，制定灾难恢复计划。典型的如两地三中心建设。
应急预案、策略和流程的制定和改进，撰写各种预案等。
注重提高运维服务质量，不注重成本和效益。
调研测试众多商业产品，通过商业产品、服务去搭建运维基础设施及服务
日常运维工作，包括系统环境部署、升级、变更、发布、故障处理等
互联网运维
运维系统的规划、选型、部署上线，建立规范化的运维体系，并实现文档化。
通常需要了解很多开源技术，需要熟悉shell/perl/python/php等语言，以促进高效运维工作。
对新技术和方案进行调研评估和引进，改进产品的服务架构，提高系统性能和健壮性，用技术去满足业务发展需求
负责公司网站基础架构运维，比如负载均衡、分布式缓存系统、应用中间件、分布式文件存储系统、虚拟化等。
经常借助技术手段控制和优化成本，通过工具化及流程提升运维效率，注重运营效益
持续性优化改进，持续性发布部署新产品新业务
制定和优化运维解决方案，包括但不限于柔性容灾、智能调度、弹性扩容与防攻击。
推动及开发高效的自动化运维、管理工具，提高运维的自动化程度和效率。
全方位的性能优化，将用户速度体验提升到极致。
会考虑做精确的容量测算和规划，优化运营成本。
2.3 知识体系差异
由于运维架构体系的差别，所接触到产品，技术也就有很多差别，那么日常工作中用到的知识体系也就有很多的差异。对于网络技术、产品，两种运维体系共性较多，差异性不明显。其知识体系的差异则通常表现为IOE架构与非IOE架构相关的知识体系差异。
这里首先介绍一下互联网运维知识体系。知识不可穷尽，这里仅做举例探讨。
互联网运维
关于互联网运维，所需要的知识体系，这里引用借鉴：运维知识体系-V1.0 By：赵舜东(赵班长) (https://www.unixhot.com/)的介绍，如下
本互联网运维知识体系从网民浏览器终端发起，分层分级方式逐步分解到服务器基础设施层，另外从运维管理体系、监控体系、安全体系、自动化体系、云计算等多个层次维度全方位展示了运维知识体系。
传统运维
如上所述，其相关知识在传统运维中也有很多共同之处。但传统运维也有些知识体系和互联网知识体系不同的地方，这里举例如下。
2.4 面向对象差异
传统运维:
传统行业的IT运维大多是面向企业内部(体系)用户，偏重业务运维。其需求相对明确、稳定，具有很强的行业系统特点，与业务耦合性很深很广。另外制造行业的MES系统、财务部门的ERP系统、企业内部的邮箱系统、OA系统以及桌面运维的相关软件及系统，也通常是面相企业内部员工。
因此传统运维面向的用户在其数量、需求、特性通常是可控的、稳定的、集中的。
也因此传统运维圈子适合购买商业产品，这些产品通常是比较成熟的产品，经过长期的测试和使用，有很好地最佳实践，相对能够较好地满足传统运维需求。
互联网运维:
互联网运维偏重技术产品运维，相比传统行业来说，互联网业务系统大都同质化，甚至没有特定业务背景，就是通用的纯技术产品。
互联网运维通常面向的是广大互联网用户，因此其面向的对象关系复杂，市场多变，需求五花八门，目的目标不可控，对象海量不可控。
也因此互联网运维的系统环境变更迭代频繁，对自动化、弹性需求要求较高。由于各种复杂多变因素，通常导致传统商业产品不能很好地支撑互联网运维环境。因此被逼无奈只能选择开源，并走自主开发这条路子。
2.5 运维人员差异
有服务器的地方就有运维
其实近年来，在这两大运维体系之间流动的运维工程师也不在少数。本文作者就是这两大运维圈子的跨界者。
传统运维:
传统运维圈的从业人员，其知识体系普遍比较高逼格。不论其学历背景还是再教育背景通常比较高大上。
同时相关商业产品的培训认证体系也相对完善，传统行业的运维工程师在这方面有其特色。在传统企业，培训通常是厂商免费，合同附带的，或者单位出钱。
比如他们通常玩过大型机、VMax、Z/os、Oracle、ITSM、PMP、ISO、PCI、某国加密产品、某国数据库，等等一系列高逼格的玩法。
互联网运维:
在互联网运维圈的从业人员，其来历千差万别，既有超人大神，也有小白。他们通常LAMP/LNMP基础扎实，写得一手好脚本，练得一身全栈功夫。在互联网企业，知识技能培训机会通常比较少，往往需要自掏腰包参见培训，自学成才。
互联网天生具有万众创新的基因，因此这片空间广阔任鸟飞，很多大神往往不是通过各种培训出来的，都是在各种磨练中涅槃出来的。
由于互联网产业的迅猛发展，互联网运维人员的薪酬也普遍高于传统运维从业人员。
2.6 运维体制理念差异
由于架构的不同，面向对象不同，服务原则不同，因此传统运维与互联网运维在商业运营模式上自然有很多不同。传统企业，有时很多运营指标是社会效益第一位的。而互联网企业则通常是经济效益第一位。关于两种运维运营理念的差异，下文列举了一些供读者参考。
传统运维
传统企业，给你的往往是一个，相对封闭的保育箱，注重大统一的发展思路，思想导向，大局导向。员工忠诚度高，离职率相对低。
传统运维圈子里，看重商业运维产品、服务支持、业务运营流程这些因素，但对开源产品体系比较慎重或者没兴趣。
传统运维关注流程、关注业务、讲究ITIL，ISO标准体系，通常关注业务运行的高度稳定，高度一致性、集中性。传统运维自动化程度通常不高，但求运营稳定可靠。
传统运维行业多是企事业单位，共和国长子长孙型企业，在运维经营指标、人事组织，薪资体系，运维KPI考核等一系列观念和互联网运维行业的理念还是有很大差别的。
互联网运维
在互联网运维圈子里，则看重开源产品、关注新技术、看重研发，对很多商业的东西则通常不会投入使用。
互联网企业注重才华外漏，很多事情是结果导向。虽然经常搞些员工贴心小活动，但员工离职相对频繁，创业的不少。
互联网运维通常关注网站响应、网站性能、关注灵活快捷、分布式、开放式，关注安全体系。在很多互联网大企业里，其运维自动化程度非常高。
3、去IOE运动探析
谈起传统运维，则通常会自然地、密切地关联到IOE架构体系。这也是传统运维近年来爱恨交加的根源。因此在本节内容，我们探讨一下去IOE相关内容。
近年来开源技术的迅猛发展，以及国内外政策环境共同作用，引发了一场去IOE的风潮，开始使用低廉的软硬件产品代替昂贵高门槛的IOE产品，搭建起自主开放的开源系统架构。
3.1 去IOE原因
之所以出现“去IOE”运动，其中原因总结概述如下几条：
1.自“棱镜门事件”之后，国家强烈意识到数据安全的重要性，开始大力提倡产品设备国产化与自主研发，这正与“去IOE”观点不谋而合，上下一致。
2.近年来，云计算、大数据等新兴IT技术的蓬勃发展，促使众多行业开始往更加开放灵活的开放系统架构转型。
而对于传统的IOE架构而言，其定制与扩展灵活性有限，往往是擅长于集中式架构的管理，而很难应对大规模集群，分布式存储计算。
3.在购买成本方面，以IOE为代表的商业产品价格昂贵(动辄上百万元);而PC服务器则相对廉价，通常几万元。
在部署与管理方面，IOE产品的学习掌握门槛偏高，而开源系统环境相对容易搭建与管理。
另外IOE产品技术相对商业封闭，不易掌握。
3.2 是否要去IOE
基于上述一些原因，去IOE应时而生。看到别人去IOE很成功，然后自己也想玩花的。有没有实力资本玩花的，具体到自身企业是否要去IOE，这需要慎重考虑，三思而行。毕竟适合自身发展需要的系统架构就是好的架构。
去IOE过程，其实是系统架构的更新换代，产品的更新换代，运维理念的更新换代，运维人员的更新换代，知识体系的更新换代，等等。
因此如果冒然去IOE，可能既不会降低成本，也不会提高效率，更不会稳定架构。如下列举几点“去IOE”要考虑的因素：
1.自身业务是否真正需要大数据、云计算以及分布式这种海量运维体系。
2.是否已经考虑好系统架构、运维理念、人员、知识更新换代的方案。
3.自身的研发实力储备是否够解决大量开源产品的坑坑洼洼，并有实力搭建开源系统架构。
4.是否有足够的资金应对“去IOE”转型中的成本，例如从软硬件高成本转向人力技术高成本。
小结论：
A. 去IOE只是给予我们一些最佳实践与选择路线，但去IOE技术门槛较高，一般企业很难复制。
B. 从目前发展来看，去I、E案例较多，去O不容易，IOE架构与非IOE架构仍将长期并存。 一时间很难找到一些能够完美替代以IOE为代表的成熟(且普适)产品方案。
4、运维自动化探析
4.1 为什么需要运维自动化
上节讨论了传统运维中典型的IOE问题。那么谈到互联网运维，我们大都也会立刻关联想到运维自动化。因为运维自动化天然带有很多互联网开源基因，在互联网行业有很多最佳实践。因此本节讨论一下运维自动化。
做好运维不是单靠几个超人就能搞定的，做好维工作需要一整套运维体系解决方案。恰恰做运维自动化是很好的切入点，通过实施运维自动化，能够很好贯穿人、事、物、流程标准。运维体系的好坏影响运维自动化的实施执行，反过来，运维自动化也会推动运维体系的建设。
当前市场上已经有很多成熟的(商业、开源)运维产品工具，各有特色也各有利弊，这也同时造成一个尴尬局面：运维人员要不断学习和管理很多运维产品工具，但却很难有找出一个很好适应本企业(持续不断)定制化需要的产品工具。当企业IT规模大到一定程度(例如拥有几千台甚至上万台以上服务器规模)，对于企业的快速变化、需求的高度定制化，灵活而又庞大复杂的运维需求，很难有(或者没有)现成的运维产品能够满足需要。因此很多有实力的企业都会选择自主运维及开发。
运维自动化开发，不再单纯、局限地依靠某个网管监控产品，而是需要提供体系化运维解决方案，包括系统网络管理、CMDB资产信息管理、知识库管理、乃至ITSM信息服务流程管理等。
4.2 运维自动化系统设计案例
下面就一个运维自动化系统案例，简介一下该系统架构。
本解决方案立足从三大维度构建，如下图所示。分别是IT运维流程、IT监控平台整合、IT运维自动化。这三大维度主要具有如下几大功能模块。
IT运维流程：资产管理、知识库管理、安全管理、事件管理、日常事项管理。
IT监控平台整合：监控报警管理、日志管理、性能管理、报表管理。
IT运维自动化：应用管理、配置管理、程序运行管理。
系统功能框图如下图所示。
本解决方案使用的开发语言及工具：
后端及系统客户端开发主要通过Python、Shell等程序语言实现。
信息采集写入MySQL数据库。
前端WEB展示以及与后台数据层、应用层的逻辑交互通过Django框架实现。
界面修饰美化使用Bootstrap等框架工具。
部分系统功能简介
如下图是网民访问实时动态分析监控。
如图所示是基于Cacti深度定制的网络拓扑流量监控。主要是动态实时地监控各个主要节点的网络流量。
如图所示是资产管理模块中的硬件配置模块。主要是资产的增删改查功能。对于大量资产信息的录入是通过后台管理中的信息导入模块(将固定格式的Excel资产信息表)批量录入到系统中。该模块主要通过Django
CBV方式快速实现。
如图所示是基于ELK深度定制的日志监控模块。基于各类日志信息进行监控与统计。
如图所示是系统的性能图表展示
如图所示是系统自动化部署模块，具有批量查询IP使用情况、派发客户端、部署与配置系统等功能。自动化部署主要基于kvm、Salstack等深度开发而实现。
5、运维发展趋势探析
5.1 运维体系构建
如上文所述，我们探析了传统运维与互联网运维的不同层面维度的差异，但从另一方面来看，都作为运维，还是有很多共同之处。这里将不再区分互联网运维还是传统运维，这里将从一个架构高度看待和规划运维。
从人、事、物、流程这四个方面便可以很好地将运维体系进行解构，它们彼此互相作用，共同构建了一个完整实用的运维体系。下面列举了这四个方面各自的含义及相关内容。
人：例如完善岗位职责与职业发展、提高团队技术水平、完善技能分享与培训、完善团队绩效考核、规范工作行为规范等。目的是要建成一支工作高效、技术水平高、团结稳定、有职业素养的运维团队。
事：例如做好日常基础运维工作，保障好生产业务运行。不断探索新的运维理念与技术，探索优化系统架构。具体可以分为几大块，例如运维流程管理，资源架构规划，应急与故障处理，监控与优化，安全与防护，项目及日常工作，等等。目的是要明白运维做什么正确的事，怎么正确地做事，做事有章法，稳定高效能。
物：主要是如何管理好系统运维所涉及的各种资源。例如机房环境、办公设备、服务器、网络设备、操作系统、应用软件、工具等各种软硬件资源。目的要使各类资源配置管理妥当，清楚资源属性，知道从哪来，现在哪，要去哪。使得物尽其用，物有所值，安置妥当。
流程标准：运用流程标准将上述要素(人、事、物)有机地结合，有序科学地流转、高效稳定地运行。例如资源规划与采购，各种标准规范、项目规范、软硬件配置部署规范、安全制度、工作交接，等等。
基于上述四大维度，下文给出了一个矩阵表进行表述举例。
5.2运维路在何方
未来的运维道路在何方，我从哪来，要到那里去?这是每一个运维从业者都会面临的问题。本文关于运维发展趋势的一些辨析如下：
云计算等各种理念技术的发展，这些都将对运维行业带来巨大的机遇与挑战。很多企业都处在传统IDC运维方式与云运维方式的探索中。
在新的形势下，传统运维方式与基于云计算的运维方式将长期并存，公有云与私有云及混合云运维局面将长期并存，传统IT运维与互联网IT运维也仍将长期并存。展开阐述如下：
传统运维领域正在探索容器、自动化、云计算、开源架构等转型之路。互联网运维也在借鉴或使用成熟的商业产品与理念。
基于IOE架构的业务系统正在处于转型中，开始逐步拥抱开源技架构。但基于开源互联网技术的成功经验也并非都能复制。基于互联网开源的技术实践正在蓬勃发展，势头迅猛，其中也借鉴了很多商业闭源的产品、架构、技术。
完全闭源的生态环境和完全开源的生态环境是两个极端，更多的IT生态是混源状态，双(多)模状态。研发与运维甚至业务之间的边界也并非黑白分明，DevOps的理念逐步深入到各类IT的各个层面。
在上述大环境下，运维部门不会变的越来越清闲了，相反承担的企业发展战略的责任越来越大了。运维部门将由传统的IT成本中心更多地向IT服务中心、价值输出中心、利润输出中心转变。
在上述发展形势下，运维的人、事、物、流程规范都将相应发生变化，如人员数量会有变化，职位职责会有变化，设备资产会有变化，各种流程规范都将发生变化。
5.3运维人发展之路
Head
The conviction to change What do they hear and think?
Are they convinced of the need for change, the vision,
the plan? What is their analysis
Heart
The desire to change What do they see, feel and want?
Are they triggered by a story, by examples? What is
their mindset? Buzz words? What behaviour change is
driving the change?
Hands
The capacity to change What do they experience? Are
they capable? Do they have the necessary new organization,
competen-ces, budgets, processes, products.
T型人才适用于很多行业人才。解释如下。
T型人才是指按知识结构区分出来的一种新型人才类型。用字母“T”来表示他们的知识结构特点。“—”表示有广博的知识面，“|”表示知识的深度。两者的结合，既有较深的专业知识，又有广博的知识面，这类集深与博于一身的人才。这种人才结构不仅在横向上具备比较广泛的一般性知识修养，而且在纵向的专业知识上具有较深的理解能力和独到见解。
T”型人才就是：既有专业深度，又有思维广度，能够跨界思考和探索;既能够在一个点上专注、投入其中，同时又能够对外部世界保持开放的心态，接纳不同的视角;既能够对问题做根源思考，又能够从系统的角度做整合解决方案设计。
我定义了一种人才模型，称为“十型人才”，更适合运维人才发展之路。我对十型人才的解释如下：
高度： 应该又高远的视野，高屋建瓴的能力，方向掌控能力。有能力，有执行力带领团队走在一个道上。
深度： 应该能敏锐的抓住问题，事情的关键点。有比较好的毅力和韧性去做事情。
宽度： 有宽广的技术知识面。有宽广胸怀气度。很好的包容协调能力。
5.4 运维路在何方
DevOps 不是一项技术，也不是一套流程和方法论，更不是一套简单的工具产品。越来越多的迹象表明，DevOps是一种文化。
这意味着，DevOps 可以持续地、源源不断地向业务传递价值，IT成为企业的生命线，事关企业生死存亡及发展大计。
这意味着，DevOps 再也不仅仅是 Dev 和 Ops 的事了，而且包括计划、需求、设计和后续的运营。所以，不再是一个纯粹的技术问题。
这意味着，DevOps 需要更广泛地知识体系。运维只是多会些 Python，就不要说自己是 DevOps
了。
写在最后一的句话：
此图从整体上看是一位和尚的图像，也就是佛教的代表，即正面是释迦牟尼。左侧头戴方巾者为儒教的代表，即孔子。右侧头后挽个发髻的则是道教的图像，即老子。三教共存一碑，一片圆融。这三个头像合在一起，加上合肩、合上身，浑成一体，两手捧“九流混元图”，构成佛、儒、道三教及“九流”的“混元三教九流图”。
大道自然，顺势而为。抉择至关重要，最好的运维是在正确的领域由正确的人干正确的运维事情…… |
