华云银安是一家致力于保障信息技术基础设施系统安全、稳定、持续运行的增值产品与服务的专业化公司；是一支以年轻高科技人才为骨干的科技队伍。公司提出的“更优解决方案的提供者,更好服务的支持者,更专业需求咨询的研发者”新世纪架构IT理念，越来越成为业界公认的发展方向。通过与IBM、HDS、ORACLE、CISCO、DELL EMC、F5、NetApp、VMware、华为、华三等国际著名IT厂商的深层次合作，在政府、金融、企业的办公自动化、社会保障系统、商业、银行、电信、移动等应用领域成为业内知名的解决方案提供者。

华云银安已有超过2+年的IT服务历史，目前向全国多家客户提供IT基础设施设备及IT服务外包与应用系统运营支持服务，客户涉及制造、电信、银行和保险等行业。

华云银安依靠强大的技术储备，在电信业、金融业、证券业、广电业、政府、制造业、教育业、医疗、新兴产业都拥有广泛的客户群，华云银安在这些行业拥有极高的商业信誉，积累了丰富的IT运维服务、应用软件开发和系统集成的成功经验。我们以不可妥协的正直原则与增值理念从事经营活动，以坦率、诚实与人合作赢得客户的信任。希望用我们的汗水化做雨露创造自身生命的奇迹，用真诚作桥梁与用户合作共赢，共同建筑理想的长城。

1.1 服务理念和宗旨

• 服务理念：  为了一切客户、为了客户一切、一切为了客户；
• 服务宗旨：  团结高能团队、致力于传播与创造、旨在保障信息技术基础设施的安全、健康、永续运行的产品与服务、为改善民族组织信息系统的效能与国民福利而奋斗；
• 服务精神：  永不抱怨、勇不放弃，内在蓬勃、外在和谐；
• 三个有利于：凡是有利于客户的、凡是有利于公司的、凡是有利于个人的，都是我们努力的方向；

我们相信没有客户的满意就没有公司的发展，没有为社会付出就没有合理的回报 ，没有整体的卓越就没有个人的成功。

• 优良的服务习惯：

a、以客户为中心，服务细致、周到；

b、办事有始有终，时间安排合理；

c、服务响应迅速，解决问题快捷；

d、用心倾听客户声音；

e、守信，切实实现每一个承诺；

f、事前预约，事中记录，事后总结。

1.2 服务资源

IT服务是社会分工不断细化和IT技术发展的产物。华云银安在信息技术支持与服务领域有着丰富的实践经验和良好的信誉，以及雄厚的技术资源。多年来，华云银安已经成为多家企业的资源运营伙伴，它们涉及制造、电信、银行和保险等行业。

华云银安的服务具有7×24×365的技术支持服务能力和充足的备件保障体系，在全国范围内拥有1个直接支持服务中心（呼叫中心），在北京公司总部配置专业技术服务支持力量，拥有10+名硬件、软件及网络工程师和多名高级技术专家工程师。在重大事件处理过程中，可以获得原厂商的售后支持。从而形成了三级技术支持体系和四级故障分级处理流程，充分保障客户业务系统的业务连续性、数据安全保护，全面实现客户服务协议SLA的达成。

1.3 服务范围及内容

自九十年代以来，随着企业对高可用性系统以及分布式系统的需求越来越明确，高额的系统管理和维护费用以及专业技术的缺乏也为企业带来了困扰。既要满足商业目标又要控制IT费用，如何才能找到二者的最佳结合点，这使众多商家一度深感困惑。长此以往，势必会阻碍业务的进一步发展。还有一个不能忽视和回避的问题是，很多公司在招收IT服务人员之后，为了进一步提高业务素质和水平，不惜耗费大量的人力、物力和财力进行业务培训，但培训之后的人员一旦流失就会给公司造成巨大的经济与技术损失。因而，出于市场竞争的需要，全球各大企业纷纷将自己的部分IT业务外包给专业IT厂商，形成了资源外包的新趋势。华云银安及时发现企业的需要，与IBM、HP、HDS、ORACLE、CISCO、DELL EMC、SAP、HDS、NetApp、VMware、华为、华三等建立全面合作伙伴关系，积累了丰富的产品经验，走在了同行业的前列，并在实践中总结出大量的适合中国国情的IT服务经验，以及全系列的IT服务资源。

服务简介

上云迁移服务是基于XX（以下简称“客户”）提供的源端信息，由华云银安行迁移方案设计和实施的专业服务。

本服务工作说明书可作为《上云迁移专业服务合同》的附件模板，对项目的工作范围、合同双方工作界面以及完成条件作了基本约定，如与《上云迁移专业服务合同》的条款和条件相冲突，以《上云迁移专业服务合同》为准。

服务范围

本项目华云银安服务包括以下内容：

• 根据双方澄清的待迁移应用和数据范围，为客户提供重新部署建议、主机、数据库和数据迁移等方案设计和实施服务。
• 在约定范围内的业务切换上华为云时，为客户提供华为云基础设施保障服务。

本项目上云迁移服务不包括以下内容：

• 客户应用软件和数据库的设计、改造。
• 客户应用软件和数据库的安装部署。
• 云平台基础架构设施设计与环境搭建。
• 迁移实施所需的通信基础组件。
• 未明确认定在“范围内”的应用系统、数据库及数据迁移。

服务内容

服务内容	服务说明
迁移方案设计	评估业务系统、数据库、存储数据等信息，提供业务迁移方案，包含云上组网规划、基础环境部署、应用主机迁移、数据库迁移、存储数据迁移等方案，协助客户完成业务切换方案。
组网实施	协助客户完成专线、虚拟专用网络（VPN）、虚拟私有云（VPC）内网、安全组、ACL等部署实施。
基础环境实施	根据上云方案，协助客户完成云上基础设施方案的实施，如协助客户进行ECS、RDS等资源购买与开通。
主机迁移	实施主机迁移方案，将应用主机的操作系统整体迁移至华为云。
数据库迁移	实施数据库迁移方案，协助客户完成全量与增量数据库迁移实施。
存储数据迁移	协助客户，实施全量与增量数据迁移，协助客户验证全量与增量数据迁移的效果，完成云下存储数据到云上存储数据的割接。
业务切换保障	在客户实施业务切换上华为云时，提供华为云基础设施的保障。

服务流程

项目启动会 -> 项目调研 ->规划设计 ->迁移实施 -> 项目验收

责任分工

上云迁移项目各阶段分工界面如下（S：Support支持方 R：Responsibility 责任方）。

上云迁移过程责任分工

• 共同责任双方商定并确认具体业务目标及范围，并完成团队组建、需求分析、计划制定和迁移演练。

• 客户
  • 指派项目负责人，负责客户侧的协调和管理，组建客户侧项目团队。
  • 提供迁移方案设计和实施所必需的源端信息和相关授权。
  • 项目实施过程中，如客户提供的第三方软件，负责协调第三方厂商，协助华云银安解决问题。
  • 负责业务验证、切换、监控和项目验收。
• 华云银安
  • 协助客户进行源端信息收集、云上方案规划设计和测试验证。
  • 负责迁移风险评估，迁移策略制定和迁移方案设计，输出《xx项目迁移方案》。
  • 根据《xx项目迁移方案》进行迁移演练和实施。
  • 输出《xx项目迁移验收报告》并提交给客户。
• 免责说明
  • 在实施过程中，非华云银安原因导致的第三方设备或系统故障。
  • 客户须保证其安装、使用的操作系统、应用软件不侵犯任何第三方的知识产权或其他权益。如因违反前述约定所导致的第三方索赔，客户应承担全部责任，华云银安免于罹受任何损失。

验收标准

满足以下条件启动项目验收：

• 华云银安已提交《xx项目迁移方案》。
• 华云银安完成约定范围的迁移设计与实施，切换后业务稳定运行5个工作日。
• 华云银安已提交《xx项目迁移验收报告》。

上述《xx项目迁移验收报告》提交后，客户应在5个工作日内进行验收确认。

项目完成

