本文根据DBAplus社群【运维技术月·第二周】分享整理而成

 

讲师介绍

 

大家好，我叫宋辉，目前在新炬网络旗下轻维软件负责运维平台的研发。从03年毕业到现在在IT行业混了有14年多了，其中有12年是在从事运维相关的工作，应该说见证了整个IT行业十多年的大发展，也经历了许多的技术及产品的兴衰起落，感触良多。

 

今天主要跟大家分享一下新一代运维管理平台的建设思路，选这个主题，一方面是因为运维在整个IT生命周期中作用越来越重要，另一方面新的技术及架构给运维带来了新的方向与思考。如何做好运维，成为更多企业及运维人员关心的重点，在这里结合个人在这个行业的一些经验，跟大家做个探讨。

 

一、运维平台的重要性

 

随着信息化建设的不断发展，企业的IT已从原来的一个后台管理职能，转变成了生产营销中心，IT越来越多地渗透到企业生产运营之中。同时IT技术架构也在逐步朝微服务、容器、云化、开源等方向演进，在新的架构规划体系下，IT系统将变得更加复杂，对于平台的运维支撑能力、资源支撑能力等带来更高的要求。

 

在当前的IT系统建设及数据中心规模扩强的速度下，没有一套合适的运维管理平台，运维工作将举步维艰，因此建设一个更可靠、更智能的运维管理平台就显得尤为重要。

 

二、运维平台发展历史

 

广义上的运维平台发展经历了三个阶段：

 

1. 第一个阶段，以专业化网管工具为代表，包括网络设备、主机、数据库、中间件、存储等进行专业监控管理的各种专业化工具。

2. 第二阶段，以ITIL流程化管理为代表的综合网管，通过事件、服务、流程等贯穿监控、变更、资产管理等一系列IT运维管理。

3. 第三阶段，以敏捷、DevOps为代表的运维管理平台，主张开发运维一体化、自动化，强调需求、资源的服务化。

 

目前第三阶段还在迭代演进中，随着人工智能的新起，AIOps的概念开始盛行，因此结合敏捷及智能，成为新一代运维管理平台的建设的核心目标。

 

三、建设原则

 

IT运维管理是一个非常宽泛的范围，整个IT生命周期都跟运维有着关系，运维难做，运维管理平台更难做，这个领域缺少标准和规范，目前也就Gartner对ITOM/ITOA有一些功能范围上的定义。

 

运维管理平台包括监控、ITSM、CMDB、自动化运维操作、日志分析、用户体验、APM、数据库管理、云平台管理、网络管理、业务监控、拨测、运维大数据等这些类别，有些企业建设了很多项目或购买了许多工具，但仍觉得用不上、不好用、用不起来，为什么？

 

个人觉得包括几个方面原因，如管理思维的问题、技术架构的问题、组织文化的问题等。我们今天重点讨论技术方面的问题，个人认为要建好一个运维管理平台，应该遵循如下的原则：

 

（1）运维管理平台包括非常多的功能和模块，不可能一步到位，建议从整体的思路构建，考虑数据上的融合和各子系统之前的协同，一个模块一个模块构建，架构清晰、稳定、方便扩展。模块多了就必须要考虑数据标准的问题，其实跟现在企业各系统之间的数据孤岛是同样一个问题，各平台之间很难产生联动的价值。这个具体的做法，会在后面讲到。

 

（2）运维平台的建设和落地应该由运维来驱动。运维是个非常专业的工作，虽然DevOps的理论已经非常深入人心，但真正解决和提升的更多是在持续集成和交付上的能力，对于专业的运维，渗透得并不是那么成功，如很多互联网公司也尝试过由开发团队来做运维，但也仅限在应用运维这一层，同时导致各自为政，工具建设泛滥的问题。阿里的DevOps也经历了几个阶段，最终成型落地也是让运维带一群开发进行运维平台的建设，提升运维的工具化能力。因此运维平台还是要由运维来主导建设，虽然运维不管业务，但需要站在业务的视角来构建运维平台。

 

（3）以业务为中心来进行构建，打通业务与设备的关联。随着微服务及分布式架构的兴起，在运维管理中，会逐步淡化系统的概念，各种微服务通过流程编排组成了各种面向用户的业务。传统的分层架构逐步往网状架构转型，对于运维平台提出了新的能力上的要求。

 

