为什么IT企业必须采取架构方法以实现自动化

IT架构师是根据需求分析人员跟客户沟通后，拿回的客户需求，将面向客户的需求文档变成面向开发人员的开发文档，同时要从功能实现和编程实现的角度出发来做系统的总体规划。

架构师的工作完成后，下一步就是开发团队沟通，然后每个开发人员各自依照开发文档负责一个或多个部分的开发工作。

而项目经理则是整个项目从头到尾的管理者，监督者，他的任务是随时保持和客户、和团队成员的沟通。对团队成员的工作进行监督和审核，以确保整个项目按时、按质、按量完成。包括处理项目实现过程中的一些特殊情况。在需求分析阶段。

简单点理解，以盖房子为例，架构师是建筑设计师，而项目经理就是工头或者说监工。一个管结构，一个管进度。

什么是超融合架构

超融合基础架构（Hyper Converged Infrastructure，或简称“HCI”）是指在同一套单元设备中不仅仅具备计算、网络、存储和服务器虚拟化等资源和技术，而且还包括备份软件、快照技术、重复数据删除、在线数据压缩等元素，而多套单元设备可以通过网络聚合起来，实现模块化的无缝横向扩展（scale-out），形成统一的资源池。

超融合与传统的IT架构有哪些区别

超融合架构与传统架构的区别主要区别还是在于分布式存储于集中式存储，以及相应的硬件/管理上，由此带来的无论是性能，还是扩展性，稳定性、可靠性，以及运维的简化，运营的成本都会有较大的差异。具体如下：

超融合架构与传统架构的区别主要区别还是在于分布式存储于集中式存储，以及相应的硬件/管理上，由此带来的无论是性能，还是扩展性，稳定性、可靠性，以及运维的简化，运营的成本都会有较大的差异。具体如下：

物理融合及管理融合：超融合架构把服务器、网络及存储进行了融合，并且搭载在统一管理平台上进行维护；而传统架构则是全部分离的。

存储架构：超融合采用分布式存储，传统架构使用集中式存储。

网络：超融合使用万兆以太网，而传统架构多使用光纤交换机。

可靠性方面：可以看出可靠性方面，超融合架构的优势非常大，但其实这里的优势都是分布式存储本身应该具备的。

性能方面：超融合在性能方面的架构优势非常明显，当然代价就是消耗计算资源，所以计算资源的消耗是检验超融合专业性的一个重要因素。

扩展性方面：超融合的架构是扩展能力强，扩容简单快速，系统复杂度不会随扩容增加而增加。

部署运维方面：相对传统架构，超融合布局，维护简单，能够在一定程度上智能运维。

企业IT组织架构总部集（）公司布配置直业界热点题与争论数据集该布没绝

错每家企业所行业同、规模同、IT应用阶段同难放四海皆准模式仍些借鉴规律其实论合其实企

业治理结构IT治理具体体现属于IT战略层面问题焦点则IT管理职责与权利何划我认本土集团型企业、元化企业CIO问

题尤其需要认真待

些企业治理结构比较完善、管理比较规范跨公司普遍实行矩阵式职能管理架构——区总部企业内部共享服务各战略业务单

元（SBU）职能管理部门提供行政性办公条件相关服务我觉企业事单或相关联业务种组织架构利于企业职能管理专业化能降

低管理本目前内本土集团型企业或元化企业实行总裁/管副总裁＋IT总监/IT部门总经理格局履行跨公司总部类似CIO职责

由于企业治理结构管理标准化程度等原加非关联性、元化或跨行业业务完全采用内部共享服务职能管理架构相沟通、协调

管理本进影响企业决策、战略执行运营管理效率所我认类企业需要根据IT应用阶段及调整IT组织架构程管理师查尔

斯·汉迪联邦制组织管理思路值CIO借鉴

我认企业IT基础设施搭建信息化初级阶段ERP等套件类应用系统构建阶段IT组织相集管理比较效阶段进行总部集

权主要原IT力资源软硬件资源充共享、效利用能逐步培养自IT队伍并传承系统实施知识与经验毕竟阶段企业IT

应用程度限或IT投入相足加数企业项目负责管理主线总部直接投资并统筹协调（）公司IT项目建设减少汇报层级协调难

度能提高IT项目建设效率些企业信息化建设初期并没设立独立IT部门IT员归属总办、企管办或财务部门或由副总裁级别领导者