验收通过，客户以签字盖章（含电子件）《xx项目迁移验收报告》或者官网点击验收确认，上云迁移专业服务工作结束。

主机迁移服务（Server Migration Service）是一种P2V/V2V迁移服务，可以帮您把X86物理服务器，或者私有云、公有云平台上的虚拟机迁移到华为云弹性云服务器（ECS），从而帮助您轻松地把服务器上应用和数据迁移到华为云

一、主机迁移服务的工作原理

1. 用户在源端服务器上安装迁移Agent。
2. 源端服务器上的迁移Agent向主机迁移服务注册自身连接状态并将源端服务器信息上报到主机迁移服务，完成迁移可行性检查。
3. 用户创建迁移任务。
4. 迁移Agent获取并执行主机迁移服务发送的迁移指令。
5. 迁移源端服务器系统盘。
6. 迁移源端服务器数据盘。

图1 主机迁移服务工作原理

二、主机迁移服务的功能

2.1、迁移可行性校验

当您在源端服务器上安装了迁移Agent，且输入华为云AK/SK校验通过后，迁移Agent会收集源端服务器信息并发送给主机迁移服务，主机迁移服务会校验源端服务器信息合法性以及是否可迁移，校验的结果您可以在主机迁移服务的“源端管理”界面查看。

2.2、Windows 迁移与同步

如果源端服务器是Windows OS且通过迁移可行性校验后，您可以在主机迁移服务界面上创建迁移任务并启动。任务启动后，源端服务器中的迁移Agent会向主机迁移服务获取迁移指令并且执行，执行时迁移Agent会识别源端服务器分区的有效块，并把有效块传输到目的端服务器对应分区，传输完成后，目的端服务器会修改系统注册表等信息以适配华为云，修改完后系统会重启完成迁移。

迁移完成后，如果源端服务器仍有新增业务数据写入，这时您可以在原有的迁移任务上启动同步任务，源端服务器上的迁移Agent会把新增的数据同步到目的端服务器，同步完后会重启。在同步过程中，建议停止源端服务器上的业务，且在同步完成后进行业务切换（割接），否则需要进行多次同步。

2.3、Linux 迁移与同步

如果源端服务器是Linux OS且通过迁移可行性校验后，您可以在主机迁移服务界面上创建迁移任务并启动。任务启动后，源端服务器中的迁移Agent会向主机迁移服务获取迁移指令并且执行，执行时迁移Agent会调用Linux的开源组件把源端服务器的目录及文件传输到目的端服务器，传输完成后，目的端服务器会修改系统的启动项等信息以适配华为云环境，修改完后系统会重启完成迁移。

迁移完成后，如果源端服务器仍有新增业务数据写入，这时您可以在原有的迁移任务上启动同步任务，源端服务器上的迁移Agent会把新增的数据同步到目的端服务器，同步完后会重启。在同步过程中，建议停止源端服务器上的业务，且在同步完成后进行业务切换（割接），否则需要进行多次同步。

2.4、动态安全传输通道

源端服务器中的迁移Agent从主机迁移服务获取到迁移指令后，会动态生成安全证书和密钥并且通过华为云OpenStack 元数据管理服务传输给目的端服务器，此后，目的端服务器会重启并使用新生成的动态安全证书建立安全的SSL通道。

图1 安全传输通道

三、主机迁移服务的优势

• 简单易用
  • 您只需在源端服务器安装和配置Agent、在服务端创建迁移任务，其余事情都由主机迁移服务处理。
  • 创建迁移任务您只需三步。即选择和配置源端、目的端及确认任务信息。
• 业务平滑切换在主机迁移过程中您无需中断或者停止业务，只需在最后一次数据同步时短暂的停止业务，待最后一次增量数据同步完成后，目的端的业务即可启动，大大减少业务中断时间。
• 兼容性好
  • 支持国内外主流公有云、私有云平台虚拟机迁移，和X86物理服务器迁移。
  • 支持约90款主流Windows Server与Linux Server OS迁移。
• 传输高效
  • 支持块迁移，且能够识别有效块数据并对其进行迁移。
  • 迁移网络利用率达到90%以上。
• 安全性高
  • 使用AK/SK校验迁移Agent身份。
  • 传输通道使用SSL加密，保证您数据传输安全性。
  • SSL加密的证书和密钥是动态生成。

四、主机迁移与其他服务的关系

将源端服务器的系统、应用和文件等数据迁移到华为云弹性云服务器。	弹性云服务器（Elastic Cloud Server，ECS）	如何创建弹性云服务器？
创建迁移任务过程中支持采用公网迁移，要求目的端服务器配置有“弹性IP”。	弹性公网IP（Elastic IP）	主机迁移的网络安全配置与条件有哪些？
在创建迁移任务前，通过虚拟私有云设置您目的端弹性云服务器所在VPC的安全组。	虚拟私有云（Virtual Private Cloud，VPC）	如何配置目的端服务器安全组规则？
迁移任务创建并启动后，主机迁移服务会创建一块临时按需计费EVS卷，迁移完成删除该临时卷。	云硬盘服务（Elastic Volume Service，EVS）	如何购买使用云硬盘
通过云审计服务收集主机迁移服务操作记录，便于日后的查询、审计和回溯。	云审计服务（Cloud Trace Service，CTS）	如何查看审计日志

五、计费说明

主机迁移服务本身不收费，但是在迁移过程中会产生少量其他服务费用：

• 云硬盘费用在迁移期间，每个迁移任务会在目的端服务器临时创建并挂载一个容量为40GB、类型为普通I/O的EVS卷，迁移完成后会释放此EVS卷。有关云硬盘的收费标准，请参见云硬盘价格说明。

• 云硬盘快照费用在迁移完成后，会对目的端磁盘做一次快照，以确保下次同步和源端数据一致。另外，在同步前会对目的端磁盘再做一次快照，保证同步失败时能回滚。云硬盘快照目前免费使用。

华云银安为客户定制最佳云迁移设计，提供调研、分析、设计、评估、迁移、测试、上线等一站式云迁移交付方案，彻底解决客户的后顾之忧。

【摘要】近年来随着银监会《商业银行数据中心监管指引》和《商业银行业务连续性监管指引》等规范的陆续出台，监管部门对商业银行信息系统业务连续性管理提出了很高的要求，特别是要求定期开展灾备切换演练，而随着业务系统架构多样性及复杂性的不断提高，整个切换流程将变得越来越复杂，同时演练中对于流程控制的要求也变得越来越高。以下是针对银行灾备自动化切换平台，社区专家分享的相关难点问题总结，希望能给银行业同行带来一些参考。

1、灾备自动化切换平台产品选型以及注意事项？

【问题描述】灾备切换面临的主要问题除保证RPO的前提下尽量减小RTO外，还包括跨部门指挥协调问题、切换流程进度监控问题、以及众多流程的维护问题。灾备切换时要考虑如何解决这些问题，实现安全有序的灾备切换，这样就需要一款能自动化执行、对所有系统的切换流程可以指挥调度的平台。现在市场上有哪些比较好的灾备自动化切换平台产品？选型过程中应该考虑哪些问题，需要注意些什么？

@梅志荣：

灾备自动化带来的是灾备切换效率的提升，业务RTO减少，人为误操作可能性降低等诸多优势，但是，灾备切换由于可能会涉及到较多的业务系统，业务数据一致性和可用性的要求高，尤其是银行类业务系统，业务类型多，关联关系复杂，实现灾备自动化相对复杂度较高，需要通过业务梳理，权重判定，业务依存关系分析，脚本定制等等繁琐的工作，同时还需要通过实际切换演练，不断优化改进灾备预案。

选择灾备自动化切换平台，建议着重考虑以下几点：

1. 业务系统可以依据用户需求进行灵活定制；

2. 具备模拟灾备切换功能；

3. 提供日志系统和切换回溯功能，发现切换过程中问题所在，并提供改进建议；

4. 友好的图形化用户界面，通过图标拖拽实现复杂系统简单定制。

