可观测性的“集中式”魔咒很多公司尤其是规模稍大的企业一研究可观测性就想着“我们要成立一个监控团队”或者“我们要搞一个可观测性平台团队”。结果呢Notes: 我见过的最糟糕的情况是——集中式团队成了“配置管理员”“告警搬运工”各业务团队甚至不知道自己的服务在监控什么、怎么配置告警。说白了可观测性的本质不是“有一个团队能做监控”而是“每个团队都能理解自己服务的健康状态”。就像质量是每个人的责任而不是质检部的事可观测性也一样。可观测性是众人拾柴火焰高不是孤岛有评论说集中式团队往往沦为工具运维中心而非赋能者最终成为开发流程的瓶颈。我特别认同。可观测性涉及多个环节开发阶段埋点(Tracing)、日志规范(Logging)CI/CD 阶段服务暴露指标(Metrics)测试阶段验证 SLO 配置生产阶段告警响应、故障排查(Alerts)这些环节没有一个能脱离业务团队单独存在。如果组织把可观测性“抽”出来丢给一个集中式团队很快就变成开发团队写代码不关心埋点 - “反正有可观测性团队兜底”可观测性团队不了解业务 - 告警规则要么太多、要么太少 - 一根筋变成两头堵双方开始互相甩锅 - ‍♂️所以正确的姿势是什么平台工程 约定优先配置 解药与其建立一个庞大的集中式团队不如建立一个可观测性平台团队。这两者区别在哪集中式团队职责配置指标、告警规则、仪表盘问题直接管理几百个服务的可观测性根本管不过来结局成为瓶颈平台工程团队职责设计可复用组件、约定优先的配置模板、最佳实践目标让各业务团队自主配置但保证数据一致性优势每个团队自己管自己的可观测性平台团队只做“工具”和“规则”就像我们当年搞 DevOps 一样——提供 Pipeline 模板让团队自己写 Job而不是运维去帮每个项目写 Jenkinsfile。Notes: 这里说的“约定优先配置”就是——你只需要像是Prometheus Crd一样类似ServiceMonitor在代码里声明service: my-app和team: team-x平台自动帮你配置默认的告警规则、仪表盘和日志收集。真实案例SpotOn 的可观测性转型前两天我看了 SpotOn 的分享How SpotOn Consolidated Observability Tools Drove Observability Culture Change with Grafana Cloud)他们从多工具的混乱状态向 Grafana Cloud 进行了整合。SpotOn 的做法工具整合把分散的 Datadog、New Relic、自研工具统一到 Grafana Cloud平台化平台团队提供可复用的 dashboard 模板、告警规则预设文化变革从“由下至上的被动告警”转向“由上至下的决策支持”其中一个观点特别值得学习可观测性不是堆砌仪表盘而是为组织提供高质量数据以驱动决策。这个“决策支持”真的是很多团队忽略的关键点。他们踩过的坑优点通过工具整合降低运维复杂度平台工程模式显著降低了团队接入门槛文化变革后各团队主动优化自己的 SLO缺点文化变革阻力很大初期有团队觉得“我们不需要监控”约定优先配置的维护成本不低平台团队需要持续更新最佳实践我的思考从 SpotOn 的案例看真正有效的可观测性不是自上而下强推的而是通过“内部产品”思维去运营的。平台团队要像做产品一样设计可观测性服务关注“用户”即各业务团队的体验和满意度。 一个关键问题你的可观测性平台是“你得用”还是“你想用”如何落地文化变革是关键很多团队的可观测性现状是这样的告警一大堆但没人知道这些告警对业务意味着什么仪表盘很炫酷但领导看完了还是不知道“我们的系统到底好不好”故障发生了才知道监控配置不到位这其实就是典型的“为了监控而监控”。那怎么变三步走。怎么变三步走定义目标明确可观测性是为了支持决策不是堆工具。