管其实与企业信息化于起步阶段关其定合理性往利于信息化建设更符合企业整体战略

企业信息化建设旦结束规模系统构建进入深化应用、持续改进与优化阶段情况发变化总部IT部门味包揽、

统管切IT事务发资源与需求益严重冲突、沟通协调困难等管理问题阶段（）公司定承担IT建设与运营力本往往

断提各种需求、节制销总部IT力资源造总部IT力资源规模断扩让总部堪重负外总部IT部门兼顾运行

维护忽略或实现IT战略、审计等重要职责难顾及远发展、IT趋势研究、总体协调等宏观事务我觉CIO阶段CIO主要工作解

决总部IT资源何效利用、总部与（）公司何担IT投资、何提高运行管理效率、总部与（）公司IT职责划等系列问题

近我与几位业界专家CIO深入交流些问题家析少企业情况比较认同本土化集团企业或元化企业IT组织三层

级实行联邦制+权制比较行模式模式具体言总部IT部门实行汉迪提联邦制辅助CIO专注于集团IT战略制订、并实

施监督；（）公司IT部门实行权制负责总公司IT战略具体实施并管理本企业IT；孙公司IT部门则负责IT运维（）公司

IT部门接受本企业直接领导与管理同应接受级IT部门专业指导协调管理

家酒店集团采用IT组织模式：IT运营归各酒店酒店主要配备IT运维员些定期集团总部受训；IT员属集团外派

接受总部IT部门绩效考核IT员源则按照总部规定员编制招聘要求属招聘；各酒店IT规划与全集团统部署项目实施则归集团总部

负责与管理酒店集团数据布式与其IT管控模式相匹配

述讨论谓意间印证《三演义》篇句——势久必合合久必企业管理定式IT组织应该随需应变、顺势

快速成长的中小企业在IT方面普遍面临着成长的烦恼，本文给出了应对此类烦恼的建议和忠告。 任何企业都希望成长与发展，小企业希望发展成为中型企业，而中型企业则希望成长为大企业。但是，企业在做大的过程中，都会遇到成长的烦恼。在信息化方面，中小企业遇到成长的烦恼尤其明显。我们听说过许多公司的发展因信息支持系统不够完备而无以为继的糟糕经历。

就像孩子总需要新衣服一样，成功的中小企业在不断发展壮大时，可能会远远超出IT部门的支持能力。正如新添子女的父母向比较有经验的家庭学习对待孩子的技巧一样，希望确保IT基础设施能跟上发展步伐的中小企业同样能得益于大企业已获得的宝贵经验。

那么，大企业到底拥有哪些经验呢？本文的几位IT专业人士供职于IT服务外包公司，他们根据经验总结了6条基本经验。其中，最为关键的是要学会战略性思维，不要根据眼下的需要来做决定，而是要根据一年半载后想要达到的目标来做决定。

不断变化的IT需求“会异常迅速地出现在大家面前”，IT工程外包公司Technisource管理服务部门总裁John Baschab这样认为。

为IT留出预算

这对于资金紧张的中小企业来说确实很难，但却是至关重要的，确保IT方面有足够的预算。致力于中小企业IT服务的BC Networks公司总裁兼CEO Dave Brewer说: “中小企业不知道如何为IT编制预算或者规划。大企业可能每年为每个员工编制的IT预算多达1万～2万美元，中小企业为IT留出十分之一的预算都很难，除了资金紧张外，缺乏远见也是一个重要原因。”

Brewer表示，中小企业很少为支持或者培训留出足够预算，结果往往是，员工并不了解最新软件，也没有体现出应有的工作效率。Brewer的忠告是: 每年为每个员工编制的IT预算要达到其薪水的10%～15%。

然后，要采用某种方式来了解你是否从投资的技术中得到相应回报。“不要一味地增加预算，而是要拿出某种财务模型，以便能够知道是否得到了投资回报。”国际系统集成咨询公司Ciber副总裁兼地区主管Dan Hoover建议。

Hoover认为，大企业的IT部门通常都使用投资回报分析或者其他某种投资评估方法，中小企业虽然没有评估投资回报的正规方法，但可以使用简单的投资回收期分析。为了进行这种分析，公司应当先列出与某项技术投资有关的所有预期成本（软件、硬件、公司内外资源、通信费用和工作空间等）; 然后，它们应当预测所有预期财务效益（降低人工成本、减少库存持有成本和提高生产力等），并且加以量化。

