可观测性工具现状能知事故却难释成因可观测性工具栈能告知有事故发生而团队接下来需要的是解释事故成因的背景信息。在过去一年里大概有 30 次进行过类似的对话工程副总裁或资深站点可靠性工程师SRE会描述他们的可观测性工具栈如搭建的仪表盘、调整的告警设置以及花数月时间配置好的 Datadog 或 Grafana。接着会讲述最近的一次重大事故告警在数秒内触发仪表盘精准显示性能下降的位置但团队仍花两三个小时才找出原因然后才能着手修复。常听到的表述是“我们能看到一切但无法解释。”这种能看到却无法解释的差距已成为运维中代价高昂的问题之一。可观测性工具的设计初衷与局限可观测性工具在其设计目标上表现出色能大规模、实时地呈现系统内部的状况如延迟峰值、错误率、资源耗尽和依赖项故障等。这种能力是基础若没有它可能要等客户反馈才知道系统出了问题。但可观测性工具围绕的是“系统此刻正在发生什么”这一特定问题能很好地回答该问题。而“为什么会发生是什么引发的”大多超出了其能力范围。“正在发生什么”主要涉及基础设施层面如指标、追踪和日志可观测性工具栈能捕捉到这些信息而“为什么会发生”往往超出基础设施范畴可能源于两天前的一次部署、告警触发前开始激增的支持队列或是工程团队在上个冲刺阶段批准的变更记录这些背景信息不会出现在遥测数据中。修复前的调查工作难题当面向客户的事故发生时能解释事故原因的信息很少集中在一处。工程团队关注基础设施信号知道系统在做什么但不清楚哪些客户受到影响也不知道在监控告警触发前客户有何反馈。支持团队掌握着客户案例和用通俗易懂语言描述症状的投诉但无法搜索部署历史。在 Jira 或持续集成/持续部署CI/CD管道中有记录显示何时发生了哪些变更包含时间戳、作者和范围但这些记录并不知晓支持案例或异常情况。因此必须有人手动将这些信息关联起来这意味着要阅读客户投诉、交叉参考部署历史同时在脑海中整合多个系统的数据直到找出规律。这才是真正的调查工作不是解决问题而是重建事件经过可能需要花费数小时且完全发生在解决过程开始之前。平均修复时间MTTR衡量的是调查结束后的情况调查本身并未被纳入考量。谁在承担这项工作及成本体现这部分工作的情况往往被系统性地低估了。手动关联工作会落到那些对系统足够了解、能同时解读不同视图的人头上比如记得上周发布内容及其异常之处的工程师、能将客户问题描述转化为技术假设的支持主管或是有足够经验能识别模式的人。这些人会被从手头的工作中抽调出来因为调查工作特别需要他们。这是当相关信号分散在互不关联的系统中时事故响应工作的一个结构性特征。调查总会找到最了解情况的人而这个人往往是最忙的也是最关键的。他们花在重建时间线的时间本可用于完成只有他们能做的其他工作。这种成本会不断累积体现在工作速度、事故复发情况以及资深员工因频繁参与应急处理而悄然流失等方面但不会体现在 MTTR 或大多数组织跟踪的其他事故指标中。两种不同类型的工作及浪费所在在事故响应的讨论中很少有人提及需要人为判断的调查工作和本质上是数据整合的调查工作之间的差异。决定是打补丁还是回滚、判断哪些客户真正受到影响、哪些告警是噪音等都需要多年经验才能做出的高情境决策。而通过交叉参考 Jira、Salesforce 和部署仪表盘上的时间戳确定在客户投诉出现之前进行了哪些变更则属于数据整合工作既繁琐又耗时几乎每次严重事故的前两三个小时都会花在这上面。问题在于这两种工作一直是捆绑在一起的能做出决策判断的人也不得不进行数据整合因为没有系统能为他们完成这项工作。所以最有经验的工程师在调查的大部分时间里都在做远低于其能力水平的工作这种工作枯燥乏味会占据他们一整天的时间最后只得到一个用于实际决策的起点。这才是很少被提及的浪费不是时间本身而是这些时间所包含的工作质量。分离两类工作后的变化与趋势能解释事故发生原因的信号其实已经存在于系统中如客户案例、部署记录和基础设施信号等在告警触发前它们就已经在那里了。调查成本是一个关联问题而非数据问题数据是存在的只是从未被自动整合过。一类较新的工具即运营智能能横跨可观测性、票务和部署系统在人工打开第二个标签页之前自动进行交叉参考。当数据整合工作与判断工作分离时应急室里的工程师会带着对事件、部署、案例和时间线的结构化视图开展工作他们的任务变成确认信息、完善信息并决定下一步的行动。这才是他们真正擅长的工作。在这方面领先的组织不一定拥有更优秀的工程师或更好的可观测性工具栈但他们会认识到调查本身是一个工作流程并非不可避免而且数据整合和人为判断是可以分离的。随着人工智能驱动的关联工具不断成熟事故响应中的真正优势可能就源于这种分离。可观测性工具栈能告知你有事故发生而团队接下来需要的是解释事故成因的背景信息。在过去十年里其中一种能力已经显著成熟而另一种能力则是当前需要努力的方向。新科技论坛为技术领导者包括供应商和其他外部贡献者提供了一个深入探讨新兴企业技术的平台。选择是主观的基于认为对《信息世界》InfoWorld读者重要且最感兴趣的技术。《信息世界》不接受营销资料用于出版并保留对所有投稿内容进行编辑的权利。如有任何咨询请发送至 doug_dineleyfoundryco.com。Devops 软件开发 开发安全运维一体化DevSecOps 应用程序安全 安全