平安云简介

平安云隶属于中国平安保险(集团)股份有限公司，依托平安集团构建的金融及健康IT生态圈，为银行，证券，保险，互联网金融及医疗健康类机构提供按需付费，高可用，高弹性，安全合规的云计算服务。结合金融及健康业务在系统，合规以及数据方面的特性，平安云除为客户提供开发，测试，生产，容灾在内的全套基础设施服务外，还提供定制化金融IT解决方案。

从13年底立项以来，平安金融云一直尽可能走开源和自研结合的路线，自主研发了IaaS层的全套产品线，为金融行业客户提供可靠、弹性、高效、集约的基础架构层服务。

日常运维管理

基于ITIL的流程管理

图1 平安云的运维管理流程体系

多数企业的日常系统运维都是遵守ITIL体系。云计算改变了资源交付与运维资源的方式，云平台本身也是新的运维对象，需要控制风险，解决事件，跟进问题，管理平台资源池的容量。

平安云承担了一部分企业基础架构的角色。如图1，为了满足金融企业的高合规特征，平安云的运维严格遵守ITIL流程，按照平安科技的制度规范要求实施变更，事件，问题，业务持续计划以及容量管理。

包括已经通过工具自动化的操作，所有的生产区变更都需要经过每周两次的内部变更评审会议授权后才可以触发工具实施。对于网络等全局性的变更更是需要提交到重大变更评审系列会议获得高级主管审批后方可授权执行。

同时，由于业务的快速转型需求，运维对象与运维内容的变化也越来越快，因此在传统的ITIL风险控制流程之上，我们借助开源或自研开发了很多运维辅助工具。另一方面，在业内去IOE、分布式系统的背景下，大量采用了供应商竞争激烈、通用的Server，通用Server的单机可靠性要比以往的专用小型机等服务器有所下降，但业务通过分布式部署后反而提升了整个应用的可靠性。，因此单一的物理资源可靠性指标的集合并不能有效地衡量IT服务可靠性，而需要从上层服务的整体可用指标来实施创新与衡量服务可靠性，这个转变对金融技术转型来说尤为重要。

平安云引入了SRE运维云平台系统，总结来说中心思想有两点：1.从软件或架构层面分析问题解决问题，避免引入人的工作或影响，2. 所有必需的操作都要有工具支撑，避免随着底层操作对象资源的增加而增加工作人力。这个思想并没有违背ITIL理念，从我们的实践经验分析，SRE可以作为ITIL新时代的工具，良好地融合后可以有效地支持金融业务在云上的可靠性。

门户自助资源交付与责任共担体系

平安云作为平安集团基础架构的延伸，首先希望能够实现下面的目标：

1.    运营或业务用户可以直接自助申请资源，分钟级交付。并进一步实现快速扩容能力。

2.    各个应用专机专用，消灭应用间的交叉影响。

3.    在云门户上实现权限控制，各应用的所有者对自己的主机有完全的管理权，在拥有root权限之上更能自主poweroff/poweron主机。

在传统的大物理机环境下，会出现多个业务应用共享一台高性能主机。在这种环境下，应用所有者很难单独为自己的应用在操作系统层调优，安装软件或自助的启停主机，必须通过冗长的申请流程要求主机管理员实施。通过云计算，应用所有者完全独享自己的云主机，并可以根据业务需求自由的设置各种操作系统参数或者安装软件。

在传统的虚拟机环境下，由于VCenter等统一管理平台的集中权限管理，业务应用虽然可以拥有自己独立的OS，但是当OS需要冷启动或需要进行配置伸缩时，必须走流程通过虚拟环境管理员帮助操作，在时效上与效率上都不能满足创新业务的快速需求。

平安云自主研发了一套云门户系统，用户可以通过门户自主的管理自己的云主机，包括主机的启停，配置修改以及类似带外管理的local console等功能。同时，由于有严格的基于租户与资源组的视图隔离与权限控制，可以确保每个应用资源组管理员只能够看到自己系统的主机，保证了资源组管理员操作应用主机合规，安全。

图2 IaaS模式下的责任共担体系

如图2，通过云门户隔离OS的视图与操作权限，将独享主机操作所有权与管理责任上浮，分布到不同的应用资源组，提供给应用资源组管理员更加自由的灵活度与更安全的应用之间的隔离，原有的基础架构运维人员可以集中精力处理平台层的优化与运维，从而提高运维效率与系统稳定性。

