启动服务并确认它在监听
场景：前面三步（依赖、配置、数据）都做完了。 任务：把服务启动起来（README 第 4 节），确认进程在（ps）、端口在听（ss -ltn）。跑好运行 ~/check。 （判分只看你在受控容器里做出的真机产物：找东西类到 ~/对照表.tx
用健康检查确认它真的能干活
场景：进程能起来了（依赖和配置已备好）。 任务：先 bash ~/svc/run.sh 起服务；然后请求健康检查接口 /healthz（端口见 config.ini），看它返回的状态码——健康不健康要看它（数据拿不到就是 503），而不只是
交付：进程、端口、健康检查三项都正常
场景：本节验收。~/svc 已 clone 并切到要部署的版本，依赖、配置、数据都还没弄；端口在 ~/说明.txt 里。 任务：让这个服务在实验机上真正跑起来——进程在、端口在听、/healthz 返回 200。跑好运行 ~/check。
服务起不来先看什么
敲了启动命令，服务没起来。第一件该做的是【0】。
这次是因为什么起不来
服务启动之后立刻退出了，看它的日志： 缺的那个配置项叫什么？ $ cat /srv/deploy/fail2.log [task-service] FATAL 启动失败：DATA_FILE is not set
先复现：确认它确实起不来
场景：有人说「服务部完起不来」，但没说细节。 任务：自己在 ~/svc 里启动一次（python3 app.py，或 --check），确认它确实退出了而不是起来了但请求不通；看它的退出码（echo $?），到 ~/对照表.txt 里查那个
从日志里找到首个错误
场景：已确认它启动即退出。 任务：在 ~/svc/logs/app.log 里找到第一条致命错误（FATAL），看清它说的是缺什么、还是找不到什么，到 ~/对照表.txt 里查那一类对应的标记。 （判分只看你在受控容器里做出的真机产物：找东
按日志说的把它修好
场景：原因已经在 logs/app.log 的第一条 FATAL 里。 任务：把日志指出的那个问题修掉（README 里写了配置项、依赖、数据各该是什么）。⚠️ 只修它说的那一处，别顺手改别的。改好运行 ~/check。 （判分只看你在受控
重新启动并验证
场景：问题已经修好了，服务还没起。 任务：重新启动（bash run.sh），并用健康检查 /healthz 确认这次真的好了。跑好运行 ~/check。 （判分只看你在受控容器里做出的真机产物：找东西类到 ~/对照表.txt 查标记填进题
再制造一次不同的失败
场景：还有别的起不来的原因。服务现在是好的（依赖/配置/数据齐全）；~/说明.txt 指定了要挪走的东西。 任务：把它挪走（mv 到别处）再启动一次，看 logs/app.log 里这次新出现的 FATAL 说的是哪一类，到 ~/对照表.t