智能运维平台产品设计方案（智能运维管理系统设计方案）

本篇文章给大家谈谈智能运维平台产品设计方案，以及智能运维管理系统设计方案对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享智能运维平台产品设计方案的知识，其中也会对智能运维管理系统设计方案进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、IT运维的产品
• 2、华为AIOps使能服务加速新基建运维智能化转型
• 3、互联网时代的网络自动化运维
• 4、开发自动化运维架构六要素
• 5、如何做好运维监控？

IT运维的产品

1.蚁巡运维平台
蚁巡运维平台是一台简单实用的运维设备，只需要接入网络，按向导简单配置，就可以使用。蚁巡能自动发现需要监控的网络设备、服务器和服务，主动巡检网络设备、服务器和服务的运行状态，发现业务系统隐患，智能预警，保障业务正常运转。蚁巡以业务为中心，自动探测网络设备、服务器和服务的可用性、性能、使用率和吞吐量，对数据进行分析处理，为用户呈现直观易于理解的图表，发现问题及时运维，并记录运维日志。蚁巡简单实用，投资成本低，是业务系统运维的好帮手。
2、EXPRESSCLUSTER
NEC的高可用集群产品EXPRESSCLUSTER是支持Windows和Linux平台的专业集群中间件软件，可用于构建高可用性、高可靠性以及高扩展性的集群系统。不论是低成本的纯软件镜像集群，还是使用磁盘阵列的大规模集群系统，EXPRESSCLUSTER都可为您轻松构建，从而为企业的24x365的关键业务应用提供了强大的保障。拥有高可靠性.高可用性---在要求持续运行的关键业务系统中，由于服务器宕机等故障所造成的业务停止将带来无法估量的损失。在由EXPRESSCLUSTER构建的集群系统中，即使某台服务器发生故障，用户业务和数据也可迅速切换到健康的服务器上，从而保证了整个系统对外服务的正常，为企业24小时x365天的关键业务应用提供了强大的保障。 远程管理.简便操作---提供标准的GUI用户界面和基于Web的跨平台控制终端这两种集群管理方式，可远程管理集群，极大的方便了系统管理员的操作和管理。
3、NetGain Enterprise Manager
NetGain Systems公司提供的NetGain EnterpriseManager（简称EM）是完全以业务为主线的对用户IT基础架构实时监测与管理的解决方案。
NetGain EM作为世界上第一款即插即用的硬件IT管理设备，通过基于WEB页面操作，帮助用户轻松实现对IT业务系统管理，确保核心业务稳定运行。这种全新的技术实现方式大大简化实施和使用过程，使用户对IT管理的满意度达到前所未有的高度。
4、Tivoli
IBM IT运维和服务管理解决方案。IBM软件Tivoli 提供了智能基础设施管理解决方案，有助于客户在随需应变世界中洞悉和主动管理 IT 系统的商业价值。Tivoli软件凌驾于客户系统的单个组件之上，它利用基于策略的资源分配、安全、存储和系统管理解决方案，提供了管理和优化关键 IT 系统的集成视图。
5、NETBASE
NETBASE作为定位于全IT架构系统管理，尤其注重分析运维的特点，注分析使用者的特点，为系统管理人员提供了“基于网络平台，面向客户应用”的网络资源与应用服务资源的全IT架构管理系统及解决方案，是用来帮助IT运维人员，缩短故障解决时间和提高工作效率的有力工具。它可以全面主动的采集IT环境的状态信息和性能数据。包括:网络设备、服务、系统、数据库、中间件、应用软件和行业专有业务软件；为您集中展示业务系统各个IT环节和组件的整体状态试图；监测到IT环境的状态或性能异常时能及时报警；发出颜色警报；通过颜色警报、电子邮件或手机短信等多种形式结合的方式，将IT系统的事件自动及时通知到您；保存历史性能和故障数据，供您查询分析。NETBASE提供了完整的产品，以监测整个IT基础设施，完成从底层环境，到高层业务应用的全面运维管理。已在政府机构及金融、电力、医疗、教育等行业得到了广泛的应用。
6、Guoyu Ahoova Software
Ahoova是基于ITIL V3和ISO20000国际标准推出的企业级流程化IT服务管理软件（ITSM），也是一种帮助企业或组织机构有效提升业务服务水平的解决方案（Business Service Promotion Solutions），产品国际化程度高，面向全球市场；包括基于ITIL框架的各类相关功能模块：门户管理、请求（事件）管理、问题管理、变更管理、配置项（固定资产）管理、知识库管理等，功能齐全。整套系统以JAVA开发，B/S结构，可维护性、可扩展性、安全性、跨平台能力、客户自定义能力等等都很强，并且可以集成其它的主流企业级应用系统、呼叫中心等等。该产品广泛应用于海内外的大型企事业单位、连锁品牌企业、制造业及IT外包商等领域。
7、Apex ITManager
泰信科技有限公司IT运维和服务管理解决方案。公司旗舰产品Apex ITManager已经在电信、电力、政府、教育、金融、医疗、公安、石油石化等各行各业得到了广泛的应用，为广大客户从根本上解决了困扰已久的IT运维难题，大大提高了用户对网络的利用效率和服务质量。
8、Broadview
Broadview的系统架构清晰，采用层次化、模块化的设计理念： 系统整体功能覆盖全面，各模块功能独立、松散耦合，便于根据需求自由组合。同时Broadview系统具有显著的开放性和持续发展能力，通过它的Probe插件体系和数据交换接口，可平滑的扩展系统功能并与第三方产品进行集成。
9、BTNM
BTNM通过对组成网络服务的IT基础架构各方面（从网络设备到服务的物理载体—服务器，再到各种应用程序）进行分层透明的监视，最终实现了以IT运维为对象的综合管理。BTNM丰富的管理模块，构成了这一完整的管理体系。
10、Mocha
摩卡IT运维和服务管理解决方案。摩卡软件有限公司，成立于1998年，是目前亚太地区最大的软件产品和解决方案提供商之一，多年来致力于IT运维管理软件的研发。
11、Siteview
SiteView网管软件是世界领先的网管产品。它以.net开发，采用分布式架构，支持多国语言，界面美观、细节完善。SiteView专注对局域网、广域网和互联网上的系统应用、服务器和网络设备的故障监测和性能管理，是集中式、跨平台的系统管理软件。
12、卡西亚
卡西亚作为目前IT运维行业布局移动终端管理较为领先的企业，其成长经历与Salesforce异曲同工 。在卡西亚之前，微软、赛门铁克、IBM以及蓝代斯克等企业已经是中国IT运维市场的老面孔了。但卡西亚敏锐地发现，市场上真正功能全面且简单易用的产品并不多，更无论贯穿始终的自动化能力了。因此运维市场，尤其是桌面运维，充斥了大量的处女地，市场潜力巨大。卡西亚是基于Web的新一代自动化IT系统管理解决方案 ，用户可以通过一个集中的管理控制台来安全掌管其基础架构、并完全透明、远程地管理服务器、台式机、移动设备（笔记本电脑和智能手机等）以及嵌入式设备。
13、TRAMIS
科技风险分析管理综合解决方案（TRAMIS – Technical Risk Analysis Management Integrated Solution）发源并服务于银行业，为信息科技部门提供客观数据采集、审计监督和数据分析，辅助以银行业普遍使用的信息科技运行维护管理工作流程，针对银行业进行设计开发的，基于过程的综合分析管理平台。
TRAMIS基于信息科技系统的各种客观数据，提供多种科技风险规避和审计监督的渠道，为客户提供综合的科技风险分析和管理平台，协助客户提高信息科技系统运行管理的效率。其功能也适用于电信、电力、政府、公共事业、企业等各个行业的信息科技部门对于计算机和网络系统的运行维护和分析管理。

