两人相遇，发现彼此都是干运维的，瞬间热泪盈眶仿佛找到了失散多年的亲人。因为他们同样都承受着 IT 运维不能承受的职业之痛：
对于我们干运维的同行，其传统运维与互联网运维有很多共同之处，但也有相隔千山万水般的鸿沟。
所以说运维的世界那么大，我想去看看，运维冰火两重天的二元世界。
近一年，关于传统运维与互联网运维的探讨越来越多，在运维体系快速变革地环境下，运维未来的走向，成为行业的关注点。他们的特点，异同在哪？从哪里来到哪里去？
每个单位组织的 IT 环境，不论大小复杂度，总会有个系统架构层次。有了这个架构体系，那所有的运维事情大体都围绕着这个系统架构上的每个元素及整体进行运维保障工作。
运维体系架构从某种角度可以划分为如下两种：
商业封闭式系统架构(IOE 架构)
开源系统架构
通常我们会将围绕商业封闭式系统架构(IOE 架构)的运维视作传统运维，将围绕开源系统架构的运维视作互联网运维。
典型的即以使用 IOE(IBM、Oracle、EMC)产品软硬件为主要元素的系统架构。
IOE 架构以纵向扩展为特点，通过增加 CPU、内存、扩展柜、冗余备件等方式来提高处理能力及稳定性。
该架构的处理能力主要取决于单台(套)设备(系统)的最大扩展能力，很难通过增加设备(系统)数量来增加处理能力，换句话说该架构很难通过扩大集群规模的方式来解决问题。
随着纵向扩展的规模增大，它的实施技术难度、管理复杂度以及隐患风险都会成比例大幅上升。基于IOE架构的典型企业如：金融业、电信业、能源业、交通运输业。
上述为IOE型系统架构，其：
这些服务器、存储等硬件本身往往就是双冗余的，线路连线也都是双冗余的，而且设备性能指标往往非常好，例如一台普通中端的 Power 7 系列服务器可以轻松划分出若干个系统分区或者一二十个虚拟机系统。
典型的即以使用廉价PC服务器，开源产品技术为主要元素的系统架构。
开源系统架构以横向扩展，分布式部署为特点。常通过向集群中增加单机设备资源解决存储空间、性能以及稳定性问题，其集群规模可以小到两三台PC服务器，也可以大到上万台。
对于数据库，可以通过分布式集群方式解决数据库扩展性的问题。另外非结构化数据库及分布式文件系统在处理非结构化数据的存储与使用方面也很灵活方便。
基于开源系统架构的典型企业如：以BAT(百度、阿里、腾讯)为代表的众多互联网企业。
上述开源系统架构中使用了 CDN 和反向代理以提高网站性能。
例如我们的服务器可能部署在北京，对于北京及周边用户来说访问是较快的，而对于远离北京的用户访问则感觉较慢，因为数据传输时间比较长。
对于这种情况，常常使用CDN解决，CDN将数据内容缓存到运营商(或自建CDN)的机房，用户访问时先从最近的CDN机房获取数据，这样大大减少了网络访问的路径。
对于反向代理，当用户请求到达时首先访问反向代理，反向代理服务器将(如：Varnish)缓存的数据返回给用户，如果没有缓存，才会从源站服务器获取，这也减少了获取数据的成本。
当然对于海量访问请求，或庞大集群架构，则就需要分多层，综合运用上述负载均衡以及代理(反代理)，同时可能需要引入 Zookeeper 等功能以协调(服务)任务调度。
从上述架构简析中，我们便会感知到两种运维体系的巨大差异。可以说基于IOE架构的传统运维体系，与基于开源架构的互联网运维体系，是当前两大运维阵营。
一个奇怪的现象
差异可见一斑
传统运维圈子和互联网运维圈子各有特点，同是运维行业，但也有很多差异之处。关于传统运维与互联网运维的不同差异。
知识体系的差异通常表现为 IOE 架构与非 IOE 架构相关的知识体系差异。这里首先介绍一下互联网运维知识体系。
本互联网运维知识体系从网民浏览器终端发起，分层分级方式逐步分解到服务器基础设施层，另外从运维管理体系、监控体系、安全体系、自动化体系、云计算等多个层次维度全方位展示了运维知识体系。
传统运维
大多是面向企业内部(体系)用户，偏重业务运维。
其需求相对明确、稳定，具有很强的行业系统特点，与业务耦合性很深很广。
制造行业的MES系统、财务部门的ERP系统、企业内部的邮箱系统、OA系统以及桌面运维的相关软件及系统，也通常是面相企业内部员工。
因此传统运维面向的用户在其数量、需求、特性通常是可控的、稳定的、集中的。
也因此传统运维圈子适合购买商业产品，这些产品通常是比较成熟的产品，经过长期的测试和使用，有很好地最佳实践，相对能够较好地满足传统运维需求。
互联网运维
偏重技术产品运维，相比传统行业来说，互联网业务系统大都同质化，甚至没有特定业务背景，就是通用的纯技术产品。
通常面向的是广大互联网用户，因此其面向的对象关系复杂，市场多变，需求五花八门，目的目标不可控，对象海量不可控。系统环境变更迭代频繁，对自动化、弹性需求要求较高。
由于各种复杂多变因素，通常导致传统商业产品不能很好地支撑互联网运维环境。因此被逼无奈只能选择开源，并走自主开发这条路子。
有服务器的地方就有运维。其实近年来，在这两大运维体系之间流动的运维工程师也不在少数。本文作者就是这两大运维圈子的跨界者。
传统企业，有时很多运营指标是社会效益第一位的。而互联网企业则通常是经济效益第一位。
近年来开源技术的迅猛发展，以及国内外政策环境共同作用，引发了一场去 IOE 的风潮，开始使用低廉的软硬件产品代替昂贵高门槛的 IOE 产品，搭建起自主开放的开源系统架构。
之所以出现“去 IOE”运动，其中原因总结概述如下几条：
自“棱镜门事件”之后，国家强烈意识到数据安全的重要性，开始大力提倡产品设备国产化与自主研发，这正与“去 IOE”观点不谋而合，上下一致。
近年来，云计算、大数据等新兴IT技术的蓬勃发展，促使众多行业开始往更加开放灵活的开放系统架构转型。
而对于传统的 IOE 架构而言，其定制与扩展灵活性有限，往往是擅长于集中式架构的管理，而很难应对大规模集群，分布式存储计算。
在购买成本方面，以 IOE 为代表的商业产品价格昂贵(动辄上百万元)；而 PC 服务器则相对廉价，通常几万元。
在部署与管理方面，IOE 产品的学习掌握门槛偏高，而开源系统环境相对容易搭建与管理。
IOE 产品技术相对商业封闭，不易掌握。
去 IOE 过程，其实是系统架构的更新换代，产品的更新换代，运维理念的更新换代，运维人员的更新换代，知识体系的更新换代，等等。
如下列举几点“去IOE”要考虑的因素：
自身业务是否真正需要大数据、云计算以及分布式这种海量运维体系。
是否已经考虑好系统架构、运维理念、人员、知识更新换代的方案。
自身的研发实力储备是否够解决大量开源产品的坑坑洼洼，并有实力搭建开源系统架构。
是否有足够的资金应对“去IOE”转型中的成本，例如从软硬件高成本转向人力技术高成本。
避免繁琐重复性工作
提高运维生产力
避免人为失误
更有效协同工作
灵活自动伸缩
推动运维标准化、智能化、体系化
互联网运维的典型标志······
当前市场上已经有很多成熟的(商业、开源)运维产品工具，各有特色也各有利弊，这也同时造成一个尴尬局面：运维人员要不断学习和管理很多运维产品工具，但却很难有找出一个很好适应本企业(持续不断)定制化需要的产品工具。
当企业IT规模大到一定程度(例如拥有几千台甚至上万台以上服务器规模)，对于企业的快速变化、需求的高度定制化，灵活而又庞大复杂的运维需求，很难有(或者没有)现成的运维产品能够满足需要。因此很多有实力的企业都会选择自主运维及开发。
运维自动化开发，不再单纯、局限地依靠某个网管监控产品，而是需要提供体系化运维解决方案，包括系统网络管理、CMDB资产信息管理、知识库管理、乃至ITSM信息服务流程管理等。
就一个运维自动化系统案例简单介绍一下该系统架构。
本解决方案立足从三大维度构建，如下图所示。分别是 IT 运维流程、IT 监控平台整合、IT 运维自动化。这三大维度主要具有如下几大功能模块：
IT 运维流程：资产管理、知识库管理、安全管理、事件管理、日常事项管理。
IT 监控平台整合：监控报警管理、日志管理、性能管理、报表管理。
IT 运维自动化：应用管理、配置管理、程序运行管理。
系统功能框图如下图所示。
本解决方案使用的开发语言及工具：
后端及系统客户端开发主要通过 Python、Shell 等程序语言实现。
信息采集写入 MySQL 数据库。
前端 WEB 展示以及与后台数据层、应用层的逻辑交互通过 Django 框架实现。
界面修饰美化使用 Bootstrap 等框架工具。
部分系统功能简介
如下图是网民访问实时动态分析监控。
虽然传统运维与互联网运维在不同层面维度存在差异，但从另一方面来看，都作为运维，还是有很多共同之处。这里将不再区分互联网运维还是传统运维，从一个架构高度看待和规划运维。
从人、事、物、流程这四个方面便可以很好地将运维体系进行解构，它们彼此互相作用，共同构建了一个完整实用的运维体系。下面列举了这四个方面各自的含义及相关内容。
人：例如完善岗位职责与职业发展、提高团队技术水平、完善技能分享与培训、完善团队绩效考核、规范工作行为规范等。
目的是要建成一支工作高效、技术水平高、团结稳定、有职业素养的运维团队。
事：例如做好日常基础运维工作，保障好生产业务运行。不断探索新的运维理念与技术，探索优化系统架构。具体可以分为几大块，例如运维流程管理，资源架构规划，应急与故障处理，监控与优化，安全与防护，项目及日常工作，等等。目的是要明白运维做什么正确的事，怎么正确地做事，做事有章法，稳定高效能。
物：主要是如何管理好系统运维所涉及的各种资源。例如机房环境、办公设备、服务器、网络设备、操作系统、应用软件、工具等各种软硬件资源。
目的要使各类资源配置管理妥当，清楚资源属性，知道从哪来，现在哪，要去哪。使得物尽其用，物有所值，安置妥当。
流程标准：运用流程标准将上述要素(人、事、物)有机地结合，有序科学地流转、高效稳定地运行。例如资源规划与采购，各种标准规范、项目规范、软硬件配置部署规范、安全制度、工作交接，等等。
未来的运维道路在何方，我从哪来，要到那里去?这是每一个运维从业者都会面临的问题。
云计算等各种理念技术的发展，这些都将对运维行业带来巨大的机遇与挑战。很多企业都处在传统 IDC 运维方式与云运维方式的探索中。
在新的形势下，传统运维方式与基于云计算的运维方式将长期并存，公有云与私有云及混合云运维局面将长期并存，传统 IT 运维与互联网 IT 运维仍将长期并存。
传统运维领域正在探索容器、自动化、云计算、开源架构等转型之路。
互联网运维也在借鉴或使用成熟的商业产品与理念。
基于IOE架构的业务系统正在处于转型中，开始逐步拥抱开源技架构。
基于开源互联网技术的成功经验也并非都能复制。基于互联网开源的技术实践正在蓬勃发展，势头迅猛，其中也借鉴了很多商业闭源的产品、架构、技术。
完全闭源的生态环境和完全开源的生态环境是两个极端，更多的 IT 生态是混源状态，双(多)模状态。研发与运维甚至业务之间的边界也并非黑白分明，DevOps 的理念逐步深入到各类 IT 的各个层面。
在上述大环境下，运维部门不会变的越来越清闲了，相反承担的企业发展战略的责任越来越大了。运维部门将由传统的 IT 成本中心更多地向IT服务中心、价值输出中心、利润输出中心转变。
在上述发展形势下，运维的人、事、物、流程规范都将相应发生变化，如人员数量会有变化，职位职责会有变化，设备资产会有变化，各种流程规范都将发生变化。
运维人发展之路
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”型人才：
十型人才，更适合运维人才发展之路。
高度： 应该又高远的视野，高屋建瓴的能力，方向掌控能力。有能力，有执行力带领团队走在一个道上。
深度： 应该能敏锐的抓住问题，事情的关键点。有比较好的毅力和韧性去做事情。
宽度： 有宽广的技术知识面。有宽广胸怀气度。很好的包容协调能力。
DevOps 不是一项技术，也不是一套流程和方法论，更不是一套简单的工具产品。越来越多的迹象表明，DevOps 是一种文化。这意味着：
DevOps 可以持续地、源源不断地向业务传递价值，IT成为企业的生命线，事关企业生死存亡及发展大计。
DevOps 再也不仅仅是 Dev 和 Ops 的事了，而且包括计划、需求、设计和后续的运营。所以，不再是一个纯粹的技术问题。
DevOps 需要更广泛地知识体系。运维只是多会些 Python，就不要说自己是 DevOps 了。
写在最后一的句话：大道自然，顺势而为。抉择至关重要，最好的运维是在正确的领域由正确的人干正确的运维事情。
本文作者:王天维 韩晓光 来源:51CTO博客
CIO之家 www.ciozj.com 微信公众号:imciow