Hoover说: “如果你的成本在头一年就能收回，那么这个项目就值得认真考虑; 如果投资回收期超过一年，最好转移目标。”

对未来IT进行规划

要是你没有为希望实现的目标做好规划，那么为IT划拨再多资金都无济于事。Brewer表示，未来规划的关键在于，如何合理分配预算。

电子数据系统公司负责基础设施IT外包团队的副总裁Kevin Karcher说: “中小企业的思路往往是更换系统。他们在采用技术或采购产品时，只是为了填补目前的空缺，也就是替代原有的、不再适应企业需求的技术。”

问题是这些企业在购买时，不管新机器上使用哪些版本的 *** 作系统和软件，只要能用就行。结果一堆不匹配的系统不仅管理起来困难，而且培训起来也比较难。“这显然不是战略性思考。”Brewer说。

这种行为模式的另一个危险是，中小企业最后面临的不仅仅是一堆拼凑的系统，而且是一堆拼凑的廉价的系统。根据眼下需要来做出采购决定，往往会导致不加选择地购买产品。这也就意味着，贵公司的网络组成包括: 性能不太可靠的路由器和交换机、消费级防火墙以及不适合公司发展需要的其他技术。

Karcher表示，大企业几乎不考虑这类所谓的单点解决方案，而是将更多的时间和精力用在集成上，这样就可以让它们获得同类中最佳的应用系统。通过研究、规划及了解业务部门的需要，大企业的IT部门更能够获得并集成来自多家厂商的领先技术。

如果中小企业一开始就注意集成，不但能够获得更高质量的应用系统，还能获得标准化和一致性。Karcher说: “确保流程规范是必须的，即以一种同样的可重复的方式有效地处理例行事务。标准化统一定义了流程、角色和职责，而这种一致性和可重复性让企业变得更加高效。”

让IT人员成为

管理团队的成员

IT人员的影响力绝不仅仅体现在采购最佳设备方面。Hoover说: “中小企业老板需要把IT人员看成是管理队伍的成员，让他们参与到有关公司业务及发展方向的讨论。”

如果让IT经理及早参与有关经营方向的讨论，他们有机会满足企业在时间和成本方面的预期目标，IT部门甚至会想方设法通过使用技术来改进经营方向。Hoover说: “大企业的IT部门能用技术降低人工成本、缩短交付时间，还为企业规范了流程。”

Baschab认为，IT人员经常接触众多厂商，包括互联网提供商、管理顾问、硬件供应商、人事服务公司、电信及数据通信提供商等，这意味着需要管理与外部厂商间的关系，这就是管理方面的内容。Karcher同意这一观点，他说: “如果IT团队里面没有能够与业务团队和决策者进行沟通的人员，就赶紧找一个吧。”

显然，中小企业并不总是有钱聘请得起专门的IT经理，所以要找准时机。Baschab认为: “如果中小企业的收入在3000万～5000万美元，就有必要聘请。良好的IT治理可以节省20%的开支，一旦企业收入达到了这个范围，就能省下足够多的费用来支付IT经理的薪水。这时候，IT治理就会开始获得回报。”

保证基础设施

稳定可靠

想知道如何分配IT预算，就要了解哪些系统必须正常运作。Baschab认为：“应当把美国社会心理学家马斯洛的需求层次理论应用到IT上。金字塔的最低层是饮食之类的生理需求，也就是IT系统和基础设施，这些是公司的立足之本，包括备份、安全、灾难恢复、互联网接入及电子邮件等。”

其中一些系统是在后台运行，除非它们出现故障，否则人们不会注意到它们的存在; 另外一些系统则好比是电力――你每天都使用，一旦你有需要，它们就必须正常工作。它们要像电话那样可靠运作，也就是说，用户期望它们能随时待命; 就像人们拿起话筒就能打电话。公司的员工期望电子邮件、打印机、传真机、即时通信、电视电话会议、备份和恢复等都是这样的。在这方面，中小企业的需求与大企业的需求从本质上来说没有什么两样，只不过规模不同罢了。Baschab说: “中小企业的防火墙需要与《财富》100强公司的防火墙一样安全。大公司可能有数百个网络设备，而中小企业可能只有两三个，但必须做到同样安全。”

特别需要注意的是，要确保维持公司业务顺畅运作的IT系统尽可能可靠，譬如说，要有冗余的互联网连接和备份方案，以应对电子邮件无法正常使用的情况。