私有云 vs 公有云

在一开始平安云是以公有云的标准来规划和运维平安自己的私有云平台产品的，但是经过两年多的运维和越来越多的生产应用上云，我们对私有云的定位和运维方式也在不断思考和改进。主要有下面三点：

1.    私有云相当于企业中基础架构的地位，因此第一价值导向为服务业务应用，保障应用可用性。这与公有云单纯追求单机可用率是不同的，私有云不但要提供可以接受的底层资源可用率，同时也要有手段分散风险影响面，避免异常集中在同一个时间点。我们在后续的架构改造中，牺牲了一定的共享资源灵活性，而转为优先保障底层资源隔离，避免由于底层共享资源异常而引起的大面积故障风险。

2.    私有云与上层应用关联紧密，应用团队与云平台团队之间的沟通频繁。云平台可以对应用部署方式提出规范，亦需要有手段与运营团队一同巡检应用的部署方式是否符合规范。因此云上应用对云平台团队来说不是黑盒，而是灰盒甚至是白盒。

3.    业务应用有编排搭建，快速扩容，容灾同步，数据备份等需求，这些都需要云平台产品针对具体的业务场景开发解决方案。因此在后期平安云的产品建设更多的以实际业务需求为导向，开发了标准应用系统编排搭建，本地盘方案，云主机复制，文件同步，按需自动开通防火墙等产品与功能。

为了保障应用可用性，我们提供了如下手段:

1.双AZ部署

每个区域(Region)均提供了两个可用区(Available Zone)，可用区之间在计算网络存储三个层面物理隔离，要求应用必须分散部署在两个可用区，通过ELB服务分散流量到两个可用区的云主机上。即使一个可用区由于物理故障全down，另一个可用区也可以正常提供服务。

2.关联性组

顾名思义，就是将一个应用集群中的云主机都放到同一个关联性组内打上标签，在云主机启动时后台会分散同一个关联性组的主机到不同的底层物理服务器上，确保单台物理服务器的硬件故障只会影响到一个应用集群中的一台主机实例。应用前端如果有使用ELB服务的话，应用可用性不会受到影响，而只会减小应用的最大服务容量。

3.超融合架构

平安云提供使用超融合存储的云主机。使用计算单元物理机的内置大容量磁盘提供三副本分布式存储，消除了iops集中在某一台存储设备或存储路径上的情况。同时控制一个存储集群上的云主机数量，避免由于底层资源故障导致的大面积故障。

工具研发

Argus监控

监控是系统管理的基石。如果监控失效，则我们无从得知系统状况如何，甚至是否运转正常，所以监控系统需要具备极高的可用性。在早期，我们选择基于zabbix进行二次开发，但随着平安云规模超过万台主机以后，zabbix达到了性能瓶颈，无法跟上业务发展的脚步。于是，在调研之后，我们选择了二次开发open-falcon 来重新构建整个监控系统。它具有高可用、易扩展、易维护的特性，支持第三方告警接入。

open-falcon的告警对接到平安自研的端到端监控平台，并在告警展现上做优化、分析与收敛，方便运维人员快速判断异常来源以及原因。同时通过open-falcon的api，接入ELK日志分析与自研的VMWare myclient监控告警，可以从日志与集群角度实施监控。

目前我们也在尝试智能的数据分析与自动恢复等策略，出于谨慎考虑我们对自动恢复还是比较保守，加入了人工触发的步骤。

图3 Argus平台架构

AlphaOPS

平安云给自己的运维自动化平台和运维体系起了个名字叫AlphaOps，寓意是希望能够达到智能运维的目标。

图4 AlphaOps平台架构

如图4，在定义AlphaOps运维自动化的时候，我们定义了三种AlphaOps的开发模式：集中管理平台模式，脚本自动化模式，产品自带运维模式。这三种自动化模式也可以诠释AlphaOps开发中的工作内容。

集中管理平台模式

AlphaOps有专职的运维开发成员，他们主要负责梳理云平台各层组件之间的关系，对接已有的核心应用CMDB与资源管理CMDB，针对高频或强烈需求的运维场景开发集中管理平台，展现资源之间的关联关系与平台容量的趋势，批量展示或操作海量资源，以及实现云内管理平台基础资源的自动交付能力。

