传统运维和云运维区别比较不同观点想法
发布时间：2022-10-21 10:17:54 所属栏目：云计算 来源：
导读： 本文内容来云头条，由捷云信通整理发布，主要目的在于分享信息，版权归原作者所有，内容仅供参考，如有侵犯您的权益或版权请及时告知，我们将在24小时内进行删除。
关于捷云
捷云信通依托阿里云
关于捷云
捷云信通依托阿里云
|
本文内容来云头条，由捷云信通整理发布，主要目的在于分享信息，版权归原作者所有，内容仅供参考，如有侵犯您的权益或版权请及时告知，我们将在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环境，不论大小复杂度，总会有个系统架构层次。有了这个架构体系，那所有的运维事情大体都围绕着这个系统架构上的每个元素及整体进行运维保障工作。 运维体系架构从某种角度可以划分为如下两种： 通常我们会将围绕商业封闭式系统架构(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架构而言，其定制与扩展灵活性有限，往往是擅长于集中式架构的管理，而很难应对大规模集群，分布式存储计算。 在部署与管理方面，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服务中心、价值输出中心、利润输出中心转变。 在上述发展形势下，运维的人、事、物、流程规范都将相应发生变化，如人员数量会有变化，职位职责会有变化，设备资产会会有变化，各种流程规范都将发生变化。 写在最后一的句话： 最好的运维是在正确的领域由正确的人干正确的运维事情…… 云自动化会让运维人员失业吗？ 99527于1 年前发表在七嘴八舌?运维经验 微软知名工程师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年发布的白皮书：《云的经济性》（）。一个重要的段落内容如下： 对于已安装了约1000台服务器的大公司而言，私有云切实可行，但是就同样的一批服务而言，私有云的成本要比公有云高出大约10倍，那是由于规模、需求多样性和多租户的共同效应。 当然，那是成本，而不是价格，不难想象公有云提供商期望靠出售服务来谋利。另外，正如白皮书在结尾处表明的那样，向公有云转变是“一种微妙的平衡行动”。如果立马全身心投入到公有云是不明智的。 但高端的私有云解决方案越来越像是通向公有云未来道路上的停留点，连极大地降低了部署和维护复杂性的那些私有云解决方案也不例外。在软件定义世界，虚拟基础设施的许多部分实现了自动化，我并不认为我们为何可能需要同样多的运维人员来运维系统。毕竟，成本节省的大头来自人员开支。 （编辑：草根网_盐城站长网 ） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
浙公网安备 33038102330471号