去年下半年我们团队被一条安全通告搅得人仰马翻。生产环境里一套基于 Docker 部署的开源数据库组件被爆出高危漏洞编号 CVE-2024-5535安全部门要求当天必须给出应急处理方案。麻烦的是这套系统跑了大半年镜像版本早就没人说得清权限也是随手开了一堆连排查从哪下手都是问题。我带着运维和开发同事从资产盘点开始一路做到隔离、止血、升级、复盘把整条链路走了一遍事后又把这套经验整理成了操作手册。今天我把这套处理和排查的思路完整写出来包括 Docker 场景下安全漏洞应急处理的流程、权限问题的定位与修复、镜像供应链的安全加固以及高频故障的排查明细。无论你用的是 Linux 服务器上的 docker 引擎还是 Windows 上装着 Docker Desktop 做开发这套方法都能直接拿去用。1. Docker 开源软件应急处理的整体思路与工作流1.1 容器化的开源软件出漏洞为什么比传统部署更难处理很多人觉得 Docker 部署比传统部署更干净、更隔离出了漏洞直接把容器删了重建就行。这个想法一半对一半错。容器确实是很好的隔离单元但它带来的问题远比想象中多。第一镜像拉取太容易导致资产无限扩散。一个开源软件被封装成镜像后docker run 一行命令就能跑起来。开发环境起一个、测试环境起一个、本地调试再起一个镜像分布在每台机器上。当漏洞通告出来的时候你根本不知道哪台机器上还有什么容器在跑。第二镜像分层复用放大了漏洞面。一个包含基础操作系统的底层镜像如果出了漏洞所有基于它构建的应用镜像都会受影响。我在实际排查中就遇到过一个被通报的基础镜像光是我们内部就衍生了十几个不同项目的应用全部要跟着升级。第三很多人只认镜像 tag 不认 digest。同一个 tag 比如 mysql:8.0镜像仓库是允许被覆盖更新的今天拉到的和三个月前拉到的可能是两个完全不同的镜像。结果就是线上容器里跑的二进制和 Dockerfile 里写的不一致排查时按 tag 定位完全是错的方向。所以在处理应急之前先接受这个现实容器环境下的资产不清是常态在漏洞通告面前平时偷的懒都会加倍还回来。1.2 一套能落地的应急响应流程我在组织应急处理时把流程固定成六个阶段每个阶段都明确动作和负责人。这样即使事发时人不在场照着操作手册也能执行。阶段目标关键动作资产盘点摸清受影响容器与镜像清单全量导出 docker ps、docker images按镜像名和 tag 过滤隔离止血阻断漏洞被利用停容器、改网络策略、关闭端口映射、备份数据证据留存保留现场便于分析保存容器日志、镜像信息、运行参数先不删容器缓解控制降级风险如果业务不能停用临时网络规则、账号口令修改、审计开启修复回归彻底清除漏洞拉取修复后镜像重建容器验证业务复盘加固防止再犯补镜像扫描、修订基础镜像、规范权限这个流程不复杂难点在于每一步都要和业务侧确认能不能停、能停多久。我建议第一步就拉上业务负责人一起开会把停机的窗口定下来后面所有操作才有节奏。1.3 平时就该备好的应急工具箱应急处理的效率很大程度上来自你平时有没有准备好工具和命令。这些工具不需要多贵全都是开源或自带的docker ps / docker ps -a列出运行中和所有容器这是资产盘点的起点。docker inspect查看容器或镜像的详细配置包括运行用户、端口映射、环境变量、挂载卷。docker logs拉取容器日志判断服务是否健康、是否有异常访问。docker diff查看容器文件系统与镜像的差异应急时可以用来判断容器是否被文件级别篡改。jqdocker inspect 输出的是 JSON用 jq 过滤字段比人眼快得多。trivy开源镜像漏洞扫描器一条命令扫出镜像里的 CVE。dive查看镜像层内容的工具排查镜像内部文件变更很有用。建议把这些命令整理成一个速查表放到团队的文档里。平时没人看真出事了它就是你救命的家伙。2. 漏洞应急实战拆解以 CVE-2024-5535 为例2.1 接到通告后先别慌先把影响面摸清楚那次处理的 CVE-2024-5535是涉及 MySQL 系列开源数据库组件的一个高危漏洞。具体的技术细节安全通告里写得很清楚这里我不展开漏洞本身重点说我们是怎么一步步处理的因为这套流程对绝大多数开源软件安全漏洞应急都是通用的。接到通告的第一件事不是拿起手机就冲到机房而是坐下来确认三个问题第一这个漏洞影响哪些版本。把安全通告里列出的受影响版本范围记下来作为后面过滤镜像版本的依据。第二线上有哪些服务用了这个组件。这一步只能靠盘点所有运行中的容器、所有本地存在的镜像都必须查一遍。第三对外暴露面有多大。就算容器里有漏洞如果数据库端口没有对公网或非信任网段开放利用难度会高很多优先级可以往后放。我当时让一个同事专门负责从 docker ps 输出里筛 mysql 相关的容器我自己负责用脚本检查全集群所有镜像的 tag 和 digest。2.2 怎么从正在运行的容器里反查出镜像是哪个很多人以为 docker ps 看到的镜像列就是全部信息其实那只是 tag 字符串。要判断一个容器到底用的哪个镜像必须同时记录 tag 和 digest。先列出所有容器docker ps -a --format table {{.Names}}\t{{.Image}}\t{{.Status}} | grep -i mysql再用 docker inspect 拿到镜像摘要docker inspect container_name | jq .[0].Config.Image, .[0].Imagedocker inspect 输出里有两个字段值得注意Config.Image 是启动容器时指定的镜像.Image 是这个容器实际基于的镜像 ID。有些容器是用旧镜像启动的后来你重新拉了个新 tag容器还是用的老版本文件系统靠 docker ps 是看不出来的。拿到镜像 ID 之后再转成 digest 形式docker inspect --format{{index .RepoDigests 0}} image_name如果这个容器当初是从本地某个镜像启动的本地又找不到对应 tag还能用 docker commit 的痕迹倒推。应急时不用追求百分百精确但凡是能确认的都要把容器名、镜像 ID、digest、启动时间记录到表格里。2.3 隔离与止血能停的停不能停的先上临时规则摸清影响面之后就要决定怎么处理。我们的原则是能停的容器立刻停不能停的容器先上临时防护。能停的容器执行docker stop container_name这里有个细节不要顺手执行 docker rm。容器一旦被删日志、运行参数、文件系统现场全没了。先 docker stop再 docker rename 加一个隔离标记docker rename container_name container_name-quarantine-$(date %Y%m%d)注意应急时不要急着 docker rm保留容器现场后面分析原因和追溯利用路径都用得上。如果业务不能停数据库还得继续对外提供服务那就先做隔离缓解。我当时按优先级做了三件事修改数据库账号口令关掉不必要的账号和权限。开启数据库审计日志把连接来源、执行过的语句记录下来。在网络侧收紧访问只允许业务网段访问数据库端口阻止来自未知来源的连接请求。这里要提醒一句Docker 的端口映射是 iptables 在 DOCKER 链里做的如果你直接用 iptables INPUT 链加规则可能拦不住容器端口正确的做法是在 DOCKER-USER 链上加规则或者用 Docker 自身的网络策略。我们后来又补了一条保险措施直接在容器层面把端口映射临时改掉比如把 3306 映射到内网不常用的端口至少能挡住一批扫描流量。无论走哪条路数据备份都要在最前面做。数据库类的容器直接 tar 数据目录比 mysqldump 更完整。我当时的备份命令tar -czvf /backup/mysql-quarantine.tar.gz -C /data mysql生产环境我建议同时做逻辑备份和物理备份物理备份用来快速恢复现场逻辑备份用来保证数据一致性。2.4 升级修复用干净的镜像重建而不是在容器里打补丁止损做完接下来就是修复。这里我有一个一直坚持的原则容器环境里的修复一定是基于新镜像重建容器而不是进容器里改文件、装补丁。原因很简单。容器是临时创建的运行实例你在里面做的任何修改都不会反映到镜像里。今天手改好了明天容器重启改动全部消失漏洞照旧。而且手动打补丁无法记录到镜像版本里审计时也说不清楚。如果是用 docker compose 部署的修复流程非常清晰。先改 docker-compose.yml 里的镜像 tag把原来受影响的 mysql 版本换到官方修复后的版本下面 8.0.39 只是示例版本号实际以官方通告为准services: mysql: image: mysql:8.0.39 container_name: app-mysql volumes: - mysql_data:/var/lib/mysql ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: 换成强口令然后拉取镜像并重建容器docker compose pull mysql docker compose up -d注意容器环境修复必须基于新镜像重建不要进容器里打补丁否则重启后一切归零。数据卷保持不变数据就还在。重建完成后不要急着走人先验证三件事进程是否正常启动、数据能否正常读取、业务侧有没有报错。我习惯用下面几个命令快速检查docker ps | grep mysql docker logs --tail 100 mysql_container docker exec mysql_container mysqladmin ping -u root -p如果验证发现新镜像有兼容性问题回滚也很简单。把 docker-compose.yml 里的 tag 改回旧版本再跑一次 docker compose up -d。所以升级前把旧镜像 tag 记住别覆盖掉。整个处理过程中所谓操作手册核心就是把每一台机器的容器清单、镜像是谁、数据卷在哪、怎么启停、怎么回滚都提前写成文档。这样到了升级那天你只需要按文档执行。2.5 修复后的安全检查与复盘修复完不代表结束。那次之后我们做了两件事第一用 trivy 把新镜像重新扫了一遍确认没有继承旧镜像里的已知漏洞。顺便把之前所有依赖这个组件的容器全部排查了一遍防止有漏网之鱼还在跑旧版本。第二做了一次完整的复盘把整个事件的因果链拉出来。结论很扎心漏洞没有被及时发现是因为我们根本没有定期做镜像扫描权限混乱是因为部署时为了省事统一用 root 跑容器。这两个问题后来都列成了整改项慢慢补上了。复盘不需要写成几百页的报告我用一个简单的四个问题清单就够漏洞是怎么进来的为什么没有被提前发现处理流程里哪一步耗时最长下次怎么避免同样的事第4个问题往往能引出有价值的改进命令统一封装、镜像扫描接入 CI、容器命名规范、数据卷备份自动化。每一条都落在具体动作上才有意义。3. Docker 权限问题排查与解决3.1 最让人头疼的几种权限报错权限问题在 Docker 运维里出现频率极高而且通常是在线上环境才暴露。我整理了实际遇到最多的三类第一类挂载目录权限不足。容器把宿主机目录映射进容器后容器内进程对目录没有写权限典型报错就是 Permission denied。这类问题常见于 MySQL、Redis、GitLab 这些需要持久化数据的服务。第二类Docker daemon 连接权限不足。你执行 docker ps系统直接回一句 Got permission denied while trying to connect to the Docker daemon socket连 docker 命令都用不了。第三类容器内进程以 root 运行导致宿主机文件属主被改得乱七八糟。很多开源镜像默认用 root 启动一旦挂载目录容器里写出来的文件在宿主机上都是 root 所有普通用户想删删不掉、想改改不了极易引发后续权限混乱。3.2 docker.sock 权限给用户加 docker 组等于授了半个 root先看最常见的用户不在 docker 组里docker 命令无法连接 daemon。常规解法很简单。把用户加入 docker 组sudo usermod -aG docker $USER重新登录终端后一般就能正常执行 docker 命令了。如果还没生效可以用 newgrp docker 切换组身份。但这个操作我强烈建议谨慎。把用户加入 docker 组基本等于给了该用户宿主机 root 权限因为 docker 的能力太强了挂载宿主机的 / 目录进容器、以特权模式运行容器、修改宿主机的文件系统通通做得到。注意docker 组权限约等于宿主机 root 权限给用户加 docker 组要当作授权 root 一样对待。生产环境慎用。所以生产环境我会优先考虑两种替代方案保留 sudo 白名单只允许指定用户执行有限的管理命令而不是放开 docker 组。使用 rootless Docker让 docker daemon 以非 root 用户运行从机制上隔离权限。开发环境图省事用 docker 组问题不大但生产环境的每一条权限都要先想清楚能不能被滥用。3.3 挂载目录 UID/GID 不匹配挂载目录权限问题核心是 UID/GID 不匹配。容器内的用户和宿主机上的用户使用的是同一个内核的用户 ID 体系容器里 UID 1000 的人在宿主机看来和 UID 1000 的本地用户是同一个身份。以 MySQL 为例。官方 MySQL 镜像里 mysql 用户的 UID 是 999。如果你在宿主机上把数据目录 chown 给了自己的用户通常 UID 1000MySQL 容器内以 mysql 用户写数据就会报 Permission denied。正确的做法是让目录属主匹配容器内运行用户docker exec mysql_container id mysql # uid999(mysql) gid999(mysql) sudo chown -R 999:999 /data/mysql用容器内用户实际的 uid 去改宿主机目录属主。不要图省事直接 chmod 777那会让整个数据目录完全裸露后续任何进程都能读写安全隐患很大。还有一种更规范的做法是在 docker compose 里显式指定 user让容器用宿主机已有的 UID 运行services: app: image: example/app:latest user: 1000:1000 volumes: - ./data:/app/data这样宿主机目录和容器内进程用的是同一个 UID天然不会冲突。但要注意很多镜像默认的用户和脚本逻辑是写给 root 的你改成普通用户之后脚本可能因为权限不足而失败这类问题后面专门说。3.4 容器内以非 root 运行开源软件容器里不用 root 跑这件事说的人多做的人少。原因无非是麻烦镜像脚本没写对、挂载目录权限要调整、某些端口绑定需要特权。但既然我们在讨论安全漏洞和权限问题这个习惯就得改。在 docker run 里指定用户docker run -d --user 1000:1000 example/app:latestdocker compose 里配置更丰富一些可以同时限制运行用户、只读文件系统和内核能力services: app: image: example/app:latest user: 10001:10001 read_only: true cap_drop: - ALL security_opt: - no-new-privileges:true这里每一项都是含义明确的user 指定运行用户read_only 让容器根文件系统变成只读cap_drop 去掉 Linux 内核能力no-new-privileges 防止进程通过 setuid 提升权限。我见过很多团队不敢做这些限制怕服务起不来。我的建议是从开发环境开始试一条一条加限制。先把 read_only 加上跑不起来就看日志把需要写的路径用 tmpfs 或 volume 挂载出来。这样逐步收紧比直接全限制再反复踩坑要高效。3.5 Docker Desktop 与 Windows 环境的权限坑Windows 上玩 Docker问题集中在 Docker Desktop 本身。搜热词都搜烂了Docker Desktop 启动失败、virtualization support not detected、连接 Docker API 失败。virtualization support not detected 基本就是虚拟化没开。排查顺序一般是这样打开任务管理器性能标签页看 CPU 的虚拟化是否是已启用。如果显示禁用进 BIOS 开启 Intel VT-x 或 AMD-V。确保 Windows 功能里勾选了虚拟机平台和适用于 Linux 的 Windows 子系统。安装 WSL2 内核更新包并在终端执行 wsl --set-default-version 2。重启 Docker Desktop在设置里确认用的是 WSL 2 backend。还有一条常见的报错failed to connect to the docker api at npipe:////./pipe/docker_engine; check... 这个问题的意思是 docker CLI 找不到 Docker daemon多半是 Docker Desktop 没启动或者启动过程中崩了。先看右下角 Docker 图标是否正常运行启动失败就把 Docker Desktop 整个退出重来或者把 %USERPROFILE%.docker 下缓存清一轮。Windows 下还有个容易忽略的权限问题项目代码放在 WSL2 里Docker Desktop 挂载 Windows 盘符路径性能差且权限别扭。我踩过的坑是 Windows 目录下的文件带 ACL 权限容器内进程偶尔读取会失败把项目迁到 WSL2 文件系统后问题就消失了。如果你长期在 Windows 上用 Docker 做开发建议早一点把代码仓库整个挪进 WSL2。4. 构建更抗打的镜像供应链与运行安全4.1 镜像从哪来可信来源与固定摘要这次应急处理让我最深刻的体会是镜像供应链的信任问题平时不显山露水出了问题才致命。开源软件镜像谁都能拉但拉下来的镜像到底是谁构建的、里面有没有夹带私货没人知道。我给自己定了几条硬规矩只从官方仓库或公司内部可信仓库拉取镜像第三方个人仓库的镜像必须经过安全评审。不认 tag只认 digest。tag 是可变的digest 是镜像内容的哈希把镜像固定到 digest 才能保证今天拉的和昨天验证过的是同一个。固定 digest 的操作很简单docker pull mysql:8.0.39sha256:xxxxxxxxxxxxdocker compose 里也可以直接用 digest 替代或补充 tagservices: mysql: image: mysql:8.0.39sha256:xxxxxxxxxxxx企业内网有条件的话建议搭一套自建的镜像仓库统一从可信源拉取镜像再分发到各个节点。这样既方便做安全扫描也方便在漏洞通告出来后批量追溯有问题的镜像。4.2 镜像拉取慢的解决办法Docker 镜像拉取慢是日常吐槽点。最直接的解决办法是配置镜像加速器。Docker daemon 支持在 /etc/docker/daemon.json 中配置 registry-mirrors。原理就是让 Docker 优先从你配置的镜像站点拉取{ registry-mirrors: [https://你的可信镜像加速地址] }配置完后重启 docker 服务sudo systemctl restart docker顺便说一句Docker 引擎本身的安装也可以走高校镜像站比如清华大学的开源软件镜像站就提供了 docker-ce 的 apt/yum 源安装速度比默认源快不少。这里不展开每个仓库的配置细节镜像站的帮助页都写得挺清楚照着配就行。另一个长期方案是自建镜像仓库做内网同步。企业里网络环境可控的话用 registry 或者 Harbor 把常用镜像同步到内网各节点从内网拉取速度稳定还能统一管理版本。成本不高但能在关键时刻帮你省下大量时间。4.3 用漏洞扫描工具提早发现风险应急处理最理想的局面是漏洞还没造成影响就被发现。镜像漏洞扫描就是这层防护。工具我推荐 trivy开源、免费、更新快一条命令就能扫出镜像里的已知 CVE。安装 trivy 之后扫描镜像trivy image mysql:8.0.28只看高危和严重级别trivy image --severity HIGH,CRITICAL mysql:8.0.28扫描结果会列出漏洞编号、依赖组件、修复版本。拿到结果之后的动作才是关键把高危漏洞镜像列入整改队列能升级就升级不能升级的至少要在资产清单里备案并在网络层面做额外限制。trivy 还能扫本地文件系统和运行中的容器trivy fs . trivy container container_name建议把 trivy 集成到 CI 流程每次构建镜像都自动扫描给团队设一条红线新镜像不允许带 HIGH 级别漏洞上线。这一步一旦跑起来能挡掉大量后面的应急事故。4.4 开源软件容器化部署的最小权限清单开源软件部署到容器里很多默认配置是怎么方便怎么来我们要反过来想怎么最小化。我整理了一个可以直接抄的权限清单运行用户优先使用镜像提供的非 root 用户或显式指定普通 user。文件系统能只读就只读目录读写权限尽量收窄。内核能力去掉 cap_net_admin、cap_sys_admin 等危险能力能 cap_drop 就 cap_drop。端口暴露只暴露业务必需的端口管理端口和调试端口一律不映射到宿主机。环境变量数据库口令、密钥一律通过 secrets 或环境变量注入不要写进 Dockerfile。配合例子里那个 docker compose 文件足够应对大部分开源软件的权限加固需求。这套配置最开始可能让服务起不来别灰心从日志里把缺失的能力找出来逐条加直到业务正常。这个逐步收紧的过程就是一次很好的安全演练。5. 常见问题与排查技巧实录5.1 Docker Desktop 启动失败virtualisation support not detected这个问题在 Windows 环境太常见了。Docker Desktop 依赖虚拟化虚拟化没开启就直接罢工。我建议按这个顺序排查任务管理器 - 性能 - CPU看虚拟化状态。已禁用就重启进 BIOS开启 Intel VT-x 或 AMD-V主板不同菜单名不一样搜一下对应主板型号就行。如果虚拟化已启用但还是报错检查 Windows 功能控制面板 - 程序 - 启用或关闭 Windows 功能勾选虚拟机平台和适用于 Linux 的 Windows 子系统。打开终端执行 wsl --status 看看 WSL 版本。如果是 WSL1docker 可能不认需要升级到 WSL2。如果是老版本 Windows可能还需要单独安装 WSL2 内核更新包安装完在终端执行 wsl --set-default-version 2。以上都做完了重启电脑再启动 Docker Desktop。这一步排查走下来绝大多数问题都能解决。剩下的小概率情况是杀毒软件拦截虚拟化服务或者 Docker Desktop 安装包本身损坏卸载重装基本能搞定。5.2 failed to connect to the docker api at npipeWindows 上执行 docker ps 报 failed to connect to the docker api at npipe:////./pipe/docker_engine本质是 docker CLI 找不到 Docker daemon。最直接的原因是 Docker Desktop 没有启动或者启动过程中崩了。我处理这个报错的顺序是看系统托盘区有没有 Docker 图标没有就直接在开始菜单启动 Docker Desktop。如果图标在但显示红点或提示 Engine stopped右键选 Restart等它起来。如果反复启动失败看 Docker Desktop 的日志路径通常在 %LOCALAPPDATA%\Docker\log.txt。清理 Docker 的缓存目录后重试有时候是缓存损坏导致 daemon 起不来。开发环境里这个报错大多不是配置问题而是部署环境不稳定。重装之前先把 Windows 更新和 WSL2 内核更新完能省很多事。5.3 Linux 下 docker 服务启动失败Linux 服务器上 docker 服务启动失败常见场景是 systemctl start docker 后没有任何提示但 docker ps 还是报错。第一步永远是看日志sudo journalctl -u docker --since 10 min agodocker daemon 的日志里大部分时候已经把原因写得很清楚。我遇到过的典型几类iptables 相关错误通常是节点之前配过其他防火墙软件把 iptables 链搞坏了。处理办法是清空 iptables 后重试但要先确认节点上没有其他安全要求。cgroup 驱动不匹配常见于 kubelet 和 docker 配置的 cgroup driver 不一致改成 systemd 之后重启即可。磁盘空间不足镜像拉取失败甚至 daemon 启动失败清干净 /var/lib/docker 下的无用镜像和日志。排查这类问题的通用思路就是先日志、后配置、再环境。别凭感觉改配置日志会告诉你真实原因。5.4 权限问题速查表报错或现象可能原因推荐处理Got permission denied while trying to connect to the Docker daemon socket当前用户不在 docker 组usermod -aG docker $USER重新登录容器内写挂载目录 Permission denied容器用户 UID 与目录属主不匹配将目录属主改为容器内用户 UID或通过 user 指定 UID 运行数据目录变 root 所有普通用户清理不掉容器以 root 运行写入文件属主为 root改用非 root 用户运行容器并统一属主Docker Desktop 报 virtualisation support not detectedBIOS 虚拟化关闭、WSL2 未启用开启虚拟化、启用 Windows 功能、安装 WSL2docker CLI 报 npipe 连接失败Docker daemon 未启动启动 Docker Desktop排查守护进程日志容器内进程无法绑定低端口非 root 用户无特权绑定 80/443使用端口映射或授予绑定低端口的唯一 capability速查表只能帮你快速定位真正解决还是要回到具体环境去验证。我最想强调的一点是权限问题别靠蒙先看报错再看日志最后动手改。5.5 我的复盘体会应急处理能力要靠平时练这次应急处理之后我给团队立的规矩很简单每一套用 Docker 部署的开源软件都必须有一套自己的应急操作手册内容包括容器清单、数据卷清单、备份方案、回滚命令。平时每季度做一次故障演练模拟某个容器被打挂了数据目录丢了镜像仓库不可用这类场景。真到了漏洞通报那天你会发现最值钱的不是某一条命令而是你已经知道该先做什么、后做什么谁会负责哪块。团队里临时翻命令的场面我见过太多了慌乱中的人是没有效率可言的。另外一个小习惯也值得分享容器命名、镜像 tag、数据卷命名都要带着项目名和环境标识。比如 mysql 容器叫 project-mysql-prod数据卷叫 project-mysql-data-prod。这样应急盘点的时候一条命令就能按项目过滤出全部相关资源不用猜这个容器是干嘛的。那次应急处理结束后我把操作手册打印了一份压在工位上同事还笑我说都什么年代了还打印文档。后来有一天临时停电内网文档系统起不来那张纸还真救了一次急。说这些不是让大家也去打印而是想说应急方案这种东西做得再漂亮不如在真出事的时候能让人不慌。希望这篇整理能让你在下一次安全通告面前少一点手忙脚乱多一点按部就班的底气。最后再分享一个小技巧每周抽十分钟跑一遍 docker ps -a看看有没有异常容器再跑一遍 trivy 扫一下最近拉的新镜像。十分钟的投入换来的是随时都能说清楚的资产清单和安全底数这笔账怎么算都值。