AlphaOps平台基于keystone框架实现了精确到实名账号的鉴权机制，对运维人员最小授权与留存所有操作日志。再配合基于FreeIPA，Tacacs+，guacamole开发的智能终端登录平台，运维人员可以在一次AlphaOps登陆验证身份后，免密登陆授权给自己的堡垒机与终端实施操作，减少了花费在设备之间跳转上的工作量，也减少了特权账户密码泄漏的风险。设备的admin账号根据需求授权到个人账号，三个月自动更改一次，自动进入后台teampass数据库，运维人员不需要知道密码即可管理相应基础资源。

脚本自动化模式

集中管理平台有一定的规划和设计，能够实现较完整的功能，但无法满足运维场景的多样化与个性化需求，因此AlphaOps平台打通了各个计算，存储，网络产品之间的连接后，既提供了集中式运维管理平台供运维人员在上面实施一键式操作，又提供了方便的web service接口供运维人员能够依据各种个性或突发运维场景在AlphaOps的工具Terminal上方便地编写运维脚本，实现对海量规模对象的高效管理。

为了确保运维脚本的一致性与可维护性，我们也要求所有的脚本都要遵循开发过程规范，所有版本修改必须由需求引发，版本入库管理，代码评审，并且需要遵守一些共通的日志，权限等规范要求。

另外，由于平安云的运维人员都具有开发能力，我们也要求运维人员积极参与到产品的早期开发建设与架构评审中，在产品开发阶段即引入运维参与，确保产品的可靠性与可运维性。

产品自带运维模式

基于开源软件做二次开发实现产品化是很多云平台建设的选择，平安云也不例外。为了确保这些产品的可靠性与可运维性，我们对产品开发提出了3条要求:

1.    不低于99.95%的可用性。

2.    在设计和开发过程中考虑可运维性，提供RESTful的CRUD以及启停等运维API接口。

3.    在产品发生异常时的快速恢复三板斧(重启/切换/回滚)需要验证有效，提供POC环境和测试环境的验证结果。

基于上述要求开发出来的产品天然具有可运维性，后续AlphaOps只需要梳理环境后，调用产品自身的API即开即用，并且组织到各个运维场景中。

CMDB

目前平安云的CMDB主要分为两个部分，向应用方向的核心配置管理与向基础资源方向的基础资源配置管理。

平安云的门户通过租户与资源组的两级管理实现了各个BU以及各个应用系统到云上交付物的映射管理，再加上平安科技原有的集群资源管理系统，AlphaOps对这些信息做了聚合，实现了从上之下与从下至上的应用与底层资源的关联关系管理。运维人员能够快速的在应用信息到所有关联的底层资源之间进行相互查询。

对于基础资源的配置管理，主要管理两类信息:

1.    基础资源的属性管理。如物理机，交换机等的配置，物理位置等信息。这部分信息大部分也与资产管理相关，在几乎所有的CMDB中都会涉及到。

2.    基础资源之间的关联关系管理。这部分信息由于错综复杂，信息量大，几乎不可能手工录入。目前平安云采用的是使用agent自动采集的方式来管理和录入系统。

另外，针对各个设备与主机自身参数设置的动态采集与基线管理也在平安云CMDB的开发计划中。

NSP

NSP全称是网络服务平台（Network Service Platform），作为平安云网络的核心组件，实现异构厂商设备的统一管理，网络功能虚拟化，抽象出通用易懂的网络功能模型，为云门户和其他系统提供网络服务。通过NSP自动化的对接平安内部的审批系统，统一的配置设计和检查，达到提高网络配置效率和减少人工错误的事件。NSP提供的服务归纳为以下四种：

图5 NSP功能架构

1.    基础网络自动化配置：NSP提供API接口，实现虚拟网络和物理网络的自动化配置，为租户提供L2/L3层网络弹性扩展能力；

2.    网络编排服务：租户VPC的网络编排，NFV设备的编排管理，SDN能力集成等。

3.    高级网络服务管理：提供防火墙、负载均衡、VPN等高级网络服务的配置和管理；

4.    网络增值服务：接入第三方网络服务，将其他公司提供的增值网络服务接入云平台，比如网络探测服务、CDN、DDoS服务等。

VMWare myclient