（4）分阶段实施，先看到成效，再进行能力扩充，不要想着一口吃个胖子，很多企业连基础监控都还没做好，就想着要搞人工智能，有点不切实际。因此充分考虑未来的方向，预留发展空间在平台建设整体规划时，需要充分考虑数据分析能力及运维大数据能力，AI是运维的未来。

 

四、建设思路：7大核心模块

 

新一代运维管理平台，主要是以业务为中心，通过问题快速发现与修复、运维批量操作与自动化，保障业务系统高效稳定运行为目标，实现运维的可视化、自动化及智能化。IT业务系统的软硬件设备及之间的依赖请求关系，组成了一个巨大的多维立体网络，中间的任一个节点出现问题，都可能引发业务系统的异常。

 

对于运维管理平台的目标，一方面是在系统出现问题时能找到真正根源的节点，同时也能分析出其内在的深度的原因（如除了定位到某个应用出了问题，还要能定位到是哪段代码或某条SQL），并进行自动有效的处理；反之要能通过所有节点蛛丝马迹的指标变化，预测系统的运行走势，在出现问题前能采取有效的措施进行处理。

 

为了达到这个目标，结合现在市面的工具，我们将其总结为7个能力的建设，包括：

 

1. 问题发现及自愈能力（监控告警）

2. 自动运维操作能力（自动化运维）

3. 资源配置管理能力（CMDB）

4. 用户体验管理能力（业务监控、用户体验管理）

5. 组件深度性能分析能力（如数据库性能分析、应用性能分析等）

6. 运维大数据分析（如大数据日志、AIOps）

7. 门户及场景集成（数据分析、Portal，运维场景集成）。

 

这7模块各就其位，相互协助，构建新一代运维管理平台的核心。

 

 

下面分别介绍每一个平台模块的建设思路：

 

模块一：构建统一的监控告警平台，实现集中采集和告警，更快速地发现和发析及处理问题。

 

统一监控平台的能力要求包括：

 

覆盖全面，具备统一数据采集的能力。对于监控告警平台的建设，这个是老生常谈了，为什么还要来说？因为很多的监控平台没有用好或用不起来。相对于传统的监控系统，我们更强调设备覆盖的完整性和指标覆盖的完整性，强调统一集中采集平台的能力，而不只是用来做监控和告警，更重要的是用于整个运维数据的采集中心，为后面所有运维决策、人工智能等提供方便的数据来源。对于已经有了许多专业网管的企业，建议进行统一数据采集的融合，提升或新建一个专业网管做为一级网管，其它下沉为二级网管。

 

对于采集回来的指标，一般可通过阀值等配置告警，但现实系统基于阀值的方式存在一定的弊端，无法对指标的异常波动做出准确的预警，如CPU使用率从20%，突然上升到70%，虽然没有触发告警阀值，但实际上系统性能可能已经发生了比较严重的恶化，需要引起关注。我们给某些企业建设的统一监控平台，指标量已达到200多万，我们需要有从这200多万的指标进行异常波动检测及快速预警的能力。一般会利用一些大数据算法进行智能基线的计算及预警。

 

对于监控系统来说，有一个非常重要的能力，就是进行告警，但许多人都觉得告警太多，导致许多人对传统的告警失去信心。

 

我们的经验是，一方面降低对低级别的告警的关注，只对致命或严重级别的事件进行短信通知，这些告警发送给相应专业的维护人员。另一方面，通过技术手段，建立告警依赖和告警关联分析，只对根因告警进行通知，对被影响的告警进行屏蔽。目前基于规则的告警依赖这个实现起来复杂度非常高，而且严重依赖于CMDB的能力，基于算法的告警关联分析准确度有待考验，我们更希望在基于算法的方向，来解决这个问题，目前已取得初步成效，后面有机会可以跟大家做进一步的分享。

 

提升了问题发现的能力、预警通知的能力后，接下来就需要构建问题自愈的能力，这里需要引用关联我们另外一个模块的能力，就是自动化运维平台，通过调用自动化运维平台的脚本或流程平台，实现问题的快速自愈，即通过事件与自动化运维操作的关联，构建IT系统的自愈能力。

 

这样我们基本上就能构建起一个非常智能和敏捷的监控系统，实现初步的机器管理机器的目标，达到自动的事件闭环管理。

 

模块二：建立自动化运维操作能力，以操作及流程或场景为闭环，构建集中运维操作平台。

 

集中运维操作平台的能力要求包括：

 

