在这个假设的例子中，我们有一个跨电子商务公司多个工程团队的数据流。这些团队在流程的不同点提供服务、生成数据并使用数据。
例如;
- “团队订单”维护订单数据库和接口
- “Team Traffic” 生成网络流量数据
- “团队仓库”维护数据仓库
- “团队流量”依赖“团队订单”的服务来检索订单数据并将其与网络流量关联
- “Team Warehouse” 依赖“Team Traffic”的数据来构建 DW 表
想象一下“团队订单”遇到数据库问题（负载、延迟等）——他们的监控系统会提醒工程师开始调查数据库问题。
与此同时，“流量团队”也收到了警告，因为他们发现不良响应数量激增。他们开始调查，并很快意识到问题出在“订单团队”的服务上，并向“订单团队”提交了一张票
所有这些的下游，“仓库团队”正在接收错误数据。他们的 DW 监控提醒他们注意这种差异，因此他们开始寻找根本原因。
问题是，我们现在至少有三名工程师正在调查同一个问题，他们甚至可能没有意识到其他团队正在做同样的事情。
重要的一点是，所有三个团队都使用不同的监控和警报系统；订单团队正在监控数据库服务器问题，而仓库团队正在寻找记录数量的差异。
还有其他方法；仅在管道顶部发出警报（阻止下游升级）或在管道底部向上游系统发出警报。
是否有任何最佳实践、白皮书或工程解决方案可供我研究，以了解在多个工程/支持团队中警报和升级数据问题的不同方法？
答案1
强烈推荐《云系统管理实践》，其中详细介绍了其中的一些内容。这里有 3 个级别的监控
- 端到端（糟糕，出问题了）
- 每个服务/API（哦，糟糕的是，SQL 集群的成员已关闭，API 响应缓慢或出现 200/300 HTTP 代码以外的其他问题等）
- APM——哪段代码等比较慢，特定服务的错误率等等。
这些 + 日志为我们提供了大部分需要了解的情况，通常我们会安排一个人负责确保问题得到解决 - 协调修复，但他们不做技术工作，这些工作都外包给了其他人。协调员的工作是确保我们在解决问题时不会互相干扰。