容器跑起来了，运维问题并没有消失
docker ps 一片绿色，不等于服务真的稳。
很多人第一次把服务装进 Docker，最直接的感受就是省事：环境统一了，部署顺了，“这台能跑、那台不行”的问题少了很多。这个判断没错，但只对了一半。
容器解决的是打包和分发的一致性。它不会替你处理日志怎么收、数据放哪、时区对不对、磁盘会不会爆、服务挂了以后谁来发现。很多故障不是容器坏了，而是大家在“能跑起来”之后，就默认“已经搞定了”。
最常见的误判：进程活着，服务就算活着
很多镜像启动后，只要主进程没退出，Docker 就会显示容器还在运行。但用户真正关心的不是进程在不在，而是接口能不能用、页面能不能开、任务有没有继续执行。
所以健康检查很重要。说人话，不是看它“有没有喘气”，而是看它“还能不能干活”。
如果没有健康检查，常见情况通常是：
- 应用卡死了，但进程没死
- 上游数据库断连后，服务一直假活着
- 定时任务线程挂了，主程序还在前台装没事
这时候 docker ps 看起来很体面，实际已经在掉数据、丢任务，或者静默失败。
数据卷不是“顺手挂一下”就完事
容器很容易制造一种幻觉：删了再建就行，反正镜像还在。真到线上，事情没这么简单。
要先分清两类东西：
- 镜像里的内容：适合被重建
- 运行中产生的数据：不能随便丢
数据库、上传文件、缓存快照、搜索索引、消息队列状态，这些都不是“重新部署一下”能恢复的。很多问题不在程序代码，而在数据目录挂错了、没挂，或者备份根本没测过恢复。
最近有读者会追问更具体的环境信息、机器信息。这个关心点可以理解，但对普通使用者来说，真正该盯的不是“它是不是容器化了”，而是下面三个问题：
- 重启后数据还在吗
- 换台机器还能恢复吗
- 备份真的试过恢复吗
第三个最容易被跳过，也最致命。没做过恢复演练的备份，可靠性其实是未验证的。
日志默认能看，不代表默认能用
容器日志的默认入口通常是 docker logs。排查小问题够用，但时间一长，问题就出来了：
- 日志太散，多个容器来回切
- 日志不保留，重建后线索直接断掉
更麻烦的是，很多程序把错误打得很随意：一行 failed，没有请求 ID，没有上下文，没有时间说明。容器只是把问题装进盒子里，没把问题讲清楚。
如果服务稍微重要一点，至少要想清楚三件事：
- 日志保留多久
- 出错时能不能快速定位到哪一层
- 容器删掉后，关键日志还在不在
不然排障很快就会变成考古。
时区、权限、磁盘，这些老问题一点没退休
容器化之后，很多人会自动忽略宿主机。其实宿主机还是地板，地板塌了，盒子摆得再整齐也没用。
时区
最常见的表象是：任务明明设了凌晨 3 点执行，结果在错误的时间跑了。报表日期错一天，日志时间对不上，追问题会很烦。
时区不是“大厂级问题”，普通服务一样会踩。
权限
容器里程序能写，挂载到宿主机后突然不能写；或者反过来，权限给得过大，图省事的同时也放大了风险。
很多看起来“莫名其妙”的失败，本质上就是 UID、GID 或目录权限没对齐。
磁盘
这件事尤其现实。镜像缓存、旧容器、构建层、日志文件、数据库卷，都会吃空间。
磁盘快满的时候，故障往往不是一个个出现，而是一起抽风：写入失败、数据库异常、服务重启、备份中断。然后你再去看，容器还在，问题已经一地鸡毛。
真正省心的，不是容器本身，而是默认动作
如果一定要给“容器化之后的运维”一个实用判断，我会看这些动作是不是已经变成默认项：
- 有健康检查，不靠肉眼看
ps - 数据目录明确，不把状态藏进容器层
- 有备份，而且做过恢复验证
- 日志能留、能搜、能定位
- 知道磁盘、权限、时区会出问题，并且提前处理
这些都不高级，甚至有点土。但运维里很多关键细节，本来就不靠炫技，靠的是别偷懒。
Docker 最有价值的地方，是把交付过程变得更可复制。它最容易带来的错觉，是让人以为“可复制”已经等于“可运维”。
后面如果继续往下写，我更想单独拆一个问题：对个人项目和小团队来说，哪些运维检查值得做成固定清单，哪些其实只是把自己忙得很有仪式感。