寮步仿做网站,网站建设流程及规范,长沙做网站价格,为什么要创建网站子目录一分钟精华速览
“只知道系统有问题#xff0c;但是找不到问题到底出在哪里”#xff0c;这几乎是大家都面临过、或正在面临的问题。用户在投诉#xff0c;但是我的指标都是正常的#xff0c;到底是哪一环出问题了#xff1f; 本文详细介绍了中国联通在智能运维领域的应用…一分钟精华速览
“只知道系统有问题但是找不到问题到底出在哪里”这几乎是大家都面临过、或正在面临的问题。用户在投诉但是我的指标都是正常的到底是哪一环出问题了 本文详细介绍了中国联通在智能运维领域的应用实践从架构师视角讲述了如何通过构建稳定性保障体系和数字化监控平台来支撑庞大分布式系统的端到端故障处理能力做到故障1分钟发现5分钟定位15分钟快速抢通。 作者介绍 中国联通软研院副总架构师——吴天昊 TakinTalks稳定性社区特邀讲师。中国联通软件研究院副总架构师主导中国联通数字化监控平台的整体架构设计及演进并负责中国联通数字化生产运营保障体系的建设与落地工作。致力于完善“平台应用”生态体系打造联通集团自动化生产和智慧化运营的生产运营平台。
温馨提醒本文约7000字预计花费10分钟阅读。
后台回复 “交流” 进入读者交流群回复“1019”获取课件资料
背景
作为中国的三大通信运营商之一中国联通可以说家喻户晓。每次大家去营业厅办理业务或者在手机上交话费、月租的扣除等等所有这些都是由中国联通软件研究院以下简称“联通软研院”建设和维护的系统在背后默默支撑。这套系统我们称之为cBSSCenter Business Support System也就是集约化业务系统中国联通也是唯一一个全国31省份的业务系统集中化的运营商。
集约化带来的好处无需赘述但同时也带来了不少挑战——系统庞大运维难度自然提升。作为联通软研院的副总架构师我负责联通软研院数字化生产运维保障体系的建设和落地包括数字化监控平台的整体架构设计及演进。我们的目标是构建一个“平台应用”的生态体系共同打造联通集团自动化生产和智慧化运营的工作台。
而数字化转型意味着系统的重构和升级也意味着新的运维问题将如影随形。那么中国联通面临的问题和挑战到底有哪些以及如何应对接下来一起探讨中国联通如何通过建设监控平台实现智能运维提升系统稳定性。
一、联通数字化转型运维遇到哪些挑战
1.1 一些常见的问题和典型故障
这里先列举了许多可能的问题和挑战。也想先请大家思考一下你们是否在自己的公司、团队或个人工作中遇到过这些问题和挑战如果你们确实遇到了这些问题希望下面中国联通的实践经验可以为你提供一些新的思考方向从中获得一些新的启示和收获。 在云原生环境下我们也经常会遇到一些典型的故障我这里举几个例子
单实例故障假设有一个服务这个服务有十个实例其中只有一个实例出现了问题。此时它可能会影响到上游的很多关联服务导致这些服务变得不可用。例如服务的JVM出现问题或者由于一条链路的数据出现问题导致服务实例异常。这样的问题如何发现和定位
下游组件故障有时候服务本身没有问题但是依赖的下游组件出现了故障。例如依赖的Redis突然出现了雪崩或者调用的ES突然查询变慢。这些问题又该如何处理
主机故障还有一些问题可能出在主机上比如主机突然死机或者主机出现故障。这将影响到主机上运行的所有组件甚至导致上层的服务无法提供进而影响业务导致业务中断或者业务损失。
外部接口故障除了自身系统内部的问题还可能会遇到外部因素的干扰。例如依赖的第三方接口出现了问题。这样的问题又该如何快速发现快速感知快速排查呢
针对这些典型的故障需要有一套有效的处理和定位机制。
1.2 运维面临的挑战
中国联通的系统架构从传统的IT架构转变为云原生架构这无疑为运维带来了许多挑战。
1.2.1 分布式架构挑战
原本只需要几个JAR包就可以提供服务的系统现在已经被解耦为成千上万个微服务。这意味着我们需要管理和维护的对象数量是几何级增加的这无疑大大增加了运维的难度。同时如何梳理这些微服务之间的调用关系也成了一个难题。诸如数据分片、异地存储等这类传统维护模式也难以为继。 1.2.2 运维生态挑战
由于各个系统都会建设自己的运维工具而这些工具往往是烟囱式的建设没有进行整体的拉通导致运维能力分散不成体系。另外各层面的数据如应用、数据库、中间件、云平台、基础设施等存在孤岛没有进行有效的整合这也给运维带来了困扰。
1.2.3 业务连续性挑战
故障处理过于依赖专家经验而系统服务之间的调用关系复杂故障分析和定位困难。此外端到端的稳定性保障体系仍有一定的缺失各个环节在监控、应急、巡检等方面的自动化和智能化能力还有待提高。我们还需要将故障处理从被动防御救火的状态转变为主动防火的状态合理利用运维收集到的大量数据提前发现和处理风险隐患。
面对这些挑战传统的运维方式已经无法满足需求。为了保障系统的稳定性和业务的高效运转我们提出了稳定性保障体系和数字化监控平台用于对系统稳定性和业务连续性进行全面保障。我将详细介绍我们是如何解决这些问题和挑战的。
二、数字化监控平台整体架构如何设计
2.1 “平台应用”体系--生产运营工作台
数字化监控平台采用了平台应用的体系结构解决了传统运维中各个应用、各个系统不同的建设运营的问题。运维人员在一个工作台上就可以进行相关的运维操作统一了运维入口减少了跳转登录不同系统的麻烦。 平台借鉴了苹果App Store的仓库模式将所有的应用都入驻到应用仓库里。运维人员只需要下载相关的应用就可以在工作台页面上进行选用无需记住多个系统的用户名和密码。它不只是由联通软研院来孵化运维应用也会邀请其他部门、各个省份公司、子公司一起共建共同构建中国联通的整个企业运维生态。
平台上有不同的应用仓库里面还有不同的类别不同的类别有不同的使用方向。通过开发者能力中心将共同的能力进行共建共享。也可以看到整个应用的使用状况以及用户的访问情况为整体运营提供数据支持。
平台和应用的体系进行了统一的架构应用可以快速地通过统一的应用框架构建出来快速地入驻到平台上实现了统一的架构、统一的登录、统一的权限和风格。同时应用的UI是一致的使用户始终在一个平台上进行整体的运维工作。
目前平台已经入驻的应用有100多个提供PC端和移动端双终端的处理能力。移动端的使用可以让运维人员不用随身携带电脑也不用登录VPN实现了咖啡运维即在喝咖啡的同时处理运维工作。
2.2 功能架构
中国联通的数字化监控平台的功能架构分为四层基础设施层、基础能力层、开发支撑层和核心应用层。 中国联通数字化监控平台功能架构
基础设施层包括分布在全国各地的数据中心其中包括北京亦庄、西安西咸、无锡、广州和呼和等地的数据中心。数据中心分布着不同的主机设备、网络设备和云平台CCS、CKE、阿里飞天等。针对这些数据中心来做不同数据的采集。
基础能力层包括权限管理用户统一管理、菜单统一管理、租户统一管理等、数据采集能力、统一监控告警能力、作业能力以及AI算法能力、流程引擎能力、配置能力和即时通讯能力等。
开发支撑层提供统一框架实现用户统一登录和账户管理同时通过开发者中心为不同的应用提供通用能力如告警能力、工单管理能力等。
核心应用层分为运行保障类和运营响应类。其中运行保障类包括监控管理基础设施监控、网络监控、云平台监控等、配置管理传统CMDB、云化CMDB等、自动化运维自动化作业、故障自愈等、变更管理任务调度平台、变更追踪等和测试接收测试、自动化巡检、压力测试等、业务连续性管理故障管理、应急预案、应急演练等和用户体验管理。
这四层构成的数字化监控平台可以全方位地保障数字化业务的高效稳定运行。
2.3 平台技术架构 中国联通的数字化监控平台的技术架构可以分为五层
基础设施层由联通云平台提供支持是联通内部的企业级云平台。同时联通云也对外提供相关输出。
容器调度层基于联通云平台采用K8S进行双擎的容器调度。
应用部署层主要进行应用的整体部署。
网关层包括内部统一框架外部应用通过统一登录进行入驻。
前端层借鉴蚂蚁的乾坤框架实现微前端独立编程、构建和部署。
在数据流方面采用开源组件如Prometheus采集监控指标PinPoint采集应用调用链路指标SDK和GS采集触点层指标。采集完的指标通过Kafka消息中间件进行处理利用Flink进行数据处理。数据存储在ClickHouse数据缓存在Redis基础数据存储在MySQL、MongoDB等数据库。
纵观整个监控平台我们通过各类基础能力和核心应用来共同构建了端到端全层级的稳定性保障支撑以保障业务稳定性。
三、智能运维如何落地有哪些核心应用案例
我将为大家详细介绍中国联通在智能运维领域的一些应用实践案例。这是我们工作的重点方向希望能够通过分享的这些实际应用案例帮助大家更深入理解智能运维。
阿里提出的1-5-10原则即一分钟内发现问题五分钟内定位问题十分钟内控制损失是一个很好的参考标准。在这个原则的启发下中国联通也制定了我们的目标即1-5-15原则1分钟故障发现5分钟内故障根因定位15分钟故障快速抢通。为了实现这些目标我们分析了六个核心场景来指导我们的工作。 接下来我将逐一说明中国联通如何通过这六个核心场景实现故障的快速发现、定位、调度、处置和整改以及预防。
3.1 统一监控告警
首先要明确需要监控的指标以及这些指标涵盖哪些内容。 中国联通监控指标及涵盖内容参考
针对这些全层级的监控指标需要了解每个指标的定义和标准。为此中国联通软院制定了364项的全层级指标规范包括每个指标的推荐配置、必须配置的指标、每个指标的配置阈值等。
根据这些规范让系统进行接入以确保全面的监控覆盖。那么如何让这些指标实现互联互通我们采用Prometheus等工具进行监控数据的采集并按照系统和租户的维度进行监控以实现不同层级指标的统一管理。 我们的目标是打破传统的分散管理模式实现数据的统一汇集和管理。在这些数据的基础上借助不同工具可以实现全层级的监控告警功能。
比如有统一的基础指标监控平台可以监控核心业务指标、中间件指标、数据库指标、基础资源指标、容器平台指标等。还有统一的告警平台可以统一发送告警信息。
在服务层面使用全流程调用链进行数据采集和展示并将相关告警推送到智能监控报警平台进行统一处理。
在前端触点层面使用APP性能监控和PC端前端触点监控工具以提供全面的监控告警服务。
3.1.1 工具1智能监控告警平台
智能监控告警平台是依据全层级的指标规范进行统一的。例如针对MySQL出现的采集情况只需要用户输入MySQL的IP和端口和只读用户的密码就可以进行MySQL的指标采集。同时也会将需要告警的指标进行套餐配置如希望采集MySQL的运行状态、连接数、表空间等只需要勾选即可自动采集。 接下来会进行告警的推荐配置设定告警规则例如当某个指标超过阈值时就会触发告警。同时为了避免某些指标抖动可以做一些告警抑制的动作比如持续2分钟后进行告警。
当在版本发布时的会产生一些告警可以设置告警静默进行统一的静默处理可以针对全量监控点或某一项监控点进行静默。
如果出现告警会生成一个告警工单并通过短信、钉钉以及外呼的策略通知值班人员。告警工单分为普通级别、重要级别和紧急级别普通级别的不需要立即电话催办而紧急级别的会立即进行外呼。值班人员收到告警后需要点击签收处理问题后再点击处理关闭。如果一直不签收或不处理会一级一级的进行升级直到打到领导层面。通过这样工单闭环的模式实现告警的处理。
3.1.2 工具2全流程调用链监控
这是在应用链路复杂的情况下帮助判断应用是否存在问题的工具。我们采用基于PinPoint探针的非侵入式字节码注入方式进行数据采集只需在启动时添加一个参数就能采集Java应用的调用量、耗时、异常等黄金指标并转换成可以使用的指标进行告警。 通过调用链路我们可以判断应用之间的关系定位底层故障在哪个应用层面上。调用链路是自动生成的如果出现问题应用层面会变红我们可以立即看到哪里出现了问题。点击有问题的应用可以看到它的上下游调用以及为什么变红。每分钟都会进行数据聚合通过这种方式可以看到整个服务的调控趋势。
我们还可以看到有哪些报错包括业务报错和系统报错例如连接超时的异常或业务规则限制导致的异常。我们会区分这两种异常针对系统异常进行告警业务异常则进行服务治理。
如果一个服务下有多个实例一个实例出现问题其他实例没有问题就可以通过重启该实例解决问题。把调用链路和云化CMDB关联起来就能知道实例所在的容器和主机以及占用的端口然后进行关联。
有了云化CMDB可以采集到云平台的资源情况如容器的内存和CPU主机的负载、CPU内存磁盘等判断是否主机或容器的异常引发了服务异常。
另外还可以看到服务之间是否是因为JVM或者GC的问题导致了实例不可用。
支持多维度告警能力例如当调用量降低20%或超过20%就进行告警或者当超时3秒的比例大于5%或者超时1秒的比例大于10%就进行告警。这种多维度的、可配置的告警规则可帮助应用系统快速地配置监控告警规则并推送到统一的监控告警中以便快速发现问题并通过调用链路进行问题定位。
3.1.3 工具3跨系统分布式追踪
以上是单系统的调用那么跨系统的调用拓扑是怎么做的基于刚才提到的PinPoint探针技术我们实现了跨系统的监控包括跨云平台监控CKE/CCS/EDAS等。我们对探针功能进行了增强以支持跨数据中心的链路拓扑监控。我们在各个数据中心和应用中进行整体的埋点通过标识出不同的租户和系统间的关系进行跨数据中心的分布式计算。然后在各个数据中心进行单元化的支撑并通过弹性拓展将分布式计算的结果汇聚起来形成跨数据中心的链路拓扑。
在亦庄主数据中心进行汇总和串联这样就可以看到不同系统之间的调用关系。例如一个系统在调用另一个系统我们可以看到这两个系统的标记说明它们之间存在调用关系。这就实现了跨系统的实时追踪能力。
3.1.4 工具4前端触点监控
采用JS埋点的方式采集用户在访问过程中的性能指标从而获取浏览器端真实的用户行为。例如可以在用户访问页面后获取用户的行为数据包括用户在什么时间访问、使用哪个IP、在什么地点以及使用哪个系统和浏览器。此外还可以获取用户的具体操作如打开页面、访问接口或弹出弹窗等。这样就可以实时采集并获取用户的真实行为和体验数据包括加载、点击、弹窗、JS报错等用户全轨迹追踪。
一旦发现页面响应时间过长或者AJAX响应时间过长或者弹窗数量突然增多就会及时进行告警因为这可能表明系统存在问题。同时还可以进行故障定位。
此外还可以通过收集工号的行为来进行分析。例如如果有工号在频繁访问某些页面或进行同样的请求就像机器人或爬虫一样就可以判断出它在进行不正常的行为。这样就可以进行安全分析并有效地进行安全治理。
3.2 一键智能诊断
基于刚才以上提到的各类监控工具如何有效实现统一的智能诊断呢 首先可以将调用量超时异常转换成指标通过链路了解整个调用关系。通过增强探针能力可以获取到异常日志、请求报文和响应报文从而进行整体关联。因此有了这样的关联可以通过指标发现问题通过链路定位问题并通过报文和日志判断问题的根因。通过这样的三位一体的可观测性可以实现故障的发现、定位和根因判断。
3.2.1 一键诊断流程 如图展示了一键智能诊断的流程。当我们发现开户业务出现报错时利用图数据库关系从150个服务告警中定位到是服务X出了问题继续通过核密度估计算法和DBSCAN聚类算法判定该服务的3个实例中是实例x3出现了问题。再次扫描根因服务调用的组件调用链指标、组件指标等从多个集群中判定到根因组件是Redis 2。继续进一步检查是否某个节点、某个主机甚至交换机出现问题……通过这样的全层级贯通可以实现一键智能诊断快速端到端地定位问题。
3.2.2 典型故障诊断案例
目前中国联通一键智能诊断准确率大概在70%左右。以下是一些系统案例截图和故障类型案例。 后台回复“1019”获取讲师课件查看大图
3.3 智能故障自愈
收到告警信息后会有相关的自动化作业进行处理。这些自动化作业是由运维专家根据运维场景提前编写并封装在自动化作业平台中的操作脚本。然后通过AI智能引擎判断是否有异常并自动调用整个作业能力进行故障自愈从而节省故障处理和恢复的时间。 3.4 故障闭环管理
在事前阶段我们会编制全面的应急预案并定期进行应急演练。这些演练不仅有助于我们预防故障也能确保应急预案非一纸空文而是真正可执行的。我们会进行桌面演练和实操演练前者用于检验流程的有效性和响应速度后者则用于验证应急预案的执行能力和预期效果。通过这些演练可以提升整个应急预案的可用性。 点击查看高清大图
在故障发生阶段主要通过监控告警、巡检、省分报告、客户投诉和舆情等方式发现故障。一旦发现业务SLO被触发将进行故障上报并通过一键拉会功能召集相关值班人员进行会议。这些人员包括故障调度负责人、业务负责人、技术负责人、信息通报负责人和信息记录负责人他们各司其职确保故障得到及时、有效的处理。
在故障结束后我们会进行故障改进。在24小时内进行标准的故障复盘在2个工作日内完成故障报告编写包括故障信息、根因分析、操作处置流程及问题整改措施等内容。在10个工作日内我们将对故障进行演练并根据出现的问题进行整改闭环追踪。
以上就是我们在故障的事前、事中、事后全生命周期的线上闭环管理方式。
3.5 智能隐患分析
将监控指标和容量指标相结合定期进行容量隐患评估。首先我们需要制定容量标准包括在业务层级、服务层级、组件层级以及资源层级上建立相关的容量水位模型形成标准制定。
其次我们会通过全链路压测借助工具手段判断链路上是否存在性能瓶颈。压测分析不仅可以评估当前是否达到预定的容量水位还能观察链路上是否有耗时增长、是否存在重复调用、线程是否已达上限、连接池是否已满等问题从而全面分析整个链路的性能瓶颈。
我们还需要建立一个健康度模型通过全层级指标分析识别系统是否处于亚健康状态进而判断相关的高、中、低风险并进行实时系统体检用以推送隐患报告进而实施问题隐患的整体闭环整改。
3.5.1 系统亚健康诊断案例
下面分享一个系统亚健康的实践案例。通过全层级指标包括网络层、平台层、组件层、服务层及触点层等不同层级的黄金指标运用AI算法分析来建立健康度算法模型。例如如果CPU使用率超过90%将发出告警。但如果CPU使用率一直维持在80%左右即使没有达到告警阈值也能通过风险等级判断其为高风险隐患从而识别出是否为亚健康状态。 通过全面的隐患分析可以实现系统健康状态的档案化管理。可以通过日、周、月等不同的时间维度来统计系统问题和风险情况观测系统在各个阶段的运行情况。也进行实时的系统体检和计算通过不同的阈值判断指标异常以及风险程度。
还可以进行版本前后的性能对比。例如如果版本更新前有10个风险隐患更新后增加到20个那么此次更新就是失败的因为它增加了风险隐患。我们需要提前规避这些问题提前治理。如果风险隐患减少到5个那么这次更新就是有效的可以看到它解决了哪些风险隐患。通过不同时间段的对比可以看到整个系统性能变化的趋势。
还可以定期自动生成体检报告通过工单形式发送给相关系统的负责人让他们明确了解系统的风险隐患以及如何进行治理。体检报告会列出相关风险指标并提供解决方案助力提升整个系统的稳定性。
四、成果实效如何
总结一下中国联通数字化生产运维保障体系和数字化监控建设取得的成果实效。
4.1 运营工具生态100工具建设节省人力成本7200万
打造了中国联通生产运营工作台这是一个整体运营生态体系。基于“平台运用”协同总部和省分公司进行共建共享完成100工具建设降低了重复建设的成本。
4.2 核心系统稳定性2022年故障数/故障时长下降均超80%
在核心系统的稳定性层面上特别是在信通院专项业务关键场景上保持行业排名领先。2022年故障数量下降83.90%故障历时下降81.95%。
4.3 重大活动保障国家级/社会侧/营销活动提供可靠保障
在重大活动保障层面上保证了系统的万无一失在疫情和洪涝灾害等方面也进行了可靠性的保障。还有校园营销、账期结算等重点活动都得到了稳固可靠的保障护航。
QA
1、“亚健康检查”中有提到监控指标请问监控指标怎么去梳理?除了基础指标还有哪些关键监控指标怎么才能做到监控覆盖全?
2、如果构建这么一套厉害的监控系统需要什么样的能力技术、人员、流程、规范的准备技术栈有什么建议吗
3、故障知识库可以展开讲下吗感觉最近经常听到这个方向的分享。
以上问题答案欢迎点击“阅读全文”观看完整版解答 本文由博客一文多发平台 OpenWrite 发布
