北京
几乎每个技术团队迟早都会撞上同一堵墙。监控系统会告诉你某些东西出了问题，然后它的价值就停在那里了。错误率上升了，响应延迟出现了，请求失败量在爬坡，这些数据你都能看到。但在故障期间真正关键的那几个问题，往往找不到答案。谁拥有这个服务？它的上下游依赖是什么？对应的标准作业流程手册在哪儿？我应该用哪个即时通讯频道上报？当前情况是一次真实宕机，还是一种已知的故障模式？
这些信息断层，就是这次做了一个小型主动式可观测性演示的直接原因。搭了一个精简的购物应用，用开放遥测协议完成了埋点，把远程遥测数据发送给了 Dynatrace，然后把 Port 当作上下文信息层，将运行信号与工程团队知识串联了起来。最后出来的故障排查流程，远比原来盯着仪表盘靠猜要顺畅得多。你可以直接问系统现在发生了什么，然后在一处同时拿到实时健康数据和团队约定好的上下文信息，比如谁是负责人、应急预案在哪里。
整个技术搭建刻意保持在小规模，但问题映射感很强，对应到真实系统里那种一团乱麻的状态非常到位。应用里包含了商品展示、购物车、结账流程，还预置了几种故障场景，让可观测性这套能力有实际的事件可以捕捉和暴露。
过去可观测性的强项集中在检测环节。它可以说清楚哪个服务状态不正常，响应时间在拉长，或是失败率在持续上升，这当然有它的价值。但事件响应的过程里，检测只能算起点，磨合和消耗紧接着就开始了。需要知道是哪个团队在负责这个服务。需要搞清楚服务的分级，是不是直接关系到核心业务。需要理解上游和下游的依赖关系。需要找到对应的操作手册。需要知道怎么联系能够恢复服务的人。需要累积足够多的前提信息，才能判断当前这个异常是意料之中的波动、人为误操作造成的连带影响，还是只是一次压测。
这也正是主动式可观测性开始显得有意思的地方。想做的不再只是源源不断地收集遥测数据，而是想办法让这些遥测数据变得可以操作，通过把它们和系统周围已经存在的运行框架、团队分工信息关联起来，让原始信号多出一层现实指向。自动化不是终点，可行动的上下文才是。
在架构选型上有意保持精简，总共只涉及三个主要组成模块，但这三者的组合创造出的使用流程，比任何单一工具所能提供的都要扎实得多。一个基于 Flask 的购物应用，负责模拟贴近真实的用户行为和故障触发。Dynatrace 用来接收链路追踪数据，分析服务健康度、延迟趋势、日志和错误分布。Port 承担上下文层的角色，存储服务归属、重要等级、应急预案、即时通讯频道以及相应元数据。
把可观测平台和上下文层粘合在一起的关键连接点，是 Port 里的模型上下文协议连接器。通过这个连接器接入了 Dynatrace 的模型上下文协议服务器，Port 就能在读取实时监控数据的同时，持续将体验锚定在工程上下文中。这一步组合，基本就是这个版本的主动式可观测性的核心逻辑。Dynatrace 掌握着系统当前正在发生什么，Port 掌握着系统应该如何被理解和处置，连接建立之后，两个世界的信息不再割裂运行。
在这个小而完整的演示环境里，排查路径发生了实质变化。不需要在监控系统和文档之间反复切换，然后靠经验去缝合线索。一个自然语言的问题就能同时带出两种维度的回应：当前这个服务的延迟是不是在持续恶化，它的处理手册在哪里，谁在线，影响的是哪些下游服务。这种回应方式更接近事件发生时实际想要的人机协作状态，而不是继续在沉默的告警页面上独自完成推理闭环。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