除此之外，Karcher提到了安全和隐私，中小企业要了解需要遵从的法律以及无意造成的错误可能带来哪些风险。“这对面向全球开展业务的公司来说尤为重要。”Karcher说，“在其他国家有许多不同的安全要求需要关注，全世界有许多新的隐私法规需要遵守。”

Hoover忠告，你还要知道哪些部分对贵公司来说最关键。这些IT设施需要你完全了解，并且需要亲自管理; 有些部分没必要亲自管理，譬如求助台服务、服务器监控、灾难恢复等，这些都可以外包给专业厂商。“这就好比维修管道，贵公司内部没有管道工，需要时才从外面请来。”Karcher解释。

以营销传播公司为例，他们希望自己掌握用来为广告和营销客户设计方案的IT设备和软件，但是可能会决定把用来向客户开票的账单系统外包出去，因为设计方案是其核心竞争力。

选择厂商要明智

Hoover说: “IT硬件、软件和服务的供应商是确保自己成功的关键，必须处理好与这些厂商的关系; 还要建立相互信任的合作关系，预期目标要明确。”

管理厂商关系的一个方面就是，要知道现有的这家厂商何时再也满足不了你的要求。Brewer建议: “随着贵公司规模不断扩大，你要知道何时换一家新厂商。中小企业往往习惯与同等规模的厂商合作，却没有认识到对方无法满足自己的要求。”一旦出现这样的情况，公司就可能错失规模定价（scale-pricing）的优势，也得不到相应级别的专长和帮助。Brewer给出的经验法则就是:“应当找规模比自己大一点的厂商。”

Hoover同意上述观点，他说: “现在选择的余地很大，选一家比自己大一点的厂商，才能向对方取经。”

在向对方取经之前，要明确自己的预期目标，不要以为厂商明白你的要求。Karcher说: “买家如果说不出自己的要求，是件不好的事情。要告诉厂商你目前的状况、态度以及要处理的优先事项。”

不断学习

如果贵公司想以大企业为榜样，就要在企业发展过程中，不断对IT人员进行教育。“应当对同行业其他公司正在做的事情有所了解。”Hoover说。

与来自其他非竞争性公司的IT队伍进行交流，有很多好处: 深入了解情况，听听对方在技术方面的经验和教训; IT团队和行业组织也是获得宝贵信息的一个来源，Hoover提到了数据管理协会、信息管理学会等。

如果这样做行不通，还可以借助互联网。Hoover说: “现在，网络上有足够丰富的信息，互联网是一大平衡器，你能够掌握与大企业一样丰富的信息。因而，中小企业研究分析的能力并不逊色于大企业。”

这一切听上去像是吸收知识，事实上的确如此。“没必要每件事都做，要注意基本规则――学会战略性思考，贵公司现阶段在技术方面至少要稍稍保持领先地位。”Hoover强调。

与大企业相比，中小企业有自己独特的优势。中小企业的管理层比较少，这样高层管理人员更清楚地了解IT方面的现行情况。领导能一眼看清楚整个业务环境，从而进行相应的决策。这方面要比大公司更灵活，而且往往能更迅速、更轻松地采用新技术。

如果结合中小企业本身具有的优势，再学习大企业IT部门的经验，就能确保你为成长和成功做好准备，减少成长的烦恼。

本方案对于企业管理的作用和价值

随着现代社会中企业对IT系统的使用越来越深入和频繁，如何管理好企业的IT系统成为不可忽视的管理议题。如果在IT建设过程中缺乏总体架构和规划，企业将在IT管理上面临众多的挑战。比如：业务越来越复杂，IT系统越来越庞大;难以统筹地管理;看不清楚IT建设的现状，更谈不上合理规划新的IT建设;企业内IT和业务沟通困难，业务人员用不好系统，IT人员服务质量也不高。

企业架构(EnterpriseArchitecture)是对构成企业的所有关键元素和关系的综合描述。它是一个用于描述和分析企业的现状，并对企业做出合理诊断和规划的方法。企业架构就类似于医学上将人体构造分解为骨骼、肌肉、血液等组成部分，既考虑每个部分的成分，也考虑这些部分是如何结合并协同工作的。它是现代企业用于自我分析和自我管理的工具。

