从脚本到函数：用华为云 FunctionGraph 打造一个零运维的定时情报推送机器人

一、痛点：被服务器"绑架"的自动化脚本

很多开发者和我的处境一样：手头有一堆自动化脚本——每天早上抓取资讯汇总成日报、定时检查数据源有没有更新、给团队群发一份简报。这些脚本逻辑本身不复杂，真正麻烦的是"养"它们的成本：

• 一台服务器：哪怕只是跑一个每天执行 5 分钟的脚本，也要 7×24 小时开机。轻量应用服务器按月付费，一个月几十块，一年下来几百块，就为了一个 cron。
• 运维负担：系统补丁、磁盘告警、SSH 密钥轮换、进程守护（crontab 挂了不会有人通知你），脚本一多，"看不见的运维"比写脚本本身还耗时。
• 容错处理别扭：想要失败重试、结果通知，都得自己在脚本里造轮子。

其实这类"短时、定时、无状态"的任务，天生就不该跑在常驻服务器上。华为云的函数计算服务 FunctionGraph，按这个思路重构一遍，体验完全不同。

二、FunctionGraph 的核心模型：事件触发 + 按次计费

FunctionGraph 的思路一句话就能说清：你只提供处理逻辑（一段代码），触发和调度交给平台。

关键概念只有三个：

1. 函数（Function）：一段带入口 handler 的代码，支持 Python、Node.js、Java、Go 等主流运行时，代码可以在线编辑，也可以上传 zip 包，或者从 OBS 拉取。
2. 触发器（Trigger）：函数不会自己跑起来，要靠事件驱动。定时触发器（默认每 10 分钟一次，可配 cron 表达式）、APIG 触发器（把函数变成一个 HTTP API）、DIS/OBS 事件触发器（有数据到达时执行）等。
3. 执行：每次触发产生一次执行实例，冷启动通常在几百毫秒内，执行完即释放，不占任何资源。

计费口径同样简单：按执行次数 + 执行时长（GB·秒）计费，每月有免费额度。一个每天跑 10 次、单次 3 秒的日报机器人，基本落在免费额度内。服务器时代的固定成本，变成了函数时代的边际成本——不用就不花钱。

三、实操：把"每日资讯日报"改造成定时函数

以我自己改造的"技术日报推送机器人"为例，它每天 8:00 抓取若干资讯源，聚合去重后生成 Markdown 日报，推送到 Webhook。拆成三步：

第一步：创建函数与在线编辑代码

控制台进入 FunctionGraph，“创建函数”→ 选择 Python 3.9 运行时 → 勾选"在线编辑"，平台会给出入口模板：

def handler(event, context):
    # event 是触发器传入的事件体（JSON）
    # context 提供 SDK、日志、临时密钥等运行时信息
    logger = context.getLogger()
    logger.info("daily report job triggered")

    items = fetch_sources()        # 抓取各资讯源
    digest = dedupe_and_render(items)  # 聚合去重，渲染 Markdown

    send_to_webhook(digest)        # 推送到 IM Webhook
    return {"status": "ok", "count": len(items)}

几个实测体会：

• 在线编辑器足够顺手：支持直接改代码、保存、配置测试事件一键调试，不需要本地搭完整工程。超过几百行或依赖第三方库时，再切到 zip 上传方式。
• 依赖包：平台内置了 requests 等常用库；更复杂依赖在函数详情页"依赖管理"挂载，注意上传的包要匹配运行时版本。
• 测试事件：定时触发器传入的 event 是固定 JSON，可以先在"配置测试事件"里模拟一遍，避免等第二天早上才发现 bug。

第二步：挂定时触发器

函数详情页 → 触发器 → 新建 → 定时触发器（CronTigger），两种写法：

• 固定间隔：如每 10 分钟、每 1 小时；
• Cron 表达式：0 0 8 * * *（每天 8 点，六段式，注意秒在前）。

保存后触发器即生效，可以在触发器列表看到下一次执行时间。到这里，"每天 8 点自动跑"这件事就结束了——没有服务器，没有 crontab，没有进程守护。

第三步：日志、监控与失败告警

• 日志：context.getLogger() 输出的内容进云日志服务（LTS），按函数名过滤，排障时直接看结构化日志。
• 监控指标：函数详情页自带调用次数、错误率、执行时长、冷启动分布，日报机器人的健康度一眼可见。
• 失败处理：执行失败会体现在指标与日志里；对关键任务可以再挂一个"执行失败时告警"的流程（如函数指标接入告警规则，或由函数自己捕获异常后调用通知 API）。

四、真实成本对比：一年能省下多少

把同一份日报脚本在两种架构下放一年，账大致是这样：

对这种低频短任务，结论很直接：为 5 分钟的任务支付 7×24 的成本，本身就是一种浪费。

五、踩坑清单（5 条实操经验）

1. Cron 时区：定时触发器的 Cron 默认按北京时间执行，但如果你的函数逻辑里有 UTC 假设，注意核对第一次触发的实际时间戳，别让日报提前/推后一小时。
2. 冷启动与代码体积：单函数 zip 尽量控制在几十 MB 内，依赖越重冷启动越慢；短平快任务建议按需 import。
3. 执行超时上限：函数默认超时较短（可在配置里调整），抓取类任务务必给足超时并做外层重试；一次抓不完可以拆成两个函数接力。
4. 敏感信息放环境变量：Webhook 地址、Token 不要硬编码在代码里，用函数"环境变量"配置，修改配置不用动代码。
5. 幂等性：触发器重试或手工补跑会让函数一天执行多次，写库/推送类副作用务必做幂等（比如带日期的去重键），否则日报会发两遍。

六、总结

把一个定时脚本从服务器搬到 FunctionGraph，改变的其实不只是托管方式，而是成本模型和心智负担：

• 按次计费替代按月包干，低频任务的边际成本趋近于零；
• 触发器替代 crontab，调度、执行、日志、监控全部平台化；
• 在线编辑 + 测试事件，让"改一行逻辑"到"验证生效"的距离缩到分钟级。

当然，它不是万能的：长时间高负载计算、有状态的服务、需要固定 IP 的场景仍然适合 ECS/容器。但就"定时任务、事件处理、轻量 API"这三类而言，函数计算是当下性价比最高的答案。如果你手头也有几个"养在服务器上"的脚本，不妨从最简单的一个开始迁移——半小时就能体会到"删掉最后一台服务器"的轻松。

本文基于华为云 FunctionGraph 控制台的实操整理，文中配置项以控制台实际界面为准。