华为AIOps使能服务加速新基建运维智能化转型

人工智能经历了六十多年的浮浮沉沉，随着计算算力的进步，算法的创新和互联网发展下的海量数据积累，人工智能技术未来十年将焕发出新的活力，成为最具有冲击力的 科技 发展趋势之一。

在HUAWEI CONNECT 2020期间，华为基于对电信领域的深刻理解和多年经验沉淀，带来了《AIOps使能服务》的分享，旨在结合电信领域应用场景，使能网络达到自动、自愈、自优和自治的自动驾驶网络，提升整个网络的效率，降低OPEX。

AIOps成为电信网络运维智能化转型趋势

随着“5G 新基建”的加速实施，数字经济发展迎来新的动能。不仅推动投资消费的快速成长，还将驱动各行业的数字化转型升级。随之而来的是网络问题复杂化与业务质量高要求的挑战，运维能力的演进成为电信网络能否持续发挥效能的关键因素。

电信网络运维作业正面临问题发现被动（75% 问题由用户发现），故障根因定位难（90% 时间用于问题定位）的业务挑战。同时，各专业运维支撑系统功能也面临开发周期长，闭环流程自动化程度低的技术瓶颈。因此，运营商期望引入AI实现智能运维，做到主动维护和故障自愈。

在运维支撑系统的演进方向上，AIOps（运用AI及大数据技术解决运维问题）已经成为电信行业运维智能化转型的趋势和共识：构建AIOps平台能力，支撑不同运维场景应用。在未来五年内，电信行业市场的运维系统和平台将加速AI能力的升级，成为电信领域AI应用的核心场景，投资占比达到60%。

因此，AIOps已经成为电信网络运维智能化转型趋势。通过构建电信领域AIOps平台能力，快速实现智能运维升级。

华为AIOps助力网络提升可靠性及使能智能化运维

按照自动驾驶网络的等级定义，运维的智能化目标是要实现全域、全流程的预测性运维，自动监控、定位、自愈。

