知名火锅连锁企业,IT 团队如何在数千家门店中先于用户发现故障
该知名火锅连锁企业是中国领先的餐饮企业,上千家门店遍布全球,由于门店餐饮行业的特殊性,需要靠前部署服务,所以在每家餐厅中,会部署相应的服务器,及相应 IT 设备,本地会运行POS、会员、下单等业务。公司有众多的餐厅门店,各个门店业务流量不同,门店的 IT 设备由于城市、开业时间等因素,其型号也不相同,服务器、应用程序分散式部署,给应用管理、IT 运维、以及先于门店发现问题,带来了极大的挑战。
所以迫切需要一个针对连锁餐饮门店的监控解决方案,以便完善监控覆盖度,及时发现并治理IT有隐患门店,提升门店IT的整体稳定性。
核心痛点
- 如何高效的集中监控所有的门店?
- 如何度量、发现、治理有 IT 隐患的门店?
- 如何让总部 IT 团队先于门店发现故障?
需求分析
1. 监控覆盖度不全
- 当前虽然有多套监控系统,但是存在监控数据不全,监控系统分散的问题,出现问题时,无法有效的收集数据进行分析;
- 门店的监控数据包括底层硬件、系统、网络、中间件、应用、交换机/防火墙、餐厅IT设备等,目前有部分监控数据还是缺失的,且需要跨团队沟通推进补齐监控采集,存在一定的推动成本;
2. 监控治理的手段不足
- 由于餐厅门店的特点,监控对象存在差异性,导致单个门店报警散发、报警频繁,无法进行有效收敛;
- 平时疲于报警,且可观测数据的不足,无法及时感知门店IT运行状况,无法及时发现趋势性问题,无法有效发现有IT隐患的“低质量”门店;
3. 进行IT“低质量”门店治理的抓手不足
- 门店的IT设施,横跨多个技术团队,有沟通、推进的成本,做为门店IT运维团队,如何推进门店IT治理,缺乏有效的手段;
方案简介
- 利用 Flashcat 的 All-in-One 采集器,统一了硬件、系统、进程等指标,并融合了公司其他内部采集系统,所有监控数据汇总一处,统一分析、处理;
- 利用“数据驱动”的理念,构建了门店 IT 质量量化体系,及时发现和治理有隐患的门店;
- 利用 Flashcat 层次化、多样化的可视化系统,构建了整个公司门店 IT 质量可视化方案,可以集中查看全局稳定性状态,同时,能够层层下钻,定位异常原因;
结合上面的需求分析,以及Flashcat的产品能力,我们围绕统一的“监控采集”、“数据驱动”的理念治理“低质量”门店,并制定了详细解决方案。
统一的监控采集
监控采集的要求
- 由于门店IT环境资源有限,我们既需要覆盖全部采集对象,同时采集器还能够尽量轻量化,少占用系统资源;
- 同时,公司的其他团队也采集了有业务特色的指标(比如餐厅Wi-Fi的信号质量,采集后存放在云存储中),需要我们一起来集成;
监控采集具体方案
- 针对业务特点,我们需要使用Categraf 监控采集器,来完成基础监控数据的采集。Categraf是一款开源采集器,能够实现All in One的监控指标采集,支持底层硬件、网络、系统、进程、各个中间件、业务等各个维度监控数据的采集;
- 门店数据库中,有门店的订单、POS、会员等实时数据,这部分我们也使用Categraf采集器的能力进行业务指标提取;
- 餐饮门店还有一些其他类型的指标,比如餐厅IT设备(Wi-Fi信号质量等),这部分指标由应用团队通过Pad应用进行采集,统一上传到云存储。之后,我们将云存储中的数据进行统一的时序化处理,处理后的数据打上对应的餐厅标签,然后录入到时序库中;
最终,所有的监控指标,都统一到了同一个时序数据库中。
其中的挑战
由于有上千家门店,且每个门店有自己的交换机、防火墙,实际上,这相当于有上千个微型IDC,给监控采集的配置带来了很大的挑战,主要包括:
- 需要集中化的管理上千台机器的采集配置;
- 部分的采集,比如防火墙、交换机的采集,每个餐厅是差异化的,这需要对上千个餐厅的网络配置进行有效管理,否则会难以维护;
- 各个餐厅的硬件设备存在差异(比如品牌、型号等等),需要采集器支持多种品牌类型的硬件设备;
- 业务指标如何采集;
应对方法
- 针对采集配置的问题:这里我们使用了Flashcat的“采集配置下发”功能,实现集中式的采集配置管理,对于数据库、业务进程的采集,全局可以一份采集模板。用户在Flashcat平台上配置/更新采集策略, Categraf 采集器会自动更新同步,从而实现平台化集中式管理,比如可以使用该功能对门店的所有机器添加一个“进程采集能力(procstat)”;
- 餐厅差异化的采集:Flashcat 目前支持了“网络设备”采集管理,在“网络设备”管理里,可以管理各个防火墙、交换机的配置信息,并能复用对应型号的硬件采集模板,提升运维效率;
- 业务指标采集:我们不仅需要关注餐厅IT基础指标,也需要关注门店的业务运营指标,运营指标波动(突增、突降),也会从业务层面反映业务稳定性。在实施时,我们目前从门店数据库,提取了门店“火锅下单”、“会员登录”等数据,通过这些数据,生成监控视图。同时,餐厅的业务指标一般具有非常强的规律性,我们可以使用基于算法的报警模型,对这些数据进行训练,并进行智能报警;
发现、治理IT“低质量”门店
“低质量”门店指存在IT隐患的门店,比如数据库性能隐患、硬件隐患、网络隐患等,或者是系统维护时漏掉的门店,环境不一致,导致程序运行性能下降,这里涉及到三个层面的问题:
- 如何具体定义IT“低质量”门店?
- 如何发现IT“低质量”门店?
- 如何治理IT“低质量”门店?
在这里,我们使用“数据驱动”的理念,制定了对应的解决方案。
定义IT“低质量”门店
这里我们需要有能够“量化”的数据来定义低质量门店,通过量化数据的高低,来进行门店IT质量的评价。同时,通过量化数据,我们还可以进行“数据驱动”,倒推各个相关团队,对得分低的环节及时进行治理。
一个餐厅门店的IT系统,包括硬件、系统、网络、中间件、业务进行、其他IT设施等等多个维度,每个维度都有几十、上百项监控指标,我们遵循哪些指标可能直接影响业务运行的原则
,从这些指标中,抽取最可能直接影响业务运行的指标,来表示这个维度的健康度,健康度得分低,则为IT“低质量”门店,我们初步制定的评价指标,主要包括以下几个大的指标维度:
指标维度 | 说明 |
---|---|
归零指标 | 该指标一旦异常,表示业务程序不可用,门店IT评分立即归零 |
系统维度 | 从系统层衡量门店IT健康度 |
数据库维度 | 衡量餐厅门店的数据库健康度(如慢查询、大表等等) |
网络维度 | 从网络连通性层面,衡量门店健康度 |
进程维度 | 从JVM维度,来衡量业务进程的健康度 |
硬件维度 | 从硬件维度(如物理机磁盘),来衡量门店健康度 |
中间件维度 | 从中间件维度,来衡量门店健康度 |
其他维度 | 如Wi-Fi信号质量 |
每个大的维度,又可以拆分多个具体的指标项,指标权重相加,就表示各个维度的健康度得分,具体指标项如下:
指标维度 | 具体指标项(权重) | 指标项说明 |
---|---|---|
归零指标 | 进程存活 | 任何一个关键进程不存活,扣分 |
磁盘写满 | 磁盘写满,扣分 | |
数据库未启动 | 数据库未启动,扣分 | |
系统维度(权重占比 xx%) | NTP(权重占比 xx%) | 误差超过正负xxxms,扣分 |
CPU负载(权重占比 xx%) | load 5 超过xx, 扣分 | |
… | … | |
… | … | |
… | … | |
数据库维度(权重占比 xx%) | 数据库慢查询(权重占比 xx%) | 每秒xx个慢查询,扣分 |
… | … | |
… | … | |
… | … | |
… | … | |
网络维度(权重占比 xx%) | 门店到公网连通性 (权重占比 xx%) | 丢包率不为x,扣分 |
… | … | |
进程维度(权重占比 xx%) | … | … |
… | … | |
硬件维度(权重占比 xx%) | … | … |
… | … | |
中间件维度(权重占比 xx%) | … | … |
… | … | |
其他维度(权重占比 xx%) | … | … |
于是,整个门店的IT健康度,就可以用各个维度项的得分,加权起来得到:
门店IT健康度(满分100分) = 系统维度 + 数据库维度 + 网络维度 + 进程维度 + 硬件维度 + 中间件维度 + 其他维度
确定好评价指标后,我们进行对应指标的提取、处理工作,将相关的监控指标,转化为“得分指标”。在计算最终的评价分数过程中,有一些特殊情况需要区别对待,比如:
- 有些指标,可能由于不同的门店,指标有差异,比如硬件、磁盘,可能由于门店服务器型号的差异、种类的差异(SSD磁盘、机械磁盘),原始监控指标是不同的,这时候我们需要对这些指标进行归一化处理,将处理后对监控数据参与到评分计算中。
- 还有部分指标,在某些时间段不希望参与评分(比如数据库在夜间可能进行正常的归档操作,业务进程在夜间可能进行程序升级等等),此时我们也需要对指标进行相应的处理,避免预期内的系统维护,影响整体评分。
发现IT“低质量”门店
每个门店的监控完善后,单店的监控指标预计超过5000个,乘以1500家门店,就有750w个监控指标,如何从海量的监控指标中发现异常数据,是个非常有挑战的工作。而且,不同的角色,关注的数据层次也有所不同:
- 专项运维人员(比如数据库运维人员),关注的是数据库维度的指标,想看到具体某个异常门店的数据库全部监控指标;
- 门店运维管理人员:关注的是餐厅整体的健康状态,期望能看到具体异常的餐厅,以及异常的维度(是系统异常还是数据库异常);
- 公司管理人员:关注的是全体餐厅的IT运营质量及趋势;
针对上面情况,结合Flashcat的产品能力,我们将监控数据分为三个层次:
- 一般监控数据
- 核心指标项(参与IT健康度评分的指标项)
- 门店整体健康度
通过层次化的数据展示,以及层次间数据的相互关联,来满足不同群体的需求,产生的效果如下:
- 能够层次化展示餐厅门店的IT质量,满足不同的角色对于门店IT质量的可视化需求;
- 下钻关联的能力,可以支持层层下钻,找到异常餐厅,以及具体的异常原因;
- 多样化的可视化效果,可以灵活的展示异常餐厅的地理分布、异常趋势变化等,便于问题的定位排查;
比如一个典型的层次化视图如下:
由下往上:
- 仪表盘:仪表盘中的数据最为详尽,可以展示单个门店某个子系统的全部指标,一般用于排查具体问题,比如排查一个门店数据库的异常,一般一线运维人员会关注这些信息,但仪表盘也有其不足,即不能快速的看到全局数据,不能快速的从上千家门店中,筛选出异常的门店;
- 灭火图:展示门店某个系统的健康度,比如上图,一个卡片表示一个门店“网络”(或者是数据库…)的健康度,当某个门店网络的核心指标异常时,该门店“网络”的灭火图就会自动“飘红”,灭火图的优势是可以展示某个维度的所有“核心指标”,能看到这个维度的全部餐厅状态,并快速筛选异常门店,但缺点是数据不如仪表盘详尽;
- 北极星:可以一眼看到全局信息,比如通过“蜂窝图”,一眼可以看到异常门店。
由上往下: 在进行问题定位时,我们可以实现从上往下(从全局到局部),层层下钻,找到问题的原因。
- 从北极星中找到异常的门店,如果我们想了解具体的异常信息,可以下钻到灭火图;
- 灭火图告诉我们XX维度中,哪些门店哪个核心指标发生了异常,以及异常前的状态;
- 灭火图可以进一步下钻,定位具体餐厅,下钻到具体XX维度的仪表盘,从而帮助我们找到具体原因;
北极星还具有多样化的数据展示能力:
- 通过“表格”的形式,我们可以实时看到数据排名,找到得分最低的门店,重点治理;
- 通过“时序图”的形式,可以看到问题发展的趋势,更容易找到问题规律;
- 我们还能自动根据餐厅坐标,生成基于地图数据的动态大屏,更好的呈现门店健康度,如下图,是基于全国地图/省份地图的餐厅坐标:
北极星的报警/报表能力:
- 实时监控报警:可以基于北极星、灭火图,以及具体的指标曲线,配置报警策略,实时发现问题,便于运维一线团队及时跟进;
- 每周报表:我们还支持数据导出的功能,每周餐厅各维度的数据,可以导出成csv,可以供相关团队使用(比如用于发送定期周报等等);
治理IT“低质量”门店
发现问题要及时治理,才是我们方案的初衷,但在实际的治理中,做为门店稳定性的负责人,我们往往需要推动不同的技术团队:
- 完善相关的指标覆盖度;
- 跟进平台发现的问题,及时跟进治理;
- 推动相关团队完善、遵循运维规范;
跨团队的沟通、推进,是成本较高的工作,这里,我们利用“数据驱动”的思路,将“门店IT情况”每周汇总、低质量门店跟进等数据生成相关周报,推送给各个团队及其负责人,由上向下进行治理,落实工作跟进;
总结
在落地Flashcat的过程中,遇到了很多挑战:
- 首先是方案设计的核心理念是什么?怎么定义低质量,怎么推进治理?在方案确认的过程中,逐渐完善了方案,利用“数据驱动”的思想推动整体方案落地,利用数据,来对低质量门店进行量化,利用数据来驱动问题的治理;
- 其次是数据的统一采集,涉及到上千家门店,其实就是上千个微型的数据中心,需要对上千个数据中心,上千台机器进行采集配置下发,是有很大挑战的,这里Flashcat的采集管理、网络管理,可以很好的解决。同时像业务指标、其他团队的监控指标,Flashcat 都统一对其进行时序化处理,将数据统一在一个数据库中,进行相关性分析;
- 数据的层级化、多样化展示有很大挑战,Flashcat构建了餐饮门店完善的监控可视化解决方案:
- 层级化:由于餐厅的特点,我们既需要关注全局状态,也需要查看局部的差异,传统的“类Grafana”样式的仪表盘很难做到层次化的展示,主要的问题在于,“类Grafana”的仪表盘往往是静态配置,关联关系也是静态配置的,而餐厅是动态的,我们需要根据餐厅的开店/关店,实时动态调整。而在Flashcat中,表示餐厅状态的“灭火图”就是动态生成的。 而且Flashcat的北极星-灭火图-仪表盘的层级设计,非常符合餐饮门店业务的 全局-异常餐厅-细节问题,这样的场景;
- 多样化:北极星支持蜂窝图、时序图、表格图等多种样式,帮助我们展示现状,分析趋势,同时可以基于坐标数据自动生成相关地图大屏,展示全国、各省、市的餐厅健康状态,便于企业内部呈现,引起相关领导及业务方的重视;
- 完善的数据加工能力,像业务营业期/维护期的处理,不同硬件类型数据统一化处理,这里对于一个标准化监控产品是没有相关能力的,这里Flashcat团队制定了相关的监控数据加工方案,实现了预期效果;