平安云的传统金融分区部分底层使用了VMWare作为虚拟化技术，平安云团队自研了一套myclient接口，实现了三个方面的能力：

1.    从hypervisor层采集监控信息，能够从全局把控虚拟化集群的健康状况与告警。

2.    作为cloudstack的补充，实现了直接管理VMWare的能力，在一些应急预案、大规模迁移、以及参数设置的场景中能够高效完成自动化操作。

3.    平安集团的传统环节还有很多存量的生产虚拟机。通过myclient与ESXi对接，将这些虚拟机接入到平安云门户，再梳理应用所有者权限后，能够达到与80%与云主机相同的效果。

Lesson Learn/最佳实践

在平安云的建设与生产使用过程中，我们经历了主机从零到百，从百到千，从千到万的过程，收获最宝贵的是架构治理，业务入云和海量运维的经验，这种不断提高的过程是平安云能够在过去2年中迅速成长的关键。其中针对海量业务中主要有下面三条心得。

共享资源粒度

由于云计算最早是从虚拟化起步，而虚拟化的一个重要标志是使用底层共享存储实现秒迁移能力，因此在前期平安云也是采用了共享存储做为底层存储。在过去2年的使用中发现共享存储有如下两个问题：

1.    定时任务共振
云主机都是由标准化的OS模板生成，这些模板中通常都内置了一些定时任务。当云主机数量上了5000之后，每一次几千几百个定时任务的同时调用对于底层存储来说都会是一次iops风暴，必须通过对cron job或者被调用脚本的random启动处理来分散io压力到不同的时间点。

2.    共享存储异常时的影响面
当同一个共享存储异常时，基本上会影响到其上所有的物理机与云主机。另一方面，尽管对云主机的io有iops限速，由于金融行业特性，大部分业务发生在工作时间内比较集中的时间段内，当一套存储上的云主机过多，且业务繁忙时期，一片面积的主机都达到iops上限时，对于共享存储的性能来说是一个很大的挑战。

因此，从分散风险的角度需要控制一个可用区内单个存储设备上的云主机个数。

黑天鹅思维

量变引起质变是所有事物的共通规律。当IT环境到达一个规模后，所有看起来是低概率的事件都一定会先后发生，肯定会发生。因此不能因为一个异常看起来发生的概率很低或感觉不会发生就忽视它们。

在经历了1，2次黑天鹅概率级别的故障之后，平安云加强了针对应急预案建设的人力投入，并且确定了下面的验证应急预案的原则：

1.    所有的关联组件都有可能出问题，并且有些关联组件有可能短时间内恢复不了，此时恢复预案是否有效。

2.    所有涉及自动化处理的代码逻辑都有可能会出问题，出问题后人工介入是否有效。

3.    针对各种组件，都需要有有效的关联关系管理的CMDB。所有的组件都必须有重启/切换预案，且必须要定期验证其有效性。

各项服务指标的全局把握

云平台本身的可用性与性能指标并不是一直不变的，随着底层资源容量的变化与规模的增大，可用性和性能很有可能在某一天会发生突然的变化，在这之前都会有一些征兆产生。

目前我们通过每日的自动化巡检，E2E不间断测试与在网络/存储端部署监控来保障云平台整体的交付能力，可用性与性能：

1.    每日自动化巡检
AlphaOps平台自动分析从各个层面的产品搜集到的信息，聚合后展现在巡检页面上，每天早班同事会确认巡检页面并且发出关于容量，资源使用状况的巡检报告。

2.    E2E不间断测试
原本测试是偏重于进入正式生产阶段前的功能性验证与并发度验证，属于一次性工作的概念。平安云通过Robot Framework+Jenkins等持续集成与自动化测试工具，编写从云主机申请到负载均衡申请等一系列测试用例，每天不间断的的在生产可用区实施端到端的自动化测试，这样可以实现从用户的角度直截了当发现平台中的潜在问题。

3.    从网络与存储聚合路径点实施监控
平安云在接入交换机上部署了对错误日志的分析告警，在存储的控制器路径上接入了CPU使用率告警，从平台上下层的入口实现了对全局流量与io指标的监控，当发生流量超过阀值告警后通过AlphaOps的性能分析工具可以迅速定位到问题主机，从而采取必要措施保障平台稳定性。（周锋、丘子隽原创）

