有人说在云计算工程领域，最难的部分是运维，因为管100台、1万台或是100万台机器，是完全不同的概念，你想机器少可以人管，机器多了还能靠人么，当然不能了。再则，运维系统不属于功能性的东西，常常因为用户看不见而被严重的低估。在8月份的“云计算运维的那些坑儿”那期在线培训中，VisualOps CTO王旭也谈过云计算运维的相关问题。但这里说的机房运维只是云计算运维的一个部分，事实上，随着云平台被越来越多的企业被认可和使用，越来越多的用户开始在云平台上部署自己的应用，如何在云平台上进行自动化运维也就被越来越多的企业所关注的难题。
云计算时代的运维和传统的运维到底有哪些不同？亚马逊AWS中国云解决方案架构师王毅表示传统层面的运维人员，接触的都是硬件，如服务器、设备和风火水电，但是在云时代，运维人员已经无法见到物理的任何设备。所以从这个角度看来，云计算时代的运维的手段和运维的目的都和传统的运维都是不一样的，因为运维人员不需要维护物理硬件的稳定和可靠性。
当然，上帝在开了一扇门的同时想必也是会合上一扇窗户。既然运维人员不再需要被束缚于物理硬件的稳定和可靠性，那新的问题就来了。云计算时代，也给用户带来了新的挑战。
在亚马逊AWS中国云解决方案架构师王毅看来，云计算带来的不同于传统运维的应用层面的三个挑战：
应用如何在云平台上实现应用的快速部署，快速更新，实时监控。云计算时代要求运维人员能够自动化地部署应用程序和所有支持的软件和软件包，然后通过生命周期阶段操作维护和管理应用程序，如自动扩展事件和进行软件更新等一系列的操作。如何快速创建和复制资源模板。有序地对资源模版进行资源配置和更新；如何在云端更加轻松的部署、配置和管理应用。如何利用工具轻松地在云中快速部署和管理应用程序，同时可以自动处理容量预配置、负载均衡、Auto Scaling和应用程序状况监控，这是对运维人员的新要求。面对这些挑战和变化，大部分运维人员开始了转型之路以应对时代的变化。谈到运维人员转型的建议，王毅认为传统的运维更多的是与物理设备打交道，很少接触操作系统甚至是应用程序的层面。所以他建议运维人员在云平台阶段应该更多介入软件部分，而且需要有代码基础。因为在云时代，infrastructure as code，所有对物理设备的操作都变成了代码。
有人说在云计算工程领域，最难的部分是运维，因为管100台、1万台或是100万台机器，是完全不同的概念，你想机器少可以人管，机器多了还能靠人么，当然不能了。再则，运维系统不属于功能性的东西，常常因为用户看不见而被严重的低估。在8月份的“云计算运维的那些坑儿”那期在线培训中，VisualOps CTO王旭也谈过云计算运维的相关问题。但这里说的机房运维只是云计算运维的一个部分，事实上，随着云平台被越来越多的企业被认可和使用，越来越多的用户开始在云平台上部署自己的应用，如何在云平台上进行自动化运维也就被越来越多的企业所关注的难题。
云计算时代的运维和传统的运维到底有哪些不同？亚马逊AWS中国云解决方案架构师王毅表示传统层面的运维人员，接触的都是硬件，如服务器、设备和风火水电，但是在云时代，运维人员已经无法见到物理的任何设备。所以从这个角度看来，云计算时代的运维的手段和运维的目的都和传统的运维都是不一样的，因为运维人员不需要维护物理硬件的稳定和可靠性。
当然，上帝在开了一扇门的同时想必也是会合上一扇窗户。既然运维人员不再需要被束缚于物理硬件的稳定和可靠性，那新的问题就来了。云计算时代，也给用户带来了新的挑战。
在亚马逊AWS中国云解决方案架构师王毅看来，云计算带来的不同于传统运维的应用层面的三个挑战：应用 如何在云平台上实现应用的快速部署，快速更新，实时监控。云计算时代要求运维人员能够自动化地部署应用程序和所有支持的软件和软件包，然后通过生命周期阶段操作维护和管理应用程序，如自动扩展事件和进行软件更新等一系列的操作。如何快速创建和复制资源模板。有序地对资源模版进行资源配置和更新；如何在云端更加轻松的部署、配置和管理应用。如何利用工具轻松地在云中快速部署和管理应用程序，同时可以自动处理容量预配置、负载均衡、Auto Scaling和应用程序状况监控，这是对运维人员的新要求。面对这些挑战和变化，大部分运维人员开始了转型之路以应对时代的变化。谈到运维人员转型的建议，王毅认为传统的运维更多的是与物理设备打交道，很少接触操作系统甚至是应用程序的层面。所以他建议运维人员在云平台阶段应该更多介入软件部分，而且需要有代码基础。因为在云时代，infrastructure as code，所有对物理设备的操作都变成了代码。
正如Joyent（公共云平台）的系统工程主管Ben Rockwood最近解释的那样：“客户可以随意启动应用程序，而我们可能视之为滥用。”曾有一回，由于客户帐户出现了貌似违规的活动，Joyent正打算关闭一个客户应用程序，但该客户的开发人员在最后一刻介入了。‘这些开发人员告诉我们，他们的内部IT人员很差劲，于是他们用私人信用卡启动了一个大项目。’”
由于众多用户竭力要求更快速、更频繁地部署，而且需要配置数量更多的资源，云计算为开发人员提供了一种诱人的机会，可以避开公司的IT运维部门。正如GigaOm网站的Barb Darrow引用Gartner的最近报告：“IT人员过去手握数据王国的钥匙，也就是说控制着哪些应用程序和数据在哪里运行，在哪些设备上运行。现在这一切都发生了变化――变化很大，这归因于IT消费化和这种计算能力的出现：即内部开发人员可以在亚马逊网络服务平台上启用计算能力，用小额现金支付，不需要经过IT部门的批准。”
由于全球经济形势依然不明朗，IT开支同样变得更加保守。云计算带来了潜在的竞争优势。云计算为各种各样的IT部门带来了机会，可以降低与内部部署型IT基础设施（软硬件）有关的风险。云提供商提供的解决方案通常提供按需计算资源、系统自动化部署及扩展，以及按使用量付费的定价模式。充分利用公共云计算提供商的共享式计算资源（软硬件），让许多公司得以节省IT基础设施成本。
Gartner副总裁兼研究员David Cearley说：“云计算是过去这两年席卷市场的一大技术潮流。它为一种新的IT方法创造了条件，这种新方法让个人和公司都可以选择如何获得或交付IT服务，不大着重传统软硬件许可证模式的限制。云计算对IT的方方面面以及用户访问应用程序、信息和业务服务的方式带来了相当大的潜在影响。”
而在传统环境下，IT运维部门重视稳定性和可靠性，保持数据中心现状，云计算则给IT运维小组指明了一个全新的方向。
IT运维团队需要转变，成为更具创新性的IT团队。出于如上所述的竞争原因和技术原因，通过IT部门分配各项资源再也行不通了。现在，业务部门需要开始对IT资产掌握更大的控制权。正如Susan Cramm指出：“关键在于实现转变，从IT服务交付给业务部门的模式，变成IT服务通过业务部门来交付的模式。”
虽然对开发人员来说云计算潜力巨大，但这种影响具有的广度和深度并不确定，还需要IT运维团队来考察。配置和交付IT服务的速度将是云计算下一个时代的关键；服务的配置和交付一定要迅速，同时又不能扩大整个IT部门的规模。
这就意味着IT运维团队需要大变样，重新定义对云的做法，因为这将影响到有关人员、流程和工具。James Urquhart解释：“就在不久前，IT部门还在遵循以服务器为中心的运维模式；而云计算是一种以应用程序为中心的运维模式。”
眼下IT运维领导需要改变做法。这意味着“少花钱多办事”，减少财务投入和组织变化，并作为一家小规模、迭代、灵活的组织来运行。云运维以应用程序为中心，这种特性将运维重心由基础设施转向应用程序。enStratus产品战略副总裁兼GigaOm云计算栏目的特约撰稿人James Urquhart解释：“如果你专注于在是否由你控制是未知数的环境下运行应用程序，就会专注于如何确保代码顺利运行，确保数据可用，确保配置切实可行，确保策略得到执行。还有，由于你唯一能控制的就是代码、数据、配置和策略，就得开始着眼于如何将性能和存活能力做入到应用程序本身当中。”
结合开发和运维的开发运维（DevOps）理念在云端会被放大，为开发和运维的工作方式提供一种更丰富的方法。云还重新组织了软件团队的传统结构，因而促进了这种关系。
部署向来是IT运维团队的一项任务；对许多企业组织来说，只有IT部门才可以在生产环境实施变化。而现在由于云计算的自我配置功能，部署任务可能交给使用基础设施即服务（IaaS）的开发团队。不过，IaaS也要求IT运维团队开发新的工具，实现部署自动化，这在功能复杂性和广度方面提高了标准。成功部署到云端需要开发和运维两边都要有相应的技能和知识。
由于最近媒体大肆报道微软Azure和亚马逊网络服务故障，有人对公共云提出了担心，因而不敢依赖公共云。不过如果选择多家提供商，那样只会增添复杂性，而且难以跟踪了解多个云平台上的配置。Switch公司的数据中心技术执行副总裁Mark Thiele指出：“把所有鸡蛋都放在一只篮子里存在固有的风险，不管那只篮子做工有多精致或营销有多到位。任何单一技术平台都有这种风险，即某一个平台特有的问题可能会给整体带来不利影响。”
在云计算时代，IT环境变得越来越复杂，仅仅想在某一个时候了解IT环境里面发生了什么情况就是一大难题。Mike Vizard在ITBusinessEdge写博文道：“IT基础设施很快就会跨越公共云和私有云这两种计算环境。在另一个极端，敏捷开发的兴起意味着，一批新的应用程序及相关升级会变得具有持续性。当然，问题在于，不仅每次更新改变了应用程序的参数，应用程序的工作负载还会日益从一个虚拟机转移到另一个虚拟机。”
IT运维团队需要运用新的管理和监控技术来提供实时洞察力，深入了解部署到多个云平台上和内部部署型基础设施上的应用程序和服务的配置情况。这可以更严格地控制公共云平台（实际上就是外部IT基础设施）。“这类技术可以借助单一的统一视图，深入了解企业内外的IT基础设施，从而简化整体IT监控任务。智能化分析多个云平台上的变化，应该是这类监控技术的一个关键属性，以便高效地支持云的动态性。”
基于云的基础设施即IaaS取代不了IT运维。我们仍需要部署、监控、故障恢复、性能管理、操作系统维护、系统配置及更多操作，这些是IT运维团队从事的关键任务。开发团队简单地“换成”IaaS方法后，甭指望这些任务由云提供商来处理。敏捷开发面临的可扩展性和更大规模由开发运维和云（即云运维）来处理比较好。云运维让你可以提高服务器与管理员之比。这意味着，配置服务器不再是一个复杂而耗时的过程，而是可以像实际软件那样来配置。如果你的整个基础设施是虚拟化设施，由代码来控制，那么代码就可以知道其领域内出现的任何问题。
顺利采用新技术和新平台的能力至关重要，而彻底改造后的IT运维起到了关键作用。务必要考虑在没有落实治理和监管等机制的云环境下怎么会出岔子，以便帮助将应用程序从测试环境迁移到生产环境。所有云都需要一套强大的管理工具、更新颖的敏捷流程，以及准备好应对挑战以帮助实现部署自动化和管理部署的人员。
本文内容来云头条，由捷云信通整理发布，主要目的在于分享信息，版权归原作者所有，内容仅供参考，如有侵犯您的权益或版权请及时告知，我们将在24小时内进行删除。
捷云信通依托阿里云以及自身私有云技术研发和在医疗行业宝贵经验积累，专注互联网云计算的技术创新，打造未来云计算全行业的新体验，努力成为中国一流的云计算（公有云，私有云，混合云）服务商。
1、对于传统企业内网运维和互联网运维，哪些技术和素质是两个运维团队都所必须具有的？
结实的技术基础，良好的日志检查、信息检控、巡检习惯，超强的责任心和处理问题的能力，跟得上行业技术更新、发展这对每个团队都是一样的。
2、企业内网运维和互联网运维人员，在面对新技术（硬件设备和软件技术）方面，有何区别，为什么？
面对新技术的学习我认为都是一样的，但是企业内的运维更看重成熟的、稳定性强、商业化程度高的技术，一般不会成为吃螃蟹的人，安全稳定是第一位的；而互联网运维正相反，要时刻紧跟新技术，应用新技术，绿色、节能、高效、可用率最大化是优先的。
3、如何看待企业内网运维和互联网运维的区别，在云计算大潮下，他们真的会走到一起么？
会走到一起的.
自动化运维到来，运维工程师将何去何从？ 互联网的应用，极大地方便了我们的生活，通过PC端，手机端等进行购物、订餐等早已不是什么稀奇事，然而在我们享受着这一便利的同时有没有想过是什么换来了我们如此的便利?在这背后是一家又一家的互联网公司提供的各种服务，我们在使用每个服务的时候都会去访问互联网公司的服务器，而为了正常访问，运维工程师需要很多人工操作，但面对海量爆发的访问，利用传统的运维技术应对也已经略显吃力。当然除了这些传统的运维技术，我们也并不是没有其他的应对方式。 我们可以用open_stack来完成虚拟化，用nagios，cacti，Ganglia等来进行监控，用puppet来进行批量操作，但当运用了这么多的软件，作为一个运维你能管理多少服务器?你招来的运维需要多长的时间来适应你各种软件?这都是互联网公司要进行考虑的问题。现在又出现一个最火的自动化运维语言的Python，那么究竟自动化运维和自动化运维语言Python给我们带来了什么呢? 既然说到Python，首先我们要对它有一定的了解，那么问题来了： 我们运用 Python 到底要完成什么工作呢? 针对我们的问题众网友、各路大神对此也给出了很好的解释。网友hx30067988说：“我们运用Python最终的目的是要实现自动化，Python是实现自动化的工具，我们通过Python将固定套路的工作流程通过Python编程进行封装，在通过Python组织和调用，实现机器的智能管理。简而言之就是把你工作的流程动作抽象成代码，让机器替你完成要做的工作，仅此而已。当然用python能完成的工作很多，比如自动化的工具，比如统计分析等等，python的魅力不单单在于他能很好的快速的开发工具，还在于他在数学建模中的优越性，毕竟python是数学建模工具之一，能简单通过数学建模实现高精度的数学统计分析。统计分析生成报告也是运维的工作之一。” 网友xkf01也表示：“python是一门黑客和geek很偏好的语言，只要你想基本上能做出任何应用软件。Google的好多应用都是基于python的，国内的豆瓣网好像就是纯pytyon开发的 。当然，感觉更偏向于写一些辅助工作和生活的小工具，要写很多方面集成的大产品，估计需要掌握的水平很高才行。”通过众网友的回答我想各位也对其有了一些初步的了解，看来诸位要想真正的熟练掌握还是要下一番功夫的。 那么在传统的运维技术已略显吃力的情况下，自动化运维是否能够取代现在的传统运维呢? 网友j_cle表示：“自动化运维是以后数据中心发展的大势，对于小的公司和团队效果不甚明显，但是对于规模庞大的公司来说如何有效的管理数千台上万台的服务器和网络设备，是一件很麻烦的事情，所以自动化运维在大的公司来讲，效果是非常显著的，但是前提是必须要做好自动化的部署工作。” 网友gary721400也表示：“ 这个问题，我认为要分两个方面来说：①对于大型企业，特别是互联网公司，这个是一定的，而且是一个必然的趋势。好像听说facebook的服务器，就几个人在维护，试想成千上万的服务器，如果单凭人为操作，非累到吐血不可;② 对于中小型企业，可能这个问题还不太明显;因为服务器可能就几台，人为或者自动的优势可能不太明显。”确实对此问题要视情况而定，各企业需根据企业规模的大小和自身的需求来判断是否需要自动化运维。 但是小编认为，就目前技术来讲，自动化运维想要完全取代传统运维时机并不成熟，网友lei8792yong说：“ 这里不能说绝对取代传统运维，而是相辅相成的。只是大部分重复的工作，需要依靠自动化运维，少量而复杂的工作，还得靠传统运维。” 自动化运维和传统的运维相比，自动化运维的成本，分界岭又在哪里呢? 网友liuadam表示：“主要的分界岭在于：建立自动化运维管理平台。运维自动化管理建设的要先建立运维的自动化监控和管理平台。建立自动化运维管理平台就需要投入大量的人力资源成本，硬件设备成本。” 网友gary721400回应称：“这个和传统运维比较，还是有优势的;对公司来说，可能不需要专职的运维了，大大节省了人力成本;使用python语音来运维，能使用大量的第三方库文件，并且对C++等都有很好的连结性，对运维工程师来说，代码的量也不会太大，即使有人员替换，也能很好的衔接!”看来相对比来说成本方面自动化运维有利有弊，节省了人力的投入，但相对增加了技术资金的投入。 写在最后 很明显，自动化运维的出现会为运维工程师减轻相当一部分的负担。表面上看是有利于运维工程师的工作，但自动化运维的出现人力上的需求势必会大大减少，部分运维工程师可能会面临失业的危机，所以我想运维工程师的未来还是掌握在自己手中的，及时掌握最新技术，完善自己将会有更加广阔的空间，反之终将被运维行业淘汰，当然这只是本人的个人观点，到底自动化运维的发展究竟会怎样，让我们一起拭目以待吧!
传统运维 VS 互联网运维：从哪来，到哪去？
近一年，关于传统运维与互联网运维的探讨越来越多，在运维体系快速变革地环境下，运维未来的走向，便成为运维行业的关注点。那么：到底什么是传统运维体系？什么是互联网运维体系？他们的特点，异同在哪？从哪里来到哪里去？
作者介绍
王天维，从事运维工作近十年，精通网络技术，CCIE专家。专注云计算、SDN、数据中心网络架构设计。
韩晓光，专业运维，兼职开发，干过商务。信息系统项目管理师、ITIL Foundation认证、IBM CATE、RHCE。著有《系统运维全面解析:技术、管理与实践》一书。
概述
近一年，关于传统运维与互联网运维的探讨越来越多，在运维体系快速变革地环境下，运维未来的走向，便成为运维行业的关注点。
那么：
到底什么是传统运维体系?
什么是互联网运维体系?
他们的特点，异同在哪?
从哪里来到哪里去?
本文将从以下角度探讨两大运维体系。
- 商业封闭式系统架构 vs 开源系统架构辨析
- 传统运维 vs 互联网运维辨析
- 去IOE运动辨析
- 运维发展趋势辨析
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架构仍将长期并存。 一时间很难找到一些能够完美替代以IOE为代表的成熟(且普适)产品方案。
4、运维发展趋势辨析
未来的运维道路在何方，我从哪来，要到那里去?这是每一个运维从业者都会面临的问题。本文关于运维发展趋势的一些辨析如下：
云计算等各种理念技术的发展，这些都将对运维行业带来巨大的机遇与挑战。很多企业都处在传统IDC运维方式与云运维方式的探索中。
在新的形势下，传统运维方式与基于云计算的运维方式将长期并存，公有云与私有云及混合云运维局面将长期并存，传统IT运维与互联网IT运维也仍将长期并存。
基于IOE架构的业务系统正在处于转型中，但基于开源互联网技术的成功经验也并非都能复制。
传统运维领域正在探索容器、自动化、云计算、开源架构等转型之路。互联网运维也在借鉴或使用成熟的商业产品与理念，例如IOE产品体系、F5、Vmware、Exchange、AD、ITIL、ISO……
在上述大环境下，运维部门不会变的越来越清闲了，相反承担的企业发展战略的责任越来越大了。运维部门将由传统的IT成本中心更多地向IT服务中心、价值输出中心、利润输出中心转变。
在上述发展形势下，运维的人、事、物、流程规范都将相应发生变化，如人员数量会有变化，职位职责会有变化，设备资产会会有变化，各种流程规范都将发生变化。
写在最后一的句话：
最好的运维是在正确的领域由正确的人干正确的运维事情……
微软知名工程师Jeffrey Snover表示，对运维人员来说，未来可谓一片光明；但先进的云自动化技术表明结果实则不然。
Jeffrey Snover是有着16年工作经验的微软老兵，也是一位杰出的技术专家，他显然站在IT运维这一阵营。他说：“我属于这个阵营的一员。我对运维人员的未来非常乐观。”
尽管站在这个阵营，但Snover可能在帮助让许多运维人员失业，不过我确信他本人不会同意这个观点。
作为知名工程师兼微软企业云部门的首席架构师，Snover一直在与Azure首席技术官Mark Russinovich紧密合作，开发Azure公有云背后的自动化基础设施。这项先进的技术还逐渐进入到Windows Server、System Center以及微软的其他内部部署型解决方案。
上周我采访了Snover，聊了聊微软在软件定义数据中心方面采取的方法；他拿OpenStack方法进行了比较，后者需要收费高昂的系统集成商才可以部署：
没人能否认这点，微软的核心竞争力始终在于拿来非常高端的计算后使之实现大众化，并提供给大众使用，我们做到这点的秘诀就是追求大批量和简洁性。对于软件定义数据中心，我们又使出了这一招。
Snover在这里谈论的是使用微软的Azure Stack解决方案来部署私有云。我明白他的意思：微软比任何一家厂商更懂得如何让云实现产品化，无论是公有云、私有云还是混合去。《InfoWorld》杂志自己的云测评支持这个说法。微软更进一步：在AWS、Azure和谷歌云三大公有云玩家中，只有微软这一家厂商提供混合云解决方案。
但是尽管Snover声称看好运维的未来，但是他一直在驳斥自己的观点。首先，他对先进的云自动化与微软在Windows 95中推出的即插即用规格作了一个历史的类比：
在即插即用问世之前，运维人员和管理员过去常带着弯曲的回形针东奔西波，拨动DIP开关，研究输入/输出图以及诸如此类的东西。有了即插即用规格，突然间你只要拿来某个设备，就可以把它插上去，它马上就可以使用。到底有谁因即插即用而失业？我从来没有发现过这样的人。
确实如此。但是虽然即插即用是一项受人欢迎的技术进步，云计算却是一种重大转变，其最终目的是让整个数据中心运行起来酷似一台可替代的计算机。如果你谈论的是公有云，这是一台几乎可以无限扩展的计算机。如果换成私有云，根本没有几乎可以无限扩展的优点，不过我丝毫不怀疑微软最新的技术进步会让内部部署型系统的管理员更高效地工作。
同样，Snover对Storage Spaces Direct特别引以为豪，Windows Server 2016技术预览版2中推出的这项功能让管理员可以管理直接连接存储，并确保高可用性和高性能。Windows Server 2016还会引入另外一大批技术成果，主要是新的容器技术和Service Fabric PaaS。
不过再次，这一切从Azure公有云传至内部部署版本，而容器技术会让开发人员能够做许多令人兴奋的新事情，根本不需要运维人员的帮助。我越来越想知道投资构建私有云的理由。Snover是这么解释这个决定的：
公有云的核心是弹性，而私有云的核心是控制。这是两个亘古不变的事实。如果你确实关注控制，比如我想要控制谁访问这些服务器、部件之间的带宽是什么、使用什么处理器、谁在使用处理器，如果你购买并控制自己的数据中心，就能获得这种控制。
我询问Snover这种对细节的关注是不是有点类似在即插即用问世之前管理员拨动DIP开关。他答复，最后，绝大多数人是选择公有云还是私有云“将是一种生活方式的选择。”
值得关注的是，Snover并不认为安全是那个选择的一部分。实际上，他把将数据交给公有云方面的担忧比作把钱放在银行而不是放在床垫下方面这个由来已久的担忧。
如此看来，不辞辛苦、不惜血本地维护私有云还有什么必要？当然，监管法规对于数据的存储位置有其要求，担心云锁定和不断上升的运维成本（而不是自己做的资本开支）也不无道理。但是最终，你在内部部署环境获得的灵活性级别永远无法与在公有云环境获得的一样高，而我谈论的不仅仅是可扩展性。
比如说到明年，3D NAND有望将闪存价格降到与旋转磁盘相当的水平，到那时用于一级存储的旋转磁盘可能会过时。你谈论的是性能方面的大幅提升。现在设想一下：今天你刚斥资几百万美元购置某种闪存/磁盘混合存储系统。你刚让自己动弹不了，然而你知道友好的公有云提供商很快会升级，一方面是由于闪存的耗电量低得多，因而天生具有规模经济效益。
我见过的支持公有云最有力的观点之一来自微软在2010年发布的白皮书：《云的经济性》（https://news.microsoft.com/download/archived/presskits/cloud/docs/the-economics-of-the-cloud.pdf）。一个重要的段落内容如下：
对于已安装了约1000台服务器的大公司而言，私有云切实可行，但是就同样的一批服务而言，私有云的成本要比公有云高出大约10倍，那是由于规模、需求多样性和多租户的共同效应。
当然，那是成本，而不是价格，不难想象公有云提供商期望靠出售服务来谋利。另外，正如白皮书在结尾处表明的那样，向公有云转变是“一种微妙的平衡行动”。如果立马全身心投入到公有云是不明智的。
但高端的私有云解决方案越来越像是通向公有云未来道路上的停留点，连极大地降低了部署和维护复杂性的那些私有云解决方案也不例外。在软件定义世界，虚拟基础设施的许多部分实现了自动化，我并不认为我们为何可能需要同样多的运维人员来运维系统。毕竟，成本节省的大头来自人员开支。
转载请注明：运维派 » 云自动化会让运维人员失业吗？
参考:https://www.aliyun.com/zixun/content/1_3_1884004.html
http://www.gongboshi.com/news/show-htm-itemid-273812.html
http://os.51cto.com/art/201605/510534.htm
http://www.yunweipai.com/archives/5398.html