华为AIOps使能服务作为自动驾驶网络AI引擎NAIE的核心能力，基于AI平台，提供了一系列的电信领域AIOps原子能力以及组合编排能力，使能网络管控析单元、智能运维解决方案等运维系统，最终帮助运营商打破原有的烟囱式建设方式，将各专业运维系统的应用与AI能力解耦，采用分层的服务化架构对接共享数据中心，集中提供AIOps能力，适配运维场景应用百花齐放的需求。

如下是华为AIOps使能服务预组合编排好的服务，可开箱即用：

kpi异常检测服务， 快速智能识别海量kpi/kqi的异常情况，广泛应用在网络性能和质量监控场景；

故障识别与根因定位服务， 根据海量告警结合对应网络拓扑和传播知识，实时识别故障及根因网元及告警，可自动学习知识规律，保证持续优化，可广泛应用在各种网络场景；

日志异常检测服务， 实现日志的自动分类和统计规律发掘，实时监控出系统的异常行为和相关日志，可广泛应用在IT及电信网络场景；

硬盘异常预测， 可智能预测短期内（14天）的硬盘故障，以采取规避预防措施，以免对业务产生影响，广泛支持主流厂商的HDD及SSD型号。

细数华为AIOps使能服务四大核心竞争力

提供丰富的AIOps原子能力： AIOps的原子能力覆盖运维全流程，包括预测、检测，定位、执行。原子能力库支持流量预测，故障预测，KPI异常检测，日志异常检测，CHR异常检测，异常关联分析，事件聚合，根因定位等20+原子能力。

作为电信领域的AIOps使能服务，具备两个核心特点：一是基于华为电信领域的经验，原子能力将AI算法与电信领域行业知识融合，预制了默认的电信领域模型参数，同时支持现网运行态的调优，解决当前通用算法模型在具体行业落地效果差的难题。目前，已经在现网得到了规模验证。

另一个是AIOps原子能力采用标准化模型规范，统一数据输入，参数配置，结果输出等接口。为AIOps单点原子能力到灵活的组合串接提供了基础。

组合编排与DevOps能力： 通过组合编排功能，使用者可选择业务场景所需的AIOps原子能力，通过可视化方式完成流程串接，并进行业务泛化参数配置，包括数据接入方式，模型参数，内置电信领域泛化参数，事件通知方式、可视化Dashboard等配置。上述能力支持可视化编排或接口调用方式实现。此外，基于NAIE平台训练服务，AIOps的原子能力库支持使用者根据实际业务需求开展算法模型的创新与开发，不断扩展AIOps能力。NAIE的生态服务也提供专业的人员培训赋能。

支持电信领域数据对接： 支持KPI、告警、日志、xDR等电信领域主流运维数据。支持Kafka，数据库，文件系统，Restful等电信运维系统的主流数据对接方式。AIOps使能服务提供通用的数据源对接和标准化数据治理组件，通过配置项快速建立与运维系统的数据源连接，通过SDK将不同的数据类型和格式治理成标准化的AIOps原子能力输入集，用于模型训练和推理。

场景组合服务： 围绕运维全流程（发现、分析、处理）提供预制典型场景组合应用，快速接入运维流程。

综上所述，华为AIOps使能服务作为智能运维AI能力引擎，融合AI的技术优势与华为在电信领域的专业优势，为运维系统的智能化演进提供AIOps平台能力支持，助力到各专业运维系统的应用快速上线，让运维专家专注场景应用设计和业务目标达成。

华为AIOps助力运营商及企业网络打造最佳实践

在KPI异常检测方面，电信网络中，通过KPI来预测和检测网络问题是最普遍的场景。通过AI算法基于 历史 数据自动生成每个KPI的动态门限，避免传统静态门限带来的误报和漏报。

华为NAIE融合了电信领域的运维业务特点，提供单指标/多指标检测，异常原因关联分析，模型的自学习调优等关键能力。目前已经用在核心网，无线，数通等不同业务领域。国内某运营商采用了核心网KPI异常检测服务以后，实现提前5小时识别异常并主动预警，降低了业务损失。

在告警根因定位方面，发现异常或者故障之后的定位是运维流程中的难点，如何准确的将多维度的异常、告警等事件进行汇聚，减少故障噪声，准确定位到具体原因？这些工作目前主要依赖专家经验或者手工分析，而且受限于分析算力和知识信息，效果并不好。

华为NAIE AIOps通过AI算法与业务的融合，支持多类异常/告警等事件的智能故障定位，自动实现时间，拓扑和故障传播图等维度的事件汇聚和根因定位。目前已经应用到无线接入网等业务领域，经过实际验证，无效上站减少60%，根因识别准确率85%+，运维效率整体提升15%。

写在最后，电信领域AIOps落地的关键是需要将行业知识与AI技术融合。网络运维系统的AIOps能力构建的趋势是业务与能力解耦，做到AIOps能力的复用、拉通，支持，适配运维场景应用百花齐放和快速上线迭代的需求。

因此，AIOps使能服务作为智能运维AI能力引擎，融合AI的技术优势与华为在电信领域的专业优势，为运维系统的智能化演进提供AIOps平台能力支持，助力到各专业运维系统的应用快速上线，让运维专家专注场景应用设计和业务目标达成。目前，华为AIOps使能服务已经在无线，核心网，数通等网络域得到了广泛的应用。