平安云简介

平安云隶属于中国平安保险(集团)股份有限公司，依托平安集团构建的金融及健康IT生态圈，为银行，证券，保险，互联网金融及医疗健康类机构提供按需付费，高可用，高弹性，安全合规的云计算服务。结合金融及健康业务在系统，合规以及数据方面的特性，平安云除为客户提供开发，测试，生产，容灾在内的全套基础设施服务外，还提供定制化金融IT解决方案。

从13年底立项以来，平安金融云一直尽可能走开源和自研结合的路线，自主研发了IaaS层的全套产品线，为金融行业客户提供可靠、弹性、高效、集约的基础架构层服务。

日常运维管理

基于ITIL的流程管理

图1 平安云的运维管理流程体系

多数企业的日常系统运维都是遵守ITIL体系。云计算改变了资源交付与运维资源的方式，云平台本身也是新的运维对象，需要控制风险，解决事件，跟进问题，管理平台资源池的容量。

平安云承担了一部分企业基础架构的角色。如图1，为了满足金融企业的高合规特征，平安云的运维严格遵守ITIL流程，按照平安科技的制度规范要求实施变更，事件，问题，业务持续计划以及容量管理。

包括已经通过工具自动化的操作，所有的生产区变更都需要经过每周两次的内部变更评审会议授权后才可以触发工具实施。对于网络等全局性的变更更是需要提交到重大变更评审系列会议获得高级主管审批后方可授权执行。

同时，由于业务的快速转型需求，运维对象与运维内容的变化也越来越快，因此在传统的ITIL风险控制流程之上，我们借助开源或自研开发了很多运维辅助工具。另一方面，在业内去IOE、分布式系统的背景下，大量采用了供应商竞争激烈、通用的Server，通用Server的单机可靠性要比以往的专用小型机等服务器有所下降，但业务通过分布式部署后反而提升了整个应用的可靠性。，因此单一的物理资源可靠性指标的集合并不能有效地衡量IT服务可靠性，而需要从上层服务的整体可用指标来实施创新与衡量服务可靠性，这个转变对金融技术转型来说尤为重要。

平安云引入了SRE运维云平台系统，总结来说中心思想有两点：1.从软件或架构层面分析问题解决问题，避免引入人的工作或影响，2. 所有必需的操作都要有工具支撑，避免随着底层操作对象资源的增加而增加工作人力。这个思想并没有违背ITIL理念，从我们的实践经验分析，SRE可以作为ITIL新时代的工具，良好地融合后可以有效地支持金融业务在云上的可靠性。

门户自助资源交付与责任共担体系

平安云作为平安集团基础架构的延伸，首先希望能够实现下面的目标：

1.    运营或业务用户可以直接自助申请资源，分钟级交付。并进一步实现快速扩容能力。

2.    各个应用专机专用，消灭应用间的交叉影响。

3.    在云门户上实现权限控制，各应用的所有者对自己的主机有完全的管理权，在拥有root权限之上更能自主poweroff/poweron主机。

在传统的大物理机环境下，会出现多个业务应用共享一台高性能主机。在这种环境下，应用所有者很难单独为自己的应用在操作系统层调优，安装软件或自助的启停主机，必须通过冗长的申请流程要求主机管理员实施。通过云计算，应用所有者完全独享自己的云主机，并可以根据业务需求自由的设置各种操作系统参数或者安装软件。

在传统的虚拟机环境下，由于VCenter等统一管理平台的集中权限管理，业务应用虽然可以拥有自己独立的OS，但是当OS需要冷启动或需要进行配置伸缩时，必须走流程通过虚拟环境管理员帮助操作，在时效上与效率上都不能满足创新业务的快速需求。

平安云自主研发了一套云门户系统，用户可以通过门户自主的管理自己的云主机，包括主机的启停，配置修改以及类似带外管理的local console等功能。同时，由于有严格的基于租户与资源组的视图隔离与权限控制，可以确保每个应用资源组管理员只能够看到自己系统的主机，保证了资源组管理员操作应用主机合规，安全。

图2 IaaS模式下的责任共担体系

如图2，通过云门户隔离OS的视图与操作权限，将独享主机操作所有权与管理责任上浮，分布到不同的应用资源组，提供给应用资源组管理员更加自由的灵活度与更安全的应用之间的隔离，原有的基础架构运维人员可以集中精力处理平台层的优化与运维，从而提高运维效率与系统稳定性。

