Avi1405/incident-observability-hub

# Incident Observability Hub 一个专注于可观测性和事件响应的工作区，旨在帮助团队了解正在发生什么、为什么会发生，以及下一步该怎么做。 ## 为什么会有这个仓库 后端工程师的评判标准往往不仅在于功能开发，同样也在于系统的可靠性。这个项目展示了我有能力构建围绕生产系统的工具：metrics、logs、alerts、SLO 以及事件处理工作流。 ## MVP - 服务健康概览 - 针对流量、延迟和错误的 metrics 图表 - 集中式 logs 搜索 - Alert 规则与通知 - 事件时间线和状态变更 - 包含错误预算视图的 SLO 追踪 - 针对常见事件的 Runbook 链接 ## 构建计划 ### 阶段 1：数据模型与摄入 - 为服务、事件、alert 和 log 条目建模 - 构建一个简单的 API 用于摄入合成的遥测数据 - 存储 metrics 样本和事件历史 - 为应用填充演示服务和事件数据 ### 阶段 2：运维工作流 - 添加带有健康指示器的服务仪表板 - 添加可搜索的 logs 和错误过滤器 - 添加 alert 创建与确认功能 - 添加事件生命周期状态：open、investigating、mitigated、resolved ### 阶段 3：可靠性功能 - 添加 SLO 目标和错误预算计算 - 添加部署标记和注释 - 添加附加到服务和 alert 的 runbook - 为 alert 状态转换和事件处理添加测试 ### 阶段 4：叙事与打磨 - 添加事件时间线视图 - 添加紧凑的根本原因总结面板 - 添加演示截图和架构说明 - 为已完成的事件添加一个小型的复盘模板 ## 延伸目标 - Trace 可视化 - 自动化异常检测 - Slack 或邮件 alert 推送 - 公开状态页面 ## 成功的标准 - 该应用让生产环境中的问题变得更容易理解 - 用户体验像是一个真正的内部运维工具 - 该项目展示了对可靠性的思考，而不仅仅是仪表板的样式设计 - 我能够探讨可观测性、alerting 和事件响应中的权衡 ## v1 注意事项 从一个服务、一个仪表板和一条 alert 路径开始。如果这个流程让人感觉扎实，那么剩余的可观测性界面就会变得更加值得信赖。

标签：API集成, IT运维, SLO管理, Socks5代理, 可观测性, 监控告警