互联网时代的网络自动化运维

互联网时代的网络自动化运维

互联网上有两大主要元素"内容和眼球"智能运维平台产品设计方案，"内容"是互联网公司(或称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 Database) 配置管理数据库(以下简称：CMDB)，将IT基础架构的所有组件存储为配置项，维护每个配置项的详细数据，维护各配置项之间的关系数据以及事件、变更历史等管理数据。通过将这些数据整合到中央存储库，CMDB可以为企业了解和管理数据类型之间的因果关系提供保障。同时，CMDB与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。可实现IT服务支持、IT运维以及IT资产管理内部及三者之间的流程整合与自动化。在实际的项目中，CMDB常常被认为是构建其它ITIL流程的基础而优先考虑，ITIL项目的成败与是否成功建立CMDB有非常大的关系。

3.百度自动化运维：部署+监控+业务系统+关联关系

百度主要面临的运维挑战包括：突发的流量变化、复杂环境的关联影响、快速迭代的开发模式以及运维效率、运维质量、成本之间的平衡等等。百度的运维团队认为，当服务器规模达到上万台时，运维视角需要转为以服务为粒度。万台并不等于"百台*100";机器的运行状态，也不再代表业务的工作状态;运维部门为研发提供前置服务，服务与服务之间关系也随着集群的扩大逐渐复杂起来。

图3.百度自动化运维技术框架

百度的自动化运维技术框架，划分为部署、监控、业务系统、关联关系四大部分，整个框架更多突出了业务与IT基础设施的融合，注重"关联关系"的联动。所谓关联关系，主要是指任务与任务之间的时序依赖关系、任务与任务之间的数据依赖关系、任务与资源之间的引用依赖关系，分别对应到任务调度、数据传输、资源定位的服务流程中，形成了多条服务链。

关联关系的运维与业务较强相关，需要有一套系统能够理清楚关系的全貌，从而在复杂的服务链上，定位运行所在的环节，并在发生故障时预估影响范围，及时定位并通知相应的部门。在这样的一套系统中，自动化监控系统非常重要。百度的技术监控框架，主要通过数据采集、服务探测、第三方进行信息收集，进行监控评估后交给数据处理和报警联动模块处理，通过API接口进行功能扩充(如图4所示)。

图4.百度自动化技术监控框架

其实无论是BAT等互联网企业还是其他行业的企业，在IT建设中都会遵循IT基础架构库(ITIL)或ISO20000服务管理的最佳实践，采用自动化IT管理解决方案以实现重要的业务目标，如减少服务中断、降低运营成本、提高IT效率等等。随着ISO20000、ITIL v3.0的发布和推广，两者已经成为事实上的某种标准。在当今企业IT管理领域，对两个标准有着很迫切的需求。特别是ISO20000的认证要求，已经成为企业越来越普遍的需求 。ITIL v3.0包含了对IT运维从战略、设计到转换、运营、改进的服务全生命周期的管理，相关方案往往覆盖了多个领域和多个产品，规划实施和工具的选择会比较纠结。如果选择开源的工具，从CMDB开始就会遇到很多的开发工作，对于很多注重成本收益比的企业，可以参考，但由于无法保证性能与效果并不一定适用。因此，成熟的商业方案会是更好的选择。