私有云 vs 公有云

在一开始平安云是以公有云的标准来规划和运维平安自己的私有云平台产品的，但是经过两年多的运维和越来越多的生产应用上云，我们对私有云的定位和运维方式也在不断思考和改进。主要有下面三点：

1.    私有云相当于企业中基础架构的地位，因此第一价值导向为服务业务应用，保障应用可用性。这与公有云单纯追求单机可用率是不同的，私有云不但要提供可以接受的底层资源可用率，同时也要有手段分散风险影响面，避免异常集中在同一个时间点。我们在后续的架构改造中，牺牲了一定的共享资源灵活性，而转为优先保障底层资源隔离，避免由于底层共享资源异常而引起的大面积故障风险。

2.    私有云与上层应用关联紧密，应用团队与云平台团队之间的沟通频繁。云平台可以对应用部署方式提出规范，亦需要有手段与运营团队一同巡检应用的部署方式是否符合规范。因此云上应用对云平台团队来说不是黑盒，而是灰盒甚至是白盒。

3.    业务应用有编排搭建，快速扩容，容灾同步，数据备份等需求，这些都需要云平台产品针对具体的业务场景开发解决方案。因此在后期平安云的产品建设更多的以实际业务需求为导向，开发了标准应用系统编排搭建，本地盘方案，云主机复制，文件同步，按需自动开通防火墙等产品与功能。

为了保障应用可用性，我们提供了如下手段:

1.双AZ部署

每个区域(Region)均提供了两个可用区(Available Zone)，可用区之间在计算网络存储三个层面物理隔离，要求应用必须分散部署在两个可用区，通过ELB服务分散流量到两个可用区的云主机上。即使一个可用区由于物理故障全down，另一个可用区也可以正常提供服务。

2.关联性组

顾名思义，就是将一个应用集群中的云主机都放到同一个关联性组内打上标签，在云主机启动时后台会分散同一个关联性组的主机到不同的底层物理服务器上，确保单台物理服务器的硬件故障只会影响到一个应用集群中的一台主机实例。应用前端如果有使用ELB服务的话，应用可用性不会受到影响，而只会减小应用的最大服务容量。

3.超融合架构

平安云提供使用超融合存储的云主机。使用计算单元物理机的内置大容量磁盘提供三副本分布式存储，消除了iops集中在某一台存储设备或存储路径上的情况。同时控制一个存储集群上的云主机数量，避免由于底层资源故障导致的大面积故障。

工具研发

Argus监控

监控是系统管理的基石。如果监控失效，则我们无从得知系统状况如何，甚至是否运转正常，所以监控系统需要具备极高的可用性。在早期，我们选择基于zabbix进行二次开发，但随着平安云规模超过万台主机以后，zabbix达到了性能瓶颈，无法跟上业务发展的脚步。于是，在调研之后，我们选择了二次开发open-falcon 来重新构建整个监控系统。它具有高可用、易扩展、易维护的特性，支持第三方告警接入。

open-falcon的告警对接到平安自研的端到端监控平台，并在告警展现上做优化、分析与收敛，方便运维人员快速判断异常来源以及原因。同时通过open-falcon的api，接入ELK日志分析与自研的VMWare myclient监控告警，可以从日志与集群角度实施监控。

目前我们也在尝试智能的数据分析与自动恢复等策略，出于谨慎考虑我们对自动恢复还是比较保守，加入了人工触发的步骤。

图3 Argus平台架构

AlphaOPS

平安云给自己的运维自动化平台和运维体系起了个名字叫AlphaOps，寓意是希望能够达到智能运维的目标。

图4 AlphaOps平台架构

如图4，在定义AlphaOps运维自动化的时候，我们定义了三种AlphaOps的开发模式：集中管理平台模式，脚本自动化模式，产品自带运维模式。这三种自动化模式也可以诠释AlphaOps开发中的工作内容。

集中管理平台模式

AlphaOps有专职的运维开发成员，他们主要负责梳理云平台各层组件之间的关系，对接已有的核心应用CMDB与资源管理CMDB，针对高频或强烈需求的运维场景开发集中管理平台，展现资源之间的关联关系与平台容量的趋势，批量展示或操作海量资源，以及实现云内管理平台基础资源的自动交付能力。