以集中操作中心为目标，覆盖对数据库、中间件、主机、网络设备、存储、云平台、硬件甚至应用程序接口的操作管理、批量调度、作业任务管理能力。当后面该平台成为整个运维的操作调度中心，这样做的好处就显而易见了，打通所有系统软硬件的操作能力后，将非常容易构建起基于任何流程的运维自动化的业务场景，通过技术手段贯打通原来的组织的壁垒。

 

举个例子，按照原来的流程，如果需要新上线一个应用，需要涉及云平台划分虚拟机资源、安装配置系统软件、开通网络防火墙、进行应用部署、进行安全扫描及加固、部署接入监控等事项。在传统企业当中，往往涉及多个部门或多个团队，如基础平台、数据库、中间件、网络、开发、安全、监控等，按照现有的基于流程的方式，需要提N个工单，花上1-2个月的时间才能搞定这个事情。但如果基于集中操作运维的平台的能力，把应用上线做为一个业务场景，把所有步骤能编排成一个大的流程，自动去执行，中间的关键步骤前可加入审批的控制，这样一个流程可能1-2天就跑完了。这就是技术的价值。

 

相对于业务化的场景，对于平台的建设，我们要提供的就是构建这些场景的基础能力。一方面是兼容各种软硬件设备的操作能力。如能对防火墙执行一个策略下发，能对云平台执行一个新建虚拟机的操作。目前有很多的开源工具，如Ansible、Saltstack等，在自动化运维领域做得很好，但这两个工具核心的能力还是在对于主机的脚本执行管理能力，需要通过自建或扩充对于各种软硬件设备的操作支持能力。

 

平台的基础能力除了兼容各种设备的操作能力，还包括文件上传、下发、脚本执行、配置管理、软件包管理、流程编排等基础能力。前面提到的对各种软硬件设备的操作能力在平台上就体现成一个个的原子操作，通过流程编排，可以快速将各种原子操作编排成一个一个的业务场景，如上线部署、安全扫描、健康巡检、安装部署、故障诊断、资源开通等各种能力。

 

在此基础上，我们可以将自动化运维平台上集成的各种操作、流程、场景封装成API，对外系统提供调用及操作。如可以提供给监控平台，进行故障自愈；提供给CMDB进行配置及关系自发现等。

 

对于自动化运维平台，需要非常关注安全的管理，因为基于此平台基本可以对整个IT系统环境执行任何操作，这个具有很大的安全隐患。当然有许多互联网公司的运维管理理念是用人不疑，充分授权，这种方式对于效率是非常大的提升，但在传统行业不一定能行得通。因此平台需要有安全管理能力，能对原子操作的执行、执行的对像、时间进行权限控制，另外支持对整个操作过程的审计，对于敏感操作能进行二次授权等。这样安全和效率才能兼得。

 

模块三：构建统一资源管理能力，成为整个运维平台的资源中心、配置中心。

 

要求具备的能力包括：

 

CMDB其实也是个老生常谈的问题，各大企业做CMDB的项目非常多，但成功的不多，最主要的原因就是把CMDB当成了excel在管，搭个平台、建个模型把各种配置数据统一录入到系统里面就结束了。这样的CMDB当然会失败。另外CMDB要以业务为中心，更多的关注在资源管理，能提供资源的整体视图，很好的展现业务及应用与资源的关联关系，除了系统视图、逻辑视图、物理视图外，需要增加业务流程视图，管理业务流程各节点与各服务之前的关系。

 

CMDB应该成为整个运维管理平台的资源及配置管理中心，成为运维的第一入口。如监控、自动化运维等均涉及大量的资源管理，不允许各自建设一套各自的资源体系，监控和自动化运维操作的资源应该来源于CMDB。整个大的流程是应该在设备上架开通后，录入CMDB，再从CMDB接入监控或运维；设备下线后，先从监控及自动化运维的平台进行监控及运维操作下线，再从CMDB进行下线。在设备没有录入CMDB时，不允许接入监控及自动化运维。这样就可以避免CMDB数据更新不及时的问题，按照CMDB管理上的经验，如果都不需要接入监控和自动化运维的设备，肯定是属于三不管的设备，上面也不会有什么重要的业务，就算CMDB里面没有数据，也无关紧要。当然这些管理上的要求，必须通过技术手段上的限制去落地。

 

