随着企业越来越依赖基于服务器的应用程序和基础设施，服务器成本已成为运营中的一个重大开支。通过实施有效的成本管理策略，企业可以显著控制支出并提高服务器基础设施的效率。以下是一些最佳实践，可帮助您优化服务器成本管理并获得最佳投资回报率：
1. 优化服务器利用率
提高服务器利用率是降低成本的最有效方法之一。通过确保服务器始终以接近容量运行，您可以减少所需的服务器数量并节省许可和维护成本。以下是一些优化服务器利用率的技巧：
- 使用虚拟机：虚拟化技术允许您在单台物理服务器上运行多个虚拟机，从而提高整体资源利用率。
- 负载均衡：负载均衡器可以将请求分配到多个服务器，确保没有一台服务器过载或空闲。
- 自动化工作负载：通过自动化任务（例如备份和软件更新），您可以释放服务器资源以处理生产工作负载。
2. 选择正确的服务器实例类型
选择正确的服务器实例类型对于优化成本至关重要。云提供商提供各种实例类型，具有不同的处理能力、内存和存储容量。选择最能满足您特定工作负载要求的实例类型，以避免为不必要的资源付费。
- 考虑应用程序的性能需求。
- 测试不同实例类型以找到最佳性价比。
- 使用自动扩展功能，以便根据需求自动调整服务器资源。
3. 优化存储和数据库
存储和数据库成本可能会迅速增加。以下是一些优化存储和数据库以降低服务器成本的技巧：
- 使用合适的存储类型：选择最适合您工作负载要求的存储类型，例如块存储、文件存储或对象存储。
- 使用数据压缩：压缩数据可以减少存储空间需求，从而降低成本。
- 优化数据库查询：通过优化数据库查询，您可以减少服务器资源的使用，从而提高成本效率。
4. 监控和分析服务器使用情况
定期监控和分析服务器使用情况对于识别成本优化机会至关重要。通过跟踪以下指标，您可以了解服务器的性能并确定改进领域：
- CPU 利用率
- 内存利用率
- 网络流量
- 磁盘 I/O
使用这些指标，您可以找出利用不足或过度利用的服务器，并对其资源进行优化。
5. 协商供应商折扣
与您的服务器供应商协商折扣可以帮助您节省大量成本。以下是一些协商技巧：
- 比较不同供应商的报价。
- 谈判长期的合同以获得批量折扣。
- 要求积分基于消耗而不是弹性容量。
6. 利用开源软件
使用开源软件可以避免昂贵的软件许可费用。对于许多任务，都有高质量的开源替代品，例如数据库、Web 服务器和操作系统。考虑使用开源软件来降低服务器成本。
- 探索 MySQL、PostgreSQL 和 MongoDB 等开源数据库选项。
- 使用 Apache HTTP Server 或 Nginx 等开源 Web 服务器。
- 考虑使用 Linux 等开源操作系统。
7. 实施节能措施
通过实施节能措施来降低服务器成本。以下是一些技巧：
- 选择节能型服务器。
- 使用虚拟化来合并工作负载并减少服务器数量。
- 关闭不使用的服务器以节省能源。
结论
通过实施这些最佳实践，企业可以显著控制服务器成本并提高效率。通过优化服务器利用率、选择正确的实例类型、优化存储和数据库、监控和分析服务器使用情况、协商供应商折扣、利用开源软件并实施节能措施，企业可以为其服务器基础设施获得最佳投资回报率。
什么是配置管理数据库
配置管理数据库是指这样一种数据库，它包含一个组织的IT服务使用的信息系统的组件的所有相关信息以及这些组件之间的关系。
配置管理数据库提供一种对数据的有组织的检查和从任何想要的角度研究数据的方法。
配置管理数据库的作用及分类配置管理数据库的作用在于：用来收集所有与配置有关的信息；用来评价系统变更的效果；用来为配置管理过程提供管理信息。
而根据配置管理数据库的不同应用，可以分为以下3种。
(1)开发库：它是指专门供给开发人员使用，里面存储的信息可能会作频繁的修改，而且对其控制也相当宽松。
主要是为了更好地适应开发人员日常工作的需要。
(2)受控库：是指在生存期某一阶段工作结束后发布的阶段性产品，通常包括人工制品和机器可读信息{源代码、可执行文件等)。
由于软件配置管理的关键也正是对受控库中的各个软件项进行管理，因此受控库也通常称之为软件配置管理库。
(3)产品库：是指开发的软件产品已经通过了系统测试后使用的配置管理数据库。
它通常存放的是最终产品，等待交付用户或现场安装的产品。
配置管理数据库识别和建立1)确定配置管理的范围建立配置管理数据库，首先要考虑的是IT基础架构中哪些信息需要纳入配置管理的控制、配置项的宽度和深度，以及配置项的生命周期。
配置管理流程作为IT服务的支持流程，IT服务本身也可以作为配置项记录在配置管理数据库中，配置管理数据库与组织IT服务管理水平密切相关。
一方面组织的服务管理水平不断提高，需要配置管理数据库为之提供更详细、更准确的配置项信息，对配置管理数据库的管理要求也随之提高；另一方面，配置项的广度的扩大会造成IT成本的增加，深度的加深又会给IT管理带来一定的难度，因为组织海量级的配置项信息需要实时性和准确性才能对业务服务有所帮助，否则就很难体现出配置管理数据库的价值。
所以组织应该从IT服务需求和配置管理数据库成本平衡角度出发，选择一个能够为业务提供所需基础信息又能将IT管理投资最小化的适合组织发展的配置管理范围。
配置项的生命周期应该从采购申请开始到报废销毁结束。
所以组织需要确定一个配置项信息被记录到配置管理数据库和从配置管理数据库中被删除的时间点，为配置管理审计提供支持。
2)配置管理数据库基线配置管理数据库的信息由配置信息基线和变更集组成，基线备份分为两种：·基于数据库的定期备份制定备份策略，备份代理定期或者适时连接备份服务器，将配置管理数据库备份到备份服务器上的备份库中。
作为某个特定时刻配置管理数据库状态的快照，当配置信息遭到破坏或丢失时，配置管理数据库可以恢复到故障前最近的完整状态，提高系统资源的安全性和抗毁性，将灾难带来的损失降到最低。
·基于变更内容的备份对配置项的修改来自于变更任务，在每次实际修改过程中，自动备份配置项的修改前内容，作为变更前版本，修改后内容作为配置项的当前值，保障配置项历史信息的回溯和查询。
3)确定配置项的颗粒度配置管理数据库能否为业务服务提供良好的支持，很大程度上取决于配置项的详细程度，组织应该制定所有配置项分类的颗粒度范围，配置项颗粒度太粗会导致配置管理数据库无法为其他流程和业务服务提供支持，同时会影响到配置项之间的关联关系。
举例来说，如果网络设备中以一个交换机为配置项，当交换机上的某一个端口发生故障时，无法立刻定位影响到哪套信息系统，只能说和这台交换机有关的业务可能都受到了影响，这就无法体现配置管理数据库的价值所在。
但是配置项颗粒度如果太细，就会造成配置管理数据库管理人员的巨大压力，会大大增加IT运维成本。
就刚才的例子来说，如果反之网络设备的配置项细化到每个交换机的端口都是一个配置项，那么当它发生故障时，的确能够很快根据配置管理数据库中的信息定位到受影响的业务系统，并且能够确定影响程度和范围，但是一个组织若有上百台甚至上千台的交换机，每天仅端口信息的修改就会给组织的人力、物力带来很大的压力。
所以如何定义配置项的颗粒度对于配置管理数据库的使用和价值体现都起着决定性的作用。
4)确定配置项的属性内容一个配置项的属性内容决定了它能为其他流程服务提供的具体信息，但是一个配置项的属性可能有成百上千个，选择找到适合配置项自身需求的属性、最有用的信息，就能够大大降低维护信息的成本。
一个配置项属性的定义要具备面向服务的特性。
例如一台服务器有很多属性，但是可能对于某个组织来说，只有IP地址、内存、CPU等信息是有实际意义的。
5)建立配置项之间的关联关系配置项的关联关系对于处理事件、问题，确定变更的影响范围和程度以及对服务可用性的预测起着很大的帮助作用。
配置项之间的关联关系可以分为四种，属于、包含、对应和连接。
组织可以采用两种方式对配置项关联关系进行整理，第一种方式是自上而下的方式，即按照“业务服务→IT服务→IT系统→IT组件”的模型定义配置项关联关系，这种模式的优点在于以业务为主线能够快速建立起所需要的配置项关联关系模型，但是很难建立完整的配置管理数据库。
另一种方式是自下而上的模式，即先建立组织内部的所有配置项和配置项关系，然后逐步映射到相应的业务服务。
这种模式的优点在于能够建立全面的配置管理数据库，为配置管理日后发展打下扎实的基础，但是建立周期较长，企业会在配置项的建立上花很多的时间。
6)配置项状态配置项的状态共分为以下四种。
·新申请状态：当对于新增配置项的变更请求还未经过评估和批准，需要在配置管理数据库中记录该新增配置项时，其状态为“新申请”。
·准备状态：新增配置项的变更请求已经经过评估和批准，但是配置项还未投入正常使用，其状态为“准备”。
·运行状态：配置项在正常使用，其状态可置为“运行”。
·报废：当配置项已经被撤销，不会再使用时，将状态置为“报废”。
7)配置项的命名规范每个配置项都应该有唯一的配置项编号，建议组织在制定配置项命名规范时，能够充分考虑编号的可扩展性和易记性，同时从编号中能够反映一部分的配置项信息和关联关系信息，为配置项管理员提供帮助。
8)配置项和流程的关联变更、事件、问题管理流程都会牵涉到配置项的更新，同时配置项信息也为IT服务管理流程提供帮助，这就需要配置项能够和这些流程紧密结合。
配置管理数据库的标准一个高效、好用的配置管理数据库(Configuration Management Database，CMDB)需满足以下6条重要标准，即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。
车辆制造商、大型零售商、银行这些全然不同的企业之间有什么共同之处？答案就是它们都需要IT，或者更准确地说，它们都要遵循IT基础架构库(ITIL)服务管理的最佳实践，采用自动化IT管理解决方案以实现重要的业务目标，包括减少服务中断、降低成本、提高IT效率、促进法规遵从等。
实施ITIL最佳实践的核心就是配置管理数据库(CMDB)。
CMDB将IT基础架构的所有组件储存为配置项，它不仅能维护每个配置项的详细数据，而且能维护各配置项之间的关系数据。
同时，CMDB还能维护各配置项中包括其事件和变更历史在内的管理数据。
通过将这些数据整合到中央存储库，CMDB可为企业了解和管理数据类型之间的因果关系提供保障。
更为关键的是，CMDB可实现IT服务支持、IT运维及IT资产管理内部及三者之间的流程整合与自动化，为业务服务管理(BSM)这全面、统一的IT运行平台奠定坚实基础。
业内普遍认为，一个精心架构的CMDB能为IT部门奠定坚实的基础，提高服务基础架构的透明度、可靠性以及可控性，并能自动化服务的配置管理，同时确保IT运维持续遵从企业政策、政府法规、行业标准和最佳实践。
当然，为实现这种高水平的集成度和自动化，CMDB需满足以下六条重要标准，即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。
联合CMDB提供IT环境的单一、准确的信息源，因此，可以将它看做是一个记录IT基础架构数据的中央存储库。
但是，将所有基础架构信息存放在一个数据库中很难实现，因为基础架构的类型、各类元素类型及管理数据的类型种类繁多，且各数据类型中也存在着不同的粒度水平。
比较可行的方法是将各个CMDB和其他的数据存储统一到ITIL所定义的配置管理系统(CMS)中。
这样，根据IT基础架构和运维管理的不同功能所创建的各个CMDB数据集将共同形成一个整体的企业CMDB。
统一多个数据存储需要采用一种联合的方法，并且在创建企业CMDB架构时就需设计考虑到这种联合方法，而不能事后补入。
建立在联合架构中的CMDB能接入广泛的信息，而无需将所有数据移动或复制到CMDB中。
为确保该方法有效实行，整体企业CMDB中的各个数据存储必须清晰地隶属于不同的功能领域，且满足数据交换、数据核实和数据访问三方面要求。
比如，在一家大型服装零售店里， CMDB存储了IT环境的基本信息，并为其他关键、详细的数据存储提供索引。
配置项关系和管理信息使工作人员能够将资产与事件和问题相关联，理清事件之间的相互关联信息，从而能从根源上分析事件和问题产生的原因。
通过联合方法，CMDB向工作人员提供所需信息，让他们更有效地管理资产生命周期。
这将有助于确保企业不会浪费资金，继续支持维护历史遗留系统。
采用联合方法的一项关键要求是具备强大的数据整合能力，以确保多源数据的准确性和一致性。
数据整合不仅能消除重复数据，使各部分有且仅有一个配置项，还能确保多源数据连接到正确的配置项。
灵活的信息模型定义CMDB信息模型有两种不同的方式。
一种是自上而下，即先有一个宏观的企业视图，然后在CMDB中为该视图部署一个元数据模型，然后确保所有管理应用程序符合元数据模型。
另一种方式是自下而上，即把低层的数据集进行标准化，依此开发元数据模型。
大多数IT机构会选择自下而上的方式。
因为采用这种方式，现有的管理数据集能轻松地并入元数据模型中，减少部署工作，加快产生价值。
由此产生的元数据模型与具体的管理功能和应用无关，因而比实际的低层次数据集更易操控，而那些低层次数据集则受制于具体应用所引发的具体管理功能。
自下而上方式的另一项优点在于它更易被接受，因为与自上而下的方法不同，它无需破坏企业的组织架构和文化。
精心架构的CMDB可同时支持这两种方式，满足IT要求并提供部署CMDB所需的IT灵活性。
标准合规联合架构包含多个CMDB，也就意味着出现多个数据集，因此必须实现各个CMDB之间及数据集之间的互操作性。
这就需要标准化的数据交换机制，以确保数据准确，保护数据安全，实现有控制的访问。
所以，CMDB架构需在网络服务方面支持如XML和SOA等开放标准。
通过标准支持，可实现不同数据存储之间的相互操作，同时确保数据不违反IT部门为其企业CMDB开发的元数据定义的整体性。
支持内置策略精心架构的CMDB可以涵盖策略、记录服务及服务相关辅助组件的创建、更新、实施、持续合规追踪等环节中用到的标准。
这些服务可以是应用、中间件、系统可用性、数据库、网络设备和操作系统等。
服务相关辅助组件可以是网络服务器、数据库服务器、应用服务器、网络设备、客户机等。
标准中必须包括数据集的详细信息，如配置、安装、性能和运行时间。
策略可能是动态的，并且可能因时间、用户数和服务水平协议(SLA)等因素而变动。
精心架构的CMDB还可包括流程模型。
由于IT环境通常随时间变化而发生变更，因此这些流程模型必须也是动态的，以自动适应这些变更。
由于能够包含策略和流程模型，CMDB在基于策略的流程自动化中发挥着十分重要的作用。
这种自动化能大幅加快流程执行，同时执行最佳实践流程应用。
例如，一家专注于卡式支付交易服务、电子支付系统和国际金融信息的基础架构服务供应商应用了CMDB之后表示，CMDB可以帮助IT部门在极短时间内高质量高水平地执行所有发布、变更和SLA管理等主动的、前瞻性的流程。
自动发现CMDB需自动发现IT基础架构中的所有资产及其详细信息、各项资产之间的物理和逻辑关系，以及资产与其支持的服务之间的关系。
联合方法可以支持自动发现，因为该方法能获得基础架构中任何一项组件的详细信息。
已经有一些领先的企业选择了自动化工具来发现IT环境中的配置项并将其反馈到CMDB，这些工具还能捕捉组件之间的逻辑依赖关系，并识别哪些IT组件包含企业应用。
传统上，IT利用自动发现功能快速传播库存信息。
最新一代的自动发现方案还可定期扫描IT环境，提供特定组件在不同时间点的实时配置信息。
对于任何针对组件及其支持的服务所进行的分析而言，实时发现加之按时间顺序产生的一系列实时信息，将有着十分重要的意义。
严格的访问控制在IT领域，未经授权或未预料到的访问和变更会导致服务中断或宕机。
因此，安全和访问控制在CMDB设计和部署中发挥着必不可少的作用。
访问政策可用于用户和工作群创建资料介绍和访问控制。
CMDB必须符合安全标准，以防止对数据集执行任何未经授权的变更。
这些标准可以通过目录进行归档，以确定各个数据集的各自授权访问人员，以及访问人员的数据集操作权限。
CMDB具有这种内置的、基于角色的访问控制之后，就可以通过目录访问权限来实现用户身份验证。
配置管理数据库的标准为了确保CMDB项目实施的成功，防止不必要的项目拖延，企业在实施配置管理数据库（CMDB）时应该有一些预防措施，本文提出了6个方面的缺陷，企业在实施CMDB时应该极力避免。
缺陷1:不能识别CMDB的目标和收益CMDB管理着企业环境内的众多配置项及其关系，这些配置项可以是服务、软件、硬件、系统、操作系统、应用程序、数据库、流程文档、安全文档、网络组件等。
在不同的企业之内，这些特定的配置项的重要性是不同的。
CMDB不能也不应该管理企业内的每个资产、文档或流程。
每一个企业都不应该对自己的配置项的特定目标和利益视而不见。
如果知道CMDB如何应用，比如理解变更的影响，就可以基于CMDB购买和实施的成本，对项目的目标进行成本－利益分析和衡量。
清楚地定义短期目标和长期规划，对于CMDB项目的初期开展很关键。
如果不能合理地定义目标和量化投入产出比（ROI），你的方案就很难得到管理层的同意。
缺陷2:让CMDB成为一个元数据的倾销库为了获得最大的业务价值，要认识到CMDB中什么可以管理与什么应该管理两者之间的区别。
一些企业在发起实施CMDB时，有时候会不加区别地将所有来自配置项（CI）仓库的数据全部输入到CMDB，而未能进行充分地关系文档化或者是对配置项的变化进行管理。
CMDB应该只包含那些计划将要积极去管理的配置项。
如果将所有的数据都倒入CMDB之中，没有一个规划，企业就会身处一个难以管理且价值不大的知识库之中。
缺陷3:忽视变更管理的需要如果没有一个有效的变更管理流程，CMDB将很快就会与现实不同步。
因此，CMDB和配置管理流程必须与变更管理流程紧密结合在一起。
只有经过认可的变更可以进入CMDB，只有作为变更请求（RFC）的一部分的配置项才能进行更新。
如果不能满足这些要求，CMDB的实施将会陷入一个向下的螺旋，直至失败。
缺陷4:不能获得利益相关者的支持CMDB实施在企业之内会有很多接触点。
与配置项相关财务、能力和可用性等属性都要求从分离的不同部门输入，如果关键的利益相关者从一开始就没参与，如果他们不能得到CMDB能为组织交付的真正价值，那么要让他们支持一个包含所有必要的属性和关系的CMDB的建设会很困难。
因此，在CMDB项目的开始，就要努力获得关键的利益相关者的支持。
要向他们表明，CMDB将会使得他们持续不断地改善相关指标和关键绩效指标（KPI），这样你就能得到所有相关方面的支持。
缺陷 5: 难以更广泛地实施在项目开始之初就能对其进行有效的引导和控制，比如说一个被清楚定义的业务服务的实施，这对于项目的成功是关键的。
首先要确定支持业务服务的配置项，如应用服务器、网络服务器、路由器、数据库和数据库服务器等，然后就要确定在这些配置项之间存着什么类型的关系，比如说是“依托运行”、“主机”、“连接”、“管理者”等。
这些关系有助于理解和降低与组成服务的配置项的变更相关的风险一旦CMDB按照这样的做法初步成功实施，企业就可以考虑扩展项目的范围，以一种有效且高效率的方式来管理更多的配置项。
这种渐进的方法可以让企业迅速地实现价值，同时还会获得进行更广泛实施所需要的经验。
缺陷6：在流程和培训的投入上吝惜CMDB的成败取决于使用和维护它的人，如果这个人没有经过合理使用和维护流程的培训，那么，CMDB将会是低效的，其中的内容很快就会变得过时和不准确。
正确的培训也有助于确保一个成功的实施，以及一次值得付出的投资。
能够避免以上六个方面错误的企业将会安全地完成CMDB的实施，并提高成功的可能性。
这意味着他们能以更低的成本为业务提供所需要的服务，同时还能确保这些服务在一个符合要求的绩效水平上运行。
参考文献配置管理数据库专家网.王俊 胡呈炜 郑迪主编.系统分析师案例分析与论文指导.人民邮电出版社,2007.4.侯维栋主编 认证与实践.清华大学出版社,2010.01.企业配置管理数据库CMDB选型的六大要点.配置管理数据库实施六忌.
项目管理中如何成本管理
要做好项目的成本管理，可以采取以下几个关键步骤：
互联网时代的网络自动化运维
互联网时代的网络自动化运维
互联网上有两大主要元素内容和眼球，内容是互联网公司(或称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等，制作平台化监控集成环境，实现全方位监控(如图所示)。
;
