ranganathan-a/Order_API_Incident_Response-Deriv

# orders-api 生产事故 — 提交 ## 已完成内容 **必须完成（共 4 项）：** - `incident_analysis.md` — 五个根本原因（Service/container 端口不匹配、 readiness probe 路径错误、liveness/readiness probe 配置互换、memory limit 设置过小、导致容量丢失的 rollout 策略），外加一个次要的凭证发现，每项都 关联到具体证据，包含需要首先运行的命令以及需要验证的已声明假设。 - `solution/deployment-and-service.yaml` — 修正后的 Deployment + Service， 解决了全部五个故障，为 DB 凭证使用 Secret 引用 （不包含任何真实或虚假的 secret 值）。 - `runbook.md` — 部署前验证、rollout 顺序、部署后检查、 成功/失败信号，以及 rollback 触发器 + 操作流程。 - `AI_USAGE.md` — 本次提交是如何在 AI 辅助下完成的，以及 每项声明/命令/manifest 是如何被检查的，而不是直接全盘接受。 **建议尝试（共 2 项）：** - `observability.md` — 5 个指标/告警，包括一个多窗口 burn-rate SLO 告警、dashboard/log 字段指导，以及一个 CI/CD 预防性检查。 - `tests/validate.sh` — 一个可在 bash 中运行的 Python 验证器，检查 Service/ container 端口匹配、probe 路径契约、明文凭证检测， 以及 resource request/limit 的合理性。已针对修正后的 manifest（通过）和原始损坏的 manifest（失败，捕获了端口不匹配、错误的 probe 路径和明文凭证）进行了验证。 **进阶（共 2 项，设计层面）：** - `stretch.md` — 一个需审批的 AI 分诊工作流设计（只读分诊 → 强制人工审批 → 限定范围的操作阶段），并针对 secret、prompt injection、幻觉命令和权限范围设置了防护措施；以及 一项针对 Service 端口故障模式的受控弹性测试。 ## 所做假设 - 应用程序在 1.9.0 版本中确实绑定了 8080 端口（根据其自身的日志行），并且 Service 只是未更新以与之匹配 —— 修复方案更新了 Service， 而不是应用程序。 - 1.9.0 版本中的 `/live` 如文档所述是轻量且无依赖的；这在 提供的日志中没有直接证据，因此被指出为在依赖其进行 liveness 检查之前需要进行冒烟测试。 - 对于 `orders-api-db-credentials`，存在（或可创建）现有的 Kubernetes Secret 机制； 根据禁止嵌入真实/虚假凭证的约束，此处未创建任何 Secret。 - 由于没有可用的活动集群，所有验证命令均为示例性说明， 但编写时确保了技术上的正确性，并且可以直接在与给定证据相匹配的真实的 `production` namespace 中运行。 ## 如何检查或运行相关产物 ``` # 从结构上和针对 4 项 checks 验证更正后的 manifest： bash tests/validate.sh solution/deployment-and-service.yaml # （可选）针对真实 cluster 进行 dry-run（如果可用）： kubectl apply --dry-run=server -f solution/deployment-and-service.yaml ``` 依次阅读 `incident_analysis.md` → `solution/deployment-and-service.yaml` → `runbook.md`，以遵循从诊断到修复再到验证的 流程；`observability.md` 和 `stretch.md` 为补充材料。 ## 耗时 在必须完成项上花费了约 45 分钟，加上在 建议尝试项和进阶项上额外花费的时间。 ## 如果有更多时间，我将进行的改进 - 实际启动一个 kind/minikube 集群，实时复现端口不匹配和 OOM 故障模式，而不是仅仅依赖 manifest 层面的推理和 静态验证器。 - 将 `tests/validate.sh` 扩展为一个真正的 CI 任务（例如 GitHub Actions），在 每个涉及 manifest 的 PR 上运行，并在 自定义检查之外加入 `kubeconform`/schema 验证。 - 添加实际的 PodDisruptionBudget 和 HorizontalPodAutoscaler 考量， 因为在节点维护期间，固定的 `replicas: 3` 加上 `maxUnavailable: 0` 会与 集群级别的中断预算相互作用，而不仅仅是应用程序的 rollout。 - 将第 7 部分的分诊工作流作为一个小脚本，针对真实的（沙盒化的）集群进行原型设计， 而不是仅仅停留在设计层面。

标签：子域名突变, 应用安全, 故障排查, 运维, 逆向工具