SuprithN236/production-monitoring-incident-sim

# 生产环境监控与事件响应模拟 ## 概述 ## 技术栈 - **计算：** AWS EC2 (Ubuntu, t2.micro / 免费套餐) - **Web 服务器：** Nginx - **监控与告警：** UptimeRobot - **事件跟踪：** Jira (Cloud，免费套餐) - **文档：** 本仓库 ## 架构 ``` [UptimeRobot] --HTTP check every 1 min--> [EC2 Instance running Nginx] | (Public IP) ``` ## 我的操作 1. 配置了一台 Linux EC2 实例，并安装 Nginx 作为 Web 服务。 2. 配置了 UptimeRobot，通过每分钟一次的 HTTP 检查来监控服务，并在停机时发送邮件告警。 3. 通过手动停止 Nginx 服务模拟了生产环境宕机。 4. 在宕机后 1 分钟内收到了停机告警。 5. 在 Jira 中记录了该事件，包括根本原因、解决方案和预防建议。 6. 恢复了服务，并通过监控仪表板确认其已恢复正常。 7. 在下方记录了完整的事件生命周期。 ## 事件报告 **事件：** Web 服务不可用 **检测方式：** UptimeRobot 告警（邮件），[截图](./screenshots/uptime-alert.png) **检测时间：** 约 1 分钟 **根本原因：** Nginx 服务被手动停止（模拟故障 — `systemctl stop nginx`） **解决方案：** 重启 Nginx 服务（`systemctl start nginx`）；通过 UptimeRobot 仪表板显示“正常”状态确认其已恢复 **解决时间：** 约 2 分钟 **预防 / 建议：** - 在 Nginx 单元上启用 `systemd` 自动重启策略（`Restart=always`），以便在服务崩溃时能够自我恢复 - 添加辅助监控检查（例如，在 HTTP 检查之外增加进程级别的检查），以加快根本原因的排查 - 考虑采用负载均衡的多实例架构，以避免单点故障 **Jira 工单：** [工单链接] — 见 [截图](./screenshots/jira-ticket.png) ## 截图 - `screenshots/uptime-alert.png` — 停机告警邮件/仪表板 - `screenshots/jira-ticket.png` — 已记录并解决的事件工单 - `screenshots/service-restored.png` — 显示恢复状态的监控仪表板 ## 展示的技能 Linux 系统管理、Nginx Web 服务器管理、AWS EC2、生产环境监控与告警、事件响应、根本原因分析、技术文档编写、Jira 工单管理。