单纯地从IT的视角管理IT系统让许多企业深陷管理困境，解决问题也是按下葫芦浮起瓢。实际上，IT的服务对象是企业的战略、组织、流程等一系列的要素。因此对IT的管理如果不考虑这些要素，那就会理不到头绪，产生诸如系统庞大并与业务脱节等症状。因此，需要通过企业架构的管理思想来管理IT架构，并实现如下价值：

1)理清IT架构，明确IT管理现状

IT架构管理对于企业来说，首先是需要“理清楚”然后才是“管起来”。与IT架构相关的内容既包括企业的业务流程、信息数据、应用功能、服务器和网络等管理要素，也包括传输类型、控制方法、管理策略、开发技术等技术层面的要素，合理清晰地梳理这些内容并了解相互管理，才算是帮助企业真正明白目前IT管理的现状。

2)分析企业现状，找到IT管理的可改进点

如果说明确IT管理现状是企业对自身的一个审视和了解，那么IT现状分析就是企业对自身的“望闻问切”。通过对企业流程与应用系统覆盖度的分析，我们可以知道企业IT应用主要存在于企业哪些地方，而通过对企业流程与应用系统冗余度的分析，我们又可以知道企业IT系统之间存在的功能重复或冲突集中在哪里。

当然，企业IT分析同样不能零散的开展，因此需要有一个整体的分析设计体系和科学的分析设计方法，本方案基于在流程分析领域一直处于世界领先地位的ARIS平台，提供了一套在IT架构现状分析上成熟的方案。

3)合理地规划与改进IT建设

以往的IT规划往往从IT系统本身出发，或借鉴国际先进的经验，或追求新的产品与技术。而一个真正适合企业的IT规划既要有适度的前瞻性，又要能够贴切地满足企业战略和企业的生存环境。否则就像在水下穿了一件太空衣，虽然外表光鲜亮丽，但实际上花费巨大却没有解决实际问题。

企业架构下的IT规划强调的是从企业战略出发，首先规划业务架构层，然后延伸到应用架构和数据架构，最后结束于企业的基础设施架构，其中包含战略、流程、系统功能、模块、数据、数据接口、系统实例、应用机房、网络信息和技术细节等等各种管理要素，可以说是对企业IT建设的量体裁衣。

4)完整地管理IT资产与技术

仅仅规划和实施IT系统是远远不够的，大多企业在实施IT系统后，更重要的是运维和管理IT系统。在这样一个层面上，IT系统无疑于企业的IT资产。结合IT服务管理标准和企业资产管理的思路来统筹的管理IT系统，也是企业架构可以发挥力量的地方。

同样，企业里面往往也有专门管理IT配置的工具(CMDB)，但这些工具往往又忽略了企业业务与战略和IT之间的关系，如何将这些内容集成和统筹地管理，也是企业架构管理思想所考虑的内容。

借用企业架构的管理思想来管理IT架构，将保障IT系统不再与现实脱节，也不再落后于战略和业务的发展。IT系统将像企业的设备等重要物质资产一样有效地管理起来。

基于企业架构(EA)的IT架构管理解决方案及其交付物

在企业架构(EnterpriseArchitecture)的管理方法中，IT的规划需要与业务的需求统筹地管理起来。因此，一般将企业的IT架构划分为四个层次：

业务架构层：包含企业的战略、组织与流程等业务相关的架构，主要用于分析业务的驱动与业务的需求。

应用架构层：包括应用系统，系统功能，系统接口，相关应用的服务等，主要用于从业务层面将需求层层分解为系统的功能。

信息架构层：包括数据体系，数据架构，数据实体等于信息数据相关的内容。由于数据是流程流转的实体，也是应用系统需要实现的功能载体，因此对数据的设计需要与应用和业务层进行统一。

基础架构层：数据的存储实体，系统实例，硬件设备，软件技术等等属于企业基础设施的内容，需要按照资产管理的模式进行管理。

企业架构中的IT架构的四个层次

如何基于企业架构进行IT应用功能的规划？

交付物一：搭建从贯穿IT架构的模型体系

企业架构就是对企业各个管理要素以及关联进行管理的过程。因此我们对IT架构的管理，需要将企业如下要素进行统筹地梳理与整合，并形成模型体系。

战略：通过BSC战略模型梳理企业战略与目标。

流程：通过增值链与EPC模型梳理企业的流程架构与现实业务流程。

功能：通过流程步骤梳理系统所因提供的应用功能。

系统：通过应用系统架构模型梳理系统类型与模块。

基础设施：通过系统与系统实例，梳理系统所存储的相关硬件与设备等基础设施。

