对于任何企业来说，服务器成本都是一项重大的支出。通过实施一些最佳实践，企业可以显著降低其服务器拥有成本（TCO）。以下是一些优化服务器成本的最佳实践：
1. 选择合适的服务器
选择合适的服务器对于优化成本至关重要。企业应考虑其工作负载和性能要求，并选择与其需求相匹配的服务器。过大或过小的服务器会导致更高的成本和效率低下。
2. 利用云计算
云计算可以为企业提供一个可扩展、按需付费的服务器解决方案。企业只需为其使用的资源付费，从而可以节省服务器购买和维护的成本。
3. 虚拟化服务器
策略可以帮助企业节省金钱，提高效率，并为其核心业务提供更好的支持。
数据中心要如何实现节能减排增加能效
我们的研究表明，通过更加严格的管理，公司可以将数据中心的能效提高一倍，从而降低成本并减少温室气体的排放。
具体而言，公司需要更积极地管理技术资产，提高现有服务器的利用率水平；公司还需要更准确地预测业务需求对应用程序、服务器和数据中心设施容量的推动效应，以便控制不必要的资本和运营支出。
数据中心的效率是一个战略问题。
企业建造和运营数据中心花费的资金在公司IT预算中占的比例不断上升，导致用于急需技术项目的预算越来越少。
数据中心建造计划是董事会一级的决策。
同时，监管部门和外部利益相关方也越来越关注公司管理自身碳足迹的方式。
采用最佳实践不仅有助于公司减少污染，还能够提高它们作为良好企业公民的形象。
IT成本高昂如今，公司进行的分析越来越复杂，客户要求实时访问账户，广大员工也在寻找新的技术密集型协作方法。
因此，即使在经济放缓时，人们对于计算、存储和网络容量的需求也在继续增长。
为了应对这一趋势，IT部门正不断增加计算资源。
在美国，数据中心的服务器数量正在以每年约10%的速度增加。
与此同时，在中国和印度等新兴市场，机构正在变得越来越复杂，更多的运营工作实现了自动化，同时有越来越多的外包数据业务在这里进行，因此数据中心的数量呈现出更快的增长态势。
这种对计算资源无法抑制的需求，导致全球数据中心容量稳步上升。
目前，这种增长并没有显露出即将结束的迹象，通常在经济衰退时期它只会进入温和增长状态。
这一增长已经导致了IT成本激增。
如果将设施、存储设备、服务器和人员成本都计算在内，数据中心支出一般会占到企业IT总预算的25%。
随着服务器数量不断增长，电价也正以高于收入和其他IT成本的速度攀升，上述比例只会日益提高。
每年，运行这些设施的成本都在以高达20%的速度上升，而IT总支出的增长速度仅为6%，二者相差极为悬殊。
数据中心支出的不断增加，改变了许多企业的经济结构，尤其是金融、信息服务、媒体和电信公司等信息密集型企业。
在过去5年中，成立一个大型企业数据中心所需的投资已经从1.5亿美元升至5亿美元。
在IT密集型企业中，最大设施的造价正逼近10亿美元。
这一支出挤占了新产品开发的资本，降低了某些数据密集型产品的经济效益，并降低了利润。
此外，不断上升的能耗产生了更多、范围更广的碳足迹，导致了环境恶化。
对于大多数服务行业，数据中心是企业最主要的温室气体排放来源。
在2000到2006年间，用于存储和处理数据的电力翻倍，每个数据设施的平均耗电量相当于2.5万个家庭的总和。
世界上共有4400万台服务器，消耗了总电力的0.5%。
如今，数据中心的碳排放已经接近阿根廷和荷兰等国家的碳排放水平。
仅仅在美国，到2010年数据中心的预计用电增长量就相当于要新建10座电厂的发电量。
目前的预测显示，如果不对需求加以遏制，2020年全球数据中心的碳排放将是现在的4倍。
监管部门已经注意到这些发展趋势，正在督促公司拿出解决方案。
美国环保署(EPA)建议，作为建立运营效率标准的第一步，大型数据中心应当使用能量计。
同时，欧盟也发布了一套自愿执行的行为准则，其中介绍了以较高的能效运行数据中心的最佳实践。
随着数据中心排放量的持续上升，政府可能会为了减排而施加更大的压力。
第2页：全面应对挑战全面应对挑战在信息密集型机构中，许多部门和级别的人员都可以做出影响数据中心运营效率的决策。
金融交易员可以选择运行复杂的蒙特卡洛(MonteCarlo)分析，而药物研究人员可以决定要将多少临床实验影像数据存储起来。
负责应用程序开发的管理人员可以决定用多少编程工作来满足这些需要。
服务器基础设施的管理人员可以做出设备采购决策。
设施主管则可以决定数据中心的位置、电力供应，以及在预测的需求出现前安装设备的时间表。
上述决策通常是在孤立状态下做出的。
销售经理可能会选择将交易由隔夜结算改为即时结算，金融分析师则可能希望为历史数据存储几份副本，他们完全没有考虑到这样做会对数据中心的成本造成什么影响。
应用程序开发人员很少想到要对自身的工作进行优化，以将服务器用量降到最低，也很少考虑开发能够跨服务器共享的设计应用程序。
购买服务器的管理人员可能会选择价格最低或他们最熟悉的产品。
但是这些服务器也许会浪费数据中心的电力或空间。
很多时候，管理人员会超额购买设备，以保证在最极端的使用情况下拥有足够的容量，而这会造成容量过剩。
管理人员往往会建造有多余空间和高制冷容量的设施，以满足极端情况下的需求或应对紧急扩建。
这些决策在整个机构中累加起来，将对成本和环境造成重大影响。
在许多情况下，公司可以在不降低自身数据管理能力的前提下，停用现有的部分服务器，并搁置购买新服务器的计划。
这可以借助一些众所周知的技术来实现。
比如虚拟化，这种技术实际上是通过寻找服务器的空闲部分来运行应用程序，以达到容量共享的目的。
但是公司不一定会这样做，因为没有哪位高管能够承担“端对端”的责任。
在机构内部，管理人员会以最符合自身利益的方式行事，这就造成大多数数据中心效率低下，每台服务器上常常只运行了一个软件应用程序。
我们分析了一家媒体公司的近500台服务器，其中利用率低于3%的占三分之一，而低于10%的则占三分之二。
虽然有诸多用于跟踪使用情况的现成管理工具，但这家公司没有使用其中任何一种。
从全球来看，我们估计服务器的日常利用率一般最高只有5%到10%而已，这造成了能源和资金的浪费。
对此，数据中心管理人员一般会回答，配备这些服务器是为了在极端情况下提供容量，例如应付圣诞节前一天的购物潮。
但一般来说，这一论断并不成立，因为数据显示：如果平均利用率极低，那么高峰时段的利用率也会很低。
此外，数据设施的数量不断攀升，但所存放的服务器和相关设备有时仅占数据设施容量的一半，这说明有上亿美元的资本支出被浪费了。
即使公司报告认为数据中心已经满载，但沿着数据中心的过道行走，经常会发现服务器机架上有很多空位，原先放在这些空位中的设备都已经淘汰。
之所以出现这种不一致的现象，部分原因在于预测数据中心需求的难度很高。
运营的时间框架是一个问题。
数据中心的设计和建造一般需要2年或更长时间，而预计的使用寿命至少为12年，因此容量是在业务部门产生实际需求之前就已经设定的。
与此同时，对于业务决策如何互相影响，如何转化为对新应用程序的需求，以及需要多少服务器容量才能满足需求，还存在着认识不够全面的现象。
例如，如果客户需求增长50%，许多公司很难预测出服务器和数据中心的容量是需要增加25%，还是增加100%。
在极端情况下，我们发现一些设施在投入运营后常年处于半空状态；而另一些公司在建成一个数据中心之后，很快就发觉需要再建一个新的。
如今数据中心已经成为一项昂贵的资产，由此可以推断，财务绩效责任落实得十分糟糕。
设施的财务和管理责任往往会落在不动产管理人员身上，而这些人基本不具备相关的专业技术知识，对于IT与核心业务问题的联系也缺乏深入的认识。
同时，管理服务器运营的人员很少去了解关键运营支出的数据，例如耗电量或IT设备所占不动产的实际成本。
相反，当IT管理人员决定购置更多的应用程序或新的服务器时，有时只会使用硬件初始成本和软件许可证费用等基本指标。
计算实际成本时，需要考虑设施运营和租赁、电力使用、支持以及折旧等因素。
这些费用可能是服务器初始购置成本的4到5倍。
加上前面说到的孤立决策和责任问题，数据中心通常会添加额外的服务器作为保险措施，而很少讨论成本权衡或业务需求。
在缺乏实际成本分析的情况下，过度建造、过度设计和效率低下就成了普遍现象。
第3页：改革运营方式改革运营方式在研究之初，我们以为通过建造新的节能型数据中心，可为降低数据中心的成本和碳排放指出一条光明大道。
新的设施可以发挥当前各种技术的优势，利用自然冷却方法和碳排放较低的电源。
但我们还了解到，在降低成本和碳排放方面成效最显著的方法是改善公司现有数据中心效率低下的状况。
通过改善资产管理，增强管理层的责任意识，并且为降低能源成本和碳排放设立清晰的目标，大多数公司都能够在2012年之前将IT能效提高一倍，并遏制其数据中心温室气体排放的增长。
实际上，您无需另行建造就能获得最环保的数据中心。
积极管理资产一家大型公司采用的做法表明，规范现有服务器和设施的使用就可能产生巨大的收益。
这家公司原本的计划是，增加服务器的数量，并建造一个新的数据中心来容纳这些服务器和其他IT设备，以便满足自身在2010年的信息需求。
该公司的董事会已经批准了这项计划，但这意味着企业在这一年会有大量的资本支出。
于是，这家公司彻底修改了计划。
它将关闭5000多台很少使用的服务器。
通过对占公司应用程序总量15%的3700个应用程序进行虚拟化，可以将现役服务器的数量由2.5万台减少至2万台。
公司还更换了一些较为陈旧的服务器，代之以能够将用电效率提高20%的产品。
这些调整使公司得以搁置原先的数据中心扩建计划，并因此节省了3.05亿美元的资本投资成本。
由于服务器数量和耗电量的下降，运营支出预计将减少4500万美元，降低到7500万美元。
考虑到停用和虚拟化因素，服务器运行时的平均容量利用率将由目前的5.6%升至9.1%。
该公司仍然能够满足自身日益增长的数据需求，但是电力需求的减少，意味着未来4年内的二氧化碳排放将由59.1万吨削减至34.1万吨。
公司还可以通过对不断上升的数据需求加强管理来实现节约。
对于应当保留多少数据，是否要缩减某些数据密集型分析的规模，业务部门应当审查相关的政策。
一些交易的计算可以推迟，以降低服务器在高峰时段的利用率，也并不是所有企业信息都需要基于广泛备份的灾难恢复功能。
更好的预测和规划是提高数据中心效率的基础。
公司应当跟踪自己对数据需求的预测与实际需求之间的差异，然后向能够最大限度减少预测偏差的业务部门提供奖励。
数据中心的管理人员应尽可能全面了解未来的趋势，例如机构增长和业务周期等，然后将这一趋势与自身采用的模型结合起来。
由数据中心、应用架构师和设施操作人员提供的建议可以用于改善这些模型。
一家全球通信公司制定了一套规划流程，将每个业务部门数据增长量的各种发展情况包括在内。
虽然公司最终得出的结论是，它需要扩大容量，但是未来需求中有很大一部分可通过现有资产来满足，这比原计划节约了35%的资本支出。
许多机构并没有将数据中心看作一种稀缺的昂贵资源，而是将其当成了等待注水的水桶。
为了避免这种趋势，公司在估算新服务器或附加应用程序和数据的成本时，可以采用实际拥有成本(TCO)核算法。
业务部门、软件开发人员或IT管理人员在进行支出决策时，很少会将应用程序和服务器的生命周期运行成本考虑在内。
提早计算这些成本，有助于限制过量的需求。
管理这些变化可能十分困难。
大型机构中的许多人并没有意识到数据的成本。
企业的每一个部门都会产生对于数据中心服务的需求。
满足这些需求的责任分散在IT部门(包括运营和应用开发)、设施规划人员、共享服务团队和企业不动产职能部门身上。
成本报告工作并没有统一的标准。
第4页：提高总体效率提高总体效率作为数据中心改进计划的一部分，我们建议采用一项新的指标：企业数据中心平均效率(CADE)。
与美国的企业燃料平均经济性(CAFE)里程标准类似，CADE考虑了数据中心内的设施能效、设施利用率和服务器利用率水平。
将这些因素综合起来，就得到了数据中心的总体效率，即CADE(图)。
减少了成本和碳排放的公司将提高自身数据中心的CADE分数。
这就像在汽车行业中，出色的里程数能够提高CAFE评级一样。
为了给改进工作设立目标，我们将CADE分为五级。
属于CADE第1级的数据中心运营效率最低；大多数机构最初可能都会被归入较低的级别。
关闭利用率低下的服务器、采用虚拟化技术以及提高设施空间的使用效率，都将提高CADE分数。
借助CADE，公司还可以对整个数据中心的设施进行基准比较分析，或者与竞争对手进行比较，也可以为管理人员设立绩效目标并加以跟踪。
在数据中心的需求管理方面，我们建议采用一种由首席信息官全权负责的新治理模型。
在这种体制下，首席信息官能够更为透彻地了解各业务部门的数据需求；对于需要更多服务器或软件应用的新数据项目，他们可以强制要求将能耗和设施成本考虑到相应的投资回报计算中。
我们还建议首席信息官采用一种新的指标来衡量改进情况，请参见副文“提高数据中心的效率”。
通过强化责任，首席信息官将拥有更高的积极性来寻求改进，例如采用虚拟化技术和提高现有设施的利用率。
由于这种模型将关键业务决策的更多责任集中在首席信息官身上，因此不但需要首席执行官的全力支持，而且要求机构转变以往对于业务部门的数据中心扩容请求有求必应的思维模式。
此外，首席信息官还应当设定将数据中心的能效提高
DCloud崔红保：云开发与跨端技术，构建企业降本增效新篇章
利用云开发与跨端技术，实现一套代码多端发布，统一前后端技术栈，简化运维，精简团队，轻盈管理、快速交付，是企业降本增效的最佳实践。
在本次论坛上，DCloud 的 CTO 崔红保分享了 DCloud 公司在云开发和跨端技术方面的最新研究成果和实践经验，强调了通过云开发平台的资源共享和高效开发工具降低企业的运营成本和开发成本的重要性。
接下来，我们将从三个部分深入探讨：回顾传统多技术栈的人效与管理挑战；基于跨端技术和云开发模式，探讨统一前后端技术栈带来的便捷性；展望未来的组件生态。
首先，让我们回顾传统的多技术栈带来的挑战。
在多技术栈环境下，企业需要投入大量人力成本，同时管理成本也随之增加。
例如，一个创业公司需要配置包括后端、前端、移动开发等多个角色的团队，每个岗位至少有两个人备份。
这种情况下，团队规模大、人员多，项目管理变得复杂，需求分析、接口设计等阶段需要召开大量会议，协调不同团队的时间，导致项目上线时间延迟。
管理团队的精力也更多地集中在人员招聘、培训和激励上，而业务和商业化方面的需求得不到充分关注。
为解决上述问题，崔红保分享了DCloud如何通过跨端技术和云开发来构建统一的技术栈。
跨端技术，尤其是基于Web技术的跨端解决方案，能够实现一套代码多端发布，统一前后端技术栈，简化运维，精简团队，提升效率和降低成本。
接着，我们将深入了解跨端技术的发展历史。
跨端技术至少已有二三十年的历史，Java作为第一个成功的跨平台开发语言，Web技术在跨端技术中占据领先地位。
在国内，跨端开发面临着终端分裂的挑战，小程序成为移动互联网的特色存在，前端工程师需要适配多家小程序平台，每家平台的开发规范和细节差异极大，这给开发带来了巨大压力。
为应对这一挑战，DCloud于2018年立项开发uni-app跨端框架，实现一套代码发布到所有平台。
uni-app不仅在国内开源社区中脱颖而出，star数名列前茅，生态也相对成熟，拥有丰富的插件资源，大大简化了开发者的工作流程。
uni-app的流行证明了跨端开发技术在提高开发效率和降低开发成本方面具有巨大的潜力。
基于uni-app，DCloud解决了小程序、App等平台上的多端分裂问题。
接下来，我们将介绍uni-app x产品的开发背景和目标。
uni-app x的开发旨在解决传统跨端框架在性能方面的短板，通过彻底干掉JS进程，实现业务逻辑和UI逻辑运行在同一进程环境中，从而提升性能。
通过TS + Vue开发并基于SWC编译成Kotlin和Swift项目，uni-app x实现了业务逻辑和渲染的原生化，显著提高了渲染性能，解决了传统跨端框架的性能瓶颈。
基于跨端框架和云开发的融合，DCloud提出了uniCloud跨云开发引擎。
uniCloud实现了技术栈的统一，前端和后端工程师使用相同的JS技术栈，使得前端开发人员能够直接在前端页面编写JS代码查询云端数据库。
uniCloud解决了传统开发模式下前端人员需要等待后端接口提供、协调联调时间的问题，降低了管理成本，提高了开发效率。
云开发的另一大优势在于弹性扩缩容和成本控制。
云开发采用按需付费的模式，只有在用户请求时才产生计费，避免了传统虚拟机的高昂成本。
此外，uniCloud提供了一种更高效、成本更低的服务器资源方案，使得开发者能够灵活应对业务需求，同时降低运营成本。
展望未来，基于跨端框架和云开发的集成，未来的应用开发将更加高效和稳定。
组件生态将以业务为中心，实现各端一致、云端一体，大大简化了开发流程，提升了开发效率和商业验证效率。
同时，DCloud通过uni-app和uniCloud两大基础设施，构建了丰富的云端一体公有模块及轮子，如schema2code、uni-id、uniPush、uniPay等，为开发者提供了快速搭建业务应用和管理后台的便利性。
开发者可以基于这些模块和轮子，构建不同行业的解决方案，实现降本增效，加速数字化建设。
总之，通过跨端技术和云开发的融合，企业能够实现技术栈的统一，简化运维，精简团队，提升开发效率和管理效率，从而实现降本增效的目标。
DCloud的实践和分享展示了这一路径在企业数字化转型中的重要性和可行性。
互联网时代的网络自动化运维
互联网时代的网络自动化运维
互联网上有两大主要元素内容和眼球，内容是互联网公司(或称ICP)提供的网络服务，如网页、游戏、即时通信等，眼球则是借指海量的互联网用户。
互联网公司的内容往往分布在多个或大或小的IDC中，越来越多的眼球在盯着ICP所提供的内容，互联网公司进行内容存储的基础设施也呈现出了爆发式的增长。
为了保障对内容的访问体验，互联网公司需要在不同的运营商、不同的省份/城市批量部署业务服务器用以对外提供服务，并为业务模块间的通信建立IDC内部网络、城域网和广域网，同时通过自建CDN或CDN专业服务公司对服务盲点进行覆盖。
因此随着业务的增长，运维部门也显得愈发重要。
他们经过这些年的积累，逐步形成了高效的运维体系。
本文将结合国内互联网公司的经验，重点针对IT基础设施的新一代自动化运维体系展开讨论。
一、运维的三个阶段
● 第一个阶段：人人皆运维
在早期，一个公司的IT基础设施尚未达到一定的规模(通常在几台到几十台机器的规模)，不一定有专门的运维人员或部门，运维的工作分担在各类岗位中。
研发人员拥有服务器权限，自己维护和管理线上代码及业务。
● 第二个阶段：纵向自动化
随着业务量的增长，IT基础设施发展到了另外一个量级(通常在上百台至几千台机器的规模)，开始有专门的运维人员，从事日常的安装维护工作，扮演救火队员，收告警，有运维规范，但运维主要还是为研发提供后置服务。
这个阶段已经开始逐步向流程化处理进行过渡，运维部门开始输出常见问题处理的清单，有了自己业务范围适用的自动化脚本，开始利用开源软件的拼装完成大部分的工作。
具体表现为：各产品线有自己编写的脚本，利用如SVN+puppet或chef来完成服务器的上线和配置管理等工作。
● 第三阶段：一切皆自动
在互联网化的大潮中，越来越多的黑马团队应运而生，都曾有过短时间内用户访问量翻N倍的经历。
在流量爆发的过程中，ICP的互联网基础服务设施是否能够很好的跟进，直接决定了业务内容能否满足海量用户的并发访问。
与此同时，运维系统需要足够地完善、高效、流程化。
谷歌、腾讯、网络和阿里等规模的公司内一般都有统一的运维团队，有一套或多套自动化运维系统可供参照，运维部门与开发部门会是相互平行的视角。
并且也开始更加关注IT基础设施在架构层面的优化以及超大规模集群下的自动化管理和切换(如图1所示)。
图1.大型互联网公司IT基础设施情况概览
二、BAT(网络、阿里、腾讯)运维系统的分析
国内的互联网公司网络、阿里、腾讯(以下简称：BAT)所提供的主要业务内容不同，IT架构不同，运维系统在发展过程中有不同的关注点。
1.腾讯运维：基于ITIL的运维服务管理
预计到2015年腾讯在全国将拥有60万台服务器。
随着2012年自动化部署实践的成功，目前正在进行自动化验收的工作。
在网络设备方面，后续将实现从需求端开始的全自动化工作：设备清单自动生成->采购清单自动下发->端口连接关系、拓扑关系自动生成->配置自动下发->自动验收。
整个运维流程也已由初期的传统IT管理演进到基于ITIL的服务管理流程(如图2所示)。
图2.腾讯基于ITIL的运维服务管理
2.阿里运维系统：基于CMDB的基础设施管理+逻辑分层建模
CMDB(Configuration Management highlight=true>数据类型之间的因果关系提供保障。
同时，CMDB与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。
可实现IT服务支持、IT运维以及IT资产管理内部及三者之间的流程整合与自动化。
在实际的项目中，CMDB常常被认为是构建其它ITIL流程的基础而优先考虑，ITIL项目的成败与是否成功建立CMDB有非常大的关系。
3.网络自动化运维：部署+监控+业务系统+关联关系
网络主要面临的运维挑战包括：突发的流量变化、复杂环境的关联影响、快速迭代的开发模式以及运维效率、运维质量、成本之间的平衡等等。
网络的运维团队认为，当服务器规模达到上万台时，运维视角需要转为以服务为粒度。
万台并不等于百台*100;机器的运行状态，也不再代表业务的工作状态;运维部门为研发提供前置服务，服务与服务之间关系也随着集群的扩大逐渐复杂起来。
图3.网络自动化运维技术框架
网络的自动化运维技术框架，划分为部署、监控、业务系统、关联关系四大部分，整个框架更多突出了业务与IT基础设施的融合，注重关联关系的联动。
所谓关联关系，主要是指任务与任务之间的时序依赖关系、任务与任务之间的数据依赖关系、任务与资源之间的引用依赖关系，分别对应到任务调度、数据传输、资源定位的服务流程中，形成了多条服务链。
关联关系的运维与业务较强相关，需要有一套系统能够理清楚关系的全貌，从而在复杂的服务链上，定位运行所在的环节，并在发生故障时预估影响范围，及时定位并通知相应的部门。
在这样的一套系统中，自动化监控系统非常重要。
网络的技术监控框架，主要通过数据采集、服务探测、第三方进行信息收集，进行监控评估后交给数据处理和报警联动模块处理，通过API接口进行功能扩充(如图4所示)。
图4.网络自动化技术监控框架
其实无论是BAT等互联网企业还是其他行业的企业，在IT建设中都会遵循IT基础架构库(ITIL)或ISO服务管理的最佳实践，采用自动化IT管理解决方案以实现重要的业务目标，如减少服务中断、降低运营成本、提高IT效率等等。
随着ISO、ITIL v3.0的发布和推广，两者已经成为事实上的某种标准。
在当今企业IT管理领域，对两个标准有着很迫切的需求。
特别是ISO的认证要求，已经成为企业越来越普遍的需求 。
ITIL v3.0包含了对IT运维从战略、设计到转换、运营、改进的服务全生命周期的管理，相关方案往往覆盖了多个领域和多个产品，规划实施和工具的选择会比较纠结。
如果选择开源的工具，从CMDB开始就会遇到很多的开发工作，对于很多注重成本收益比的企业，可以参考，但由于无法保证性能与效果并不一定适用。
因此，成熟的商业方案会是更好的选择。
最新的iMC V7版本，围绕资源、用户、业务三个维度进行创新，发布了SOM服务运维管理(基于ISO、ITIL标准)等组件，增加了对服务器的管理，能很好的满足更多互联网化的场景需求。
通常认为，一个高效、好用的配置管理数据库一般需要满足6条重要标准，即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。
企业IT基础架构的元素类型、管理数据的类型往往有较多种，如网络设备、服务器、虚拟机等，因此对于多种信息的存储需要有合适的联合的方法。
虽然 iMC智能管理平台在网络设备、服务器设备等方面已经能够较好的的满足，但是随着服务器虚拟化技术的发展，虚拟机正越来越多的成为IT基础架构的一大元素。
因此，针对这一需求华三通信基于CAS CVM虚拟化管理系统，对服务器CPU、内存、磁盘I/O、网络I/O等更细节的重要资源以及虚拟机资源进行全面的管理。
与BAT不同，华三通信的网管软件面向全行业，目前虽然没有对域名管理等特殊资源的管理，但是能够通过API接口等方式与特有系统进行联动，进而满足定制化运维的需求，尤其是在互联网化的场景中，针对不同的业务需求，可以实现很多定制化的对接需求，例如，iMC+WSM组件与国内某大互联网公司自有Portal系统进行了对接，打通了iMC工具与用户自有运维平台，很好的实现了架构融和。
另外，与阿里的逻辑分层建模相似，H3C iMC+CAS软件体系在上层也做了很多的逻辑抽象、分层，形成了诸多的模块，也即是大家看到的各种组件。
三、网络自动化运维体系
哪怕是一个只有基础技术能力的陌生人，也能做专业的IT运维;哪怕是一个只有初中学历的运维人员，也能够带队完成中小型机房节点的建设，并负责数百至上千台服务器的维护管理工作–这是一些公司对自己IT运行维护水平的一个整体评价。
看似有些夸大的嫌疑，但实际上依托于强大的IT运维系统，国内已经有不少互联网公司能够达到或者接近这一标准。
这些企业都经历了运维发展过程中的各个阶段，运维部门曾经也是被动的、孤立的、分散的救火队式的团队，在后来的发展过程中，IT系统架构逐渐走向标准化、模型化，运维部门建立了完整的设备、系统资源管理数据库和知识库，包括所有硬件的配置情况、所有软件的参数配置，购买日期、维修记录，运维风险看板等等，通过网管软件，进行系统远程自动化监控。
运维过程中系统会收集所有的问题、事件、变更、服务级别等信息并录入管理系统，不断完善进而形成一套趋向自动化的运作支撑机制。
按照云计算的体系架构，在这样一套系统中，主要的IT资源包括计算、存储、网络资源，近些年随着网络设备厂商的推动，网络设备管理方面的自动化技术也得到十足的发展。
总结来看，一个企业在进行互联网化的建设初期，就需要考虑到随着用户访问量的增加，资源如何进行扩展。
具体可以细化为规划、建设、管理、监控、运维五个方面。
1.规划模型化
为了确保后续业务能够平滑扩容，网管系统能够顺利跟进，互联网企业一般在早期整体系统架构设计时便充分考虑到标准化、模型化，新增业务资源就好比点快餐，随需随取。
标准化：一是采用标准协议和技术搭建，扩展性好，使用的产品较统一，便于管理;二是采用数据中心级设备，保证可靠性、灵活性，充分考虑业务系统对低时延的要求。
模型化：基于业务需求设计网络架构模型，验证后形成基线，可批量复制，统一管理，也适宜通过自动化提高部署效率、网管效率。
图5.常见互联网IDC架构
2.建设自动化
互联网IT基础设施具备批量复制能力之后，可以通过自动化技术，提高上线效率。
在新节点建设过程中，3～5人的小型团队即可完成机房上线工作。
例如某互联网公司某次针对海外紧急业务需求，一共派遣了2名工程师到现场进行设备安装部署和基本配置，而后通过互联网链路，设备从总部管理系统中自动获取配置和设备版本，下载业务系统，完成设备安装到机房上线不超过1周时间。
要达到自动化运维的目标，建设过程中需要重点考虑批量复制和自动化上线两个方面(如图6所示)。
批量复制：根据业务需要，梳理技术关注点，设计网络模型，进行充分测试和试点，输出软、硬件配置模板，进而可进行批量部署。
自动化上线：充分利用TR069、Autoconfig等技术，采用零配置功能批量自动化上线设备，效率能够得到成倍提升。
图6.批量配置与自动化上线
○ Autoconfig与TR069的主要有三个区别：
○ Autoconfig适用于零配置部署，后续一般需要专门的网管系统;TR069是一套完整的管理方案，不仅在初始零配置时有用，后续还可以一直对设备进行监控和配置管理、软件升级等。
○ Autoconfig使用DHCP与TFTP–简单，TR069零配置使用DHCP与HTTP–复杂，需要专门的ACS服务器。
安全性：TR069更安全，可以基于HTTPS/SSL。
而H3C iMC BIMS实现了TR-069协议中的ACS(自动配置服务器)功能，通过TR-069协议对CPE设备进行远程管理，BIMS具有零配置的能力和优势，有灵活的组网能力，可管理DHCP设备和NAT后的私网设备。
BIMS的工作流程如图7所示。
图7.H3C iMC BIMS工作流程
3.管理智能化
对于网管团队而言，需要向其他团队提供便利的工具以进行信息查询、告警管理等操作。
早期的网管工具，往往离不开命令行操作，且对于批量处理的操作支持性并不好，如网络设备的MIB库相比新的智能化技术Netconf，好比C和C++，显得笨拙许多。
因此使用的角度考虑，图形化、智能化的管理工具，往往是比较受欢迎。
智能化：使用新技术，提升传统MIB式管理方式的处理效率，引入嵌入式自动化架构，实现智能终端APP化管理(如图8所示)。
图8.消息、事件处理智能化
● Netconf技术
目前网络管理协议主要是SNMP和Netconf。
SNMP采用UDP，实现简单，技术成熟，但是在安全可靠性、管理操作效率、交互操作和复杂操作实现上还不能满足管理需求。
Netconf采用XML作为配置数据和协议消息内容的数据编码方式，采用基于TCP的SSHv2进行传送，以RPC方式实现操作和控制。
XML可以表达复杂、具有内在逻辑、模型化的管理对象，如端口、协议、业务以及之间的关系等，提高了操作效率和对象标准化;采用SSHv2传送方式，可靠性、安全性、交互性较好。
二者主要对比差异如表1所示。
表1 网管技术的对比
● EAA嵌入式自动化架构
EAA自动化架构的执行包括如下三个步骤。
○ 定义感兴趣的事件源，事件源是系统中的软件或者硬件模块，如：特定的命令、日志、TRAP告警等。
○ 定义EAA监控策略，比如保存设备配置、主备切换、重启进程等。
○ 当监控到定义的事件源发生后，触发执行EAA监控策略。
4.监控平台化
利用基本监控工具如Show、Display、SNMP、Syslog等，制作平台化监控集成环境，实现全方位监控(如图所示)。
;