AlphaOps平台基于keystone框架实现了精确到实名账号的鉴权机制，对运维人员最小授权与留存所有操作日志。再配合基于FreeIPA，Tacacs+，guacamole开发的智能终端登录平台，运维人员可以在一次AlphaOps登陆验证身份后，免密登陆授权给自己的堡垒机与终端实施操作，减少了花费在设备之间跳转上的工作量，也减少了特权账户密码泄漏的风险。设备的admin账号根据需求授权到个人账号，三个月自动更改一次，自动进入后台teampass数据库，运维人员不需要知道密码即可管理相应基础资源。

脚本自动化模式

集中管理平台有一定的规划和设计，能够实现较完整的功能，但无法满足运维场景的多样化与个性化需求，因此AlphaOps平台打通了各个计算，存储，网络产品之间的连接后，既提供了集中式运维管理平台供运维人员在上面实施一键式操作，又提供了方便的web service接口供运维人员能够依据各种个性或突发运维场景在AlphaOps的工具Terminal上方便地编写运维脚本，实现对海量规模对象的高效管理。

为了确保运维脚本的一致性与可维护性，我们也要求所有的脚本都要遵循开发过程规范，所有版本修改必须由需求引发，版本入库管理，代码评审，并且需要遵守一些共通的日志，权限等规范要求。

另外，由于平安云的运维人员都具有开发能力，我们也要求运维人员积极参与到产品的早期开发建设与架构评审中，在产品开发阶段即引入运维参与，确保产品的可靠性与可运维性。

产品自带运维模式

基于开源软件做二次开发实现产品化是很多云平台建设的选择，平安云也不例外。为了确保这些产品的可靠性与可运维性，我们对产品开发提出了3条要求:

1.    不低于99.95%的可用性。

2.    在设计和开发过程中考虑可运维性，提供RESTful的CRUD以及启停等运维API接口。

3.    在产品发生异常时的快速恢复三板斧(重启/切换/回滚)需要验证有效，提供POC环境和测试环境的验证结果。

基于上述要求开发出来的产品天然具有可运维性，后续AlphaOps只需要梳理环境后，调用产品自身的API即开即用，并且组织到各个运维场景中。

CMDB

目前平安云的CMDB主要分为两个部分，向应用方向的核心配置管理与向基础资源方向的基础资源配置管理。

平安云的门户通过租户与资源组的两级管理实现了各个BU以及各个应用系统到云上交付物的映射管理，再加上平安科技原有的集群资源管理系统，AlphaOps对这些信息做了聚合，实现了从上之下与从下至上的应用与底层资源的关联关系管理。运维人员能够快速的在应用信息到所有关联的底层资源之间进行相互查询。

对于基础资源的配置管理，主要管理两类信息:

1.    基础资源的属性管理。如物理机，交换机等的配置，物理位置等信息。这部分信息大部分也与资产管理相关，在几乎所有的CMDB中都会涉及到。

2.    基础资源之间的关联关系管理。这部分信息由于错综复杂，信息量大，几乎不可能手工录入。目前平安云采用的是使用agent自动采集的方式来管理和录入系统。

另外，针对各个设备与主机自身参数设置的动态采集与基线管理也在平安云CMDB的开发计划中。

NSP

NSP全称是网络服务平台（Network Service Platform），作为平安云网络的核心组件，实现异构厂商设备的统一管理，网络功能虚拟化，抽象出通用易懂的网络功能模型，为云门户和其他系统提供网络服务。通过NSP自动化的对接平安内部的审批系统，统一的配置设计和检查，达到提高网络配置效率和减少人工错误的事件。NSP提供的服务归纳为以下四种：

图5 NSP功能架构

1.    基础网络自动化配置：NSP提供API接口，实现虚拟网络和物理网络的自动化配置，为租户提供L2/L3层网络弹性扩展能力；

2.    网络编排服务：租户VPC的网络编排，NFV设备的编排管理，SDN能力集成等。

3.    高级网络服务管理：提供防火墙、负载均衡、VPN等高级网络服务的配置和管理；

4.    网络增值服务：接入第三方网络服务，将其他公司提供的增值网络服务接入云平台，比如网络探测服务、CDN、DDoS服务等。

VMWare myclient