资产：通过整理相关资产获得资产的生命周期。

资产集：通过整理资产并分类获得完整的资产集合。

架构生命周期：管理各个业务单位的IT架构的生命周期。

企业架构各个层面的整理

交付物二：企业架构现状评估与分析报告

企业架构的IT架构现状评估与分析方法是以企业架构方法论作为理论依据，分析企业的各个架构元素和架构元素之间的关联性，例如：应用系统架构下应用系统的岛屿数量和程度，以及应用系统对业务流程的覆盖率。然后对现状的业务进行科学地诊断。

采用目标分解与纬度分析方法开展。分析包含一个总体目标，按照多视图分解到多个分目标，每个分目标包含多个分析指标，而每个分析指标都有相应的定性分析方法和分析结果。沿用的分析手段采用了平衡积分卡的思想，便于企业长期使用。

使用ARIS模型与ARIS工具对于模型的统计分析功能来完成分析工作。由于前期的建模工作有了大量模型成果，一些关键的数据分析可以通过模型来开展，例如：流程的应用系统覆盖率。在模型真实的情况下，此类分析能够很精确地反映企业架构管理现状。因此为了达到更准确的效果，还将对模型的真实度加以评估。

应用系统架构良好支持业务代表了企业架构下应用系统架构建设的质量。应用系统的建设为业务信息流的自动化提供技术平台，并业务流程的标准化提供支持，可以说，企业应用系统建设的主要目的就是为了业务服务。应用系统架构的建设也是建立在IT的基础设施之上，因此对它的规划将直接影响IT基础设施的需求。应用系统架构良好支持业务流程需要在良好地支撑流程需求和数据运作的基础上，还要保留有良好的系统集成性和可扩展性。因此，应用系统对业务流程流程执行过程，数据流转过程的可服务性是很重要的。在此基础上，多个应用系统之间的系统接口和架构方式也是需要关注的。

基于ARIS平台的企业架构分析与评估结果示例

交付物三：经过合理规划的TO-BE的IT架构

在IT架构管理的整体下，如何通过对业务的变更获得系统的变更方案？博阳咨询推荐IT城市规划(ITCityPlanning)的规划方法。

IT城市规划方法

在IT规划中采用ARIS的信息系统视图(IS视图)，可以作为层次与层次之间转换的媒介。在ARIS中，IS视图中的对象类型必须放在功能和应用系统之间，这样便拓展了ARIS中的功能视图。如同各种功能一样，IS的元素与不同的结构相连接，出现在ARISHouse模型的常见视图中。这些扩充主要与流程视图和数据视图相关。在下面所述的IS视图中，涉及来自于ARISHouse模型的功能和流程视图中，用来描述IS元素之间的关系的模型类型，或者在其它ARIS视图的背景下，用来详细描述IS元素的模型类型。

交付物四：IT资产与IT架构的生命周期平台

对系统的功能进行规划后，不可忽略地就要考虑系统的实施过程。但对于完整的IT架构来说，系统从规划到实施，再到使用与维护，直至淘汰，是一个完整的生命周期。因此把系统当做IT的资产来进行管理是可以覆盖到系统的完整生命周期。

系统实施周期的评估过程

系统评估的方法有很多种，博阳咨询建议对规划好的系统以及系统模块按照成熟度与重要性进行评估，便可以知道哪些系统需要先期建设，哪些后期建设，有一个良好的系统引入的过程。

系统生命周期的评估过程

同样，系统一旦建设完成，系统的管理与评估工作远没有结束。需要持续地通过对系统功能满足程度的评估，不断地获取系统是否要升级或者淘汰的预期，保证系统能够时刻满足业务需求。这也是IT架构管理中持续改进的建设环节。

说一说对互联网系统和传统企业IT系统的一些看法和观点。

现在被炒的很火热的互联网，云计算架构，其相对于传统的大型企业系统架构，最大的区别就是以分布式的架构去替代原先的集中式系统架构。

打个比方，原先的大型企业系统架构，就好像一架大型的民航客机。作为出行来讲，飞机无疑是最舒适最快的交通工具，同时安全性也很好。但飞机却也不是人人都能坐的。首先：做飞机要经过换领登机牌，安检等若干道手续，乘客必须提前一个多小时到机场办理各种手续，而坐火车大巴则随到随买随上车，方便的多；其次：坐飞机很多东西不能随身携带甚至不能托运，火车大巴则相对宽松;还有：机票很贵坐飞机花销很大而且飞机运载能力也不如火车。当你有数万数千人要一次性到达某地时，一两架飞机的运载能力根本不够，要调动成批飞机的话整体成本又太高。最后：虽然飞机很少出事故，飞机一旦出现事故的话危险级别往往都会很高。

