传统运维 VS 互联网运维
运维是什么
运维是什么
运维，一般专指互联网运维，是互联网企业的技术部门之一；对网络、服务器、服务的生命周期各个阶段进行运营和维护，使公司在成本、稳定性、效率上达到一定的平衡状态。
互联网运维工作，以服务为中心，以稳定、安全、高效为三个基本点，确保公司的互联网业务能够7×24小时为用户提供高质量的服务。
运维人员对公司互联网业务所依赖的基础设施、基础服务、线上业务进行稳定性加强，进行日常巡检发现服务可能存在的隐患，对整体架构进行优化以屏蔽常见的运行故障，多数据中接入提高业务的容灾能力。
通过监控、日志分析等技术手段，及时发现和响应服务故障，减少服务中断的时间，使公司的互联网业务符合预期的可用性要求，持续稳定地为用户提供服务。
在安全方面，运维人员需要关注业务运行所涉及的各个层面，确保用户能够安全、完整地访问在线业务。
扩展资料：
IT运维管理是指单位IT 部门采用相关的方法、手段、技术、制度、流程和文档等，对IT运行环境（如软硬件环境、网络环境等）、IT业务系统和IT运维人员进行的综合管理。
随着信息化进程的推进，运维管理会复盖对整个组织运
行，进行支持的管理信息系统涵盖的所有内容，除了传统的IT运维，还拓展了业务运维和日常管理运维。
业务运维面向整个组织提供各业务系统的问题受理、响应、处理和转交等方面的服务；日常管理运维面向整个组织提供针对各业务系统的运行状态和需求变化和不同的记录、跟踪、保存、分析方面的管理。
07聊聊CMDB的前世今生
07 | 聊聊CMDB的前世今生赵成- 00:04 / 10:11我们前面在讲标准化的时候，对关键的运维对象做了识别，主要分为两个部分：基础设施层面：IDC机房、机柜、机架、网络设备、服务器等；应用层面：应用元信息、代码信息、部署信息、脚本信息、日志信息等。
这两部分是整个运维架构的基础部分，运维团队是维护的Owner，需要投入较大的精力去好好地规划建设。
当我们识别出运维对象和对象间的关系，并形成了统一的标准之后，接下来要做的事情就是将这些标准固化，固化到某个信息管理平台中，也就是我们常说的配置管理叫作CMDB（Confguration Management DataBase）。
其实，如果我们找准了需求和问题在哪里，你会发现技术手段和平台叫什么就真的不重要了，只要是内部能够达成一个统一共识的叫法就好。
关于如何打造CMDB和应用配置管理，我之前有一篇公开的文章《有了CMDB，为什么还需要应用配置管理》，写得已经比较细致了，会在下一期发布出来，但不占用我们专栏的篇幅。
今天我主要来聊一聊CMDB的前世今生，帮助你更加深刻地理解这个运维核心部件，对我们后面开展CMDB的建设大有裨益。
CMDB源起CMDB并不是一个新概念，它源于ITIL（Information Technology Infrastructure Library，信息技术基础架构库）。
而ITIL这套理论体系在80年代末就已经成型，并在当时和后来的企业IT建设中作为服务管理的指导理论得到广泛推广和实施。
但是为什么这个概念近几年才被我们熟知？为什么我们现在才有意识把它作为一个运维的核心部件去建设呢？我想主要有两个因素，一个起了限制作用，一个起了助推作用。
CMDB这个概念本身的定义问题，限制了CMDB的实施；互联网技术的发展驱动了运维技术的发展和演进，进而重新定义了CMDB。
传统运维思路下的CMDB我们先来看下第一个原因，按照ITIL的定义：CMDB，Confguration Management D ataBase，配置管理数据库，是与IT系统所有组件相关的信息库，它包含IT基础架构配置项的详细信息。
运维发展趋势
运维发展趋势随着信息技术的不断进步和应用，运维（Operations and Maintenance）领域也面临着新的发展趋势。
下面是运维发展的一些趋势：1. 自动化：随着机器学习、人工智能等技术的发展，自动化已成为运维的一个重要方向。
自动化可以降低人为操作的错误率，提高效率，减少人力成本。
例如，自动化的监控和告警系统可以实时监测系统状态，并及时发出警报。
自动化的配置管理系统可以自动更新和管理系统配置，提高稳定性和安全性。
2. 云计算和虚拟化：云计算将计算、存储和网络等资源进行了虚拟化和集中管理，为运维工作带来了新的挑战和机会。
云计算环境下的运维需要熟悉虚拟化技术，能够有效管理和监控云平台的资源和服务。
3. 容器化：容器化技术（如Docker）的发展为应用程序的打包、部署和管理带来了革命性的变化。
容器技术可以将应用程序及其依赖打包成一个独立的运行时环境，使得应用程序可以在不同的环境中快速部署和迁移。
容器化的应用程序更易于扩展和管理，减少了运维的工作量。
4. DevOps：DevOps是开发（Development）和运维（Operations）之间的一种合作模式和文化。
它通过强调沟通、协作和集成来提高软件开发和运维的效率。
在DevOps模式下，开发和运维团队共享资源和知识，将开发和运维过程融为一体，实现持续集成和持续交付。
DevOps将开发和运维的界限打破，提高了应用交付的速度和质量。
5. 硬件定义的网络（SDN）和网络功能虚拟化（NFV）：SDN和NFV技术将网络资源进行了虚拟化和集中管理，使得网络的配置和维护更加灵活和可靠。
运维人员需要熟悉SDN和NFV技术，能够有效管理和维护虚拟化的网络环境。
6. 安全性：随着信息安全威胁的不断增加，安全性成为运维的重要关注点。
运维人员需要密切关注安全漏洞和威胁，并及时采取相应的措施进行防御。
运维人员需要掌握网络安全、应用安全等方面的知识，能够对系统进行有效的安全监控和防护。
运维服务发展历程
运维服务发展历程运维服务是指对计算机系统或网络进行监控、修复和维护的一项服务。
随着计算机技术的发展，运维服务也经历了不断的演进和发展。
本文将从初期的手动运维到现代的自动化运维，概述运维服务的发展历程。
早期的运维服务主要是由人工操作进行的。
当计算机系统发生故障时，运维人员需要到现场进行检修和维护。
这种方式人工成本高，效率低下，且容易出现人为操作错误。
随着计算机系统的规模不断扩大，手动运维变得越来越难以胜任。
为了提高运维效率，自动化运维工具逐渐出现。
最初的自动化运维工具主要是针对特定的操作系统或软件，例如Shell脚本和批处理脚本等。
这些工具可以自动化执行一系列操作，如安装软件、配置网络等，提高了运维效率。
然而，由于不同的系统和软件要求不同的运维工具，使得运维人员需要掌握多种工具的使用方法。
随着云计算和大数据技术的发展，虚拟化技术在运维服务中得到了广泛的应用。
虚拟化技术可以将物理资源抽象为虚拟资源，使得运维人员可以更灵活地进行资源管理和调度。
同时，容器技术的出现使得应用程序的部署和管理更加便捷。
运维人员只需通过简单的命令，即可实现应用程序的自动化部署和扩容。
近年来，自动化运维趋势越来越明显。
自动化运维工具的功能不断增强，可以根据预设的规则，根据系统状态自动执行相应的操作。
例如，当网络出现故障时，自动化运维工具可以自动检测故障点并进行修复。
此外，利用机器学习和人工智能等技术，运维工具可以分析历史数据，预测未来发生的故障，并提前采取措施防止故障的发生。
总体来说，运维服务经历了从手动运维到自动化运维的发展历程。
自动化运维工具的出现大大提高了运维效率和可靠性，降低了人工成本。
未来，随着技术的不断进步，运维服务将进一步向智能化和自动化方向发展。
运维人员将更多地担负起规划和设计系统、优化运维策略的角色，将运维工作推向更高的层次。
IT运维这份工作有没有意思？看看行内人怎么说…
IT运维这份工作有没有意思？看看行内人怎么说…在公司里面，IT运维通常都被认为是打杂的、吃力不讨好的工作。
那些从事这类工作的童鞋们 ，你们觉得IT运维有意思么？如果有，那哪方面比较有意思呢？陈小生，网络游戏系统运维工程师最近收到批量邮件，都是某某某职位某某某同事升职的消息，高级xxx，资深xxx，就是没有SA职位的动静。
呵，同事的一句话：我们已经是ROOT了，不需要这些！有了ROOT，还会没趣么？dccmx，IT、互联网、搞技术的这个跟如何定位运维工作以及如何要求运维工作有关。
有没有趣不好说，但是如果说有没有挑战，那是肯定有的。
这里就说说运维的挑战。
运维本身范围很广，从基本的资源管理、配置，到数据库维护、应用的部署。
再到事故的分析处理。
到处需要技术与智慧。
和业务开发一样，只要量一上来，什么都是问题。
如果仅仅把自己的工作定位于帮开发准备一下机器，部署一下应用，删一删垃圾文件，再盯一盯机器，然后，做这些事情的时候就按照最普通的手工方法一步一步做，一个人做不来，就两个人做，一天做不完就两天做完，反正能在某个时间做完就行了。
如果这样，很快工作就会变得枯燥乏味。
如果把要求提高，能够用最少的人，花最少的时间和精力，将这些基本的事情做漂亮，后续监控不要人肉盯。
那就很难了。
如果再进一步，想反过来促进开发，让开发人员在开发的时候就想到这个业务需要怎么样来运维，那挑战就更多了。
此外，突发事故的处理也是极需要技术和经验的，这里的挑战很多，技术和经验的积累不必多说，另外我觉得很关键的一点是，运维有没有渗透到业务的开发中。
总结来说就是一句话——就看你喜不喜欢挑战。
如果你喜欢挑战，那就是有趣的；否则，就是个打杂的。
张麒，System Admin认为运维是打杂的公司，他们的内部IT一般不会好，有可能一团糟。
首先从运维工作的性质来讲，在任何公司都是一种“服务型“岗位，如果运维搞不好，会严重影响公司的发展，尤其是IT公司。
打个很简单的比方，公司的内部网络需要维护，文件服务器、BBS、邮件等等，非技术类的工作还包括固定资产管理、设备选型、采购，另外就是日常办公设备的维护、保养……也许工作比较杂，但绝对不是一个打杂的。
运维的四个发展阶段，看看自己在哪个阶段，聊聊怎么升级打怪
运维的四个发展阶段，看看⾃⼰在哪个阶段，聊聊怎么升级打怪运维的四个发展阶段，看看⾃⼰在哪个阶段，聊聊怎么升级打怪Linux 运维发展路线常见的就是下⾯这条路线：运维应⽤-->系统架构-->运维开发-->系统开发按照运维的职业发展阶段，⾄少可以分为运维应⽤级别、系统架构级别、运维开发级别、系统开发级别。
每个阶段都有不同的特点，也⾯临着不同的难题，以下是我的总结。
⼀、运维的四个发展阶段01.运维应⽤级别：这个阶段就是玩别⼈的软件，例如：linuxnginxmysqlphpnagios ⼤多数的 linux运维⼯程师，⽹络⼯程师，系统⼯程师都是这个阶段。
这个阶段的⼯资平均3-10K。
处在这个阶段的伙伴们要注意了。
这⾥属于⾦字塔的底端，⼯资是相对⽐较低的。
02.系统架构级别：这个阶段就是⽤已知软件架构⼤规模集群⽅案以及实现各种技术⽅案这个就是所谓的系统架构师，如果是程序开发就是程序架构师。
这个阶段的⼯资平均 10K-30K，属于运维应⽤上层，需要靠技术，沟通，思想三条线通⼒配合才能达到这个⽔平。
03.运维开发级别：这个阶段就是利⽤已知语⾔，开发基本的应⽤层⼯具，例如：web 管理系统这个阶段的平均⼯资⼤概 10-30K，如果具备前两个运维应⽤和系统架构的积淀，那么⼯资 30-60K 很轻松。
这个阶段就是利⽤已知语⾔，开发基本的应⽤层⼯具，例如：web 管理系统04.系统开发级别：这个阶段就是修改开源的软件，或者开发新的服务软件（例如：也开发⼀个 web软件，存储软件）与底层软件（例如：OS）这个阶段的平均⼯资⼤概 20-60K，如果具备前两个运维应⽤和系统架构的积淀，⼯资更⾼！那么⼯资 30-60K 很轻松。
⼆、如何升级打怪打怪路线：⼊门-->新⼿-->困惑-->转型第⼀阶段：⼊门前有朋友问，运维怎么⼊门，需要学习哪⽅⾯的知识，怎么才能找到运维的⼯作。
这些朋友⼤多是学⽣，或者是其他⾏业的从业者，都对互联⽹运维感兴趣，希望能从事这⽅⾯的⼯作。
运维发展历程
运维发展历程运维是现代企业管理中不可或缺的一环，它负责维护、监控和优化企业的信息技术系统，确保系统的稳定运行和高效性能。
在过去的几十年中，运维经历了许多变革和发展，下面是运维发展的一个简要历程。
运维最早起源于计算机时代的开端。
上世纪六十年代，随着计算机技术的进一步发展，企业开始使用计算机来处理各种业务数据。
为了确保计算机系统的稳定运行，他们设立了运维团队，负责维护和管理计算机硬件设备。
到了七十年代和八十年代，随着计算机技术的普及，运维的工作逐渐变得复杂。
除了硬件设备的维护，运维团队还需要处理操作系统、网络和数据库等软件的安装、配置和维护。
此时，运维的工作职责开始扩大，需要具备更全面的技术能力。
九十年代和二十一世纪初，企业的信息技术系统变得更加复杂和庞大。
面对这种情况，运维团队开始关注系统的可用性和性能。
他们引入了各种监控系统和自动化工具，以便及时发现和解决系统故障，并提升系统的性能。
随着互联网的兴起，运维的发展进入了一个新的阶段。
企业开始将自己的业务上云，采用云计算、虚拟化和容器化等新技术。
这使得运维工作变得更加灵活和便捷。
运维团队可以通过云服务商提供的管理工具和接口来快速部署和管理系统，大大减少了运维的负担。
近年来，随着人工智能和大数据等新兴技术的应用，运维工作迎来了更大的机遇和挑战。
传统的基础设施监控逐渐向智能化和自动化发展，使得运维团队可以更加深入地了解和优化系统的运行状态。
此外，运维团队还开始利用大数据分析技术，通过对系统日志和用户行为数据的分析来预测和避免潜在的故障。
未来，随着技术的不断进步，运维将继续发展和演变。
一方面，运维将更加注重系统的弹性和可扩展性，以应对不断变化的业务需求。
另一方面，随着智能化和自动化的推进，运维团队将更多地跨界融合，与开发、测试和安全等团队密切合作，共同推动企业信息技术的创新和发展。
综上所述，运维经历了从硬件维护到系统管理、监控和优化的发展过程。
随着技术的不断发展，运维的工作越来越便捷和智能化。
互联网运维主要做什么
互联网运维主要做什么在互联网时代，互联网运维成为了每个互联网企业都不可或缺的重要部分。
互联网运维是通过合理、有效地管理和维护互联网基础设施，确保互联网服务的稳定性和可靠性。
本文将探讨互联网运维的主要职责和任务。
1. 硬件及网络设备管理互联网运维的第一项任务是负责管理和维护互联网公司的硬件设备。
这些设备包括服务器、路由器、交换机等。
互联网运维团队需要确保这些设备正常运行，及时处理硬件故障，并进行设备的维修和更换。
此外，他们还需要监控网络设备的性能，及时处理网络故障，确保互联网服务的平稳运行。
2. 系统运维和配置管理互联网运维团队负责管理和维护互联网公司的服务器和操作系统。
他们需要监控服务器的性能，及时发现和解决服务器故障，并通过优化配置来提高服务器的性能和稳定性。
互联网运维人员还需要负责系统软件的安装和配置，并对系统进行维护和更新，确保系统始终在最佳状态下运行。
3. 数据备份和灾难恢复互联网运维团队需要定期备份互联网公司的重要数据并保证数据的安全性。
他们需要确保数据备份的完整性和可靠性，并及时测试和验证备份数据的恢复能力。
此外，在灾难事件发生时，互联网运维人员还需要迅速采取措施来恢复系统和数据，确保业务的连续性和稳定性。
4. 安全监控和防护互联网运维团队负责监控互联网公司的网络安全状况，并采取预防措施来保护公司的网络免受黑客攻击和数据泄露。
他们需要实施安全策略和控制，监控网络流量和活动，及时发现和应对安全事件。
互联网运维人员还需要定期进行安全漏洞扫描和评估，并确保系统和应用程序的安全性。
5. 性能优化和容量规划互联网运维团队需要监控和优化互联网公司的性能和资源利用效率。
他们需要分析系统和网络的性能数据，及时发现瓶颈和问题，通过优化配置和调整来提高系统的性能和响应速度。
此外，互联网运维人员还需要进行容量规划，预测和管理资源需求，确保系统能够满足不断增长的用户需求。
6. 服务监控和故障处理互联网运维团队需要监控互联网服务的可用性和性能。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
传统运维VS 互联网运维：从哪来，到哪去？作者介绍王天维，从事运维工作近十年，精通网络技术，CCIE专家。
专注云计算、SDN、数据中心网络架构设计。
韩晓光，专业运维，兼职开发，干过商务。
信息系统项目管理师、ITIL Foundation认证、IBM CATE、RHCE。
著有《系统运维全面解析:技术、管理与实践》一书。
概述近一年，关于传统运维与互联网运维的探讨越来越多，在运维体系快速变革地环境下，运维未来的走向，便成为运维行业的关注点。
那么：到底什么是传统运维体系?什么是互联网运维体系?他们的特点，异同在哪?从哪里来到哪里去?本文将从以下角度探讨两大运维体系。
1.商业封闭式系统架构vs 开源系统架构辨析2.传统运维vs 互联网运维辨析3.去IOE运动辨析4.运维发展趋势辨析1、商业封闭式系统架构vs 开源系统架构辨析每个单位组织的IT环境，不论大小复杂度，总会有个系统架构层次。
有了这个架构体系，那所有的运维事情大体都围绕着这个系统架构上的每个元素及整体进行运维保障工作。
运维体系架构从某种角度可以划分为如下两种：∙ A. 商业封闭式系统架构(IOE架构)∙ B. 开源系统架构通常我们会将围绕商业封闭式系统架构(IOE架构)的运维视作传统运维，将围绕开源系统架构的运维视作互联网运维。
就上述两种运维体系，下文做一些辨析。
A. 商业封闭式系统架构(IOE架构)典型的即以使用IOE(IBM、Oracle、EMC)产品软硬件为主要元素的系统架构。
IOE架构以纵向扩展为特点，通过增加CPU、内存、扩展柜、冗余备件等方式来提高处理能力及稳定性。
该架构的处理能力主要取决于单台(套)设备(系统)的最大扩展能力，很难通过增加设备(系统)数量来增加处理能力，换句话说该架构很难通过扩大集群规模的方式来解决问题。
随着纵向扩展的规模增大，它的实施技术难度、管理复杂度以及隐患风险都会成比例大幅上升。
基于IOE架构的典型企业如：金融业、电信业、能源业、交通运输业。
IOE典型的系统架构如下图所示。
典型IOE架构图上述为IOE型系统架构，其服务器多使用小型机、大型机(还有以往的中型机);数据库系统往往会使用Oracle;存储则多使用知名品牌的中高端存储阵列、带库等设备。
服务器与存储之间多使用SAN存储网络。
这些服务器、存储等硬件本身往往就是双冗余的，线路连线也都是双冗余的，而且设备性能指标往往非常好，例如一台普通中端的Power 7系列服务器可以轻松划分出若干个系统分区或者一二十个虚拟机系统。
B. 开源系统架构典型的即以使用廉价PC服务器，开源产品技术为主要元素的系统架构。
开源系统架构以横向扩展，分布式部署为特点。
常通过向集群中增加单机设备资源解决存储空间、性能以及稳定性问题，其集群规模可以小到两三台PC服务器，也可以大到上万台。
对于数据库，可以通过分布式集群方式解决数据库扩展性的问题。
另外非结构化数据库及分布式文件系统在处理非结构化数据的存储与使用方面也很灵活方便。
基于开源系统架构的典型企业如：以BAT(百度、阿里、腾讯)为代表的众多互联网企业。
开源系统架构如图所示：典型开源系统架构图上述开源系统架构中使用了CDN和反向代理以提高网站性能。
例如我们的服务器可能部署在北京，对于北京及周边用户来说访问是较快的，而对于远离北京的用户访问则感觉较慢，因为数据传输时间比较长。
对于这种情况，常常使用CDN解决，CDN将数据内容缓存到运营商(或自建CDN)的机房，用户访问时先从最近的CDN 机房获取数据，这样大大减少了网络访问的路径。
对于反向代理，当用户请求到达时首先访问反向代理，反向代理服务器将(如：Varnish)缓存的数据返回给用户，如果没有缓存，才会从源站服务器获取，这也减少了获取数据的成本。
当然对于海量访问请求，或庞大集群架构，则就需要分多层，综合运用上述负载均衡以及代理(反代理)，同时可能需要引入Zookeeper等功能以协调(服务)任务调度。
从上述架构简析中，我们便会感知到两种运维体系的巨大差异。
俗话说隔行如隔山，现如今就算都是运维这一行，也可谓千山万岭。
对于上述基于IOE架构的传统运维体系，对比基于开源架构的互联网运维体系，可以说是当前两大运维阵营。
2、传统运维vs 互联网运维辨析一个奇怪的现象传统运维圈子通常高度认可商业闭源产品。
而对开源产品及其技术则很谨慎，很少采纳，甚至认为很多开源产品不上档次。
而互联网运维圈子通常高度青睐开源产品、技术、理念。
而对商业闭源产品则比较排斥抵触，再好也不买。
差异可见一斑传统运维圈子和互联网运维圈子各有特点，同是运维行业，但也有很多差异之处。
关于传统运维与互联网运维的不同差异，本文总结了如下几点差异：A. 架构差异B. 面向对象差异C. 运维人员差异D. 体制理念差异解析如下：A. 架构差异传统运维:传统运维多是围绕以IOE架构及其产品体系进行运维，在性能、数据库、中间件、HA高可用、灾备、存储等环节通常大量采用商业闭源的软硬件产品及其解决方案。
这些方案的特点是通常纵向扩展能力极强，横向扩展能力很弱。
商业案例成熟稳定，方案组合重度耦合，讲究两地三中心这种典型的重量级、集中式运维管理方式。
另外IOE架构后面通常有强大的MA维保支持体系，甚至MA人员常年驻场。
互联网运维通常是围绕开源产品、技术解决方案进行运维。
在负载性能、数据库、中间件、集群高可用、灾备、分布式存储、自动化部署等环节通常大量采用开源的软件产品及其技术解决方案。
硬件通常使用廉价的X86服务器，甚至白盒产品。
这种开源解决方案通常纵向扩展能力很弱，横向扩展能力很强。
有大量社区、行业成熟案例。
方案组合灵活，讲究分布式存储、负载集群、轻量级、模块化、去中心化的运维管理方式。
另外互联网系统架构通常缺少MA维保支持。
开源产品更新换代甚至消亡的风险较大。
B. 面向对象差异∙传统运维:传统行业的IT运维大多是面向企业内部(体系)用户，其需求相对明确、稳定，具有很强的行业系统特点，另外桌面运维中的OA、ERP、MES、企业邮箱等系统，也通常是面相企业内部员工。
因此传统运维面向的用户在其数量、需求、特性通常是可控的、稳定的、集中的。
也因此传统运维圈子适合购买商业产品，这些产品通常是比较成熟的产品，经过长期的测试和使用，有很好地最佳实践，相对能够较好地满足传统运维需求。
∙互联网运维:相比之下，互联网运维通常面向的是广大互联网用户。
因此其面向的对象关系复杂，市场多变，需求五花八门，目的目标不可控，对象海量不可控。
也因此互联网运维的系统环境变更迭代频繁，对自动化、弹性需求要求较高。
由于各种复杂多变因素，通常导致传统商业产品不能很好地支撑互联网运维环境。
因此被逼无奈只能选择开源，并走自主开发这条路子。
C. 运维人员差异有服务器的地方就有运维其实近年来，在这两大运维体系之间流动的运维工程师也不在少数。
本文作者就是这两大运维圈子的跨界者。
∙传统运维:传统运维圈的从业人员，其知识体系普遍比较高逼格。
不论其学历背景还是再教育背景通常比较高大上。
同时相关商业产品的培训认证体系也相对完善，传统行业的运维工程师在这方面有其特色。
比如他们通常玩过大型机、VMax、Z/os、Oracle、ITSM、PMP、ISO、PCI、某国加密产品、某国数据库，等等一系列高逼格的玩法。
在互联网运维圈的从业人员，其来历千差万别，既有超人大神，也有小白。
他们通常LAMP/LNMP基础扎实，写得一手好脚本，练得一身全栈功夫。
互联网天生具有万众创新的基因，因此这片空间广阔任鸟飞，很多大神往往不是通过各种培训出来的，都是在各种磨练中涅槃出来的。
由于互联网产业的迅猛发展，互联网运维人员的薪酬也普遍高于传统运维从业人员。
D. 运维体制理念差异传统运维圈子里，看重商业运维产品、服务支持、业务运营流程这些因素，但对开源产品体系比较慎重或者没兴趣。
而在互联网运维圈子里，则看重开源产品、看重研发、但凡是商业的东西则通常没兴趣。
传统运维关注流程、关注业务、讲究ITIL，ISO标准体系，通常关注业务运行的高度稳定，高度一致性、集中性。
传统运维自动化程度通常不高，但求运营稳定可靠。
而互联网运维通常关注网站响应、网站性能、关注灵活快捷、分布式、开放式，关注安全体系。
在很多互联网大企业里，其运维自动化程度非常高。
另外传统运维行业多是企事业单位，共和国长子长孙型企业，在运维经营指标、人事组织，薪资体系，运维KPI考核等一系列观念和互联网运维行业的理念还是有很大差别的。
由于架构的不同，面向对象不同，服务原则不同，因此传统运维与互联网运维在商业运营模式上自然有很多不同。
3、去IOE运动辨析近年来开源技术的迅猛发展，以及国内外政策环境共同作用，引发了一场去IOE的风潮，其中以阿里巴巴发动的“去IOE”运动较为著名。
他们使用低廉的软硬件产品代替昂贵高门槛的IOE产品，搭建起自主开放的开源系统架构。
之所以出现“去IOE”运动，其中原因总结概述如下几条：∙自“棱镜门事件”之后，国家强烈意识到数据安全的重要性，开始大力提倡产品设备国产化与自主研发，这正与“去IOE”观点不谋而合，上下一致。
∙近年来，云计算、大数据等新兴IT技术的蓬勃发展，促使众多行业开始往更加开放灵活的开放系统架构转型。
而对于传统的IOE架构而言，其定制与扩展灵活性有限，往往是擅长于集中式架构的管理，而很难应对大规模集群，分布式存储计算。
∙在购买成本方面，以IOE为代表的商业产品价格昂贵(动辄上百万元);而PC服务器则相对廉价，通常几万元。
在部署与管理方面，IOE产品的学习掌握门槛偏高，而开源系统环境相对容易搭建与管理。
另外IOE产品技术相对商业封闭，不易掌握。
基于上述一些原因，去IOE应时而生。
看到别人去IOE很成功，然后自己也想玩花的。
有没有实力资本玩花的，具体到自身企业是否要去IOE，这需要慎重考虑，三思而行。
毕竟适合自身发展需要的系统架构就是好的架构。
去IOE过程，其实是系统架构的更新换代，产品的更新换代，运维理念的更新换代，运维人员的更新换代，知识体系的更新换代，等等。
因此如果冒然去IOE，可能既不会降低成本，也不会提高效率，更不会稳定架构。
如下列举几点“去IOE”要考虑的因素：∙自身业务是否真正需要大数据、云计算以及分布式这种海量运维体系。
∙是否已经考虑好系统架构、运维理念、人员、知识更新换代的方案。
∙自身的研发实力储备是否够解决大量开源产品的坑坑洼洼，并有实力搭建开源系统架构。
∙是否有足够的资金应对“去IOE”转型中的成本，例如从软硬件高成本转向人力技术高成本。
小结论：A. 去IOE只是给予我们一些最佳实践与选择路线，但去IOE技术门槛较高，一般企业很难复制。
B. 从目前发展来看，去I、E案例较多，去O不容易，IOE架构与非IOE架构仍将长期并存。