以上个人观点，仅供参考。

@njtukang：

个人感觉切换自动化工具技术上来说，跟应急自动化工具，运维自动化工具技术上是一致的，市面上很少有一套即插即用的切换工具平台，原因不是技术，而是各行的数据中心，应用系统，现有监控工具，自动化脚本，自动化工具都存在差异和个性化，所以很多都是在产厂商基本组件或者开源组件基础上自主研发。开源流程编排有activity，自动化工具有ansible，mco，saltstack，都有一些优缺点，需要结合自身特点和需求，选择的组件进行搭建和定制化开发。需要注意的点，除了大家都说到的纬度外，我觉得与日常自动化还有两点差别，一个这个工具开发要考虑真实场景，不只是演练场景。第二要考虑工具自身可用性，要避免工具自身受到故障干扰，工具串接的流程步骤也要容错，比如进入故障中心内部进行操作，这个在真实场景下可能无法成功的。

@baidongxu：

由于各个公司业务系统特性不同，IT技术使用各异，很难有一个开箱即用的商业产品能满足要求，都需要在使用过程中总结需求和使用的痛点持续改进。

正如问题所述，解决跨部门协调问题，降低沟通成本，直观展现切换流程，流程数据维护这些都是实际切换过程迫切需求，也是灾备自动化产品选型需要考虑的因素。另外我觉得还需要考虑以下因素：

1 该产品对公司现有IT技术的支持，以及未来发展的支持，如双活技术。

2 该产品性能，是否满足多套系统并行切换的要求。

3 是否满足真实切换和演练功能要求，比如流程单步执行，桌面演练，大屏展现等。

4 系统的可维护性，对于业务系统架构和技术调整，产品的变更是否方便，可追溯。

二、在灾备双活或多活架构中，多系统切换中发生脑裂如何判断并解决？

【问题描述】

背景：灾备体系建设，双活或多活架构
环境：小型机和x86平台，高端存储vmax200，中端存储vnx5500等，数据库db2
现场信息：距离100公里，裸光纤
思考：在灾备双活或多活架构中，多系统切换中发生脑裂如何判断并解决的？
难点：发生站点级别灾难的自动判断依据？

@njtukang：

1、脑裂主要一般说的是一些部件高可用协议层面，两个节点同时认为自己为主节点。在双活架构下，一般数据中心级别切换一般需要人工介入，全部自动化触发同城切换的案例我还没有见到（一方面监控主要、切换工具自身可能存在故障或者误判，并且概率较发生数据中心故障更高。第二，切换过程也包含风险，切换在部分环节需要人工介入）。人工条件下，一般不存在脑裂，是由人工指定主节点，备节点。在人工介入情况下，确实需要保证故障节点不再承载交易，不然会出现数据紊乱。一般可考虑从源头上封禁导向故障节点的流量，也可尝试在故障节点进行关机操作，但是不一定能够成功。

2、站点级建议从业务交易角度判别，因为技术故障场景很多，对于业务的影响也难以第一时间判断。其次，为了防止业务监控的误判，也独立增加一套独立的监控手段，或者可以通过收集客户反馈进行辅助验证。但是全面、快速、准确的业务影响还是依靠监控，一般业务反馈需要时间，汇总，分析以及精准度问题。

@asdf-asdf：

在灾备双活或多活架构中，多系统切换中发生脑裂如何判断并解决的？

需要第三方进行仲裁。

发生站点级别灾难的自动判断依据？

多级监控判断, 或者人为预警了。

@梅志荣：

双活或者多活架构下，当发生数据链路问题时，需要第三方仲裁站点提供脑裂解决方案，通过第三方站点判断是站点间链路问题？还是确实是某个站点发生了灾难。第三方仲裁站点通用的方法是采用仲裁主机，各站点通过iscsi或者其他方式获取仲裁设备。

个人不建议采用自动方式判断站点级灾难，毕竟站点级灾难发生的几率不大，而且决策因素较多，灾备应用软件再怎么智能也不能赋予它决策的功能，否则发生误操作，站点上的业务系统切来切去，搞出的事情就不是简单丢数据了。

个人建议，仅供参考！

三、虚拟化平台的应用级容灾如何实现自动切换？

【问题描述】我司现在所有应用系统都采用了虚拟化技术，现在规划采用存储复制的方式将虚机文件同步到容灾中心，如果主中心出现故障，将采用手工方式启动虚拟化，并通过全局负载均衡实现容灾切换。但不了解如何实现自动方式的切换，并且自动切换是否会带来安全隐患，例如在没有必要切换到容灾中心的情况下出现切换操作。

@asdf-asdf： 

做好业务和虚拟机已经虚拟化的物理机监控，在监控触发业务故障情况下，进行故障分析，需要一个elk平台和故障分析平台。

再次通过监控分析结果触发容灾级别的故障切换，自动化平台承接底层切换过程，包括网络和负载均衡设备的配置。

前提示你有业务监控分析和故障分析平台。

@njtukang：

切换虚拟机的方案有两个问题，不知道解决没有，一个是切换后虚机还保留之前的ip？如果保留，在一套网络里面如何解决ip冲突问题。其次，数据复制都有延迟，这些延迟的数据有哪些，业务是否容忍。在真实故障下，可能没有机会再同步数据。个人建议业务连续性要从业务角度考虑，不一定通过应用切换，甚至虚拟机切换去保证。全量虚机进行迁移，步骤复杂，难度大，失败率高，时间长。

@baidongxu：

vmware虚拟化的srm方案类似您的方法，通过存储复制进行虚拟机文件同步，切换时进行存储角色切换并拉起虚拟机。

如条件允许也可以考虑存储双活，如emc vplex方案，将容灾的工作交给存储负责，虚拟化层基本无感知。

四、灾备系统数量多，如何保证RTO基础上，既要做到灾备切换过程可控还要提高沟通效率，需求分析应该如何做？

【问题描述】考虑到场景复杂，灾备系统数量多，在确保RTO基础上，既要做到灾备切换过程可控，满足多种容灾场景，还要提高跨部门沟通效率，因此对平台建设的需求分析如何做？

@njtukang：

1、结合个人的经验，在灾备系统数量较多的情况，应该以业界连续行管理理论作为指导，首先从业务角度进行分级管理，高等级应用优先保证回复，例如达到几十分钟级别，低等级应用可以容忍恢复时间，在几天内完成。

2、对于灾容场景复杂，场景较多的情况，如果每个都制定预案，预案多，演练多，成本高。依据个人经验，应进行场景和故障域的整合，例如如果存在整体服务器恢复的预案，则可以不需要过多考虑服务器内部某个组件的故障场景。如果做到一个机房模块的快速切换，可能就需要过多考虑一排机柜的故障。如果做到数据中心级别的快速切换，则不需要针对单独一个机房的故障。

@baidongxu：

RTO保障方面可以根据以往的灾备切换经验评估整体和各种场景的切换时间，如果RTO无法保证，可以将业务系统分模块切分，并行切换，同时保证现有模块直接的依赖关系，缩短RTO。

在灾备建设初期就要进行容灾场景设计，容灾场景覆盖大多数真实灾难情况，通过模块化的流程编排满足容灾场景的切换。

灾备建设的一项目标就是提高人员参与程度，降低沟通成本，灾备指挥平台需要实现日常切换过程需要的功能比如集合签到，公告栏，工作台等，对于不同用户设计不同展现视图。

五、银行如何实现业务由生产中心自动切换到灾备系统？自动切换的条件有哪些？如何规划？

@asdf-asdf：

按照系统进行分析，切换条件和切换业务涉及的应用和内容。

网络连接部分按照应用完成切换操作步骤。