但是，以前除了飞机之外，就只有火车，大巴这种交通方式选择了。相比之下，这些方式虽然收费低廉，乘车，携带物品都比较方便，但是速度实在太慢而且受外界因素诸如雨雪等等的影响太大，乘坐也不是很舒适。只能满足那些相对时间宽裕，或者囊中羞涩人群的出行需求。

于是，为了满足更多人，更便利更高速的交通运输需求，新的交通运输模式—动车/高铁就出现了。它和火车最大的区别是：火车只有一节车头有动力，后面能拖几节车厢跑多快基本就是看一个车头有多强劲。但个体的力量终究有限，一个车头再强劲也有个极限，发展空间也就那点了，实在难以有太大作为。动车则不同，它每节列车都独立有自己的动力系统，连在一起各节车厢动力系统就是一个叠加递增的关系。所以理论上越多节车厢接在一起就可以拉更多人跑的更快，是一个无限扩展的系统!而且因为动车可以搭载的乘客很多，所以均摊到每个乘客头上，坐动车的速度可以某种程度上接近坐飞机，但成本要低很多。

现在互联网，云计算的系统架构其实和动车的理念相类似，就是分布式系统的架构 – 将任务分解交由每个小计算单元进行分布式的并行处理，充分利用每个单元的计算和存储能力，理论上性能可以无限线性扩展，任何一个节点的故障不影响整个系统的运行，整个系统没有单点故障。

也就是说：我们可以简单把大型企业核心架构，或者说就是大型机，RISC系统比作飞机;而把互联网，云计算的系统架构比作动车。现在，就可以做些很有意思的讨论了。

还是来说说稳定性和可靠性：就说2012年吧，飞机也好，动车也好，新闻里面都有报道过出现严重事故，可见没有一种系统是完全稳定可靠不会出现任何宕机风险的，但是其概率都是非常非常小的。从整体来讲，都是很稳定很可靠很安全的选择。只不过各自对于如何防灾冗余的策略还是有些不一样。先说飞机，因为飞在空中，万一出了事情没有后备可用，所以能采取的方式只有想尽一切办法提高飞机自身个部件的冗余度，设计时尽可能多的考虑各种小概率事件。哪怕发生某故障的概率只有千万分之一甚至亿万分之一，只要有可能，也要把应对措施设计进去。这也是飞机造价为什么会那么高，对携带物的要求会那么多的原因。而动车则相对简单：反正多拖几节车厢又不影响我速度，那我就尽量多拖些备用车厢跑着呗。万一某节车厢出事了，就把里面乘客挪到备用车厢里，车照样跑得欢。然后等到了站再去更换检查有问题车厢也不迟。

回到IT世界也是一样。分布式系统基本都是基于x86的PC服务器。单就一台服务器而言，虽然性能可靠性在不断加强，但肯定还是不如RISC系统的。但是没关系，咱可以用数量来弥补单机冗余度的不足啊。设计没你好冗余度没你考虑的多我就多拉几台呗。坏了几台没事，应用任务再分配到别的空闲机器上就好了。坏了的机器也不用马上修，反正没坏的机器加起来也够用。等到故障机器到了一定数量我再一次性批量检修更换部件效率更高。对于用户来讲，即使我坏了100来台服务器只要剩下的服务器还能正常工作，应用就不会受任何影响。谷歌，Facebook那些超大型数据中心现在的工作思路大致如此。这么做看起来是个很简单有效，很聪明的方法，但其实也有不少问题存在。

首先我觉得这个架构好处是实现原理简单，而且扩展性d性比起RISC架构来好处不言而喻。但其实这个架构里面也存在着无谓的资源浪费可能性。例如拿存储而言，目前Hadoop类的多副本分布式存储很火。一份数据存三份，发现有数据损坏立即找空闲空间恢复。听上去很简单很容易实现很高效，但如果你真的坐下来仔细算算账，你就会发现：

1 当你数据量不大(小于PB)的情况下这种一份数据存三份方式的成本其实比现有任何商业存储方案的成本都要高。

