记录一次事故

Posted 2023-03-02 云满笔记

这里填写目录标题

• 记录一次事故
• • 先讲个故事(也是个事故。..)
  • 事后分析

记录一次事故

先讲个故事(也是个事故。…)

最近手头的一个工作是分析全站的镜像流量, 流程大概是抓取网卡的所有帧逐层解析, 最终是在应用层实现重组 http 会话, 将重组后的数据发送到 kafka 供后端分析。(程序的代码在 http-capture)

程序的细节这里不谈, 直接进入事故。…

一开始这个程序是直接跑在后台的, 为了保证程序的可靠性, 准备托管给 supervisor。于是巴拉巴拉把 supervisor 的配置文件写好, 然后 supervisorctl update, 把程序跑起来了。

嗯, supervisorctl status 看一下, http-capture 状态变成 running, 没毛病, 非常稳! 再 ps 查看一下进程的大概情况, 我了个去有两个 http-capture 进程在工作, 原来之前运行在后台的进程忘记关掉了!

由于是使用 ansible 批量操作的, 所以全部的 12 台设备都是启动了两个进程, 也就是说每台设备同时输出了两份相同的数据! 再一看 kafka 那边的入队情况, 果然 double 了。oh, my god!

事故整个复盘就是这么简答, 后续的处理、恢复工作就先不谈了。

事后分析

整个事故直接原因总结起来很简单, 就是操作人员大意, 误操作导致的。但是深究背后的程序是否存在问题呢, 当然存在很多问题的。

• 首先, 我在操作过程中测试成功后直接使用 ansible 全量上线。更合适的方式应该是先 ansible 操作 1~2 台设备上线, 然后待观察稳定后全量上线。
• 其次, 就是程序本身存在问题, 逻辑不够严谨, 这种要保证一台服务器上只能唯一启动的进程, 在程序启动逻辑中就应该验证这个条件。
• 另外, 就是问题的发现过程, 是偶然的通过 ps 命令查看进程此发现的此问题, 缺少统一的监控、告警工具。
• 最后, 发现问题后, 没有快速的回滚机制, 只能通过命令依次全部 kill 掉后, 但是此时有大量的数据走入后端了, 容错能力不足。

总体说在, 就是在程序启动、运行、关闭的过程中缺少必要的检测、容错和恢复手段。其他的不谈, 这里重点说说第二点, 程序自身的问题, 如何实现程序自身的启动检测。