存储切换按照应用切换顺序进行规划，完全需要安装切换应用的过程进行每个业务应用切换，前验证切换条件，后验证切换是否成功，自动切换条件一般为网络故障，应用无法连接，存储故障，数据库连接故障，物理机的虚拟层故障等，需要监控进行触发，生产切换到灾备系统需要一个自动化灾备切换软件支持流程操作的系统软件，支持包括网络和存储接口、设备接口openstak接口或者vcenter接口、powervc接口、hmc接口、可包含所有物理机和网络设备以及虚拟设备。规划需要按照自身业务系统进行梳理，业务系统关联性和网络、存储关联性进行详细梳理和分布操作，一般金融行业都有灾备切换操作步骤(手工步骤，安装这个进行详细梳理，绘制流程图，部署到自动化切换软件中，可完成大部分人为操作过程，其它特殊步骤依然需要人为操作。

@baidongxu：

首先业务系统灾备投产时已经梳理了整个切换的流程步骤，并且通过灾备指挥平台调用切换成功。切换动作大概分为存储，操作系统，数据库，应用，网络五个部分。存储通过角色swap从主站点切换到灾备站点，操作系统涉及vg,fs,ip,ha等的启停，数据库和应用涉及相应软件的启停，网络通过操作f5 vs member做到流量更改。

切换条件分为日常演练和真实灾难情况，真实灾难可能有网络故障，主机存储故障，站点故障等，针对具体灾难场景梳理切换流程，比如主机故障那么对应主机操作的步骤可以省略，网络故障对应的f5操作可以跳过。

六、自动化切换如何做到涵盖应用？

【问题描述】自动化切换面对复杂多样的应用启停方式，如何做到包含基础设施和应用系统一起的自动化切换？

@rimp：

应用的灾备切换，这个还是要提前做好应用标准化，比如我行所有系统目前都支持在指定的标准目录使用标准命名脚本实现分步骤或者一键式启停，在实现应用标准化后也能方便接入运维自动化系统方便进行统一的管理。

@baidongxu：

应用启停和检查状态的逻辑多种多样，我们是建立一个启停应用的通用脚本，传入应用启停的脚本，用户，进程关键字，端口号，检查脚本等参数，通用脚本放在服务器自动化平台，由灾备指挥平台调用，具体应用的脚本放在服务器本地，由通用脚本调用，这样我们只负责通用脚本的逻辑。对于标准化的应用，比如weblogic应用我们是要求运维人员填写domain路径，log路径，adminserver监听地址，managedserver监听地址，应用关键字（即server的名字），由通用脚本拼接生成启停命令，不需要运维人员自己编写启停脚本，减少工作量，其他如apache,nginx等也可以类似实现。

七、灾备切换如何处理不同级别的应用？

【问题描述】灾备切换如何处理不同灾备级别的应用，而这些不同灾备级别的应用相互之间还有关联？

@baidongxu：

我理解您说的应用是具体的业务系统，业务系统按照重要程度，灾备级别可能是2:1,2:2或者是双活，目前灾备指挥平台支持上诉场景的灾备切换。

在业务系统灾备上线时，我们会联系负责人梳理参与切换的应用模块范围，尽量保证一个灾备业务系统的闭包，使得应用内部的模块切换不依赖其他应用的切换。如果应用之间确实有依赖关系，我们采用两种方式切换：

1 将有依赖关系的两个或者多个应用作为一个逻辑应用进行切换。但是如果依赖应用过多会导致逻辑应用体量过大，切换时间长。

2 预约切换功能，即灾备切换过程定义具体应用的切换时间来实现有依赖关系的切换。

八、采用存储级同步，双活，还是采用应用的AA模式来实现，是如何考虑容灾方案的？

【问题描述】：

1 对于容灾方案的选择，贵行是如何考虑的？采用存储级的同步技术，双活技术，还是采用应用的AA模式来实现？

2 在您二位关于容灾的设计方案中，容灾的演练（应急手册）是需要实现自动化的。那么这个自动化容灾平台的搭建大致需要多少人力物力？如果我们也想构建一个类似的平台需要什么样的准备？

@baidongxu ：

1 由于我们灾备建设较早，当时还没有成熟的存储双活技术大规模使用，我们使用的是存储复制技术，目前也在考虑存储双活和双主模式。

2 我们是行内人员投入两人AB岗，负责灾备指挥平台设计和业务系统投产，公司人员负责具体开发，指挥平台的系统变更，运维，包括后期业务系统变更带来的指挥平台级联变更，当然变更后还是要桌面演练核对变更准确和系统负责人确认。

灾备指挥平台的建设我觉得应该首先争取领导支持，全面分析目前使用的技术栈，对灾备使用的技术进行评估，存储双活还是复制？数据库复制还是双活？项目初期明确使用的技术，规范业务系统灾备投产条件，避免以后走弯路；其次，技术方面应该争取技术人员全方面参与，单人的技术能力有限，而灾备往往涉及非常具体的技术细节，从组织架构上保证大家积极参与，避免技术上挖坑；任何灾备变更包括开发都应该全面测试，确保通过功能测试、压力测试。

九、两中心数据同步方式应该如何选择？

【问题描述】：

在同城数据中心的建设中，两中心的数据同步是个必须解决的问题，选择何种数据同步方式最稳妥，最安全？目前我所在的单位选用的是存储复制技术，正在调研数据库自带的逻辑复制方式，不知道这类技术是否成熟，会遇到哪些问题？

@njtukang：

1、我看到几个案例是数据库dg+存储复制。数据库复制需要需要分钟级别延迟，存储在同城情况下可以采用最大可用模式，一般情况下实时同步，双中心互联故障下会中止同步，保证主中心交易。

2、数据库自带的复制较为成熟，主要是日常情况rpo较高，但是演练过程中切换或者回切较为简单。

@baidongxu：

存储复制技术目前比较稳定，能够保证RPO，存储双活技术也是灾备的未来方向；数据库方面有自身的复制技术，但是切换过程对技术要求较高。

@asdf-asdf ：

数据库自带的逻辑复制，用过oracle 的 dataguard，db2也有类似技术。文件系统建议用 ibm的 cluster file。因为上面技术都用过最后感觉还是存储复制 运维比较快速部署。

十、银行灾备演练切换频次以及哪些系统进行切换，关联业务如何处理？

【问题描述】：

灾备切换经验问题，每年贵银行灾备演练几次，是采用数据中心级的切换，还是单个业务系统切换，有业务关联怎么处理？

@rimp：

同城的灾备切换是每半年一次，我行是所有系统统一进行切换，如果是负载均衡系统需要进行停单边一周进行业务检验。

异地灾备切换目前是重要信息系统进行切换，每季度进行一次连通性测试。

@baidongxu：

按照监管要求，同城业务系统每三年一次，异地每年一次。

对于具体业务系统，我们每年根据变更安排，改造情况定制灾备切换计划，频次高于监管要求。

关联业务系统我尽量安排在同批次切换。

云平台的特点是快速部署、弹性伸缩、动态调整、运维自动化，对应的监控也需要是动态发现、自动化部署的，因此对监控的要求会更高。在案例 基于 Prometheus 和 Zabbix 实现容器云平台整体监控方案中，基础监控是以Zabbix为基础监控工具设计和建设，鉴于Prometheus对docker和k8s监控的天然集成，引入Prometheus和Zabbix结合起来，Prometheus只负责docker+K8S基础监控数据采集, Zabbix负责容器内应用监控数据采集，采集的数据集中接入Zabbix进行告警触发，并复用基于Zabbix开发的潜望者Zabbix运维管理平台，集中进行监控配置管理、阈值管理、巡检管理、数据对接等工作，大幅减少基于prometheus的定制开发工作，实现快速实现、高效部署的云平台整体监控

1、刚接触prometheus，请教一下关于部署方式的问题？

【问题描述】请问目前prometheus+zabbix这个解决方案，是通过K8S上pod直接部署还是通过独立的服务器软件包安装部署？两种方式如何选择？

@zhangfan13cmbc 中国民生银行 项目经理：

通过K8S上pod部署。

每个 K8S 集群上默认部署 prometheus ，在 K8S 集群内部署 prometheus server 和 kube-state-metrics 两个组件。

@zftang0809 合肥华宇随身软件 软件开发工程师：

一、单独部署

二进制安装

各版本下载地址：https://prometheus.io/download/

Docker运行

运行命令：docker run –name prometheus -d -p 127.0.0.1:9090:9090 prom/prometheus

暴露服务：http://localhost:9090/

二、在K8S中部署

如果在Kubernetes中部署Prometheus，可以使用prometheus in kubernetes，含exporter、grafana等组件。

2、为什么要复用zabbix 而不直接使用promethues+grafana这种模式？

@zhangfan13cmbc 中国民生银行 项目经理：

该案例中基于zabbix做了大量的二次开发，包括自动化部署、自巡检、批量配置等等，如果再另外维护一整套promethues功能，成本太大，而且重复建设，因此，只把promethues作为标准采集工具，复用zabbix的管理功能。监控数据有专业定制化的集中监控平台进行存储和消费，因此没有使用grafana。

3、zabbix-promethues和 promethues-grafana相比优势在哪？

@zhangfan13cmbc 中国民生银行 项目经理：

zabbix和promethues都是开源监控工具，它们的使用是一个互补和结合的关系。

promethues和grafana的关系是监控工具和页面图形工具的关系。

所以这个不太好比较。

4、prometheus+grafana是现在流行的方案，能否实现监控大盘？

【问题描述】grafana的数据展现没有层次，所有的dashboard通常是单层，用list来切换，granfana中有没有做到可以挖掘的功能，也就是实现监控大盘的功能？从表层可以向里层挖掘显示？如果不能，有没有可以取代grafana的工具来对接prometheus？

@nexpose 阳光信保：

grafana 它的BI组件的灵活度和对各种数据源的支持是它最大优势，它的标准组件是为了兼容各种数据源而服务的，Dashboard 这种要求大屏首页的震撼感，对组件的特效要求较高的场景，多数效果需要专门定制开发以满足大屏特效，满足行业特殊需求。grafana的图表组件某种程度上更适合Dashboard数据深钻时二级图表的呈现（但是其实grafana 也能开发出拥有特效的BI组件，我们就将D3部分组件移植了进去，但是目前只支持ES）

5、zabbix和Prometheus如何对容器数据库的监控？

@zhangfan13cmbc 中国民生银行 项目经理：

按照容器监控的内容，分为 docker+K8S 基础监控和容器内应用监控两部分来分别实现。

1、docker+K8S 基础监控的实现：

由于 prometheus 对 docker 和 k8s 监控的天然集成，通过 cAdvisor 可以直接获取 docker 基础监控数据，通过 kube-state-metrics 可以直接获取 K8S 的资源对象和对应监控数据，因此在每个 K8S 集群上默认部署 prometheus 实现这部分监控采集，然后通过 Zabbix Http Agent 方式调用 prometheus API 来获取数据，接入 Zabbix Server 从而复用之前建设的功能，实现后续的告警阈值配置和数据接入集中监控平台。

2、容器内应用监控的实现：

所有的应用监控都通过 Zabbix 实现，这里的“应用”可以是数据库、中间件、也可以是某个应用系统，通过在容器中增加环境变量 monitor_type 来定义，比如 monitor_type=mysql 就代表这个容器的“应用”是 mysql ，将对它进行 mysql 监控。

6、Prometheus采集是怎么实现主备的，历史数据怎么处理？

@zhangfan13cmbc 中国民生银行 项目经理：

目前部署在K8S的master节点上，单POD，利用K8S的高可用机制确保服务连续性。历史数据是通过zabbix接入推送到KAFKA里，供集中监控数据消费并存储

7、Prometheus是怎么做到可扩展的？超出单个Prometheus的采集能力，如何做自动分工？

@郭晓云 平安 系统运维工程师：

采用thanos的集群方案和conusl的注册中心，在注册中心中给每个机器划分组，每台prometheus交叉监控，也就是说每一台服务器保证有两个prometheus server取数据，这样可以横向扩容。

8、prometheus能够监控的内容非常丰富，是不是大部分功能可以取代zabbix了？

@郭晓云 平安 系统运维工程师：

prometheus是组件式的，在使用方面来看各有所长，从功能上来讲是可以取代zabbix的，只是组件多了之后运维更复杂。

@zftang0809 合肥华宇随身软件 软件开发工程师：

各有所长，各取所需。

9、请问如果是多云多集群环境如何进行监控部署？基于prometheus + Thanos的部署是否实践过？优缺点是什么？

@zftang0809 合肥华宇随身软件 软件开发工程师：

具备较好的高可用性，缺点我觉得是Prometheus集群无法拆分。

10、Prometheus监控较大规模kubernaetes集群时需要注意哪些方面的问题？

@zftang0809 合肥华宇随身软件 软件开发工程师：

本质上还是kubernetes中内置了一些exporer, prometheus 可以通过http请求抓取数据。

11、prometheus采集的数据如何接入Zabbix进行告警触发及展示？

【问题描述】1、在已有zabbix的监控体系下引入prometheus的优缺点 ，zabbix不能很好的实现哪些功能；2、zabbix如何对集群的应用进行有效的告警及展示；3、prometheus与zabbix如何分工，可否只引入export；4、prometheus推荐配置；5、如何自动的、批量的添加prometheus的数据到zabbix；6、两套监控系统是否会对运维造成较大的运维成本？请各位专家不吝赐教，谢谢。

@zhangfan13cmbc 中国民生银行 项目经理：

详见  基于 Prometheus 和 Zabbix 实现容器云平台整体监控方案 

12、请问prometheus+zabbix场景下，监控数据的存储是如何考虑的？是prometheus自身的持久化还是统一由zabbix的数据库存储？

@zhangfan13cmbc 中国民生银行 项目经理：

鉴于之前在Zabbix上做的二次开发成果，所以选择统一由zabbix持久化，通过 Zabbix Http Agent 方式调用 prometheus API 来获取数据，接入 Zabbix Server 从而复用之前建设的功能，实现后续的告警阈值配置和数据接入集中监控平台。

13、关于 Zabbix 在 DB2 数据库监控的经验分享？

【问题描述】各位专家，我们都知道 zabbix 在 oracle，mysql等数据库的监控方面已经很完善了，想了解下它在 DB2数据库监控方面的应用如何？目前可以达到BMC、IBM等传统监控软件的监控程度吗？

@zhangfan13cmbc 中国民生银行 项目经理：

我们设计了一套自动发现的监控方案，其实连库查询的监控项使用odbc的方式，系统命令的监控项使用agent的方式实现。从试运行的情况看，比BMC更易部署和维护，监控项完全根据需求二次开发，符合监控要求。

@Zabbix大叔_乐维 广州九一乐维信息科技有限公司 研发工程师：

首先，可以从网上找到一些查询db2数据库性能的语句，然后可以通过python的一些数据库连接库，在zabbix_server上通过外部检查的方式，远程到db2数据库执行查询的语句，获取数据，并返回到zabbix-server。

14、基于 Zabbix 二次开发的实践案例分享？

【问题描述】各位专家，能否分享一下基于 Zabbix 二次开发的经验，我现在有个性能数据仓库的需求，需要将各个层面的监控数据通过 Zabbix 监控抽取到该数据仓库中，进而拓展应用。各位老师能否分享一下这方面的经验？

@zhangfan13cmbc 中国民生银行 项目经理：

Zabbix完全可以作为数据采集的工具，并且采集方式多样，比如agent、trapper、odbc、jmx等等，选择合适的采集方式进行二次开发或配置即可。

@Zabbix大叔_乐维 广州九一乐维信息科技有限公司 研发工程师：

可以把zabbix的告警功能和一个工单系统结合使用。zabbix根据不同分类的告警，生成对应的工单，交给不同的人处理。

15、金融行业中成功实施Prometheus和zabbix的案例，是如何与cmdb等其他周边系统进行交互的场景？

@zhangfan13cmbc 中国民生银行 项目经理：

由于我行已有自动化系统作为CMDB的数据采集，所以监控更多是在配置层面和CMDB做一些比对，确保CMDB中的资源及时部署了监控，另外，CMDB的一些维度属性，会作为Zabbix监控配置和巡检的条件，提高处理效率。我们的Zabbix监控和自动化系统交互实现自动化批量部署，和IPAAS系统交互实现一些标准监控的自动化配置。

16、zabbix如何实现和现有的云计算平台结合，实现更高级别、更细粒度的监控？

@Zabbix大叔_乐维 广州九一乐维信息科技有限公司 研发工程师：

可以尝试用脚本采集的方式，这种方式可以实现，界面有的信息都获取下来。但是对服务器负载有影响。

17、zabbix如何配置对WEBLOGIC的监控，能监控运行情况吗？

【问题描述】zabbix监控WEBLOGIC的进程是可以，但是监控weblogic运行情况怎么配置？就是监控所有部署正常及消息传送是否正常？

@Zabbix大叔_乐维 广州九一乐维信息科技有限公司 研发工程师：

在weblogic的配置文件中开启jmx远程，然后zabbix采用jmx监控方式即可监控weblogic

18、zabbix是如何处理容器云上监控对象弹性伸缩的？

@聂奎甲 长春长信华天 项目经理：

对于容器内中间件和数据库的监控，zabbix自身的Database、jmx监控方式或应用主动推送数据不需要安装agent，实现方便，容器内应用仅需与同k8s集群的容器内zabbix proxy能实现互相访问即可，监控项可以复用容器外应用模板，所以仍采用zabbix监控容器内应用实现方案。

19、Zabbix目前是否已经支持对容器云的监控了？

【问题描述】zabbix应该是可以实现对容器云的监控的，是否在新版本中有所体现？  或是否有其他插件可以支持，如同orabbix监控oracle一样？

@zhangfan13cmbc 中国民生银行 项目经理：

Zabbix可以实现二次开发脚本实现容器云监控，但对于容器基础监控和K8S监控，肯定是不如天然集成的prometheus方便和高效了，所以建议综合考虑现状和成本，结合使用

20、最近设计的容器平台Prometheus生产监控架构，分享与大家线上探讨，指点一二！

容器平台Prometheus分指标联邦架构方案：

1.    单个生产机房按采集指标划分K8S调度部署多个prome 1、prome 2

2.    用K8S保证基层prome的可用性

3.    汇聚数据至上层联邦prome A与prome B，两个联邦节点独立写库，两套持久数据库单点部署，分别保留独立数据，以保证数据多副本

4.    告警数据从2个联邦层prome获取，经过gossip筛选产生告警

5.    Kibana经过负载均衡获取联邦prome数据出图（@mtming333 甜橙金融翼支付 系统运维工程师）

@anonymous：

上述方案概括为：基本HA + 远程存储 + 联邦集群 

该方案在我在一个项目上落地过，客户场景为：管理为省级-地市级，每个地市是独立的监控中心，统一汇报至省级prometheus，省级prometheus通过nginx做高可用，持久化数据使用influxdb来存储省级prometheus数据。 

落地需注意如下：

1、需考虑网络延时

2、监控数据量评估

3、成本问题

@郭晓云 平安 系统运维工程师：

建议采用thanos的集群方案，Grafana也是可以集群化的，数据存储可以自己写一个influxdb-proxy

@zhangfan13cmbc 中国民生银行 项目经理：

联邦成本比较高，但可以获得更好的高可用，适合自己的需求即可，方案没有最好只有最合适。

@edwin1986edwin1986 上汽通用汽车 系统架构师：

很好的方案方案，但比较麻烦

概述

云计算被称为是继个人 PC 、互联网之后的第三次信息化革命，不仅实现了 IT 技术的革新，更是 IT 商业模式和服务模式的一次重大变革。越来越多的商业活动几乎都采用云计算技术作为后台支撑，实现按需服务，按需计费。

我国对云计算的产业高度重视，已把云计算产业的发展提到了国家战略的高度，在十二五规划中将云计算列入重点扶植的战略新兴产业。通过云计算技术缩小中小企业和大企业的 IT 应用差距，让每个人能以极低的成本获得顶尖的信息技术和服务。

随着云计算市场规模的不断扩大，应用场景涉及到个人数据存储、企业数据及应用支撑、国家公共基础设施支撑等多个领域，云计算的发展趋势自然已成为业界关注的焦点。

云计算从部署场景分为公有云、私有云和混合云，本文将重点介绍在混合云模式下，计算架构如何搭建？要考虑哪些因？未来的发展趋势如何？

什么是云？

云计算可不像西游记中的孙猴子一样，从石头缝中一下子蹦出来。它是经过了 16 年的技术发展与业务需求而形成的。16 年前，那个时期的计算机又笨重又昂贵，根本谈不上普及。之后随着芯片技术和软件计算的发展，体型越来越小，速度越来越快，价格逐渐亲民。各个企业可以购买符合业务性能需求的物理机，放到数据中心进行集中式的计算，这就形成了最原始的传统数据中心模型。

随着业务的快速增长， IT 需求强烈，采购传统物理机需求暴增，成本逐年提高。但从运维角度发现，大量服务器的性能并未被全部使用，造成严重的资源浪费。为解决此问题，雏形的云计算基础形成，也就是虚拟化技术。将一台物理机逻辑分隔成多个虚拟机，每个虚拟机相互隔离，提供不同的业务服务。

虚拟化解决了资源浪费的问题，但在服务的提供和使用上，与物理机类似，依然存在资源超配的现象。随着需求精细化、资源可视化的需求，云计算诞生了。根据需要的计算、存储、网络等资源实现按需付费。人们使用资源时不再需要拥有自己的计算系统，就像使用水、电一样，不需要自己建立发电站和水厂。

云计算从部署场景又分为公有云、私有云和混合云：

私有云：

顾名思义，是为一个个人、组织、公司提供专有资源的云计算平台。自建基础设施，并控制在此基础设施上部署应用程序的方式。提供对数据、安全性和服务质量的最有效控制。私有云可部署在企业数据中心的防火墙内，也可以部署在一个安全的主机托管场所，私有云的核心属性是专有资源。

公有云：

一般是指第三方提供商，如 AWS 、阿里、腾讯等公有云厂商，为用户提供服务的云。通过互联网，提供免费或成本低廉的服务，公有云的核心属性是共享资源服务。

混合云：

就是融合了私有云和公有云服务模型， 来提供云计算解决方案。混合云服务将内部 IT 基础架构与其他公有云产品和服务集成在一起，以满足企业的特定和独特需求。

图 1- 云计算发展进程

云架构与传统架构的区别？

云架构和传统架构如果不说一下，很可能会让读者混淆。其实云计算最大的好处就是便利，用户按需索取，服务商按需提供。

传统 IT 架构较为封闭，计算、存储、网络相对集中，管理分化，各个资源相对独立。

传统架构的特点：

• 物理资源相对独立，如计算、网络、存储等设备；
• 存储架构集中，普遍采用集中式存储；
• 数据集中存储，可靠性问题明显；
• 性能主要集中在单机处理能力，无联动机制；
• 资源弹性扩展能力受限；
• 自动化运维方式欠缺，运维人员多。

首先要了解，云计算架构主要是为了解决业务扩展性和高并发的需求。从架构划分，可以分为基础设施层【 IAAS 】、平台层【 PAAS 】和软件服务【 SAAS 】三个层。

图 2- 云计算服务模型

IAAS ：

Infrastructure as a service 【基础设施即服务】，包括服务器、网络、存储等设备，池化计算、网络和存储等 IT 基础设施资源，将基础设施资源作为服务，按需提供给用户。用户无需购买任何硬件即可使用基础设施资源。

PAAS：

Platform as a Service 【平台即服务】，是指将一个完整的软件研发和部署平台，包括应用设计、应用开发、应用测试和应用托管，都作为一种服务提供给客户。在这种服务模式中，客户不需要购买硬件和软件，只需要利用 PaaS 平台，按需索取，就能创建、测试和部署应用和服务。

SAAS ：

Software as a service 【软件即服务】，是一种通过互联网提供软件服务的软件应用模式。在这种模式下，用户不需要再花费大量投资用于硬件、软件和开发团队的建设，只需要支付一定的租赁费用，就可以通过互联网享受到相应的服务，而且整个系统的维护也由厂商负责，如 Gmail 、网盘、 QQ 邮箱等应用。

云计算架构的特点：

• 分布式架构、灵活扩展；
• 海量资源，按需分配；
• 资源动态分布，无物理限制；
• 性能弹性，动态调整；
• 分布式存储，数据高可用；
• 运维自动化程度高。

图 3- 云计算维护模型

混合云架构设计

混合云作为未来云计算发展的趋势已经被越来越多的企业所接受，企业通过整合私有云和公有云的资源，结合各自特有的优势与实际业务相结合，整合资源，实现统一配置和管理，可以在多个环境（公有云、私有云或边缘环境）中以一致的方式交付和使用服务，充分展现混合云的价值。

设计的原则

混合云架构在设计方面建议参考以下几个原则：

大势所趋：

正所谓与什么斗，也不用和趋势斗。首先要明确一个数据，根据 Gartner 公有云使用方面的调研显示， 2016 年全球 IaaS 投入增长为 38.4% ，达到了 224 亿美元，并预计到 2020 年，全球 IaaS 投入将增至 560.5 亿美元，复合年增长率将达到 29% 。这意味着，企业内部自身的数据中心由于利用率较低，运营成本高等因素，企业经营者不愿投资太多，逐步将应用上云。

但是并不意味着企业内部的所有系统都可以进入公有云，所以长期来看，企业自有 IT 私有环境和公有云会长期并存，形成混合云形态，成为不可逆的趋势。

高可用性：

可靠性设计是云计算架构中亘古不变的原则。针对企业自有的数据中心架构，传统 IT 系统经常会谈到 “ 两地三中心 ” 架构 ( 即生产数据中心、同城灾备中心、异地灾备中心 ) 。这种模式下，主要目标就是防止各种级别的故障，导致业务受到影响。

针对云计算架构，多数据中心的高可用架构可以借助多区域（ Region ）架构方式来实现。在不同区域间实现远距离的灾备部署，保证当出现故障时，应用连续性和数据无丢失。

开放性：

针对每一个上云的用户，最担心的问题就两个，数据安全问题和被绑架问题。

所以一定要选择一个上下线自如、安全透明的云架构。能够方便的把企业各类业务应用平滑迁移上云，也可以在峰值过后，平滑地回退到企业数据中心来，不需要额外的应用代码修改。

低成本：

上云的目的很多，其中之一就是降低 IT 总体成本。所以在设计混合云架构的时候，要充分考虑企业内 IT 实际的投入成本。融合后的架构，能够帮助企业省下购买设备、软件和维护项目和费用，同时减少 IT 人员的投入，最终形成低成本投入，高效回报的成果。

便利性：

混合云是资源的统一配置和管理，可以在多个环境（公有云，私有云或边缘）中以一致的方式交付和使用服务，用户可以通过一个统一界面，实现云任务管理。

架构设计

了解设计的原则后，就要围绕其对混合云架构进行整体设计。不同的层级有不同的架构设计，如计算架构、存储架构、网络架构、应用架构甚至安全架构等。

随着多云时代的到来，混合云优势突显，众多的企业信息化规划均已将混合云提上议程。运维领域经常说的一句话就是“鸡蛋不能放在一个篮子里”，于是基于多云的云管平台也逐渐取代单一的云管理平台成为热门话题。

整体混合云架构大面上分为用户层、服务层、计算层和基础设施层，引用业界同仁的一张架构图，可以很清楚地看出混合云架构的大概。

图 4- 混合云架构

其实，这张图可以更加细化，突出每个层级的逻辑和特点，比如网络如何连接、安全体系如何建立等等，在后面的文章中，将一一分解，本次将主要针对计算架构进行讨论，从架构上、效果上及技术发展趋势上进行说明。

计算架构设计

计算架构属于混合云架构的计算层，又细分为 IAAS、PAAS、SAAS ，本文就不一一进行术语解释了，大家可以在 TWT 网上找到相关的答案。

计算架构作为核心架构之一，虚拟化技术是计算的核心。从硬件虚拟化开始，经历了基于操作系统的虚拟化，基于容器虚拟化技术以及应用虚拟化等技术。每种虚拟化技术都有各自不同的优劣势，从当前的虚拟化技术发展和业务应用，基于容器的云计算模式已逐渐形成。通过容器的特点，可以最大限度地发挥每个硬件最大的计算资源，与 DevOps 相结合，实现业务快速迭代，提升生产效率。

图 5- 容器云架构

容器云架构的流行带动了微服务架构的火热，容器技术提供一致性的分发手段和运行环境，使得只有微服务化后的应用架构，才能配合容器发挥其最大价值。而微服务化架构引入了很大的复杂性，只有应用容器化以及规模化的容器编排与调度才能避免运维效率下降。容器技术和微服务化架构之间就形成了一种相辅相成的互补关系。

设计的原则

计算架构作为最重要且最基础的核心架构，同类合并后总结出 4 个最关键且有效的原则，分别是：

大道至简

云计算已有 10 多年的发展历史了，越来越被企业所接受。计算架构作为核心基础，如果过于复杂的架构不利于云计算的实施与推广。

计算架构不应该是一个让人看不透，摸不着头脑的架构，这种架构在项目实施过程中往往问问层出不穷，难以排查，最终以失败告终。计算架构作为重要架构之一，应该秉承大道至简的原则，无论用户的基础设施选择如何，计算架构简单明了，满足业务基本需求，并允许用户更加简单地部署应用程序。同时，复杂的架构，只会延长实施和学习曲线，减慢部署速度，并在企业看到成果之前不断增加投资。尽可能的自动化架构，帮助企业用户简化管理过程。

开源基础

不得不承认，开源架构已成为技术发展的趋势。封闭式的架构很难被二次使用，架构扩

展困难，影响业务应用系统的快速部署。因为开源框架提供了对开发、 IT 运营或 DevOps 流程都至关重要的核心功能。以开源架构为基础的原则将确保企业的解决方案顺利落地和实施，而不必考虑底层基础设施的供应商是谁，兼容性如何等。

成本可控

记得以前刚学习架构的时候， IBM 的一位老师问大家一个问题，是否会因为自己设计的

架构过于简单而觉得自己很平庸。搞一个高大上的架构，才算本事，在领导面前也有牛 B 可吹。其实老师最终给了解答，一切技术架构都是为商业架构所服务的，能达到目的，走的路越短越好。所以，过于超前和复杂的架构，往往会增加建设成本，无论是研发成本、采购成本还是运营成本。

易于继承

计算架构不但要考虑业务的实际需要，更要考虑后续架构的运营承接能力。复杂的架构

在后续的运维承接上一定会出现各种不同的问题，难以被运维团队继承。所以在做计算架构的时候，一定要考虑后续的承接能力，避免有终无始。

架构设计

混合云架构在上文已经做了简单介绍，计算架构作为核心架构之一，主要负责计算资源的管理，如资源虚拟化、虚拟资源的分配、调整、回收等。

通用计算架构可以完成大多数企业的计算需求，如图 6 所示：

图 6- 云计算架构示意图（黄色区域）

计算架构主要分为基础设施层、虚拟化层、功能层、应用层及用户层。

基础设施层：

基础设施在本层可以理解为组成云平台的计算节点、存储节点、网络节点，也被称为“老三样”。那么本章重点介绍计算节点，计算节点提供 VM 所使用的计算资源，如 CPU 、内存。一般主机的资源的数量决定上次 VM 的最终数量，在实际的部署中，要充分考虑业务对 VM 的性能和数量的要求，从而采购符合要求和标准的计算节点。

虚拟化层：

虚拟化层的主要功能就是将计算、网络和存储资源池化，按照 VM 的实际需求进行资源分配。主流的虚拟化软件如 VMware 、 Hyper-V 、 KVM 等，云操作系统如 Openstack 、 VMware 及 SCVMM 等。

功能层：

主要是虚拟化软件中的功能模块，如计费、资源控制、资源监控、功能扩展等。主流的如软件定义存储（ SDS ） 软件定义网络（ SDN ） 软件定义安全（ SDSecurity ）等

应用层：

主要是各种业务应用，所有资源都会从池子中分发到应用所在的 VM 中。计算架构就是为应用而更好的服务的。应用的类型决定资源的利用情况，从资源利用率上来看，针对非关键应用采用动态调整策略，核心应用采用固定资源策略。

用户层：

各种用户终端可以通过内、外网进行云服务访问，终端设备包含但不限于笔记本、台式机、服务器、移动设备甚至各种智能设备等，如物联网。

计算架构的演进

计算架构始终随着云计算的发展趋势而发展。历经 10 多年的发展历程中，计算架构发生了多次改革，从最早的硬件分割开始，经历了分区虚拟化、操作系统虚拟化，到现在的基于容器技术的虚拟化等。

随着互联网技术的发展及业务场景的层出不穷，虚拟化技术不断演进。当前主流的虚拟化技术非容器技术莫属。容器技术作为新的计算架构已经开始普及，越来越多的企业开始部署和规划。其自身的特点非常适合 DevOps 、敏捷开发及微服务的场景。未来的计算架构一定是实时的、敏捷的、快速伸缩及具备普及性的。

技术趋势

容器化、微服务化、原生化是当前 IT 系统演进的大趋势。越来越多的企业不是已经在使用容器，就是在准备使用容器的路上。原生化不仅改变了已有应用的架构，也促进了业务的多元化发展，实现 IT 系统的服务规模加速提升。尽管容器技术目前看来呼风唤雨，但挑战还是真实存在的，比如：

• 容器技术如何与现有的系统更好地进行集成，实现共存；
• 推广使用会对应用和架构进行较大的改造，传统企业缺乏相关的技术人才；
• 技术自身的成熟度不够，缺乏合适的应用场景。

相信随着技术的不断发展、成熟以及业务的多元化深入，容器技术在未来一段时间内一定是虚拟化技术发展的趋势。

应用趋势

容器技术的普及、云计算的发展带动整个应用产业得改革，微服务化、 SAAS 化、轻量化将成为应用发展趋势的代名词。

利用容器等技术与 DevOps 相结合，实现敏捷开发，提高应用的开发周期和按需发布的能力。云计算的不断发展，有越来越的用户开始接受 SAAS 带来的便利性和稳定性。通过 SAAS 降低企业建云成本，提高企业的专注度，专业的人做专业的事情。应用可以随着业务的转变而迅速迭代，利用容器技术，应用可以轻量化部署，提升企业转型速度，提高业务的稳定性。

结束语

计算架构一定会随着业务的需要和整体云计算计算的发展不断更新，但是万变不离其宗，所有技术架构都是为商业架构而服务的。脱离业务的架构就如同人没有骨架，无法撑起身体而前进。相信计算架构会随着技术的发展，越来越开源化、轻量化和更具前瞻性。

云驻场运维服务是华云银安以客户信息服务管理成熟度、运维规范成熟度、运维人员技能成熟度、服务价值期望及服务质量管控要求等为需求基准， 安排驻场工程师或专家组实地深入地了解客户云计算平台运营、日常维护、人员培养等方面的现状，并根据客户的服务需求，派驻驻场工程师到客户现场对云计算平台运营维护、人员技能提升等提供技术保障的服务。

一、基础运维服务

1.1、服务计划与监控：

根据客户需求制定年度维护服务计划，每季度对服务内容进行回顾和调整，全程对服务质量进行监控

1.2、日常维护与监控

协助客户对云平台软件和相关的服务器、存储和网络等硬件设备进行日常维护和例行监控，并提供维护服务记录

1.3、高级巡检服务

每季度一次，定期采集客户云平台软件和相关硬件设备的运行信息并进行分析，对客户云平台的运行和维护现状进行检查，并对存在的潜在风险和漏洞进行分析和汇报。

1.4、信息分析整理

协助客户管理设备资产信息（序列号、维保起始时间）、网络拓扑信息（IP地址、接口、对端设备等），为后续运维工作提供参考依据。

1.5、故障与问题处理

快速解决由于设备本身原因造成的故障和问题，并恢复业务；对于重大问题，直接升级到专家级别，提升问题处理效率，并全程跟踪问题的处理进展，定期回顾。

1.6、设备硬件维护

根据服务器、网络、存储等硬件设备的备件服务级别，协助客户进行快速备件更换

1.7、重大变更协助

协助变更责任人制定云平台变更实施方案，对变更实施方给予必要的指导和配合

1.8、服务总结与汇报

每季度一次日常维护服务总结，每年度一次对客户汇报，听取客户相关意见，做出后续服务工作规划

二、云运维服务

2.1、云服务开通

协助客户开通云服务，包括云主机、云存储、云网络等

2.1、云资源管理

每周输出云资源（CPU、内存、存储、网络等）使用情况的总结报表，为容量管理决策提供参考

2.3、云迁移协助

有业务迁移需求时，根据迁移服务商要求，提供迁移环境信息，协助准备迁移环境。

2.4、云技术培训

每季度一次向客户提供云平台相关产品培训、运维案例分享，提升运维团队技术水平。

三、专项保障

在任何可能对业务运营产生重大影响或客户指定的其他重要时刻，提供专业的华云银安的值守保障服务。

四、客户获益

4.1、专业的云计算驻场运维工程师，经过严格的技术培训和实践练习，上岗后可快速进入工作状态；在执行驻场运维服务的同时，定期输出技术总结和案例分享，协助用户共同提高云运维服务能力；

4.2、依托华云银安强大的专家团队，可快速的解决现场问题，恢复业务正常运行；

4.3、现场主动式巡检，结合三级网上问题管理机制，可提前发现问题，消除隐患；

云运维规划服务是华云银安公司为了针对性的提升用户云数据中心合作、维护能力水平而推出的专业化服务。主要应用场景为：客户需要新建、重建、优化现有云运维和合作管理体系时，为客户规划提供运维着眼点并设计运维方案；客户现使用的运维管理体系/流程/平台工具不健全、效率不高，为客户提供改进运维效率的方案。

一、现状调研与分析

1.1、现状调研

华云银安服务专家将采用资料查阅、访谈、信息收集及现场调研等方式，收集客户需求和现状信息，将收集的信息分类汇总，进行分析，展现客户真实的现状和需求

1.2、现状评估分析

基于客户的管理目标，访谈中梳理的管理痛点，依据《云数据中心运维成熟度模型》进行现状评估，并输出《现状分析报告》并向领导进行阶段性工作汇报

二、云运维体系规划设计

华云银安服务专家根据现状调研与分析阶段的工作成果，为客户进行整体蓝图及路线规划。

三、云运维组织设计

本领域设计内容包括：1.云运维组织架构设计；2.岗位职责设计；3.人员技术能力要求设计

四、规划流程详细设计

4.1、云资源管理域流程设计

本领域设计的流程包括：资源计量管理，资产管理，镜像管理，资源池管理

4.2、云服务交付域流程设计

本领域设计的流程包括：服务目录管理，服务水平管理，服务报告管理，满意度管理，服务质量管理

4.3、云运维域流程设计

本领域设计的流程包括：服务发布管理、服务开通管理、监控管理、变更管理、故障管理、问题管理、知识管理、云配置管理

4.4、云服务规划域流程设计

本领域设计的流程包括：云服务可用性管理，业务连续性管理云服务容量管理，供应商管理，IT财务管理

五、集中评审与验收

5.1、集中评审

汇总完成流程文件进行集中评审后进行体系发布运行

5.2、项目验收

流程详细设计方案通过客户内部评审后，云运维规划服务进入项目验收阶段。

六、客户获益

解决云计算技术变革对运维产生的挑战，建立新管理模式；

快速提升云运维管理成熟度；

强力提供云运维保障能力，支撑企业云业务、云战略的推进