2 这种方式下每台服务器的CPU利用率都很低，而现在市面上的大存储容量服务器，CPU配置都很高。所以这种方式，基本上是对于CPU资源的一种浪费。所以，或许对于数据量适中的企业来说，用EC CODE这种以计算能力换存储的分布式存储解决方案会比多副本方案更经济实惠。

3 这种方式很容易让IT运维人员产生一种习惯性思维 – 即要提高系统在线时间就多买些服务器就好了。因为服务器多了分布性好了自然冗余度就高了。于是不必要的服务器采购就这么产生了，每个数据中心也就又多了很大一笔不是很必要的电费开销。

其次，我觉得分布式架构的某些故障很可能会产生连锁效应，导致更严重全局瘫痪。打个比方，大家都知道赤壁之战的故事。里面有个很著名的桥段就是庞统献连环计，铁锁连舟。起始时使曹 *** 万余战船连成一体稳如平地进可攻退可守前后都可照应看似完美，但唯有一个命门就是怕火攻。而诸葛亮周瑜正是利用这个命门，解东风火烧赤壁把曹 *** 百万大军杀的丢盔卸甲。互联网的分布式架构其实我觉得也有类似“命门”。大型机或者RISC系统之所以那么贵，其实很多时候用户在为千万分之一甚至亿万分之一的“万一”买单。而互联网，现在的公有云架构，在设计之初，基本的考虑思路是大用户，大并发，然后尽量减少TCO。所以很多时候，设计架构时会先把那些“千万分之一”排除在外，暂时不予考虑。而系统上线之后，稳定运行一段时间用户量暴涨，精力往往又会去专注扩容方面了。搞不好就会把一些“命门”漏掉，于是乎万一正好遇上“东风”吹到了命门上，后果估计会比曹阿瞒更惨。因为IT世界里还没有那么仁义的关云长会在华容道上放曹 *** 一马。

其实从最近Facebook，Amazon、谷歌的几次宕机事件来看，已经有些那个苗头了。好在那些互联网领头羊们应该是已经意识到这些问题，已经在积极修补“命门”了。

最后，我想说互联网，云计算的业务类型其实和传统企业的业务类型不一样，所以大型机，RISC系统处理的任务，运行的计算并不一定都适合移植到分布式系统架构上来。还是以交通运输举例：我要去美国，目前还是只有飞机可以满足我的需求。当然你可以说我坐动车也可以，无非是多转几趟跨国列车。但那毕竟很勉强，速度不快，费时费力还不省钱，毫无意义。人家直接飞过去就行了，你却要绕着太平洋海岸线跑一个大圈来兜，何必呢

那么以上这些问题有没有办法解决呢其实我觉得解决以上问题的关键就是两个字：运维。分布式系统，要保障其安全可靠的运行，合理有效的扩容，关键不在系统的软硬件，而是在系统搭建之后的运维和持续的对系统的改进修正!现在网络上很多人都在热衷于各种开源架构如openstack，Hadoop的开发，应用场景探讨。但个人以为这些开源系统的特点是搭建简单，维护艰难!要想把这些架构和技术真正投入企业成熟应用，在运维管理上投入的成本可能要比RISC大得多。因为这些系统架构更分散，出现的不可预估性更多，同时也更需要有人来理清何时用分布式架构，何种场景还是需要传统架构。那么可能有人要问，既然如此，我们还有必要走分布式系统这条路吗当然有!原因也很简单：分布式架构给了我们处理海量请求的能力和应对突发事件的d性;同时分布式架构也使系统具备了更好的扩展能力和更多业务创新的可能性。

说了这么多，基本要讲的也就讲得差不多了。怕前面说的有些散稍微总结下我想说的观点：无论传统RISC架构还是现在流行的分布式架构，虽然实现方式各有不同，但都是具有很高的稳定性可靠性的系统。但没有一个系统是绝对稳定不会宕机的，要保障系统稳定可靠运行，运维管理很重要。分布式系统相比传统RISC架构有扩展性和灵活性方面的巨大优势，但也存在资源浪费和故障隐患危险。在这一方面，分布式系统架构还需要多向传统架构的运维管理学习借鉴，提升自身的忧患意识和故障预警处理能力。

以上就是关于谁能为我解释IT架构师与项目经理......全部的内容，包括:谁能为我解释IT架构师与项目经理......、什么是超融合架构，与传统的IT架构有哪些区别、为什么IT企业必须采取架构方法以实现自动化等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！