HECHEN 这个代号最初只是我在一台旧服务器设备清单上随手写下的几个字母完整名称后面还带了一长串房间号后缀后来没人记得了大家都直接叫它 HECHEN。它原本只是一个小实验把每天早上需要手工汇总、手工核对、手工通知的数据流程自动化。结果这个实验从第一天跑通之后就再没停过慢慢成了我们部门每天早上离不开的工具。如果你也经常被重复的报表、核对、提醒搞得心烦那这篇文章应该能给你一些启发——它不涉及什么高深技术但里面关于需求取舍、格式兼容、告警策略的教训都是实打实踩过坑换来的。1. 为什么会有 HECHEN从一个很朴素的痛点开始1.1 每天早上的数据整理战先说背景。我们部门每天早上要出一份前一天的运营汇总内容不复杂就是把几个不同来源的数据拼到一张表里再检查有没有明显异常。听起来很简单但实际执行起来非常费劲。数据来源大概有三个一个是内部系统导出通常是 Excel但表头偶尔会变一个是第三方平台导出的 CSV 列顺序和编码偶尔也会抽风还有一个是共享文档里面由不同的人各自维护填写格式经常不统一。我每天早上大概要花二十到四十分钟在复制粘贴和格式调整里反复折腾。最让人崩溃的不是工作量大而是错了不容易发现。比如某个渠道的数据忘了粘贴或者小数位没对齐汇总表看起来依然整整齐齐但数值已经不对了。有一次周一的晨会大家盯着一个异常高企的转化率讨论了很久最后查下来发现是某人复制的区域比平时多了一行。那次之后我下定决心做一个自动化的小东西哪怕只能省一半时间也值。1.2 需求收敛从“大平台”到“小工具”最开始我脑子里冒出来的方案其实很夸张。我想做一个完整的数据平台支持多用户登录、权限区分、自定义报表、可视化大屏还要能对接公司的审批流。这些想法拆开看都很美好但以当时的时间精力根本不现实而且团队真正需要的也许根本不是那些东西。于是我给自己定了一个规则先列出“每天必须重复做的事”而不是“以后可能用得上的功能”。最后筛选出来的核心动作只有三个把数据按固定格式汇总到一张表里按照预设条件判断哪些数据异常把结果以一份简短报告的形式发到群里。HECHEN 的所有功能都是围绕这三件事展开的其他全部砍掉。事实证明这个收敛非常关键本来预估两三个月都未必做完的事情最后大概花了两周就有一个能用的版本。越到后期我越发现内部工具最怕的不是功能少而是功能多到没人愿意维护。1.3 关于名字一次随意但凑巧的命名关于 HECHEN 这个名字可能有人以为是取什么英文单词或者某个人的名字其实都不是。当时项目一开始要注册一个内网服务名我对着设备清单随手填了几个字母加上房间号后缀全称很长后来为了在群里发链接方便就简化成了 HECHEN。严格来说它没有任何含义但因为它简洁、好记、在群里不会和别的服务重名就一直用下去了。起名这件事我一直觉得内部工具叫着顺口比寓意重要省得每次沟通都要解释一遍全称。2. HECHEN 的核心方案与选型理由2.1 技术栈为什么是 Python Flask很多朋友问我为什么选 Python 加 Flask而不是 Node 或者 Spring Boot。最大的原因其实是团队的语言环境我们平时做数据处理、写分析脚本都用的 Python大家看 Python 代码基本没有障碍。如果有人要接手改一个小需求不需要重新学一套东西。框架方面我对比过 Flask 和 DjangoHECHEN 的接口数量很少核心逻辑就几十个函数Django 自带的管理后台、ORM、迁移工具大部分用不上Flask 就足够清爽。当时也想过直接上前后端分离Vue 写页面后端只出接口后来觉得内网小工具没必要增加构建和部署的复杂度所以用简单的服务端渲染页面就几页完全够用。这是典型的内部工具选型思路优先考虑维护成本和上手门槛而不是技术栈本身的流行度。代码放到现在看也谈不上多优雅但胜在简单任何初级工程师花半天就能把整个项目读懂。项目目录结构大概是这样的hechen/ ├── app.py # 入口与页面路由 ├── scheduler.py # 定时任务调度 ├── adapters/ │ ├── base.py # 数据接入抽象基类 │ ├── excel_adapter.py │ ├── csv_adapter.py │ └── json_adapter.py ├── config.json # 数据源与规则配置 ├── templates/ │ ├── index.html # 汇总看板 │ └── detail.html # 异常详情 └── data/ └── hechen.db # SQLite 数据库这个目录结构是我后来整理的最初所有代码都挤在一个脚本里能跑之后才慢慢拆开。如果一开始就规划得太细可能反而迟迟动不了工。2.2 数据存储SQLite 够用就别折腾存储这块我一开始差点上了 MySQL。当时觉得数据库总得用正经的客户端服务器架构后来冷静想了想 HECHEN 的实际负载每天入库的记录多的时候也只有几万条同时在线的人基本就是早上那一两个盯着看板的人SQLite 单文件数据库对这种场景绰绰有余。用 SQLite 最大的好处是备份变得极其简单每天半夜打包拷贝一个文件就够了开发的时候也方便代码里直接连本地文件完全没有环境依赖。有的同事问过并发写的问题。HECHEN 的写入主要发生在定时任务执行的那一刻而读又集中在早上查看报告那几分钟SQLite 的锁机制处理这种低并发完全没问题。我唯一加的保险是定时任务串行执行不要多个任务同时写库。如果你的场景也是这种高写一次、低频读的类型SQLite 真的够用没必要为了一个内网系统引入一套数据库服务器。2.3 调度与通知APScheduler 加群机器人定时任务是 HECHEN 最核心的能力之一。最开始我当然想过直接用系统 crontab但很快发现一个问题我希望每天早上执行完任务之后能有一个运行记录留在页面上方便大家确认到底跑没跑、跑了多久、结果怎么样。cron 本身不提供这种状态管理所以选用了 APScheduler把调度信息放在内存里同时在数据库里记一份执行日志。服务重启之后下一次到点会自动重新调度不需要人工干预。通知方式选的是办公群机器人。为什么不用邮件因为每天早上大家基本都在 IM 上群消息里直接带链接点开就能看到完整报告比邮件少一个跳转步骤。为什么不用短信内网工具没必要消息内容又不是真的紧急到什么程度。配置群机器人基本不需要走审批流程填一个 webhook 地址就能用接入成本几乎为零。这里想提醒一句群机器人通知最好把“异常摘要”放在消息正文里而不是只扔一个链接不然大家看到消息还要多一次点击才明白发生了什么久而久之就没人看了。3. HECHEN 的核心实现从数据接入到规则判断3.1 数据接入层先解决格式混乱真正写代码的时候发现最耗时间的不是规则判断而是数据接入。每个数据源的格式都有自己的脾气Excel 的表头有时带合并单元格有时第一行是标题第二行才是表头CSV 的编码可能是 GBK 也可能是 UTF-8列顺序还会调整第三方平台导出的 JSON 字段名跟内部习惯叫法完全不一样。为了不让这些差异污染上层逻辑我设计了一个很薄的接入层每个数据源写一个适配器统一输出为标准结构。# adapters/base.py from abc import ABC, abstractmethod class BaseAdapter(ABC): def __init__(self, source_config): self.source_config source_config abstractmethod def fetch(self): 返回标准化的 DataFrame统一包含列名、日期、数值字段 def _standardize_columns(self, df, mapping): 把源字段名映射成内部统一字段名 return df.rename(columnsmapping)每个数据源的适配器只需要做三件事读取原始文件、清洗格式、映射字段名。上层规则引擎根本不需要知道数据来自 Excel 还是来自接口。这种抽象虽然很简单但价值非常大后来第三方平台的导出格式变了好几次我都只需要修改对应的适配器其他代码一行没动。清洗的时候我养成了一个习惯别相信任何外部文件的表头。宁可多写几个判断也不要假设第几列一定是日期。因为这种假设早晚会被某个同事新加的列打乱那时候不是代码报错而是一声不响地错位比报错难查得多。3.2 可配置规则引擎把检查逻辑从代码里抽出来规则判断是 HECHEN 最有意思的部分。一开始我把规则硬编码在代码里比如 if value 10000: flag()改一次阈值就要改一次代码、重启一次服务非常麻烦。后来我把它改成了配置文件驱动所有规则写成 JSON程序启动时读取页面还提供一个简单的编辑入口这样修改阈值不需要碰代码。{ rules: [ { name: 单渠道销售额突增, field: sales, operator: gt, threshold: 100000, level: warning, days: 1 }, { name: 订单量连续两日下降, field: orders, operator: decreasing_for_days, threshold: 2, level: blocker } ] }解析规则时我用的是白名单方式操作符只能从预设集合里选比如 gt、lt、eq、decreasing_for_days、not_empty每个操作符对应一个实现函数。这样做有两个原因一是安全配置文件不会被执行任意代码二是可控页面下拉框能直接展示所有可用操作符使用者不用记语法。规则级别分为 warning 和 blocker。warning 只在看板里标黄不打断流程blocker 会额外在群里通知需要有人处理。把级别分开很重要不然所有异常都同等对待很快就会被忽略掉。3.3 极简页面能看清异常就够了HECHEN 的页面极其朴素。首页是一个日期选择器加上一张汇总表异常单元格用不同颜色标注黄色是 warning红色是 blocker鼠标点上去会弹出具体规则和当前值。每一行数据旁边还有一个“忽略”按钮操作人会填写忽略原因这个原因会记录到数据库里后续在报告里能追溯。这个功能看着不起眼但非常实用很多异常其实不需要处理有了“忽略”通道大家才愿意继续关注真正重要的告警。我没有用大屏、图表、趋势线这些花哨的东西因为团队真正需要回答的问题是“昨天的数据正不正常”而不是“本周的趋势波形长什么样”。少一点视觉噪音页面加载更快关注点更集中。4. 从开发机到团队日常部署与运维实录4.1 部署环境与进程守护HECHEN 跑在一台内网旧台式机上装了 Linux 系统Python 3.8。选这台机器没有特别理由它是当时闲置配置最高的一台。部署方式也很朴素把代码放到 /opt/hechen 目录创建虚拟环境然后用 systemd 把它注册成一个常驻服务。为什么用 systemd 而不是 nohup 或者 Docker因为这台机器资源有限Docker 不是必须的而 systemd 自带进程守护服务挂了会自动拉起日志也能统一收进 journalctl排查问题非常方便。# /etc/systemd/system/hechen.service [Unit] DescriptionHECHEN Data Check Service Afternetwork.target [Service] WorkingDirectory/opt/hechen ExecStart/opt/hechen/venv/bin/python /opt/hechen/app.py Restartalways RestartSec5 Userhechen [Install] WantedBymulti-user.target启动之后记得执行 systemctl enable hechen否则机器重启之后服务不会自动起来。这个教训我印象很深有段时间总感觉第二天早上页面打不开最后发现是为搭建测试环境重启过机器服务没设开机自启。4.2 定时任务的时间线设计HECHEN 的一天大概是这样的节奏7:20 各数据源调度器开始拉取文件7:30 数据入库7:35 规则引擎跑一遍检查7:40 汇总报告推送到群里。为什么中间留这么多缓冲因为数据源之间的文件上传时间并不固定有的第三方平台偶尔会延迟十几分钟缓冲留大一点报告内容才更完整。如果你把时间卡得太死比如 7:30 拉数据 7:31 出报告很容易因为上游一个小延迟就全线失败。除了定时任务我还加了一个页面上的“手动执行”按钮方便补跑。这个按钮做的事跟定时任务完全一样只是多了一个“立即执行”的入口。后来有很多次真实的救场场景比如某数据源早上漏传文件等文件补传到位后点一下按钮报告马上重新生成不用登录服务器去手动跑脚本。4.3 备份与恢复策略HECHEN 的数据其实很简单核心就是 SQLite 单文件加一些上传的源文件所以备份策略也很简单每天凌晨 2 点用 cron 执行一个打包脚本把 data 目录压缩后按日期命名保留最近 30 天。没有做什么异地备份或者实时同步因为对于一个早间小工具来说哪怕丢了前一天的数据影响范围也有限最重要的是备份恢复的过程要足够简单。#!/bin/bash # /opt/hechen/backup.sh BACKUP_DIR/backup/hechen DATA_DIR/opt/hechen/data DATE$(date %Y%m%d) tar czf ${BACKUP_DIR}/hechen-${DATE}.tar.gz -C /opt/hechen data find ${BACKUP_DIR} -name hechen-*.tar.gz -mtime 30 -delete恢复的时候只需要解压文件到 data 目录覆盖原来的文件再重启服务。整套流程我在测试环境演练过两次确认三分钟内能完成才敢放心把备份周期设为一天一次。5. 常见问题与排查技巧实录5.1 数据源格式变化最防不胜防的坑运维 HECHEN 大半年遇到过最多的故障就是数据源格式变。有次第三方平台升级导出的 Excel 里多了一个空列适配器按原来列名映射时没报错但整行数据整体后移数值全部对到错误字段上导致规则引擎报了十几条 blocker群里一大早就炸了锅。排查过程也很典型先看报告里的异常列表发现异常字段集中在同一行之后再回到原始文件对比才看到多了一列。从那以后我做了两件事一是在适配器里加了一个完整性校验行数据映射完之后检查必填字段是否都存在如果缺失就直接在报告中标成“解析异常”而不是继续往下走二是每次第三方平台发送更新公告我都会第一时间在测试环境跑一遍数据接入确认格式没变。这个前置检查比事后排查省心得多。5.2 定时任务不跑或重复跑两个方向的问题定时任务偶尔会出现两种完全相反的故障该跑的时候没跑或者不该跑的时候跑了两次。没跑的情况最常见的原因是服务挂了。如果 systemd 配置得当它能自动拉起来但架不住有人手动停了服务之后忘记启动。所以我后来加了一个健康检查接口和办公群机器人联动每天早上 7:45 如果没收到任何执行日志页面或群里就会看到异常提示算是双保险。重复跑的问题则出在手动执行和定时任务同时触发的情况下。比如定时任务已经 7:30 开始跑数据入库有人看页面数据不对又点了一下手动执行导致两个进程同时写库。修复方式是加了一个简单的文件锁任务启动前先检查锁文件是否存在存在就直接退出任务结束后删除锁文件。这个锁粒度比较粗但对 HECHEN 这种单人维护的小工具完全够用。5.3 告警风暴规则太灵敏等于没有规则HECHEN 上线后的第一周群里消息多得让人想把它卸载。原因是我把阈值设得太灵敏比如销售额环比下降超过百分之一就告警结果正常的业务波动也会触发。大家开始还认真看后来直接免打扰告警反而失去了意义。后来我把规则调成两个维度一是“连续 N 天满足条件才触发”单日波动不再告警二是加了静默窗口同一规则在某个时间段内只告警一次。这两条改完后群里安静了很多但真正重要的异常一条没漏。做这类工具一定要记得告警目的是让人采取行动而不是展示存在感宁可少一点也不要让高频无效消息淹没有效消息。5.4 问题速查表现象常见原因快速排查方法解决办法页面打不开服务未启动或端口占用journalctl -u hechen 查看日志重启服务确认端口未被占用数据缺失上游文件未按时上传查看数据源适配器日志重新拉取或等待文件就绪后手动补跑字段错位数据源增加了列对比原始文件和标准字段映射更新适配器映射并加完整性校验规则没触发阈值设置或规则级别不对在测试环境用构造数据验证规则调整阈值检查规则 operator 是否在支持列表内通知没收到webhook 失效或网络受限直接 curl 测试 webhook更新 webhook 地址检查网络策略定时任务没跑服务被手动停止检查服务状态与上次运行日志重新启动并检查开机自启配置任务重复执行手动触发与定时任务并发查看执行日志是否有重叠增加文件锁保证任务串行这张表是我在后来交接给同事时整理的基本上 90% 的日常问题都能通过它定位到方向。如果你也要做一个类似的小系统建议从上线第一天就把常见的故障现象、原因和排查步骤记录下来因为三个月后你一定会忘记当初是怎么修好的。最后说点跟技术无关的体会。HECHEN 带给我的最大收获不是代码多优雅也不是架构多正确而是让我看明白了一件事内部工具能不能活下去核心不在于功能多少而在于它是否真的解决了某个每天都在发生的琐碎痛点。对于可能想照猫画虎做一个 HECHEN 的朋友我只有几条朴素的建议范围能小就小数据格式兼容要留足冗余告警宁可少而准备份一定要简单可演练。工具是给人用的哪怕只是让谁每天早上的复制粘贴少一次就值得继续维护下去。