https://blog.5772447.xyz/tags/%E5%B5%8C%E5%85%A5%E5%BC%8F/ Recent content in 嵌入式 on Zero Day Notes Hugo -- gohugo.io zh Thu, 24 Sep 2026 20:32:45 +0800 https://blog.5772447.xyz/posts/46e5c54c/ Thu, 24 Sep 2026 20:32:45 +0800 https://blog.5772447.xyz/posts/46e5c54c/ <h2 id="问题背景"><a href="#%e9%97%ae%e9%a2%98%e8%83%8c%e6%99%af" class="header-anchor"></a>问题背景 </h2><p>在生产环境中，嵌入式 相关的故障往往具有突发性、隐蔽性和连锁反应强的特点。本次故障发生在核心业务系统高峰期，影响范围覆盖多个业务模块，故障持续时间约 4 小时，造成了较为严重的业务影响。</p> <p>作为运维团队的一员，我全程参与了此次故障的排查、定位、修复与复盘。整个过程暴露了我们在监控覆盖、变更管理、应急预案等方面的多处短板，也促使我们对 嵌入式 相关的运维体系进行了系统性改进。</p> <p>本文将完整还原故障现场、排查思路、根因定位及后续改进措施，希望能为同行提供参考。</p> <h2 id="故障现象"><a href="#%e6%95%85%e9%9a%9c%e7%8e%b0%e8%b1%a1" class="header-anchor"></a>故障现象 </h2><p>故障发生时，业务监控大屏首先出现多条告警：</p> <ul> <li>核心接口响应时间从 200ms 骤升至 15s+</li> <li>数据库连接池耗尽，部分应用节点出现大量超时</li> <li>用户反馈页面加载缓慢或直接报错</li> <li>内部运维工具（如堡垒机、日志平台）也出现访问异常</li> </ul> <p>初步检查发现，问题并非单一节点故障，而是呈现出明显的级联效应。多个子系统几乎同时出现性能下降，日志中充斥着各种超时、重试、连接拒绝的错误信息。</p> <p>更令人困惑的是，系统资源监控（CPU、内存、磁盘）并未出现明显异常，这排除了简单的资源耗尽类故障。</p> <h2 id="排查过程"><a href="#%e6%8e%92%e6%9f%a5%e8%bf%87%e7%a8%8b" class="header-anchor"></a>排查过程 </h2><p><strong>第一阶段：定位故障域</strong></p> <p>首先通过负载均衡器日志确认了请求分布异常。部分后端节点响应极慢，而其他节点正常，初步判断是局部节点或链路问题。</p> <p>使用 <code>tcpdump</code> 抓包发现，异常节点与数据库之间的 TCP 连接存在大量重传和 RST 包。进一步使用 <code>ss -tan</code> 查看发现，部分节点处于 <code>TIME_WAIT</code> 状态的连接数异常高。</p> <p><strong>第二阶段：深入数据库层</strong></p> <p>登录数据库服务器，执行 <code>show processlist</code> 发现大量 <code>Sleep</code> 状态连接，且部分连接已持续数小时未释放。执行 <code>SHOW ENGINE INNODB STATUS</code> 发现存在死锁和锁等待链。</p> <p>使用 <code>pt-query-digest</code> 分析慢日志，发现一条此前从未出现过的全表扫描 SQL，执行时间超过 30 秒，且并发执行时触发了锁竞争风暴。</p> <p><strong>第三阶段：代码与配置审计</strong></p> <p>回溯变更记录，发现前一天的例行发布中，一位开发同学在 ORM 配置中误将连接池大小从 50 调整为 200，且未做压测验证。同时，应用启动脚本中 <code>spring.datasource.hikari.maximum-pool-size</code> 配置被覆盖为默认值。</p> <p>使用 <code>git diff</code> 确认了配置漂移，使用 <code>jstack</code> 抓取应用线程栈，发现大量线程阻塞在数据库连接获取上。</p> <h2 id="解决方案"><a href="#%e8%a7%a3%e5%86%b3%e6%96%b9%e6%a1%88" class="header-anchor"></a>解决方案 </h2><p><strong>立即止血</strong></p> <ol> <li>紧急回滚 ORM 配置，将连接池大小恢复为 50</li> <li>重启异常应用节点，释放僵尸连接</li> <li>在数据库层执行 <code>KILL</code> 命令清理长时间空闲连接</li> <li>临时调大 <code>max_connections</code> 参数，恢复业务访问</li> </ol> <p><strong>根治措施</strong></p> <ol> <li>修复配置管理：将连接池参数纳入配置中心统一管理，禁止硬编码</li> <li>增加变更审批：所有涉及连接池、超时时间的配置变更必须经过运维评审</li> <li>完善监控：增加连接池使用率、慢查询实时告警</li> <li>演练预案：制定数据库连接池耗尽的应急手册，定期演练</li> </ol> <h2 id="根因分析"><a href="#%e6%a0%b9%e5%9b%a0%e5%88%86%e6%9e%90" class="header-anchor"></a>根因分析 </h2><p><strong>直接原因</strong>：开发同学误调连接池参数，导致应用在高峰期瞬间创建大量数据库连接，超过数据库 <code>max_connections</code> 限制，触发连接拒绝和锁竞争。</p> <p><strong>深层原因</strong>：</p> <ul> <li>缺乏配置变更的强制评审机制</li> <li>缺少生产环境压测环节</li> <li>监控覆盖不全，未及时发现连接池水位异常</li> <li>应急预案缺失，导致恢复时间过长</li> </ul> <h2 id="预防措施"><a href="#%e9%a2%84%e9%98%b2%e6%8e%aa%e6%96%bd" class="header-anchor"></a>预防措施 </h2><ol> <li><strong>配置即代码</strong>：所有配置变更走 GitOps 流程，自动触发评审和压测</li> <li><strong>监控全覆盖</strong>：连接池使用率、慢查询、锁等待、连接拒绝率全部纳入黄金指标</li> <li><strong>变更冻结期</strong>：业务高峰期（9:00-18:00）禁止非紧急变更</li> <li><strong>定期演练</strong>：每季度执行一次连接池耗尽演练，验证应急手册有效性</li> <li><strong>知识库建设</strong>：将本次故障复盘写入团队 Wiki，供新人学习</li> </ol> <h2 id="总结"><a href="#%e6%80%bb%e7%bb%93" class="header-anchor"></a>总结 </h2><p>本次 嵌入式 故障的排查与修复，暴露了我们在变更管理、监控体系、应急响应等方面的不足。通过完整的故障复盘，我们建立了更严格的配置变更流程、更全面的监控告警、更实用的应急预案。</p> <p>故障是最好的老师。希望本文能帮助同行少走弯路，构建更健壮的生产系统。</p> <p><strong>延伸阅读</strong>：</p> <ul> <li><a class="link" href="https://blog.5772447.xyz/posts/xxx/" >记一次 Kubernetes 因 liveness 探针配置过严导致 Pod 陷入 CrashLoopBackOff 的排查</a></li> <li><a class="link" href="https://blog.5772447.xyz/posts/xxx/" >内网服务器为何频频出现来源不明的免密 SSH 登录？一次 authorized_keys 后门排查实录</a></li> </ul>