平安云的传统金融分区部分底层使用了VMWare作为虚拟化技术，平安云团队自研了一套myclient接口，实现了三个方面的能力：

1.    从hypervisor层采集监控信息，能够从全局把控虚拟化集群的健康状况与告警。

2.    作为cloudstack的补充，实现了直接管理VMWare的能力，在一些应急预案、大规模迁移、以及参数设置的场景中能够高效完成自动化操作。

3.    平安集团的传统环节还有很多存量的生产虚拟机。通过myclient与ESXi对接，将这些虚拟机接入到平安云门户，再梳理应用所有者权限后，能够达到与80%与云主机相同的效果。

Lesson Learn/最佳实践

在平安云的建设与生产使用过程中，我们经历了主机从零到百，从百到千，从千到万的过程，收获最宝贵的是架构治理，业务入云和海量运维的经验，这种不断提高的过程是平安云能够在过去2年中迅速成长的关键。其中针对海量业务中主要有下面三条心得。

共享资源粒度

由于云计算最早是从虚拟化起步，而虚拟化的一个重要标志是使用底层共享存储实现秒迁移能力，因此在前期平安云也是采用了共享存储做为底层存储。在过去2年的使用中发现共享存储有如下两个问题：

1.    定时任务共振
云主机都是由标准化的OS模板生成，这些模板中通常都内置了一些定时任务。当云主机数量上了5000之后，每一次几千几百个定时任务的同时调用对于底层存储来说都会是一次iops风暴，必须通过对cron job或者被调用脚本的random启动处理来分散io压力到不同的时间点。

2.    共享存储异常时的影响面
当同一个共享存储异常时，基本上会影响到其上所有的物理机与云主机。另一方面，尽管对云主机的io有iops限速，由于金融行业特性，大部分业务发生在工作时间内比较集中的时间段内，当一套存储上的云主机过多，且业务繁忙时期，一片面积的主机都达到iops上限时，对于共享存储的性能来说是一个很大的挑战。

因此，从分散风险的角度需要控制一个可用区内单个存储设备上的云主机个数。

黑天鹅思维

量变引起质变是所有事物的共通规律。当IT环境到达一个规模后，所有看起来是低概率的事件都一定会先后发生，肯定会发生。因此不能因为一个异常看起来发生的概率很低或感觉不会发生就忽视它们。

在经历了1，2次黑天鹅概率级别的故障之后，平安云加强了针对应急预案建设的人力投入，并且确定了下面的验证应急预案的原则：

1.    所有的关联组件都有可能出问题，并且有些关联组件有可能短时间内恢复不了，此时恢复预案是否有效。

2.    所有涉及自动化处理的代码逻辑都有可能会出问题，出问题后人工介入是否有效。

3.    针对各种组件，都需要有有效的关联关系管理的CMDB。所有的组件都必须有重启/切换预案，且必须要定期验证其有效性。

各项服务指标的全局把握

云平台本身的可用性与性能指标并不是一直不变的，随着底层资源容量的变化与规模的增大，可用性和性能很有可能在某一天会发生突然的变化，在这之前都会有一些征兆产生。

目前我们通过每日的自动化巡检，E2E不间断测试与在网络/存储端部署监控来保障云平台整体的交付能力，可用性与性能：

1.    每日自动化巡检
AlphaOps平台自动分析从各个层面的产品搜集到的信息，聚合后展现在巡检页面上，每天早班同事会确认巡检页面并且发出关于容量，资源使用状况的巡检报告。

2.    E2E不间断测试
原本测试是偏重于进入正式生产阶段前的功能性验证与并发度验证，属于一次性工作的概念。平安云通过Robot Framework+Jenkins等持续集成与自动化测试工具，编写从云主机申请到负载均衡申请等一系列测试用例，每天不间断的的在生产可用区实施端到端的自动化测试，这样可以实现从用户的角度直截了当发现平台中的潜在问题。

3.    从网络与存储聚合路径点实施监控
平安云在接入交换机上部署了对错误日志的分析告警，在存储的控制器路径上接入了CPU使用率告警，从平台上下层的入口实现了对全局流量与io指标的监控，当发生流量超过阀值告警后通过AlphaOps的性能分析工具可以迅速定位到问题主机，从而采取必要措施保障平台稳定性。（周锋、丘子隽原创）