可观测性不是孤岛：团队协作与文化变革
说实话，最近跟几个在一线做运维的老哥聊天，大家普遍反映一个现象：公司要么没有专门的人搞可观测性，要么搞了个“集中式可观测性团队”，结果这团队天天忙着修 Grafana 页面、配告警规则、挖指标字段，最终成了“工具运维中心”——活没少干，但业务团队该吐槽还是吐槽，该漏报还是漏报。
这让我想起一个经典问题：可观测性到底应该谁来做？ 今天我们就聊聊这个话题，结合我自己踩过的坑和 SpotOn 的实战案例，谈谈我对可观测性组织模式的看法。
背景：可观测性的“集中式”魔咒
很多公司，尤其是规模稍大的企业，一研究可观测性就想着“我们要成立一个监控团队”或者“我们要搞一个可观测性平台团队”。结果呢？
📝 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 的案例看，真正有效的可观测性不是自上而下强推的，而是通过“内部产品”思维去运营的。平台团队要像做产品一样设计可观测性服务，关注“用户”（即各业务团队）的体验和满意度。
🤔 一个关键问题：你的可观测性平台，是“你得用”，还是“你想用”？
如何落地：文化变革是关键
很多团队的可观测性现状是这样的：
- 告警一大堆，但没人知道这些告警对业务意味着什么
- 仪表盘很炫酷，但领导看完了还是不知道“我们的系统到底好不好”
- 故障发生了才知道监控配置不到位
这其实就是典型的“为了监控而监控”。那怎么变？三步走。
怎么变？三步走
- 定义目标：明确可观测性是为了支持决策，不是堆工具。
- 培养习惯：
- 定期复盘：讨论告警响应情况、SLO 达标率
- 最佳实践分享：让做得好的团队分享经验
- 建立反馈：平台工程团队要持续接受用户（业务团队）的反馈，不断优化模板和规则
平台团队的操作建议
- 以“内部产品”思维设计可观测性服务：包括文档、模板、skills、API、最佳实践、审计机制
- 通过社区运营推动文化渗透：定期举办可观测性研讨会、总结最佳实践、设置“可观测性大使”
- 避免强推，而是赋能：让业务团队有“我自己就能搞定可观测性”的感觉
最后说几句
可观测性这件事，说难也难，说简单也简单。关键不在于用了多少工具，而在于团队如何组织、文化如何建设。我自己之前带过一阵子可观测性团队，深有体会——方向对了，路就好走。而不是用战术上的勤奋掩盖战略上的懒惰。
核心要点：
- 没有集中式可观测性团队，只有平台工程团队 + 各业务团队
- 约定优先配置是降低门槛的关键，平台团队负责“造轮子”，业务团队负责“开车”
- 最终目标是提供高质量数据以驱动决策，而不是堆砌仪表盘
- 文化变革比工具整合更难，但更值得投入
折腾到现在，回头看看，能坚持把可观测性从“工具”变成“文化”的团队，最后都尝到了甜头。
🎉🎉🎉
📚 参考文档
- How SpotOn Consolidated Observability Tools & Drove Observability Culture Change with Grafana Cloud
- Observability is a team sport