elizabeth-ikechukwu/technical-support-portfolio

# 技术支持作品集 **生产级事件响应与监控模拟** 这是一个实践性的技术支持工程项目，展示了在真实的 AWS 生产环境中，端到端的事件处理流程——从前瞻性检测、自动化修复、根因分析到永久预防。 ## 实时环境 | 组件 | 详情 | |---|---| | 应用 URL | https://support.lizzycloudlab.online | | 服务器 | AWS EC2 Ubuntu t3.micro | | 主机名 | support-simulation-server | | 监控面板 | Datadog -- Support Simulation - Server Health | ## 技术栈 | 工具 | 作用 | |---|---| | AWS EC2 Ubuntu | 生产服务器 | | Node.js | 应用 runtime | | Nginx | 反向代理及 SSL 终止 | | Certbot | SSL 证书管理 | | Datadog | 监控、报警、日志管理、Synthetics | | Slack | 事件通知渠道 | | Systemd | 服务管理与自动重启 | | Bash | 自动化修复与预防脚本 | | Cron | 定时自动化任务 | | Logrotate | 日志轮转与管理 | ## 架构 ``` Internet │ ▼ DNS (support.lizzycloudlab.online) │ ▼ AWS EC2 -- support-simulation-server │ ├── Nginx (port 443/80) │ └── Reverse proxy → Node.js app (port 3000) │ ├── Node.js App (systemd managed) │ ├── GET / │ ├── GET /health │ └── GET /api/tasks │ ├── Datadog Agent │ ├── Host metrics (CPU, memory, disk, network) │ ├── Nginx integration │ ├── Log collection │ └── Synthetics HTTP check │ └── Bash Scripts ├── incident-response-nginx.sh ├── cpu-remediation.sh ├── cleanup-disk.sh └── remediate-app.sh ``` ## 监控设置 ### Datadog 监视器 | 监视器 | 指标 | 报警阈值 | 警告阈值 | |---|---|---|---| | CPU 使用率过高 | system.cpu.user | > 85% | > 70% | | 内存使用率过高 | system.mem.pct_usable | < 15% | < 20% | | 磁盘空间危急 | system.disk.in_use | > 80% | > 70% | | Nginx 宕机 | nginx.net.connections | < 1 | < 2 | | 应用健康检查 | Synthetics HTTP | non-200 响应 | - | 所有监视器都会将报警路由到 Slack 的 `#LizzyCloudLab-incidents` 频道，并在每条报警消息中嵌入结构化的调查步骤。 ### Datadog 面板 **Support Simulation - Server Health** —— 实时面板，在单一视图中展示 CPU 使用率、内存使用率、磁盘使用率、Nginx 连接数、系统负载以及日志流。 ## 事件模拟 在此环境中模拟、调查并解决了四个生产级事件。每个事件都遵循完整的生命周期：检测 → 调查 → 解决 → 预防。 ### INC-001 -- Nginx 服务故障 (P1 - 紧急) | 指标 | 详情 | |---|---| | 日期 | 2026年4月12日 | | 检测 | Datadog Nginx 监视器 -- 2 分钟 | | 解决 | 自动化脚本 -- 13 分钟 | | SLA | 达标 | **事件经过：** Nginx 服务停止，导致面向客户的应用下线。Datadog 在 2 分钟内检测到中断，并发送了 Slack 报警。自动化响应脚本验证了配置，重启了 Nginx，并确认了服务已恢复。 **脚本：** `incident-response-nginx.sh` **完整报告：** [INC-001-nginx-service-failure.md](./incidents/INC-001-nginx-service-failure.md) ### INC-002 -- CPU 使用率过高：失控进程 (P2 - 高) | 指标 | 详情 | |---|---| | 日期 | 2026年4月13日 | | 检测 | Datadog CPU 监视器 -- 5.5 分钟 | | 解决 | 进程终止 -- 3 分钟 | | SLA | 达标 | **事件经过：** 两个失控的压力测试 worker 进程消耗了两个 vCPU 上 95-98% 的 CPU。Datadog 在平均 CPU 达到 90.859% 时触发了报警。调查通过 `ps aux` 确定了导致问题的 PID。部署了 CPU 修复脚本，并通过 cron 每 5 分钟调度一次，以自动防止此类问题复发。 **脚本：** `cpu-remediation.sh` **完整报告：** [INC-002-high-cpu-runaway-process.md](./incidents/INC-002-high-cpu-runaway-process.md) ### INC-003 -- 磁盘空间危急：失控日志文件 (P2 - 高) | 指标 | 详情 | |---|---| | 日期 | 2026年4月13日 | | 检测 | Datadog 磁盘监视器 -- 11 分钟 | | 解决 | 清理脚本 -- 43 分钟 | | SLA | 达标 | | 额外发现 | 发现并纠正了 Datadog 监视器配置错误 | **事件经过：** 一个失控的日志文件在 `/tmp` 中占用了 1.6G 空间，将根分区使用率推高至 96%。Datadog 在磁盘使用率达到 95.8% 时触发了报警。调查使用 `df -h` 和 `du -sh` 找出了罪魁祸首文件。清理脚本删除了大文件并清除了 journal 日志。配置了 Logrotate 和 cron 作业以实现永久性的自动化预防。 **关键发现：** 在调查过程中发现了一个 Datadog 监视器的配置错误——该监视器之前评估的是 loop 设备，而不是根分区。通过将监视器范围限定为 `device_label:cloudimg-rootfs` 纠正了此问题。 **脚本：** `cleanup-disk.sh` **完整报告：** [INC-003-disk-space-critical.md](./incidents/INC-003-disk-space-critical.md) ### INC-004 -- 应用 502 Bad Gateway (P2 - 高) | 指标 | 详情 | |---|---| | 日期 | 2026年4月14日 | | 检测 | Datadog Synthetics HTTP 检查 -- 1 分钟 | | 解决 | 自动化修复脚本 -- 17 分钟 | | SLA | 达标 | **事件经过：** Node.js 应用进程停止，而 Nginx 继续运行，导致所有请求返回 502 Bad Gateway。Datadog Synthetics 在 1 分钟内检测到了 non-200 响应。调查通过 `ss -tlnp` 确认 3000 端口上没有任何程序在监听。自动化修复脚本重启了服务，并在无需人工干预的情况下确认了 HTTP 200 的状态恢复。 **核心洞察：** 502 错误表明上游应用无法访问——而不是 Nginx 本身损坏。对于初始分诊，端口检查（`ss -tlnp`）比日志分析更快。 **脚本：** `remediate-app.sh` **完整报告：** [INC-004-502-bad-gateway.md](./incidents/INC-004-502-bad-gateway.md) ## 自动化脚本 | 脚本 | 用途 | 触发方式 | |---|---|---| | `incident-response-nginx.sh` | 验证 Nginx 配置，重启服务，验证恢复情况 | 手动或值班响应 | | `cpu-remediation.sh` | 识别并杀掉 CPU 占用超过 80% 的进程 | Cron，每 5 分钟 | | `cleanup-disk.sh` | 删除 /tmp 中的大文件，清除旧的 journal 日志 | Cron，每天凌晨 02:00 WAT | | `remediate-app.sh` | 检查 endpoint 健康状态，检测到 non-200 时重启应用 | Cron，每 5 分钟 | 所有脚本都会将带有时间戳的输出记录到 `/var/log/` 中，以供审计追踪。 ## 仓库结构 ``` technical-support-portfolio/ ├── incidents/ │ ├── INC-001-nginx-service-failure.md │ ├── INC-002-high-cpu-runaway-process.md │ ├── INC-003-disk-space-critical.md │ └── INC-004-502-bad-gateway.md ├── scripts/ │ ├── incident-response-nginx.sh │ ├── cpu-remediation.sh │ ├── cleanup-disk.sh │ └── remediate-app.sh ├── screenshots/ │ ├── incident-1-nginx-down/ │ ├── incident-2-high-cpu/ │ ├── incident-3-disk-space/ │ └── incident-4-502-bad-gateway/ └── README.md ``` ## 展示的核心技能 - 使用 Datadog 监视器和 Synthetics 进行前瞻性事件检测——无需等待客户报告 - 使用 Linux 命令进行结构化的事件调查——`systemctl`, `journalctl`, `ss`, `top`, `ps aux`, `df`, `du` - 使用 Bash 脚本进行自动化修复——生产环境中无需人工干预修复 - 使用 cron、logrotate 和 systemd 重启策略实现永久预防 - 专业化的事件记录，包含 SLA 指标、时间线、根因分析和经验总结 - 在实时事件调查过程中识别并纠正监控配置错误 - 通过 Slack 进行报警路由，并在报警消息中嵌入结构化的调查步骤 ## 下一步计划 - INC-005：内存耗尽模拟——即将推出 - Runbooks：针对所有 4 类事件的内部值班 Runbook - 项目 2：针对 5 种常见 SaaS 支持场景的面向客户的故障排除 Runbook *构建与维护：Elizabeth Ikechukwu -- 技术支持工程师 | DevOps 与云计算背景* *LinkedIn: https://www.linkedin.com/in/ikechukwu-elizabeth*

标签：AWS EC2, Bash脚本, Datadog, Nginx, 库, 应急响应, 自动化运维, 运维监控