1. 课程导学与场景概述：定时巡检自动化是什么、为什么需要自动化、Lambda在其中的角色
定时巡检自动化，说白了就是让机器替你盯着系统。有问题自动喊你，不用每天亲自登录服务器去敲命令、看指标。
我刚开始做运维那会儿，每天早上的第一件事就是挨个服务器检查磁盘、内存、CPU。20多台机器，一台一台登录，敲 df -h、free -m、top，把结果记在Excel里。那个滋味，谁干谁知道。
后来我接手了一个电商平台，服务器从20台涨到80台。每天光巡检就要花掉一个专职人力。更痛苦的是——有一次我漏查了一台机器的磁盘，结果凌晨3点告警响了，磁盘写满，服务挂了4个小时。那个教训，我到现在都记得。
1.1 定时巡检自动化是什么
定时巡检自动化，就是让系统按照预定计划，自动执行检查任务，验证各项服务是否正常运行。你只需要定好规则、写好逻辑，剩下的交给机器。
传统做法：每天登录服务器，敲命令，看输出，人工记录。偶尔写个脚本，还得手动触发。说白了，"人肉巡检"。
自动化的做法：用CloudWatch Events设置一个定时触发器，到点自动调用Lambda函数。函数里写好了巡检逻辑——检查磁盘、测端口、验证API响应、查看日志错误。检查完把结果写到日志或数据库，有问题直接发告警。
我在上一个项目中，把30多个巡检项全部搬到了Lambda上。你猜怎么着？整个巡检链路从原来的2小时缩短到3分钟，而且是全自动的。
核心转变：从"人盯着系统"变成"系统盯着系统"，人只在异常发生时介入。
1.2 为什么需要自动化
手动巡检的问题，其实远不止"费时间"这么简单。我来列几个典型的痛点：
- 人力成本高——每天至少占用一个人，规模大了根本顶不住。
- 容易遗漏——机器一多，总有漏查的。人不是机器，会疲劳。
- 响应滞后——白天巡检没问题，晚上出了故障，第二天才知道。
- 难以追溯——昨天的巡检结果记在哪个文件里？上周三的磁盘使用率是多少？查起来很麻烦。
- 规模瓶颈——100台服务器还能勉强应付，1000台呢？手动查一遍要一整天。
我曾经因为一次巡检遗漏，导致某个核心服务在凌晨挂了，直到早上7点用户投诉才发现。从那以后，我下定决心——绝不能再靠"人工盯防"了。
下面是手动巡检和自动化巡检的对比，数据来自我实际项目的统计：
| 维度 | 手动巡检 | 自动化巡检 |
|---|---|---|
| 巡检效率 | 2小时 / 天（30台） | 3分钟 / 天（30台） |
| 准确性 | 依赖个人状态，漏查率约5% | 100%一致，不遗漏 |
| 人力成本 | 1人专职，年薪十几万 | 几乎为零（Lambda按调用量计费） |
| 可追溯性 | Excel / 纸质记录，难查 | 完整日志，随时回溯 |
| 覆盖范围 | 核心服务器 + 关键服务 | 全量覆盖，包括边缘服务 |
| 响应速度 | 被动发现，延迟数小时 | 实时告警，分钟级响应 |
你想想看，这些优势还不是最关键的。真正让我下定决心的是——自动化巡检能把人从枯燥的重复劳动中解放出来，去做更有价值的事情。
1.3 Lambda在其中的角色
为什么选Lambda来做定时巡检？说白了，就是不想再维护一台专门跑脚本的服务器。
我之前用Crontab + Shell脚本做过一套巡检系统，跑了两年。问题在哪？那台ECS服务器要打补丁、要监控磁盘、要处理进程挂掉的情况。为了一个巡检脚本，我得养一台服务器，还得保证它7×24小时在线。这本身就是一个运维负担。
Lambda彻底解决了这个问题：
- 无服务器——不用管操作系统、运行时环境、补丁升级。
- 事件驱动——CloudWatch Events定时触发，到点自动执行。
- 按量付费——没执行就不花钱。一天巡检24次，一个月才几块钱。
- 自动扩展——同时巡检100个服务也不怕，Lambda自己扛并发。
- 生态集成——跟SNS发告警、跟DynamoDB存结果、跟CloudWatch记日志，一行代码的事。
我的习惯：每个Lambda函数只做一件事。比如"检查磁盘"是一个函数，"检查API响应"是另一个函数。分开部署，互不影响，出问题时定位也快。
下面是一个极简的巡检Lambda函数示例，检查目标URL的健康状态：
import json
import urllib.request
def lambda_handler(event, context):
target = event.get('target_url', 'https://api.example.com/health')
try:
req = urllib.request.Request(target, method='GET')
with urllib.request.urlopen(req, timeout=5) as resp:
body = resp.read().decode()
status = 'healthy' if resp.status == 200 else 'degraded'
return {'status': status, 'code': resp.status, 'body': body[:200]}
except Exception as e:
return {'status': 'unhealthy', 'error': str(e)}我曾经踩过的坑：Lambda默认超时是3秒，第一次写巡检函数时忘了改，结果目标API响应慢了一点，函数直接超时报错。巡检任务建议把超时设为30秒以上，尤其是涉及数据库查询或外部API调用的场景。
1.4 整体工作流程
到这里，你应该对定时巡检自动化的核心链路有了基本认识。下面这张图把整个流程串了起来：
整个链条很清晰：定时触发器到点唤醒Lambda → Lambda去检查目标服务 → 拿到结果后分析 → 异常就走告警分支，正常就走日志分支。每个环节职责单一，出了问题也容易排查。
1.5 小结
这一章我们聊了三件事：
- 定时巡检自动化是什么——用自动化工具替代人工，按计划执行系统检查。
- 为什么需要自动化——省人力、防遗漏、快响应、可追溯。规模越大，收益越明显。
- Lambda在其中的角色——作为无服务器计算核心，承载巡检逻辑，与CloudWatch Events、SNS等云服务协同工作。
一句话总结：定时巡检自动化的本质，就是用"机器监控机器"替代"人肉盯防"。Lambda让这件事变得简单、便宜、可靠。
我个人觉得，做运维也好，做后端也好，凡是重复性的"检查工作"，都值得用自动化替代。你省下来的不只是时间，还有半夜被告警吵醒的"惊喜"。嗯，这个我经历过太多次了。