通过把CMDB做为整个运维管理平台资源的入口（其实这也是CMDB数据消费的非常大的一个场景），可以解决CMDB设备数据不完整的问题，甚至说不费吹灰之力。CMDB的配置数据及关系数据，可以通过监控或自动化运维平台去进行自发现，确保数据的完整性。

 

对于CMDB数据的完整性，需要除了管理上的要求，需要构建自发现的能力，对于配置项的属性及关系，大部份可以通过自发现来实现。CMDB应该与监控系统及自动化运维平台保持非常好的联动关系，监控及自动化运维的资源数据来源于CMDB，同时监控及自动化运维作为CMDB配置项属性及关系数据自发现的最主要的来源。这样无须独立为CMDB构建复杂的自发现模块。

 

CMDB关系数据不完整，另外有很大一个方面的原因是，设备量太多，维护团队很难知道哪些配置项关系有问题，无从下手。平台应该提供业务视角的数据校验的能力，如一个业务系统，包括应用、数据库、中间件、主机、存储、网络等很多设备，这些设备构成了一个拓扑关系，但如果数据不完整，这个拓扑关系就是不完整的，我们很容易看到哪里出现了中断，去把这个关系补上就好了。所以我们虽然很难发现一个完整的业务系统拓扑，但通过数据校验，能发现拓扑关系的缺失，再提供快速便捷的修复能力，这样关系就能慢慢完整了。这也符合CMDB的数据众包修复原则。

 

关于CMDB的数据消费，数据越完整消费价值越大，把资源数据提供给监控、自动化运维平台进行接入，把关系数据提供给监控平台进行基于规则的告警关联分析、根因分析等。与监控数据结合进行维保分析，对于低频使用的机器，可以降低维保级别等。对于低频使用机器，结合上线时间，进行设备下线、退网提醒等。CMDB结合监控、自动化运维等平台，可以不断完善数据，也可以构建更多更有价值的消费场景。

 

CMDB一半是技术，一半是管理，成功的CMDB需要重视CMDB看不见的能力与价值。

 

CMDB数据消费场景（基于规则的告警根因分析）

 

模块四：关注用户体验，运维需要重视和关注业务及用户。

 

之前很多企业的运维是不关注业务的，只是在业务反馈用户投诉或系统出现故障时，才会响应分析系统平台的问题。这种方式是非常不合适的，往往只能做到被动响应，无法做到主动预防。用户体验包括以下几个部份的内容：

 

1. 浏览器、APP上终端用户的真实体验，这部份数据可以通过流览器插码及APP SDK收集。如现在比较流行的APM for APP及Browser模块。

2. 通过应用拨测的方式，在各IDC部署拨测终端，模拟用户对系统平台进行拨测，对响应时长，错误率、成功率等进行分析。

3. 业务系统平台数据侧的统计与分析，如基于流程数据的统计、基于应用日志的统计，对系统业务量及响应时间等用户体验数据进行统计与分析。 

4. 利用抓包解码的方式，对网络流量数据进行解码，分析与统计终端用户的体验数据。

 

实际落地时需要结合企业使用的技术架构进行选择，也可以采用多种技术手段结合的方式进行。在这个领域互联网公司有非常成熟的经验值得借鉴。

 

模块五：新一代运维管理平台，需要引入对用户体验数据的监测与分析，结合系统平台数据，真正做到端到端的监测与分析能力。

 

应用组件深度分析能力，通过监控或智能告警等一般可以定位到一个软硬件设备的状态出现异常，但异常的真正原因是比较难排查的。重启、扩容应用或许可以短期内解决问题，但真正的原因可能是代码的缺陷或低效的SQL语句或数据库本身的资源争用导致的。

 

目前大多数的应用还是属于数据密集操作型的，也就是重数据库的，对于这些应用、应用本身代码级的诊断和数据库的深度诊断分析能力要求更高。应用组件深度分析能力主要体现在：

 

• 应用端的深度分析，利用应用探针技术或应用日志埋点，对应用代码级的方法、请求进行分析，实现代码级的诊断，在应用请求量、成功率、响应时间等出现异常时能快速定位问题节点及代码。这个在当前的微服务和分布式架构下显得尤为重要，蜘蛛网式的应用架构，在出现性能问题时，如果没有明确的调用链路分析手段，将是非常致命的。

 