最新的iMC V7版本，围绕资源、用户、业务三个维度进行创新，发布了SOM服务运维管理(基于ISO20000、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等，制作平台化监控集成环境，实现全方位监控(如图所示)。

;

开发自动化运维架构六要素

运维自动化是我们所渴望获得的，但是我们在一味强调自动化能力时，却忽略了影响自动化落地的一个关键因素。那便是跟运维朝夕相处，让人又爱又恨的业务架构。
要点一：架构独立
任何架构的产生都是为了满足特定的业务诉求，如果我们在满足业务要求的同时，能够兼顾运维对架构管理的非功能性要求。那么我们有理由认为这样的架构是对运维友好的。
站在运维的角度，所诉求的架构独立包含四个方面：独立部署，独立测试，组件化和技术解耦。
独立部署
指的是一份源代码，可以按照便于运维的管理要求去部署、升级、伸缩等，可通过配置来区分地域分布。服务间相互调用通过接口请求实现，部署独立性也是运维独立性的前提。
独立测试
运维能够通过一些便捷的测试用例或者工具，验证该业务架构或服务的可用性。具备该能力的业务架构或服务让运维具备了独立上线的能力，而不需要每次发布或变更都需要开发或测试人员的参与。
组件规范
指的是在同一个公司内对相关的技术能有很好的框架支持，从而避免不同的开发团队使用不同的技术栈或者组件，造成公司内部的技术架构失控。
这种做法能够限制运维对象的无序增加，让运维对生产环境始终保持着掌控。同时也能够让运维保持更多的精力投入，来围绕着标准组件做更多的效率与质量的建设工作。
技术解耦
指的是降低服务和服务之间相互依赖的关系，也包含了降低代码对配置文件的依赖。这也是实现微服务的基础，实现独立部署、独立测试、组件化的基础。
要点二：部署友好
DevOps 中有大量的篇幅讲述持续交付的技术实践，希望从端到端打通开发、测试、运维的所有技术环节，以实现快速部署和交付价值的目标。可见，部署是运维日常工作很重要的组成部分，是属于计划内的工作，重复度高，必须提升效率。
实现高效可靠的部署能力，要做好全局规划，以保证部署以及运营阶段的全方位运维掌控。有五个纬度的内容是与部署友好相关的：
CMDB配置
在每次部署操作前，运维需要清晰的掌握该应用与架构、与业务的关系，为了更好的全局理解和评估工作量和潜在风险。
在织云自动化运维平台中，我们习惯于将业务关系、集群管理、运营状态、重要级别、架构层等配置信息作为运维的管理对象纳管于CMDB配置管理数据库中。这种管理办法的好处很明显，集中存储运维对象的配置信息，对日后涉及的运维操作、监控和告警等自动化能力建设，将提供大量的配置数据支撑和决策辅助的功效。
环境配置
在运维标准化程度不高的企业中，阻碍部署交付效率的原罪之一便是环境配置，这也是容器化技术主要希望解决的运维痛点之一。
腾讯的运维实践中，对开发、测试、生产三大主要环境的标准化管理，通过枚举纳管与环境相关的资源集合与运维操作，结合自动初始化工具以实现标准环境管理的落地。
依赖管理
解决应用软件对库、运营环境等依赖关系的管理。在织云实践经验中，我们利用包管理，将依赖的库文件或环境的配置，通过整体打包和前后置执行脚本的方案，解决应用软件在不同环境部署的难题。业界还有更轻量的容器化交付方法，也是不错的选择。
部署方式
持续交付原则提到要打造可靠可重复的交付流水线，对应用软件的部署操作，我们也强烈按此目标来规划。业界有很多案例可以参考，如Docker的Build、Ship、Run，如织云的通过配置描述、标准化流程的一键部署等等。
发布自测
发布自测包含两部分：
应用的轻量级测试；
发布/变更内容的校对。
建设这两种能力以应对不同的运维场景需求，如在增量发布时，使用发布内容的校对能力，运维人员可快速的获取变更文件md5，或对相关的进程和端口的配置信息进行检查比对，确保每次发布变更的可靠。
同理，轻量级测试则是满足发布时对服务可用性检测的需求，此步骤可以检测服务的连通性，也可以跑些主干的测试用例。
灰度上线
在《日常运维三十六计》中有这么一句话：对不可逆的删除或修改操作，尽量延迟或慢速执行。这便是灰度的思想，无论是从用户、时间、服务器等纬度的灰度上线，都是希望尽量降低上线操作的风险，业务架构支持灰度发布的能力，让应用部署过程的风险降低，对运维更友好。
要点三：可运维性
运维脑海中最理想的微服务架构，首当其冲的肯定是可运维性强的那类。不具可运维性的应用或架构，对运维团队带来的不仅仅是黑锅，还有对他们职业发展的深深的伤害，因为维护一个没有可运维性的架构，简直就是在浪费运维人员的生命。
可运维性按操作规范和管理规范可以被归纳为以下七点：
配置管理
在微服务架构管理中，我们提议将应用的二进制文件与配置分离管理，以便于实现独立部署的目的。
被分离出来的应用配置，有三种管理办法：
文件模式；
配置项模式；
分布式配置中心模式。
限于篇幅不就以上三种方式的优劣展开讨论。不同的企业可选用最适用的配置管理办法，关键是要求各业务使用一致的方案，运维便可以有针对性的建设工具和系统来做好配置管理。
版本管理
DevOps持续交付八大原则之一“把所有的东西都纳入版本控制”。就运维对象而言，想要管理好它，就必须能够清晰的描述它。
和源代码管理的要求类似，运维也需要对日常操作的对象，如包、配置、脚本等都进行脚本化管理，以备在运维系统在完成自动化操作时，能够准确无误的选定被操作的对象和版本。
标准操作
运维日常有大量重复度高的工作需要被执行，从精益思想的视角看，这里存在极大的浪费：学习成本、无价值操作、重复建设的脚本/工具、人肉执行的风险等等。
倘若能在企业内形成统一的运维操作规范，如文件传输、远程执行、应用启动停止等等操作都被规范化、集中化、一键化的操作，运维的效率和质量将得以极大的提升。
进程管理
包括应用安装路径、目录结构、规范进程名、规范端口号、启停方式、监控方案等等，被收纳在进程管理的范畴。做好进程管理的全局规划，能够极大的提升自动化运维程度，减少计划外任务的发生。
空间管理
做好磁盘空间使用的管理，是为了保证业务数据的有序存放，也是降低计划外任务发生的有效手段。
要求提前做好的规划：备份策略、存储方案、容量预警、清理策略等，辅以行之有效的工具，让这些任务不再困扰运维。
日志管理
日志规范的推行和贯彻需要研发密切配合，在实践中得出的经验，运维理想中的日志规范要包含这些要求：
业务数据与日志分离
日志与业务逻辑解耦
日志格式统一
返回码及注释清晰
可获取业务指标（请求量/成功率/延时）
定义关键事件
输出级别
管理方案（存放时长、压缩备份等）
当具体上述条件的日志规范得以落地，开发、运维和业务都能相应的获得较好的监控分析能力。
集中管控
运维的工作先天就容易被切割成不同的部分，发布变更、监控分析、故障处理、项目支持、多云管理等等，我们诉求一站式的运维管理平台，使得所有的工作信息能够衔接起来和传承经验，杜绝因为信息孤岛或人工传递信息而造成的运营风险，提升整体运维管控的效率和质量。
要点四：容错容灾
在腾讯技术运营（运维）的四大职责：质量、效率、成本、安全。质量是首要保障的阵地，转换成架构的视角，运维眼中理想的高可用架构架构设计应该包含以下几点：
负载均衡
无论是软件或硬件的负责均衡的方案，从运维的角度出发，我们总希望业务架构是无状态的，路由寻址是智能化的，集群容错是自动实现的。
在腾讯多年的路由软件实践中，软件的负载均衡方案被广泛应用，为业务架构实现高可用立下汗马功劳。
可调度性
在移动互联网盛行的年代，可调度性是容灾容错的一项极其重要的运维手段。在业务遭遇无法立刻解决的故障时，将用户或服务调离异常区域，是海量运营实践中屡试不爽的技巧，也是腾讯QQ和微信保障平台业务质量的核心运维能力之一。
结合域名、VIP、接入网关等技术，让架构支持调度的能力，丰富运维管理手段，有能力更从容的应对各种故障场景。
异地多活
异地多活是数据高可用的诉求，是可调度性的前提。针对不同的业务场景，技术实现的手段不限。
腾讯社交的实践可以参考周小军老师的文章“2亿QQ用户大调度背后的架构设计和高效运营”。
主从切换
在数据库的高可用方案中，主从切换是最常见的容灾容错方案。通过在业务逻辑中实现读写分离，再结合智能路由选择实现无人职守的主从切换自动化，无疑是架构设计对DBA最好的馈赠。
柔性可用
“先扛住再优化”是腾讯海量运营思想之一，也为我们在做业务架构的高可用设计点明了方向。
如何在业务量突增的情况下，最大程度的保障业务可用？是做架构规划和设计时不可回避的问题。巧妙的设置柔性开关，或者在架构中内置自动拒绝超额请求的逻辑，能够在关键时刻保证后端服务不雪崩，确保业务架构的高可用。
要点五：质量监控
保障和提高业务质量是运维努力追逐的目标，而监控能力是我们实现目标的重要技术手段。运维希望架构为质量监控提供便利和数据支持，要求实现以下几点：
指标度量
每个架构都必须能被指标度量，同时，我们希望的是最好只有唯一的指标度量。对于业务日趋完善的立体化监控，监控指标的数量随之会成倍增长。因此，架构的指标度量，我们希望的是最好只有唯一的指标度量。
基础监控
指的是网络、专线、主机、系统等低层次的指标能力，这类监控点大多属于非侵入式，很容易实现数据的采集。
在自动化运维能力健全的企业，基础监控产生的告警数据绝大部分会被收敛掉。同时，这部分监控数据将为高层次的业务监控提供数据支撑和决策依据，或者被包装成更贴近上层应用场景的业务监控数据使用，如容量、多维指标等。
组件监控
腾讯习惯把开发框架、路由服务、中间件等都统称为组件，这类监控介于基础监控和业务监控之间，运维常寄希望于在组件中内嵌监控逻辑，通过组件的推广，让组件监控的覆盖度提高，获取数据的成本属中等。如利用路由组件的监控，运维可以获得每个路由服务的请求量、延时等状态和质量指标。
业务监控
业务监控的实现方法分主动和被动的监控，即可侵入式实现，又能以旁路的方式达到目的。这类监控方案要求开发的配合，与编码和架构相关。
通常业务监控的指标都能归纳为请求量、成功率、延时3种指标。实现手段很多，有日志监控、流数据监控、波测等等，业务监控属于高层次的监控，往往能直接反馈业务问题，但倘若要深入分析出问题的根源，就必须结合必要的运维监控管理规范，如返回码定义、日志协议等。需要业务架构在设计时，前置考虑运维监控管理的诉求，全局规划好的范畴。
全链路监控
基础、组件、业务的监控手段更多的是聚焦于点的监控，在分布式架构的业务场景中，要做好监控，我们必须要考虑到服务请求链路的监控。
基于唯一的交易ID或RPC的调用关系，通过技术手段还原调用关系链，再通过模型或事件触发监控告警，来反馈服务链路的状态和质量。该监控手段属于监控的高阶应用，同样需要业务架构规划时做好前置规划和代码埋点。。
质量考核
任何监控能力的推进，质量的优化，都需要有管理的闭环，考核是一个不错的手段，从监控覆盖率、指标全面性、事件管理机制到报表考核打分，运维和开发可以携手打造一个持续反馈的质量管理闭环，让业务架构能够不断进化提升。
要点六：性能成本
在腾讯，所有的技术运营人员都肩负着一个重要的职能，就是要确保业务运营成本的合理。为此，我们必须对应用吞吐性能、业务容量规划和运营成本都要有相应的管理办法。
吞吐性能
DevOps持续交付方法论中，在测试阶段进行的非功能需求测试，其中很重要一点便是对架构吞吐性能的压测，并以此确保应用上线后业务容量的健康。
在腾讯的实践中，不仅限于测试阶段会做性能压测，我们会结合路由组件的功能，对业务模块、业务SET进行真实请求的压测，以此建立业务容量模型的基准。也从侧面提供数据论证该业务架构的吞吐性能是否达到成本考核的要求，利用不同业务间性能数据的对比，来推动架构性能的不断提高。
容量规划
英文capacity一词可以翻译成：应用性能、服务容量、业务总请求量，运维的容量规划是指在应用性能达标的前提下，基于业务总请求量的合理的服务容量规划。
运营成本
减少运营成本，是为公司减少现金流的投入，对企业的价值丝毫不弱于质量与效率的提升。
腾讯以社交、UGC、云计算、游戏、视频等富媒体业务为主，每年消耗在带宽、设备等运营成本的金额十分巨大。运维想要优化运营成本，常常会涉及到产品功能和业务架构的优化。因此，运维理想的业务架构设计需要有足够的成本意识，
小结
本文纯属个人以运维视角整理的对微服务架构设计的一些愚见，要实现运维价值最大化，要确保业务质量、效率、成本的全面提高，业务架构这块硬骨头是不得不啃的。
运维人需要有架构意识，能站在不同角度对业务架构提出建议或需求，这也是DevOps 精神所提倡的，开发和运维联手，持续优化出最好的业务架构。

如何做好运维监控？

统一监控平台，说到底本质上也是一个监控系统，监控的基本能力是必不可少的，回归到监控的本质，先梳理下整个监控体系：

① 监控系统的本质是通过发现故障、解决故障、预防故障来为了保障业务的稳定。

② 监控体系一般来说包括数据采集、数据检测、告警管理、故障管理、视图管理和监控管理6大模块。而数据采集、数据检测和告警处理是监控的最小闭环，但如果想要真正把监控系统做好，那故障管理闭环、视图管理、监控管理的模块也缺一不可。

一、数据采集

1、采集方式

数据采集方式一般分为Agent模式和非Agent模式；

Agent模式包括插件采集、脚本采集、日志采集、进程采集、APM探针等

非Agent模式包括通用协议采集、Web拨测、API接口等

2、数据类型

监控的数据类型有指标、日志、跟踪数据三种类型。

指标数据是数值型的监控项，主要是通过维度来做标识。

日志数据是字符型的数据，主要是从中找一些关键字信息来做监控。

跟踪型数据反馈的是跟踪链路一个数据流转的过程，观察过程中的耗时性能是否正常。

3、采集频率

采集频率分秒级、分钟级、随机三种类型。常用的采集频率为分钟级。

4、采集传输

采集传输可按传输发起分类，也可按传输链路分类。

按传输发起分类有主动采集Pull（拉）、被动接收Push（推）

按传输链路分类有直连模式、Proxy传输。

其中Proxy传输不仅能解决监控数据跨网传输的问题，还可以缓解监控节点数量过多导致出现的数据传输的瓶颈，用Proxy实现数据分流。

5、数据存储

对于监控系统来说，主要有以下三种存储供选择

① 关系型数据库

例如MySQL、MSSQL、DB2；典型监控系统代表：Zabbix、SCOM、Tivoli；

由于数据库本身的限制，很难搞定海量监控的场景，有性能瓶颈，只在传统监控系统常用

② 时序数据库

为监控这种场景设计的数据库，擅长于指标数据存储和计算；例如InfluxDB、OpenTSDB（基于Hbase）、Prometheus等；典型监控系统代表：TICK监控框架、 Open-falcon、Prometheus

③ 全文检索数据库

这类型数据库主要用于日志型存储，对数据检索非常友好，例如Elasticsearch。

二、数据检测

1. 数据加工

① 数据清洗

数据清洗比如日志数据的清洗，因为日志数据是非结构化的数据，信息密度较低，因此需要从中提取有用的数据。

② 数据计算

很多原始性能数据不能直接用来判断数据是否产生异常。比如采集的数据是磁盘总量和磁盘使用量，如果要检测磁盘使用率，就需要对现有指标进行一个简单的四则运算，才能得到磁盘使用率。

③ 数据丰富

数据丰富就是给数据打上一些tags标签，比如打上主机、机房的标签，方便进行聚合计算。

④ 指标派生

指标派生指的是通过已有的指标，通过计算得出新的指标。

2. 检测算法

有固定规则和机器学习算法。固定算法是较为常见的算法，静态阈值、同比环比、自定义规则，而机器学习主要有动态基线、毛刺检测、指标预测、多指标关联检测等算法。

无论是固定规则还是机器学习，都会有相应的判断规则，即常见的< =和and/or的组合判断等。

三、告警管理

1. 告警丰富

告警丰富是为了后续告警事件分析做准备，需要辅助信息去判断该怎么处理、分析和通知。

告警丰富一般是通过规则，联动CMDB、知识库、作业历史记录等数据源，实现告警字段、关联信息的丰富；通过人工打Tags也是一种丰富方式，不过实际场景下由于人工成本高导致难以落地。

2. 告警收敛

告警收敛有三种思路：抑制、屏蔽和聚合

① 抑制

即抑制同样的问题，避免重复告警。常见的抑制方案有防抖抑制、依赖抑制、时间抑制、组合条件抑制、高可用抑制等。

② 屏蔽

屏蔽可预知的情况，比如变更维护期、固定的周期任务这些已经知道会发生的事件，心里已经有预期。

③ 聚合

聚合是把类似或相同的告警进行合并，因为可能反馈的是同一个现象。比如业务访问量升高，那承载业务的主机的CPU、内存、磁盘IO、网络IO等各项性能都会飙升，这样把这些性能指标都聚合到一块，更加便于告警的分析处理。

3. 告警通知

① 通知到人

通过一些常规的通知渠道，能够触达到人。

这样在没有人盯屏的时候，可以通过微信、短信、邮件触发到工作人员。

② 通知到系统

一般通过API推送给第三方系统，便于进行后续的事件处理

另外还需要支持自定义渠道扩展（比如企业里有自己的IM系统，可以自行接入）

四、故障管理

告警事件必须要处理有闭环，否则监控是没有意义的。

最常见还是人工处理：值班、工单、故障升级等。

经验积累可以把人工处理的故障积累到知识库里面，用于后续故障处理的参考。

自动处理，通过提取一些特定告警的固化的处理流程，实现特定场景的故障自愈；比如磁盘空间告警时把一些无用日志清掉。

智能分析主要是通过故障的关联分析、定位、预测等AI算法，进一步提升故障定位和处理的效率；

1. 视图管理

视图管理也属于增值性功能，主要是满足人的心理述求，做到心中有底，面向的角色很多（领导、管理员、值班员等）。

大屏：面向领导，提供全局概览

拓扑：面向运维人员，提供告警关联关系和影响面视图

仪表盘：面向运维人员，提供自定义的关注指标的视图

报表：面向运维人员、领导，提供一些统计汇总报表信息，例如周报、日报等

检索：面向运维人员，用于故障分析场景下的各类数据检索

2. 监控管理

监控管理是企业监控落地过程中的最大挑战。前5个模块都是监控系统对外提供的服务功能，而监控管理才是面向监控系统自身的管理和控制，关注真正落地的过程的功能呈现。主要有以下几个方面：

配置：简单、批量、自动

覆盖率：监控水平的衡量指标

指标库：监控指标的规范

移动端：随时随地处理问题

权限：使用控制

审计：管理合规

API：运维数据最大的来源，用于数据消费

自监控：自身稳定的保障

为了实现上述监控六大基础能力模块，我们可以按如下架构设计我们的统一监控平台。

主要分三层，接入层，能力层，功能层。

接入层主要考虑各种数据的接入，除了本身Agent和插件的采集接入，还需要支持第三方监控源的数据接入，才能算一个完整的统一监控平台。

能力层主要考虑监控的基础通用能力，包含数据采集模块、数据存储模块、数据加工模块、数据检测模块、AI分析模块。

功能层需要贴近用户使用场景，主要有管理、展示两类功能，在建设的过程中可以不断丰富功能场景。

另外，考虑到数据的关联关系，为未来的数据分析打下基础，监控和CMDB也需要紧密联动，所有的监控对象都应该用CMDB进行管理，另外，还可以配置驱动监控为指导理念，实现监控的自动上下线，告警通知自动识别负责人等场景，简化监控的维护管理。

为了统一监控平台能够在企业更好的落地，我们需要配备对应的管理体系，其中最重要的是指标管理体系。

指标管理体系的核心理念：

监控的指标体系是以CMDB为骨架，以监控指标为经脉，将整个统一监控平台的数据有机整合起来。

贯穿指标的生命周期管理，辅以指标的管理规范，保障监控平台长久有序的运行。

从企业业务应用的视角出发，一般将企业监控的对象分为6层，也可以根据企业自己的情况进行调整：

基础设施层

硬件设备层

操作系统层

组件服务层

应用性能层

业务运营层

关于智能运维平台产品设计方案和智能运维管理系统设计方案的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 智能运维平台产品设计方案的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于智能运维管理系统设计方案、智能运维平台产品设计方案的信息别忘了在本站进行查找喔。