观测性不是孤岛团队协作与文化变革说实话最近跟几个在一线做运维的老哥聊天大家普遍反映一个现象公司要么没有专门的人搞可观测性要么搞了个“集中式可观测性团队”结果这团队天天忙着修 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、最佳实践、审计机制通过社区运营推动文化渗透定期举办可观测性研讨会、总结最佳实践、设置“可观测性大使”避免强推而是赋能让业务团队有“我自己就能搞定可观测性”的感觉最后说几句可观测性这件事说难也难说简单也简单。关键不在于用了多少工具而在于团队如何组织、文化如何建设。我自己之前带过一阵子可观测性团队深有体会——方向对了路就好走。而不是用战术上的勤奋掩盖战略上的懒惰。核心要点没有集中式可观测性团队只有平台工程团队 各业务团队约定优先配置是降低门槛的关键平台团队负责“造轮子”业务团队负责“开车”最终目标是提供高质量数据以驱动决策而不是堆砌仪表盘文化变革比工具整合更难但更值得投入
可观测性不是孤岛:团队协作与文化变革
发布时间:2026/6/28 3:34:12
观测性不是孤岛团队协作与文化变革说实话最近跟几个在一线做运维的老哥聊天大家普遍反映一个现象公司要么没有专门的人搞可观测性要么搞了个“集中式可观测性团队”结果这团队天天忙着修 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、最佳实践、审计机制通过社区运营推动文化渗透定期举办可观测性研讨会、总结最佳实践、设置“可观测性大使”避免强推而是赋能让业务团队有“我自己就能搞定可观测性”的感觉最后说几句可观测性这件事说难也难说简单也简单。关键不在于用了多少工具而在于团队如何组织、文化如何建设。我自己之前带过一阵子可观测性团队深有体会——方向对了路就好走。而不是用战术上的勤奋掩盖战略上的懒惰。核心要点没有集中式可观测性团队只有平台工程团队 各业务团队约定优先配置是降低门槛的关键平台团队负责“造轮子”业务团队负责“开车”最终目标是提供高质量数据以驱动决策而不是堆砌仪表盘文化变革比工具整合更难但更值得投入