• 数据库的深度分析，对于目前企业大多数应用来说，数据库仍处于非常核心的地位，对于数据库的维护管理显得尤为重要，一条SQL语句搞跨一个系统的事经常出现，不管是Oracle，还是DB2、MySQL，SQL Server，这些数据库都需要最高级别的深度监控和分析，包括数据库低效SQL的分析、一键式的性能诊断、SQL语句的自动优化、SQL上线前性能审核、SQL版本比对分析等。许多企业都有好几种关系型数据库，构建一个有强大SQL性能管理为核心的数据库统一管理平台非常关键。我们在为许多大型企业构建新一代运维管理平台时，都会重点考虑构建数据库的深度分析管理能力。

 

 一键式的数据库深度分析

 

模块六：大数据日志分析及运维大数据能力

 

前面已经提到AI是运维的未来，任何现象都可能跟某个隐含的数据有密切的关系。因此依赖于大数据、人工智能等新型的技术，将人对问题、故障分析的经验移植到代码上，甚至在不久的将来，对于运维，机器干得比人还要出色。当然对于真正的AIOps我们还处在很初级的阶段，但必须从现在开始准备。

 

第一步先要把数据集中起来，建议先构建大数据日志分析平台，形成大数据分析能力，把设备日志数据、应用日志数据集中起来，提供基本的关键字搜索、统计、告警、趋势分析等能力。这些是对于传统监控告警一个非常重要的补充。

 

依据日志数据中的标签、埋点及关系，构建基于日志数据的场景分析能力。应用场景包括业务指标分析、业务链路分析、接口性能分析、用户体验分析、故障隐患分析、故障根因分析等。

 

接下来考虑基于大数据日志分析平台构建运维大数据分析能力，将统一监控平台的海量指标数据同步到日志分析平台，构建成运维大数据平台，一方面，基于这些数据可以进行大量主题的分析，如容量分析、性能分析、事件分析、隐患分析等。另一方面，利用监控告警事件、CMDB资源关系、设备及应用日志，进行关联分析，同时利用各种人工智能、机器学习算法，进行基于人工智能的运维分析与诊断。

 

模块七：集成平台构建运维场景集成能力

 

如前面的架构图所示，整个平台分为三个层次：监控及运维操作、运维大数据分析及门户与集成平台。集成平台主要用于下面两层能力的自定义构建与场景化，通过下面两层的服务化接口，构建面向不同维护人员的运维场景，以支撑更多的个性化应用。利用各种报表工具，进行多维度的自定义数据分析与运维能力集成。通过集成平台，构建运维一体化PaaS平台，提供面向业务的运维监控、运维操作及决策分析平台。

 

集成平台通过调用平台服务化API接口，提供自定义场景集成能力，快速构建各种应用场景。如下图所示，通过CMDB的数据查询接口在平台自动构建一个系统拓扑，通过采集监控模块的API接口把系统运行指标数据、告警事件映射到拓扑图上，通过自动化运维模块API，把常见的运维操作能力集成到拓扑图上，这样可以快速构建一个可视化的智能运维场景，这些都无须运维人员有任何开发能力，大大降低运维开发的难度。

 

 

五、小结

 

建设一个具有先进性、扩展性及未来性的新一代运维管理平台非常重要，但同样难度也不小，个人认为整体上的规划至关重要，有了清晰的战略才能有良好的落地与效果。7种能力就像7种武器，互相搭配，各舞所长，才能发挥最大作用。

 

今天给大家讲的主要是思路，很少涉及具体的技术，里面包括了许多的内容，每个企业的实际情况及IT发展阶段、甚至管理模式都不太一样，大家可以选择性的参考与借鉴。运维是企业IT的基础，未来运维的挑战只会比现在更大，及早构建一个新一代的运维管理平台意义非凡，我们在此方面积累了许多成功的经验，也具有了一定的产品体系，欢迎大家与我们进行更深入的探讨。

 

Q&A

 

 

Q1：目前运维自动化实践在哪个行业和客户落地的比较成熟？

A1：自动化运维来说，在互联网落地成熟度较高，因为互联网行业的设备标准化能力较好。但传统行业随着云的普及和落地，标准化程度不断提高，自动化运维大有可为。

 

Q2：中间都会用到哪些软件？

A2：这个是一个大的方案，里面有很多的平台模块，形成合力。里面具体的一些点，可以有很多开源的解决方案，如监控的Zabbix、自动化运维的Ansible，CMDB也有开源的。但开源的方案一般较难打通和基于企业业务情况构建场景。

 

直播链接回放

 

 https://m.qlchat.com/topic/details?topicId=2000000218877425&null