核心要点
- 连锁门店可观测性的特殊性在于：既要观测总部服务端系统，也要观测分布在全国各地的大量门店端设备、网络和程序。
- 门店端建设要把门店、设备和程序作为观测对象，用区域、设备类型、系统类型等视角组织健康状态。
- 服务端建设仍应覆盖功能接口、微服务、标准中间件和基础设施，并通过灭火图把异常对象逐层冒泡。
- IT 部门要从“等投诉后处理”转向“先于投诉发现故障”，需要建设北极星业务指标，例如 POS 机订单量、支付量等。
- 门店数据采集和规范是基础难点，门店 ID、门店名称、地理信息、指标名称和标签规范会直接影响后续观测准确性。
Flashcat 是快猫星云开发的一体化可观测性产品，已服务各行各业众多企业。本文总结分享 Flashcat 为多家大型连锁门店企业建设可观测性平台的经验。结合连锁门店行业的情况，文章从以下三个问题出发：
- 连锁门店的可观测性有什么特点？
- 连锁门店的 IT 部门面临什么挑战？
- 连锁门店的可观测性建设难在哪？
连锁门店的可观测性有什么特点
连锁门店的可观测性最大的特点是：除了服务端的 IT 基础设施和程序需要观测外，还有分布全国各地的大量门店 IT 基础设施和程序需要观测。如何既做好服务端的观测，又做好门店端的观测，并将两者打通，是连锁门店观测方案的一大特点。
| 观测范围 | 典型对象 | 建设目标 |
|---|---|---|
| 门店端 | 门店、路由器、交换机、网络、点餐机、门店程序 | 让总部能快速看到每家门店 IT 健康状态 |
| 服务端 | 功能接口、微服务、MySQL、Redis、Kafka、主机、DNS、CDN | 让技术团队能从业务影响下钻到服务和组件根因 |
| 业务指标 | POS 机订单量、支付量、各门店订单数据汇总 | 先于投诉发现业务趋势异常 |
门店端：把每家门店和设备变成观测对象
门店端的可观测性建设有相当的特殊性。首先，大量门店的 IT 设备和程序数据需要采集；其次，采集后要做出直观呈现，让 IT 技术人员或值班人员（有可能是外包人员）方便快速地确认问题。这些都是门店端方案需要考虑的重点。
门店端的数据采集是门店行业的一大难点，后面描述。这里重点介绍Flashcat针对门店端观测做的方案和效果。
这里还是利用 Flashcat 的灭火图来做观测方案。
Flashcat 将每个门店和门店中的设备、程序当做“观测对象”。这些观测对象按企业的观测习惯和使用方不同，可以按门店或区域来组织，比如华东市场、华南市场、华北市场。
也可以按设备和程序的类型来组织，如归零类（异常后整个门店IT不可用）、网络类、中间件类、系统类、程序类等等。
灭火图提供了灵活的组织这些视角的规则和能力。
最后每个观测对象的异常都可以在灭火图首页呈现出来，并可以下钻或直接透视定位到具体的异常对象及其异常指标，实现成千上万个门店的统一观测。
服务端：把功能接口、服务和组件串起来
连锁门店的服务端和其他行业的 IT 架构基本类似，大致都包括以下几层：
- 功能接口：如登录接口、下单接口、支付接口等等，通常成百上千。
- 微服务：如库存管理系统的程序、用户管理系统的程序等等研发编写并运行的程序服务。
- 标准中间件：如MySQL、Redis、Kafka等等。
- 基础设施：如主机、内网质量、外网质量、DNS、CDN等等。
Flashcat 的灭火图能够将所有的“IT 对象”分层分组，并做好各类对象的健康度量化。通过将异常对象冒泡上浮的方式，首页即可纵览所有 IT 基础设施的“着火点”，引导用户下钻分析异常对象的指标、日志、链路、事件、仪表盘等，完成故障分析和确认。
连锁门店的 IT 部门面临什么挑战？
一个典型挑战是，IT 部门在业务故障处理中通常处于被动地位，往往等到业务部门或门店经理投诉后才知道发生了业务层面的故障，影响程度也靠投诉量来判断。
IT部门如何早于投诉发现业务的故障，并定量的描述故障的影响范围和影响深度，让IT部门在故障处理中化被动为主动？
Flashcat 的北极星即针对性地解决这个问题。
北极星可以从业务数据库表单中计算生成业务指标，典型门店业务指标包括 POS 机订单量、支付量等。也可以将从各个门店收集的订单数据汇总成总的业务指标，并对这些业务指标做智能异常检测，发现业务指标趋势异常，及时发出告警。
通过建设连锁门店的北极星指标，Flashcat 的客户实现了真正的化被动为主动，先于投诉发现故障问题。这类 good case 在 Flashcat 的门店客户场景中出现，对技术部门往往是一个巨大的鼓舞。
连锁门店的可观测性建设难在哪？
门店数据的采集和规范建设可能是建设过程中最基础也最难的一个点。
连锁门店企业，门店的数量往往成千上万，所有门店及门店设备的数据都需要采集。同时门店设备种类多、系统多，可能还存在设备和系统老旧的问题。
如何采集到这些数据，并建立起门店的数据规范，以让后面的观测能够做到准确无误，是落地过程中的一大难点。
Flashcat 在和客户推进门店数据采集的过程中，利用采集器 Categraf 积累了大量设备和程序的采集模板和方案，例如门店路由器、交换机、网络、点餐机、程序等。这些采集方案都可以在其他门店企业中快速应用。
针对老旧设备和程序，Flashcat 可以配合 Categraf 的拨测能力实现对设备和程序的探测，保障最基本的异常感知能力。
门店数据在采集的过程中，很重要的一点是同时建设好采集数据的规范，比如指标名称的规范、标签的规范等。
其中最重要的是为每个门店采集的指标打上门店 ID 和门店名称标签。甚至可以在采集数据的处理过程中，为指标添加门店对应的地理经纬度。
有了这些完善的数据规范，后面 Flashcat 就可以准确而快速地建立起灭火图、地图等观测视角，实现对门店 IT 健康状态精准而直观的观测。
如何让保障流程运行起来？
有了观测能力，保障连锁门店 IT 服务的稳定性还差最后一步：建立相应的稳定性保障流程。让制度来驱动保障能力落地。
Flashduty 就是针对性解决这个环节的问题。Flashduty 可以收集观测系统、灭火图、北极星以及各个告警源的告警，对所有告警事件做聚合降噪、优先级划分、值班排班、告警升级等设置。这样，整个保障流程就能通过告警驱动运行起来，实现用机制保障稳定性的效果。
推荐建设路径
连锁门店企业可以按以下顺序推进可观测性建设：
- 梳理总部服务端和门店端的观测对象，明确门店、设备、程序、接口、服务、组件的分层。
- 使用 Categraf 或拨测能力采集门店端设备、网络和程序数据。
- 规范门店 ID、门店名称、区域、设备类型、指标名称和标签。
- 用 Flashcat 灭火图按区域、门店、设备类型或系统类型组织观测对象。
- 建设北极星业务指标，例如 POS 机订单量、支付量和门店订单汇总。
- 将灭火图、北极星和各类告警接入 Flashduty，形成值班、升级和治理流程。
- 在稳定性例会或供应商治理中持续复盘异常门店、反复故障和长期隐患。
总结
各家连锁门店企业可能因业务特点和已有观测能力不同，建设侧重点也不同。
和客户一起实施的过程中，Flashcat还实践了包括 门店IT健康度量化、SLO驱动技术团队和供应商改进、IT隐患治理 等工作，都取得了很不错的效果。
总结来看，连锁门店行业的可观测性建设有很明显的独特性，和Flashcat的灵活性及最佳实践结合后形成了一套行之有效的可观测性解决方案。各连锁门店行业的朋友可以参考，并欢迎做进一步的交流探讨。
FAQ
Q1：连锁门店可观测性为什么不能只看服务端？
A：门店故障往往发生在门店端设备、网络或本地程序上。只看服务端，可能无法及时发现某个区域、某个城市或某批门店的 IT 异常。
Q2：门店数据规范里最重要的标签是什么？
A：至少要有门店 ID 和门店名称。根据观测需要，还可以补充区域、城市、设备类型、系统类型和地理经纬度。这些标签会影响灭火图、地图视角和异常聚合的准确性。
Q3：北极星指标在连锁门店场景里解决什么问题？
A：北极星指标帮助 IT 部门从业务结果侧发现异常，例如 POS 机订单量或支付量趋势异常。它能让团队先于投诉发现问题，并定量描述影响范围和影响深度。
