技术文档中心

从应用负载推算 CPU、内存、存储与带宽，留出增长空间。

操作步骤与验证

1. 记录峰值而非平均值：统计高峰并发、请求耗时、CPU 使用率和内存工作集。数据库、缓存及运行时应分别估算，避免只按网站数量选套餐。
2. 检查磁盘与传输预算：把数据库、媒体、日志、快照与增长量纳入容量。10Mbps 的理论上限为 1.25MB/s，实际吞吐还受协议开销及路径影响。
3. 用接近真实流量的请求做压测，观察 p95 延迟、交换分区和磁盘等待。先处理慢查询与缓存问题，再决定扩容 CPU、内存或带宽。
4. 为预算建立一张资源表：分别记录当前峰值、预计增长、可接受延迟和扩容条件。例如图片网站优先核对存储增长与出站流量，交易数据库则更关注内存命中率和同步写入延迟；相同访问量不代表相同配置。

free -h
df -h
vmstat 1 5

用相同端点、运营商与时段比较 CN2 GIA、CMI、PCCW 或国际 BGP。

操作步骤与验证

1. 向支持获取所选产品的测试地址，记录用户所在地、运营商、时间和测试协议。公共地区参考 IP 不能证明实际实例使用同一线路。
2. 从用户网络采集去程 MTR，再从服务器或对应 Looking Glass 采集回程。AS4809 与 59.43 跳点可作线索，但单个跳点不能证明完整双向 CN2 GIA。
3. 比较高峰与非高峰的端到端丢包、抖动和实际 HTTPS 请求耗时。中间路由器可能限制 ICMP 响应；只有中间跳点丢包而最终目标正常时，不应直接判定业务丢包。
4. 把测试结果按运营商、时间和方向保存，并同时记录应用实际请求耗时。路由会随互联策略与故障切换改变，购买前的一次 traceroute 不能代替持续监控，也不能据此推断所有用户的体验。

mtr --report --report-cycles 20 YOUR_TEST_IP

从域名解析到证书续期，完成可验证的网站部署。

操作步骤与验证

1. 将域名 A/AAAA 指向实际地址；仅在服务器配置了可用 IPv6 时添加 AAAA。安装受支持的 Web 服务器、PHP 与数据库版本，并创建独立数据库账户。
2. 从 WordPress 官方下载程序，设置站点地址与管理账户。Web 进程只需获得必要目录的写权限；数据库端口不应向公网开放。
3. 配置 ACME 客户端与 HTTPS，确认域名验证方式需要的端口或 DNS 权限，再测试自动续期。HTTPS 验证正常后启用 HTTP 重定向。
4. 检查登录、上传、邮件及结账等关键流程；建立数据库和上传目录的异机备份，执行一次恢复演练后再切换正式流量。
5. 上线后检查固定链接、媒体上传大小、计划任务和缓存规则。购物车、登录态及后台页面不应被当作匿名静态页面缓存；在开启 CDN 或页面缓存后，分别用登录和未登录状态完成一次业务流程。

curl -I https://YOUR_DOMAIN

核对实际交付配置、磁盘健康与管理权限。

操作步骤与验证

1. 对照订单核对 CPU 型号与数量、可用内存、磁盘类型和数量。区分物理核心与线程，区分原始磁盘容量与阵列可用容量。
2. 核对 RAID 级别、热备盘及控制器缓存保护。RAID 0 不提供冗余；RAID 1/10 与 RAID 5/6 的容量和故障容忍不同，RAID 不能替代备份。
3. 检查健康告警、阵列降级与重建状态；记录序列号和交付结果。压力测试应在业务上线前执行，磁盘写入或阵列重建操作需先确认数据保护。
4. 建立验收记录，区分已确认项目与尚未测试项目。带宽端口速率不等于任意目的地都可达到该吞吐；硬盘型号也不能单独证明阵列性能。用实际业务负载验证，并记录测试时是否存在备份或其他争用。

lscpu
free -h
lsblk -o NAME,SIZE,TYPE,MODEL

验证远程控制台、启动介质与故障恢复入口。

操作步骤与验证

1. 确认管理地址、账号交付方式及允许访问的网络。使用独立管理网络或 VPN，避免把 IPMI/iDRAC 暴露到所有公网来源；修改默认凭据。
2. 在维护窗口验证控制台画面、键盘和虚拟介质。重启、关机与修改启动顺序会中断业务，应先排空流量并确认备份。
3. 保存系统盘恢复步骤和联系人。网络失联时先检查控制台中的接口、路由与防火墙；不要在不了解磁盘状态时直接重装系统。
4. 恢复前先识别目标物理机和业务负责人，区分正常关机、强制断电与系统重装的影响。控制台可访问不代表网络故障已解决；完成恢复后验证业务端口、磁盘挂载和数据库状态，并关闭临时挂载的安装介质。

区分桥接与路由子网，再配置虚拟机网络。

操作步骤与验证

1. 保存供应商分配的网关、掩码、可用地址与 MAC 限制。桥接、路由子网及单 IP NAT 的设置不同，不能直接套用另一机房的示例。
2. 保留带外控制台，备份现有网络配置。先用一台测试虚拟机验证网桥、出站 DNS、回程路由及重启后的连通性，再批量创建租户。
3. 管理面与租户网络分离，按租户配置防火墙、防 IP 冒用与访问权限。只有供应商分配的 IPv4 可以使用，独立 IP 不等于业务隔离。
4. 将虚拟机备份放到独立故障域，记录恢复顺序；恢复测试应同时验证磁盘、网络、应用和权限。
5. 正式交付前，向服务商确认额外 MAC 地址和嵌套虚拟化是否受限。保存已验证的网络配置及回滚步骤，避免后续新增租户时套用其他机房的配置。

ip -br address
ip route
bridge link

同时计算内存、存储 IOPS、CPU 与网络，避免只按虚拟机数量估算。

操作步骤与验证

1. 为宿主系统、文件系统缓存和管理服务预留内存。合计各虚拟机的峰值工作集，避免将所有物理内存直接出售给租户。
2. 按业务衡量 CPU 超分比例，并观察宿主负载、guest steal time 和调度延迟。低负载 Web 与数据库、实时游戏负载不应使用同一超分假设。
3. 把随机 IOPS、同步写入和备份窗口纳入磁盘预算。为容量耗尽、薄置备增长与网卡拥塞设置告警，升级前完成迁移或回滚计划。
4. 容量表应包含故障维护时的迁移余量，而不仅是正常运行时的利用率。若计划在宿主机维护期间迁走虚拟机，需要提前确认目标主机的 CPU 兼容、内存、存储访问及网络一致性，单机备份不能替代可用的迁移容量。

模型权重只是起点，还需计算 KV Cache、运行时与训练状态。

操作步骤与验证

1. 先确认推理、LoRA 或全量训练任务。7B 参数在 FP16 下仅权重约需 14GB（十进制），实际加载还需要框架与运行时开销，不能据此断言能在 16GB 显卡稳定运行。
2. 推理需为上下文长度、并发与 KV Cache 留空间；训练还需梯度、优化器状态与激活内存。量化可减少权重占用，但要验证模型质量及算子兼容。
3. 多卡显存通常不会自动合并成一个大显存池。先确认模型并行方案、PCIe/NVLink 拓扑及框架支持，再用目标 batch size 验证峰值显存和吞吐。
4. 为每次试跑保存输入长度、并发、精度和峰值显存。若使用量化权重，模型加载过程仍可能产生临时内存峰值；对训练任务还应验证保存检查点和恢复训练的过程，避免长时间运行后才发现空间不足。

nvidia-smi
nvidia-smi topo -m

先验证驱动，再安装匹配的运行时并测试 GPU 运算。

操作步骤与验证

1. 运行 nvidia-smi 检查 GPU、驱动版本与占用进程。其显示的 CUDA 版本是驱动可支持的版本信息，不一定代表已经安装对应 CUDA Toolkit。
2. 根据 PyTorch 官方安装说明选择匹配驱动的构建，在独立虚拟环境中安装。容器还需 NVIDIA Container Toolkit 与正确设备授权，不要混用不明来源驱动。
3. 确认 torch.cuda.is_available()、设备名称与一个小型张量运算成功后，再安装模型依赖。记录驱动、PyTorch、CUDA 运行时与模型版本，方便复现和回滚。
4. GPU 可被框架识别后，还应执行实际模型的小批量推理或训练并保存输出。出现算子或动态库错误时，先检查虚拟环境与依赖版本，避免在同一环境中反复覆盖安装；可用环境应导出依赖清单并固定容器镜像。

python -c "import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'No CUDA device')"

以可恢复的数据和明确的恢复时间为目标，而不是只看备份成功提示。

操作步骤与验证

1. 定义可接受的数据丢失时间范围（RPO）和服务恢复时间（RTO）。数据库使用应用一致性备份或受支持的快照流程，不要直接复制正在写入的数据目录。
2. 将加密备份存到独立设备或区域，设置保留周期与最小权限。记录密钥保存位置，并检查备份失败、存储空间与过期告警。
3. 在隔离环境恢复最近一次备份，验证记录数量、文件、权限与应用流程；记录实际恢复耗时。上线前确认监控、证书续期、联系人和回滚步骤。
4. 将恢复演练结果与目标比较：备份间隔是否满足 RPO，下载、解密、导入和业务验证的总时间是否满足 RTO。恢复验证应覆盖数据库与上传文件的对应关系；只检查压缩包能解压，不能证明业务可以恢复。

建立可验证的远程管理入口，分清超时、拒绝连接与认证失败。

操作步骤与验证

1. 在自己的电脑生成带口令的 SSH 密钥，将公钥添加到服务器账户的 authorized_keys。私钥保留在本机，不要上传到工单、聊天或服务器公共目录；不同管理员使用各自的密钥。
2. 首次连接前，通过控制台或可信交付渠道核对主机指纹。如果重装后指纹变化，先确认重装记录；不要为了消除提示直接关闭主机验证。
3. 保持当前管理会话，在第二个终端测试新账户和密钥，并确认所需 sudo 权限可用。只有验证成功且控制台恢复入口可用后，再按业务要求限制密码登录。
4. 连接超时先检查实例状态、目标 IP、端口、安全组和本机出口；立即提示 Connection refused 通常需要检查 SSH 服务是否监听正确端口。认证失败则核对用户名、公钥、文件权限和服务日志。
5. 修改 SSH 配置后先使用 sshd -t 验证语法，再按系统服务管理方式重载。保留旧会话，重新建立连接测试；若失败，通过控制台恢复配置，避免反复重启扩大问题。

ssh -vv YOUR_USER@YOUR_SERVER_IP

按 DNS、连接、证书、应用四层定位网站无法访问的原因。

操作步骤与验证

1. 先记录完整域名、故障时间、访问网络和浏览器错误。比较根域名与 www 子域名，它们可能使用不同记录；不要只凭控制面板显示的记录判断解析已生效。
2. 分别查询 A、AAAA 和 CNAME。若 IPv4 正常而部分用户失败，重点核对 AAAA 对应的 IPv6 服务；删除或修改记录后仍要等待递归缓存按 TTL 过期。
3. 确认域名指向预期源站或 CDN。CDN 开启代理时，DNS 返回边缘地址属于正常现象；源站检查应使用保留正确 Host 与 SNI 的方式，不要直接用 IP 判断证书是否正确。
4. HTTPS 证书须覆盖实际访问域名，并检查有效期、系统时间和完整中间证书链。HTTP 到 HTTPS 的重定向应与应用、反向代理配置一致，避免两端互相跳转。
5. 出现 502/504 时检查上游服务监听、反向代理日志和应用耗时；出现 403 时检查访问控制与站点权限。修复后从不同网络验证首页、登录与静态资源，并检查自动续期任务。

dig YOUR_DOMAIN A
dig YOUR_DOMAIN AAAA
curl -I https://YOUR_DOMAIN

将镜像、持久数据、网络入口与回滚步骤分开管理。

操作步骤与验证

1. 确认操作系统与 Docker 支持范围，使用官方软件源安装。记录 Compose 版本和镜像架构，ARM 与 x86 镜像不能默认互换；生产部署固定版本或摘要，避免 latest 标签带来意外升级。
2. 将数据库和上传文件放入明确的持久卷，记录宿主路径、所有者与备份方式。容器可重建不代表数据可重建，不能把唯一数据留在容器可写层。
3. 只发布业务需要的端口，数据库使用内部网络。Docker 发布端口可能影响既有防火墙规则的实际效果，应从外部网络验证可访问范围，不要仅查看防火墙界面。
4. 配置健康检查、资源限制和日志轮转。区分容器正在运行与应用已经就绪；上线前验证数据库依赖、迁移结果、文件权限以及重启后的数据是否保留。
5. 保存上一版镜像与配置，在测试环境演练回滚。数据库架构迁移可能不向后兼容，旧镜像并不保证可以直接使用新数据；升级前备份，并为不可逆迁移准备恢复方案。

docker version
docker compose ps
docker stats --no-stream

区分 CPU、内存、磁盘、inode 与应用瓶颈，避免盲目扩容。

操作步骤与验证

1. 在故障发生时记录请求量、延迟、系统负载和近期发布。load average 不是 CPU 使用率，也包含部分等待任务；应结合 CPU 核数、运行队列和 I/O 等待判断。
2. 使用 free 的 available 观察可用内存，不要把 Linux 文件缓存全部当成泄漏。持续 swap 活动、OOM 日志和应用堆增长比单次内存占用更能说明问题。
3. 同时检查 df -h 与 df -i：空间尚有余量但 inode 用尽也会写入失败。若 df 与目录统计差距明显，检查已删除但仍被进程打开的文件、挂载点及快照占用。
4. 磁盘等待较高时关联数据库慢查询、备份任务和随机写入。先在低影响时段采样，避免直接在生产盘执行高强度写入压测；吞吐高不一定代表随机 IOPS 足够。
5. 按证据处理日志轮转、慢查询或容量问题，每次只改变一个关键变量并对比同等负载下的延迟。不要直接删除数据库文件，也不要用清空缓存掩盖真实内存需求。

uptime
free -h
df -h
df -i
vmstat 1 5

在可控维护窗口完成数据同步，避免新旧站点同时写入。

操作步骤与验证

1. 列出域名、数据库、上传文件、定时任务、邮件、第三方回调和白名单。记录旧服务器的系统与运行时版本，先确认新环境支持应用依赖，避免迁移时同时进行多项大版本升级。
2. 提前降低 DNS TTL，并等待原 TTL 周期经过后再安排切换。降低 TTL 不会立即清除已缓存的旧记录；确认 CDN、代理和应用缓存也纳入计划。
3. 在新环境恢复初始备份，通过测试域名或本机 hosts 验证页面与后台。阻止测试环境执行正式支付、邮件、队列消费者和重复定时任务，防止产生真实副作用。
4. 维护窗口内暂停写入，完成数据库一致性备份与文件最终增量同步。核对关键数据、权限和证书后切换入口；只改变 DNS 而不处理写入，可能产生订单或文件分叉。
5. 保留旧环境与备份，观察访问日志、错误率和业务流程。若切换后新站已经写入，回滚前必须处理新增数据，不能直接把 DNS 指回旧站；达到验收条件后再退役旧资源。

用可复现的小负载定位显存峰值、并发与数据读取问题。

操作步骤与验证

1. 记录模型、精度、上下文长度、batch size、并发数和完整错误。先以单请求、较短上下文复现，再逐步增加一个变量；不要只用模型文件大小估计运行显存。
2. 使用 nvidia-smi 核对同卡其他进程和显存占用，结合框架的 allocated、reserved 与峰值统计判断。框架缓存可能保留显存，但释放缓存不能让本来放不下的活跃张量自动变小。
3. 推理可先降低并发、batch 或上下文上限，再评估量化与 KV Cache 策略；训练可评估梯度累积和激活检查点。每次调整都应复核输出质量、吞吐及延迟，避免只追求不报错。
4. GPU 利用率低时检查 CPU 预处理、磁盘读取、数据加载与主机到设备传输。首次请求可能包含模型加载或编译，应区分冷启动、预热后首 token 延迟和持续生成速度。
5. 用代表性输入持续测试并观察 p95 延迟、峰值显存和错误率。多卡场景还需验证任务是否真正分布到各卡，检查拓扑和通信等待；保存配置与软件版本作为稳定基线。

nvidia-smi
nvidia-smi topo -m

操作步骤与验证

1. 按用户所在地、运营商、数据库和第三方接口的位置画出访问路径。网页、API 与数据库跨区往返可能比用户到首页的延迟更影响体验。
2. 在候选地区使用同类配置、相同请求和相近时段测试，记录 p50/p95 延迟及失败率；同时确认数据存储地域要求、备份位置和实际可购库存。
3. 先将非关键服务或部分流量切到目标地区，观察业务指标再扩大。主数据库跨区迁移应单独规划一致性与回滚，不能仅修改网页的 DNS。

操作步骤与验证

1. 区分端口速率、承诺带宽和月流量额度，核对入站与出站是否分别计费。Mbps 为比特速率，除以 8 才是理论 MB/s，尚未扣除协议开销。
2. 用平均响应大小乘以请求量估算流量，并单列视频、下载、备份和爬虫。100Mbps 持续跑满一天理论约传输 1.08TB（十进制），实际业务不应假设持续满速。
3. 为日流量和月累计设置告警，确认超额后的限速、停机或额外计费规则。下载慢时同时检查单连接限制、源站磁盘、跨境路由和 CDN 缓存命中。

操作步骤与验证

1. 先查应用所需的 PHP、Python、数据库、内核和 CPU 架构，再选系统。优先使用仍在安全维护期内的发行版，避免为了旧教程安装已结束支持的版本。
2. 记录软件源、包管理器、防火墙和网络配置方式；不同发行版的服务名称与路径可能不同。先在测试实例验证启动、依赖安装、监控和备份代理。
3. 主版本升级前确认备份可恢复并安排维护窗口。系统重装通常会影响系统盘数据，须先确认保留范围；不要把重装按钮当作普通更新。

操作步骤与验证

1. 先确认应用在预期本机地址与端口监听，再配置代理。应用无需直接暴露公网时绑定回环或私网地址，TLS 在代理终止后仍需正确传递协议与主机信息。
2. 修改配置后运行 nginx -t，通过后再重载。502 先查连接拒绝、Unix socket 权限和上游崩溃；504 则关联应用执行时间，不应只无限提高超时。
3. 测试上传、重定向、客户端 IP 与 WebSocket 等实际功能。只信任来自已知代理的转发头，避免应用把任意客户端传入的 IP 当成可信身份。

操作步骤与验证

1. 创建业务专用数据库账户并限制来源地址，不让应用使用管理员账户。确认监听范围与防火墙，只在确有需要时开放远程连接，并配置传输保护。
2. 将请求延迟与慢查询记录关联，再用 EXPLAIN 检查访问路径、索引和扫描行数。不要看到慢查询就直接加索引；索引也增加写入和存储成本。
3. 修改连接数、缓存或查询前保存基线，在相同负载下复测。验证一致性备份和恢复，监控连接耗尽、磁盘空间及复制延迟，而不仅是数据库进程存活。

操作步骤与验证

1. 明确 Redis 存储的是可重建缓存、会话还是关键队列，三类数据不能采用完全相同的持久化与淘汰策略。限制网络访问，按版本支持设置认证与权限。
2. 设置内存上限时预留持久化、复制缓冲和操作系统开销。根据键是否设置 TTL 选择淘汰策略，确认无可淘汰键时应用如何处理写入失败。
3. 观察命中率、淘汰量、慢命令和大键，而不是只提高内存。故障演练应验证缓存清空后的数据库负载，以及需要持久化的数据能否恢复。

操作步骤与验证

1. 先在源站完成域名、证书与业务验证，再开启代理。明确 CDN 到源站使用的协议和证书校验方式，避免为了消除错误而长期关闭源站身份验证。
2. 分别设置静态资源、HTML、登录和 API 的缓存规则。带 Cookie、鉴权头或个性化内容的响应需明确处理，防止将用户私有页面缓存给其他用户。
3. 比较边缘和源站日志、缓存命中及错误码。若按 CDN 地址限制源站访问，维护官方 IP 列表，并保留受控管理入口与更新失败时的恢复办法。

操作步骤与验证

1. 先确认套餐分配的 IPv6 地址、前缀长度和网关，不能根据 IPv4 网关自行推算。配置前保存现有网络设置，并确认远程控制台可用。
2. 验证路由、DNS 和应用监听。仅系统有 IPv6 不代表 Web 服务监听 IPv6；检查防火墙的 IPv6 规则，并保留 IPv6 正常运行所需的 ICMPv6 流量。
3. 从具备 IPv6 的外部网络访问目标域名，确认 HTTPS 与关键路径正常后才发布 AAAA。双栈故障时分别测试 IPv4 和 IPv6，避免随机成功掩盖一侧故障。

操作步骤与验证

1. 明确任务以系统时区还是业务时区运行，并考虑夏令时。使用完整命令路径和工作目录，定时环境中的 PATH 与交互终端可能不同。
2. 为长任务设置互斥或租约，避免上一次未结束又启动下一次；多台服务器部署时确认只有预期节点执行，任务逻辑应能安全重试并避免重复扣费。
3. 记录开始、结束、退出码与处理数量，为超时和漏跑告警。验证服务重启、断网和失败重试场景，不要把日志文件存在误认为任务已经成功。

操作步骤与验证

1. 按磁盘数量、容量和业务读写模式选择阵列。相同容量磁盘下，RAID 1 为镜像，RAID 5 扣除一盘容量、RAID 6 扣除两盘容量；另需预留格式化与热备空间。
2. 确认控制器缓存保护、写入策略和掉电行为。RAID 10 的容错取决于故障是否落在同一镜像组，不能简单宣称任意两盘损坏都安全。
3. 规划重建期间的性能下降与再次故障风险，监控阵列降级和热备状态。业务备份仍需独立存储，删除、勒索和文件损坏会同时影响阵列成员。

操作步骤与验证

1. 记录磁盘型号、序列号、槽位和阵列成员关系，再读取 SMART 或 NVMe 健康信息。不同厂商原始值含义不同，应结合官方说明与趋势判断。
2. 关联介质错误、温度、寿命消耗和内核 I/O 错误。单个健康状态为通过不保证不会故障；持续增加的错误与业务延迟比一次静态截图更重要。
3. 更换前验证备份、正确槽位与阵列容错，并确认热插拔支持。更换后监控重建直至正常，再验证文件系统与业务，不要在重建期间随意拔第二块盘。

操作步骤与验证

1. 核对物理插槽、每插槽核心、线程数和 NUMA 节点。逻辑线程不等于完整物理核心，频率与缓存也影响单线程任务，不能只比较总线程数。
2. 使用业务负载观察 CPU 调度、内存带宽和跨节点访问。内存绑定或 CPU 亲和性可能改善局部性，也可能造成局部资源不足，应先测量再调整。
3. 保存默认配置与测试结果，在相同并发下比较吞吐和尾延迟。虚拟化宿主机还需核对 vNUMA 和虚拟 CPU 配置，避免把单台虚拟机分配跨越过多节点。

操作步骤与验证

1. 核对订单、系统识别信息与管理入口，记录网卡、磁盘、内存和序列号。确认维护联系人、故障工单渠道及约定的更换流程，避免故障时才寻找权限。
2. 在数据导入前安排适当的 CPU、内存、网络和磁盘测试，明确哪些测试会写入磁盘。观察温度、错误日志与降频，不把短时间跑分当作稳定性保证。
3. 最后验证重启后自动挂载、应用启动、监控和备份恢复。保存验收基线，后续性能下降时用相同工具与负载复测，以区分硬件变化和业务增长。

操作步骤与验证

1. 记录最后一次变更及启动报错，通过控制台判断是引导、文件系统还是网络问题。先核对目标磁盘与分区，救援环境中的设备名称可能与原系统不同。
2. 优先只读检查与复制关键数据；不在未确认备份时直接格式化或强制修复。加密卷需要合法密钥，RAID/LVM 还需正确识别成员与逻辑卷。
3. 按已定位原因修复配置或引导，退出救援前恢复正确启动顺序并卸载介质。重启后验证网络、挂载、数据库和定时任务，记录修复与回滚步骤。

操作步骤与验证

1. 区分存放 ISO、备份和虚拟磁盘的存储用途，确认目录、LVM-thin、ZFS 或共享存储支持的内容类型。看到总容量不代表每种内容都可直接写入。
2. 薄置备要同时监控物理池空间与元数据，虚拟磁盘标称容量之和可能超过实际容量。为快照、增长和迁移预留空间，避免池满导致多个租户同时停写。
3. 在测试虚拟机验证创建、快照、备份和恢复流程。共享存储可见不等于有高可用性，仍需验证网络冗余、权限及故障时的行为。

操作步骤与验证

1. 明确管理、存储和租户网络的边界，记录 VLAN ID、子网、网关及允许经过的端口。VLAN 只是二层分隔，跨网段访问仍需路由和防火墙策略。
2. 核对物理交换机、网桥与虚拟机网卡的 tagged/untagged 设置，不能只改一端。管理口调整前保留控制台，先用测试 VLAN 验证，避免切断宿主机访问。
3. 从不同租户分别测试允许与禁止的连接，检查 IPv6、DHCP 和伪造源地址是否绕过隔离。保存规则和测试矩阵，新增租户时按同一流程验收。

操作步骤与验证

1. 检查源端和目标端的 CPU 特性、虚拟化版本、存储名称及网桥映射。直通 GPU、USB 或本地设备可能限制在线迁移，需要单独规划停机流程。
2. 估算内存和磁盘传输量，确认目标容量与迁移带宽。如果虚拟机修改内存页的速度超过复制速度，在线迁移可能无法完成，不能保证所有负载都无中断迁移。
3. 先迁移低风险测试机，验证网络、时间、磁盘和应用，再安排正式批次。源端清理前确认目标稳定且备份可恢复，避免同时启动两个相同身份的实例。

操作步骤与验证

1. 快照通常依赖原存储或原磁盘链，主要用于短期回退；备份应能在独立故障域恢复。存储损坏时，同池快照可能与业务数据一起不可用。
2. 数据库快照需考虑应用一致性，可结合受支持的 guest agent、冻结或数据库备份流程。仅冻结磁盘写入不一定涵盖所有外部依赖与分布式事务。
3. 为快照设置过期时间并监控增长，定期在隔离环境从备份还原。回退快照前确认会丢失哪些新写入，以及外部服务是否需要同步回滚。

操作步骤与验证

1. 将管理界面和 SSH 与租户网络隔离，优先通过受控管理网络访问。不要将宿主机管理员凭据交给租户，使用独立账户、最小权限和多因素验证。
2. 限制 API token 的权限和期限，记录自动化工具使用范围；备份配置中的密钥也需受控保存。审查闲置账户、过期 token 和近期权限变更。
3. 更新前验证管理配置备份与控制台恢复，维护后测试租户隔离和审计日志。管理入口故障时保留独立恢复通道，避免依赖同一台已失联虚拟机。

操作步骤与验证

1. 先在宿主机确认驱动正常，再安装与容器引擎匹配的 NVIDIA Container Toolkit。容器内通常使用宿主驱动接口，不应把容器当作独立重装内核驱动的主机。
2. 使用固定版本的受信镜像测试设备可见性与小型运算，明确分配的 GPU。容器能运行 nvidia-smi 不代表模型依赖和所需 CUDA 算子全部兼容。
3. 限制数据卷与凭据暴露，设置内存、CPU 和日志策略。升级镜像后重复模型验证，并保留上一版本；GPU 使用权限不等于可以放开所有宿主设备。

操作步骤与验证

1. 记录模型许可、版本、精度和输入限制，确认权重来源与校验。先运行固定样本集保存输出，再验证服务接口，避免把模型下载完成等同于可用。
2. 为请求设置鉴权、输入大小、上下文上限、队列和超时。对外 API 需要限制并发与速率，取消的请求应能释放资源，避免无限排队耗尽显存。
3. 测量冷启动时间、首个 token 延迟、生成速度和 p95 请求延迟，并测试错误输入与过载情况。质量和性能达标后逐步切换流量，保留旧模型和配置用于回滚。

操作步骤与验证

1. 区分单请求 batch、动态批处理与同时连接数。增加 batch 可能提高吞吐但增加等待时间；交互式聊天与离线批处理应使用不同延迟目标。
2. 以真实输入长度分布测试，并记录显存峰值、排队时间、首 token 和完成时间。不要只用短输入或固定输出长度得到看似理想的吞吐。
3. 寻找满足 p95 目标的最大稳定吞吐，设置排队上限和过载响应。保留余量应对长请求及模型切换，量化或多卡策略变更后重新测量。

操作步骤与验证

1. 检查点除模型权重外，按框架要求保存优化器、学习率调度器、训练步数和随机状态。只保存推理权重通常无法无缝恢复训练轨迹。
2. 根据可接受重算时间设置保存间隔，估算单次体积、写入耗时和保留份数。采用框架支持的一致写入方式，避免中断时覆盖唯一可用检查点。
3. 在短训练中主动停止并恢复，核对步数、损失曲线与数据采样。将可用检查点复制到独立存储，分布式训练还需确认各分片齐全与版本一致。

操作步骤与验证

1. 明确基础模型、目标任务、许可与数据授权，分离训练集和验证集。清理重复和敏感样本，保留数据版本，避免只看训练损失判断模型变好。
2. LoRA 减少可训练参数但仍需加载基础模型与激活，显存随上下文、batch 和实现变化。先用少量数据试跑，记录峰值与每步时间，再估算总成本。
3. 保存 adapter、基础模型标识与完整配置，在独立验证集比较任务指标和退化情况。上线前测试 adapter 加载与回滚，不把微调产物误当独立完整模型。

操作步骤与验证

1. 检查 GPU 数量、PCIe 链路、NUMA 位置与 NVLink 支持，核对框架采用数据并行还是模型并行。多卡数量增加不代表显存自动合并或吞吐线性增长。
2. 先建立单卡基线，再逐步测试两卡与目标规模，比较计算、数据加载和同步时间。跨节点训练还需测量网络与集合通信，不只看公网端口标称速率。
3. 核对每个分布式进程的编号（rank）、GPU 分配、日志和错误处理，避免多个进程意外占用同一卡。保存可复现的启动配置，通信异常时先检查网络与版本。

操作步骤与验证

1. 列出每个服务的来源、目标、协议和端口，区分公网、私网与管理入口。安全组、主机防火墙和应用权限是不同层，任意一层阻断都可能导致连接失败。
2. 修改远程访问规则前保留会话与控制台恢复，先添加明确允许规则再收紧范围。检查 IPv4 和 IPv6，数据库与管理面仅允许必要来源。
3. 从允许与禁止来源分别验证，并确认重启后规则仍生效。记录变更人、用途与过期时间，清理临时开放规则，避免逐次排错积累无限制入口。

操作步骤与验证

1. 以用户体验指标为起点：可用性、请求错误率、延迟和关键业务成功率，再补充 CPU、内存、磁盘和网络。资源正常并不证明支付、登录等流程正常。
2. 区分需要立即响应的故障与容量趋势，设置持续时间、恢复通知和去重。阈值应来自正常基线与业务目标，避免所有短暂尖峰都触发紧急通知。
3. 每条关键告警配负责人、排查入口和升级渠道，模拟一次通知确认能送达。定期检查监控自身和数据缺失，不能把没有数据默认为没有故障。

操作步骤与验证

1. 盘点应用、系统、代理和容器日志位置，记录产生速率与责任进程。日志中不应输出明文密码、token 或完整敏感请求，排错时也应进行脱敏。
2. 按大小或时间配置轮转、压缩和保留周期，确认进程能重新打开日志文件。直接删除仍被打开的大文件可能不会释放空间，应使用服务支持的轮转方式。
3. 验证轮转后继续写入、权限正常且检索可用，为容量和采集失败告警。集中日志与源站应采用受限访问和传输保护，并按需要管理保留期限。

操作步骤与验证

1. 列出操作系统、应用、数据库和驱动版本，区分安全修复与功能升级。阅读兼容说明，确认更新是否需要重启、数据库迁移或客户端同步升级。
2. 先在接近生产的环境更新并验证关键流程，确认备份和回滚方式。维护窗口通知应包含预计影响、联系人和验收条件，不只记录开始时间。
3. 更新后检查版本、服务启动、监控和应用错误率，必要时验证实际重启后的状态。保留变更记录并跟踪异常，不能以安装命令退出成功作为唯一验收。

操作步骤与验证

1. 区分系统时钟、时区和应用显示格式。时区错误可能只影响显示，时钟漂移则可能导致 TLS、登录签名、队列与分布式任务失败。
2. 检查时间同步服务是否运行、上游是否可达，以及宿主与虚拟机的时间策略。避免多个同步程序互相调整时钟，先定位偏差来源而非手工反复改时间。
3. 生产环境大幅时间跳变前评估数据库、日志和任务影响。修复后比较多节点时间、证书验证与定时任务，监控偏差趋势并统一日志时间标准。

操作步骤与验证

1. 根据恢复地区和访问要求选择对象存储，分别估算存储、请求、取回和出站流量费用。归档层取回等待时间应满足 RTO；最低存储期限则影响保留策略与成本。
2. 使用受限凭据上传，配置加密、版本和生命周期，并核对删除权限。生命周期规则可能自动删除旧版本，不能在不理解匹配范围时直接应用到所有备份。
3. 从独立恢复环境下载并校验备份，记录取回时间与费用，确认密钥也能获取。对象上传成功只证明存储写入完成，仍需应用级恢复验证。

操作步骤与验证

1. 先确认影响范围：单用户、单地区、单实例还是全部服务，记录准确时间与时区。保存错误码和最近变更，避免在尚未记录证据时连续重启多个组件。
2. 按 DNS、网络、主机、应用和数据库逐层验证，优先恢复关键业务并控制变更数量。使用回滚或降级前评估数据写入，防止恢复服务时造成不一致。
3. 工单提供实例编号、目标地址、时间、复现步骤与脱敏日志，不发送密码或私钥。恢复后记录根因、验证结果和防复发措施，区分暂时恢复与彻底解决。

操作步骤与验证

1. 盘点所有域名、证书部署点与 ACME 账户，区分 CDN 边缘证书和源站证书。证书文件已更新不代表 Web 服务已加载新证书，应检查实际握手结果。
2. 按客户端支持方式测试续期，确认 HTTP 验证路径或 DNS API 权限。自动化凭据应限定范围，DNS 传播与防火墙变更可能影响续期，需保留执行日志。
3. 配置续期成功后的安全重载与失败通知，另外从外部监控到期时间。监控应覆盖实际域名和 SNI，而非只读取本地文件，避免遗漏错误虚拟主机。

操作步骤与验证

1. 区分公开配置与数据库密码、API key、签名密钥，不将真实密钥提交到代码仓库或写入镜像。环境变量不是自动加密的保险箱，仍需限制进程和管理权限。
2. 按服务分配独立凭据和最小权限，记录所有者、用途与轮换方式。日志、崩溃报告、备份和诊断命令也可能泄漏密钥，需脱敏并限制读取。
3. 轮换前确认应用支持双密钥或明确切换顺序，先验证新凭据再撤销旧凭据。疑似泄漏时不仅删除公开文件，还需撤销相关权限并检查异常访问记录。

操作步骤与验证

1. 记录 Linux 发行版名称与版本、内核版本、CPU 架构和虚拟化类型。安装包应匹配系统实际架构，不能只依据产品名称选择。
2. 核对主机名、地址、挂载点和系统时间，将结果与订单及配置记录对照。
3. 保存不含凭据的基线，更新或迁移后用相同项目复核，异常时附在工单中。

cat /etc/os-release
uname -r
uname -m
lscpu

操作步骤与验证

1. 为每位管理员建立独立账户，确认默认 shell、家目录和所属组，避免共用 root 凭据。
2. 通过发行版支持的 sudo 配置授予所需权限，编辑 sudoers 时使用 visudo 检查语法。
3. 保留已有管理会话，在新会话验证登录和必要命令；确认成功后再收紧旧账户权限。

id
sudo -l

操作步骤与验证

1. 先确定实际运行进程的用户，再检查目标文件及每一级父目录的所有者、组和访问权限。
2. 区分文件读取与目录进入权限；应用需要写入的目录应单独授权，不要用全站 777 解决问题。
3. 修改前保存权限记录，验证应用写入与普通用户访问，再检查 ACL、SELinux 或 AppArmor 是否另有限制。

操作步骤与验证

1. 查看服务状态与本次启动日志，记录退出码、失败时间和 ExecStart 实际执行的程序。
2. 检查工作目录、环境文件、运行用户与依赖服务，交互终端中成功不代表服务环境中可用。
3. 修正配置后检查语法；修改 unit 文件时，按要求重新加载 systemd 配置。测试启动、重启以及实际业务功能，通过后再启用开机自动启动。

systemctl --failed

操作步骤与验证

1. 先限定服务名称、时间窗口和启动批次，避免直接导出所有日志造成噪声或暴露敏感信息。
2. 将错误与更新、重启、磁盘告警等事件按时间关联，区分首次失败和重复重试产生的后续错误。
3. 保存脱敏片段与查询范围，检查日志保留策略；没有旧日志时不要推断事件从未发生。

journalctl --list-boots
journalctl -p err -b --no-pager -n 50

操作步骤与验证

1. 检查是否存在正常运行的更新进程，软件包锁可能属于自动安全更新，不应直接删除锁文件。
2. 确认进程状态与安装日志后，按发行版说明恢复中断的事务和依赖，先了解会被安装或移除的包。
3. 完成后检查软件包数据库与服务版本，若系统核心组件受到影响，在维护窗口验证重启。

操作步骤与验证

1. 通过 UUID、容量和文件系统类型识别磁盘，避免只依赖可能变化的设备名称。
2. 修改 fstab 前备份配置，检查挂载点、选项和启动依赖；网络存储还需考虑网络就绪条件。
3. 在保留控制台的情况下验证挂载，再测试重启；不要对包含业务数据的磁盘执行格式化。

lsblk -f
findmnt

操作步骤与验证

1. 确认产品已完成虚拟磁盘扩容，再区分分区、LVM、加密层和文件系统各层实际容量。
2. 备份并查阅对应文件系统的扩容方式，XFS 与 ext4 的工具不同，不能照搬缩容命令。
3. 按存储层次逐级扩展后核对可用空间与应用写入，保留操作记录；遇到不支持的布局先停止变更。

lsblk
df -Th

操作步骤与验证

1. 同时查看容量和 inode 使用率，空间有余量但 inode 用尽也会导致上传、日志或临时文件创建失败。
2. 定位大量小文件的目录，确认属于缓存、会话、邮件还是业务数据，先了解保留与清理规则。
3. 按应用支持的方式分批清理并验证服务，调整过期策略与告警，不要直接递归删除不明目录。

df -h
df -i

操作步骤与验证

1. 结合可用内存、持续换入换出、应用延迟和 OOM 记录判断，不把少量 swap 已用等同于故障。
2. 定位内存增长的进程及近期负载，核对容器或服务限制与主机总内存的关系。
3. 先减少异常占用或调整容量，禁用 swap 可能使进程更早被杀死，任何更改都需在代表性负载下验证。

free -h
vmstat 1 5

操作步骤与验证

1. 确认日志中是否存在 OOM 或 cgroup 内存限制事件，普通退出与内存不足应分别处理。
2. 记录受影响进程、内存峰值、容器限制及同时运行的任务，检查是否由一次异常输入触发。
3. 设置合理并发和资源上限，修复泄漏或扩容后重复负载验证，不能只通过自动重启掩盖故障。

操作步骤与验证

1. 出现 too many open files 时，区分进程限制与系统限制，统计普通文件、socket 和连接的增长。
2. 检查应用是否释放连接、文件及日志句柄，持续增长通常需要修复生命周期而不是无限提高上限。
3. 调整服务级限制后验证实际生效值，并用峰值并发测试内存和连接回收情况。

ulimit -n
cat /proc/sys/fs/file-nr

操作步骤与验证

1. 先确认进程归属和托管方式，使用对应服务管理器，避免手动杀死后被守护程序立即重启。
2. 优先正常停止，给连接排空、队列确认和数据刷盘留时间，强制终止前确认数据风险。
3. 重启后检查监听、依赖、积压任务和错误率，记录停止原因与恢复时间以便追踪。

操作步骤与验证

1. 确认更新涉及的内核、驱动和启动项，保留已知可用版本与远程控制台入口。
2. 安排维护窗口并暂停或迁移受影响任务，确认磁盘挂载和服务自动启动配置。
3. 重启后核对实际运行内核、网络、存储与业务，GPU 或第三方模块需再次检查兼容性。

uname -r
systemctl --failed

操作步骤与验证

1. 确认终端、文件、数据库与应用分别使用的编码，不将显示乱码立即解释为文件已损坏。
2. 检查 UTF-8 locale、应用启动环境及数据导入选项，在副本上验证转换，避免重复转码。
3. 用包含中文、符号与换行的样本测试保存和读取，记录跨系统迁移所需的编码设置。

locale
locale -a

操作步骤与验证

1. 记录系统版本、版本类型、补丁级别和 CPU 架构，确认应用及驱动支持该系统。
2. 在产品交付说明中核对授权责任和激活方式，系统能够启动不等于授权已满足。
3. 保存不含密钥的状态记录，授权异常通过正式支持渠道处理，不使用来历不明的激活工具。

Get-ComputerInfo -Property WindowsProductName,WindowsVersion,OsBuildNumber,OsArchitecture

操作步骤与验证

1. 确认系统允许远程桌面、账户具备登录权限，并区分网络失败与身份验证失败。
2. 检查客户端兼容性、系统时间、账户锁定及域连接，保留控制台再修改 NLA 设置。
3. 通过允许的来源重新测试，避免为临时排错长期关闭认证保护或公开管理入口。

操作步骤与验证

1. 核对当前网络配置文件和服务监听地址，规则可能仅适用于域、专用或公用网络之一。
2. 按程序、端口和来源地址建立最小范围规则，避免关闭所有配置文件的防火墙。
3. 从允许及禁止的网络分别测试，并在重启或网络配置文件变化后复核规则效果。

操作步骤与验证

1. 以故障时间筛选系统与应用日志，记录事件来源、ID 和完整消息，而不是仅截取红色图标。
2. 把服务启动、磁盘、登录和更新事件按时间关联，注意本地时区与应用日志时区差异。
3. 导出必要范围并脱敏，保留原始日志用于复核，不要在调查完成前清空事件记录。

操作步骤与验证

1. 检查服务启动类型、依赖和登录账户，确认账户有读取程序与访问数据目录的权限。
2. 密码轮换或权限变化可能导致服务无法启动，应更新受影响服务并记录变更范围。
3. 测试服务重启与系统重启后的状态，避免在无人登录时应用停止运行。

Get-Service | Where-Object Status -eq Running

操作步骤与验证

1. 查看待安装更新、重启要求与维护策略，确认业务允许的停机窗口。
2. 更新前备份关键配置与数据，测试依赖应用，避免同时修改网络和系统版本。
3. 重启后核对更新状态、远程桌面、服务与业务请求，失败时保留错误信息再决定回退。

操作步骤与验证

1. 先确认平台磁盘扩容完成，在磁盘管理中识别正确磁盘与未分配空间。
2. 检查分区布局和文件系统支持情况，相邻空间与分区类型可能影响扩展操作。
3. 备份后使用受支持方式扩展，核对盘符、容量、权限和应用写入，禁止误初始化已有数据磁盘。

Get-Disk
Get-Volume

操作步骤与验证

1. 明确计划任务使用的账户和工作目录，以及是否需要在用户未登录时运行；凭据的保存方式应符合账户安全策略。
2. 设置触发器、失败重试、最长运行时间，以及上一次任务尚未结束时的处理方式，避免不支持并行的任务重复启动。
3. 查看执行历史、返回码与输出文件，在重启和无人登录场景实际测试一次。

操作步骤与验证

1. 核对站点主机名、IP、端口和应用池，多个 HTTPS 站点需检查 SNI 与证书选择。
2. 确认应用池身份与内容目录权限，检查证书私钥访问以及完整证书链。
3. 从实际域名验证响应与证书，更新证书后测试重启和自动续期流程。

操作步骤与验证

1. 围绕故障选择 CPU、内存、磁盘延迟、队列和网络计数器，避免盲目收集全部指标。
2. 在正常与高峰时段分别记录，并关联进程、计划任务和最近更新。
3. 以相同采样间隔比较改动前后，确认瓶颈后再调整容量或应用配置。

操作步骤与验证

1. 确认域名实际使用的 NS 与修改记录的平台一致，注册商页面与权威 DNS 不一定是同一服务。
2. 分别查询权威与递归结果，记录 TTL、响应码和完整主机名，避免只测试根域名。
3. 修改后按旧 TTL 等待缓存过期，持续不一致时检查委派、DNSSEC 和记录冲突。

操作步骤与验证

1. 明确要配置的是根域名还是子域名，普通 CNAME 不能与同名其他记录任意共存。
2. 根域名别名能力取决于 DNS 提供商的 ALIAS 或扁平化实现，不能把产品专有功能当通用标准。
3. 验证 A/AAAA 最终结果以及邮件、验证记录是否受到影响，保留旧配置便于回滚。

操作步骤与验证

1. 当部分递归服务器返回 SERVFAIL 时，先比较支持验证与未验证的查询结果。
2. 核对注册商 DS 与权威侧 DNSKEY 是否匹配，迁移 DNS 时旧 DS 可能导致验证失败。
3. 按提供商支持的密钥轮换或取消流程处理，等待缓存更新并从多个解析器复核。

操作步骤与验证

1. 记录目标地址、端口与源网络，测试应用所用协议，不只依赖 ping 判断服务是否开放。
2. 超时可能来自路径、防火墙或服务无响应，拒绝连接则通常需要核对监听和主动拒绝规则。
3. 同时检查客户端与服务器日志，使用控制台确认服务状态，再按证据调整规则。

操作步骤与验证

1. 以最终目标与应用体验为主，路由器可能对 ICMP 限速，单个中间节点不回复不代表转发失败。
2. 在相同时间段重复测试并记录方向，回程与去程可以不同，单向结果无法完整描述线路。
3. 只有后续跳点与最终目标也出现一致异常时再关联业务请求与运营商信息提交排查。

操作步骤与验证

1. 若小请求正常而上传、TLS 或隧道流量卡住，记录路径中的 VPN、封装和网卡 MTU。
2. 使用适合系统的路径 MTU 诊断方式，区分 ICMP 被阻断与真实包长限制，不盲目统一设定固定值。
3. 在测试入口调整并验证大文件、HTTPS 和双向连接，保留原配置及管理控制台恢复。

操作步骤与验证

1. 核对实际分配的子网、网关和路由范围，不将未分配的私网地址配置到公网接口。
2. 检查最长前缀匹配的路由、默认路由和多网卡策略路由。返回流量走向不符合预期时，可能导致连接失败。
3. 分别验证同子网、跨子网与公网访问，修改前保存路由并保留控制台。

ip address show
ip route show
ip -6 route show

操作步骤与验证

1. 列出监听服务及绑定地址，将业务端口、数据库与管理面分别记录。
2. 从授权的外部测试点验证 IPv4 和 IPv6 的实际可达性，主机本地监听不代表公网一定可达。
3. 关闭不需要的入口后复测，容器端口发布和代理配置也需纳入检查。

ss -lntup

操作步骤与验证

1. 确认请求经过的 CDN、负载均衡和反向代理链，记录每一层可信来源。
2. 应用仅信任已知代理写入的转发头，不能直接用任意 X-Forwarded-For 进行身份或白名单判断。
3. 测试直连与代理请求、IPv6 和多级代理情况，确认日志和限流使用预期地址。

操作步骤与验证

1. 区分进程存活与服务就绪，检查端点应代表可以接收业务请求，而非简单返回静态成功。
2. 设置超时、间隔与连续成功失败阈值，防止短暂抖动造成所有后端反复上下线。
3. 演练后端停止、依赖故障与恢复，确认连接排空和重新加入行为符合业务目标。

操作步骤与验证

1. 确认表引擎、事务特性和数据库版本，再选择受支持的逻辑或物理备份方式。
2. 记录备份时点、binlog 信息与业务写入状态，普通文件复制不保证活跃数据库一致。
3. 在独立实例恢复并验证表、权限与业务查询，备份日志成功不能替代恢复测试。

操作步骤与验证

1. 统计应用实例数和每个实例连接池上限，总连接需求需加上后台任务与管理入口。
2. 检查连接泄漏、长事务和慢查询，不应只提高数据库最大连接数而忽略内存开销。
3. 设置获取连接超时与限流，在高峰负载验证等待时间、错误率和连接回收。

操作步骤与验证

1. 收集真实慢查询、参数分布和执行频率，避免只优化一个不代表业务的样本。
2. 查看执行计划中的扫描、连接与排序方式，结合索引选择性和写入成本判断。
3. 在测试数据量接近生产时验证，新增索引操作可能锁表或消耗空间，安排合适维护方式。

操作步骤与验证

1. 确认复制拓扑、数据库版本和接收线程、应用线程的状态，区分连接中断、接收事件延迟与执行事务积压。
2. 关联大事务、写入突增、磁盘瓶颈和从库查询压力，延迟秒数并非全部健康信息。
3. 恢复后核对数据一致性与应用读写策略，不能在不了解影响时跳过复制错误。

操作步骤与验证

1. 选择逻辑转储或物理备份前确认恢复目标、版本兼容与所需停机时间。
2. 物理恢复通常需要匹配版本和完整 WAL 链，不能只复制正在写入的数据目录。
3. 在隔离环境验证角色、扩展、编码与查询，记录恢复时长以及所需空间。

操作步骤与验证

1. 检查数据表的更新频率、已失效的行版本和长事务。长时间未结束的事务可能阻止旧行版本被清理。
2. 核对 autovacuum 配置与实际运行情况，普通 VACUUM 和 VACUUM FULL 的锁与空间行为不同。
3. 调整前评估负载，监控事务 ID 年龄、磁盘增长和查询延迟。VACUUM FULL 会重写数据表，应提前安排维护并预留空间。

操作步骤与验证

1. 根据允许丢失的数据量选择持久化策略，RDB 快照与 AOF 刷盘周期有不同恢复边界。
2. 为后台重写和 fork 预留内存与磁盘，检查失败日志和文件位置。
3. 使用副本验证恢复并核对关键键与过期时间，持久化不能代替异机备份。

操作步骤与验证

1. 根据延迟、命令统计与访问分布定位热点，不在繁忙实例上无计划扫描全部键。
2. 大键会影响网络、删除与复制，评估拆分、分页和过期策略时考虑应用兼容。
3. 在低影响窗口验证调整，观察延迟和内存回收；异步删除也要确认版本支持。

操作步骤与验证

1. 根据恢复目标、业务周期和存储成本定义日、周、月保留规则，不只保留最后一份。
2. 确认增量备份依赖链，删除基础备份可能使后续增量不可恢复。
3. 在执行自动删除前验证规则与恢复样本，告警覆盖失败、容量和备份过期。

操作步骤与验证

1. 明确传输加密与静态加密覆盖范围，记录恢复需要的密钥、权限及工具版本。
2. 密钥与备份分开保管并限制读取，至少设计一个主机故障后仍可使用的恢复入口。
3. 在独立环境验证解密与恢复，轮换密钥时保留历史备份所需的解密能力。

操作步骤与验证

1. 记录镜像仓库、版本和 CPU 架构，可变标签可能在不同部署时间指向不同内容。
2. 正式发布使用已验证版本或摘要，保存依赖配置与上一版本，避免只保留 latest。
3. 在测试环境验证拉取、启动、数据兼容和回滚，不把成功下载视为应用验收。

docker image ls --digests

操作步骤与验证

1. 确认哪些数据需要跨容器重建保存，区分命名卷、绑定挂载和容器可写层。
2. 核对宿主路径、容器 UID/GID 和读写权限，避免将整个宿主根目录挂入应用。
3. 重建测试容器并确认数据仍在，备份卷时使用数据库一致性流程。

操作步骤与验证

1. 区分 Compose 文件插值、环境文件和容器运行环境，变量相同名称不代表来源优先级相同。
2. 检查最终配置时防止输出真实密钥到公开日志，记录工作目录和使用的配置文件。
3. 在测试环境确认应用读取到预期配置，变更后按服务要求重建或重启。

操作步骤与验证

1. 健康检查应验证服务就绪，命令需要在容器中存在并有合理超时。
2. 容器 unhealthy 不一定触发重启，实际行为取决于引擎、编排和重启策略。
3. 演练进程退出、依赖失败和主机重启，确认不会无限重启或反复执行不可重复的初始化。

docker ps -a

操作步骤与验证

1. 确认日志驱动与应用文件日志是否同时产生，双重记录会增加磁盘占用。
2. 设置大小、份数与保留策略，已有容器可能需要重建才应用新的日志配置。
3. 验证轮转后可查询且采集不中断，为主机磁盘容量和采集失败设置告警。

操作步骤与验证

1. 同一容器中的 localhost 指向自身，不代表宿主机或另一个数据库容器。
2. 核对服务是否处于同一受支持网络、名称解析与监听端口，区分内部端口和发布端口。
3. 仅向外发布必要服务，从容器内部和外部各测一次，避免数据库误暴露公网。

操作步骤与验证

1. 不要用普通 COPY 或持久环境变量写入仓库 token，删除文件也不保证旧镜像层中不存在。
2. 使用构建工具支持的临时 secret 挂载。限制构建上下文，也就是可供构建过程读取的文件范围，并维护忽略规则，避免包含凭据。
3. 检查镜像历史和日志，发现泄漏应轮换凭据并清理发布镜像，不能只提交一次删除。

操作步骤与验证

1. 确认新旧版本能同时处理请求并兼容数据库结构，单实例应用不能默认无停机更新。
2. 先启动并验证新实例，停止向旧实例发送新请求，再等待已有连接与任务完成。
3. 按错误率和延迟逐步扩大流量，设置回滚门槛并处理发布期间的数据变化。

操作步骤与验证

1. 确认应用所需 Python 版本，用独立虚拟环境安装依赖，避免覆盖系统 Python 包。
2. 固定依赖版本并记录安装源与平台架构，原生扩展可能需要匹配系统库。
3. 用相同运行用户测试导入、启动和业务样本，保存可重建依赖清单以支持回滚。

python --version
python -m pip --version

操作步骤与验证

1. 选择仍受支持且兼容应用的运行时，记录包管理器和锁文件版本。
2. 以非特权账户安装依赖和运行服务，明确工作目录、环境变量和反向代理入口。
3. 使用服务管理器测试自动启动、正常停止和日志轮转，更新后验证关键接口。

node --version
npm --version

操作步骤与验证

1. 核对管理接口、物理网卡和网桥成员，保存配置并确认控制台可用。
2. 按服务商交付方式区分桥接与路由子网，不能把网关放到错误接口或使用未分配地址。
3. 先验证测试虚拟机的入站与出站，再处理正式租户；管理访问异常时立即用控制台恢复。

操作步骤与验证

1. 确认虚拟化平台与客体系统支持的代理版本，按官方方式安装并启用。
2. 验证平台能够读取客体状态和执行约定操作，文件系统冻结需要与应用一致性一起评估。
3. 升级后测试正常关机、地址获取与备份集成，不把代理在线视为全部业务正常。

操作步骤与验证

1. 制作模板前移除临时凭据、敏感日志与不应复制的密钥，保留必要补丁和代理。
2. 按系统支持方式处理机器身份、SSH 主机密钥和网络配置，避免克隆后地址或身份冲突。
3. 先创建测试实例验证首次启动、账户和自动初始化，再用于批量交付。

操作步骤与验证

1. 确认镜像支持的 datasource 与平台注入方式，区分首次执行、重启和实例身份变化。
2. 查看初始化状态与分阶段日志，检查 YAML 语法、网络依赖和命令退出结果。
3. 在副本上验证修改，重置初始化状态可能重新执行用户创建或脚本，不能在生产上盲目清理。

操作步骤与验证

1. 分别监控池数据空间与元数据占用，虚拟磁盘声明容量可以超过物理容量。
2. 将快照增长、备份暂存和租户突增纳入预留，不等池满才处理。
3. 扩展前确认存储布局和备份，验证告警阈值及客体写入，避免同时承诺无法兑现的容量。

操作步骤与验证

1. 记录池状态、设备错误与冗余布局，scrub 用于校验已有数据，不是备份。
2. 安排适合业务的执行时段并观察 I/O 影响，设备故障与校验错误需要结合历史趋势判断。
3. 完成后核对结果与错误处理，替换磁盘前确认设备身份、备份和可用冗余。

操作步骤与验证

1. 核对宿主 CPU 特性和集群最小兼容范围，host 模式可能暴露目标节点不支持的指令。
2. 在应用性能和跨节点迁移之间选择合适模型，记录需要特定指令集的软件。
3. 用测试虚拟机验证冷启动与迁移，变更 CPU 模型可能需要关机，先安排维护。

操作步骤与验证

1. 比较宿主和客体的时钟与时间同步服务，暂停、恢复和高负载可能触发异常。
2. 避免多个代理与时间服务互相调整，核对平台推荐的时间源及客体工具。
3. 测试迁移和重启后的偏差，验证证书、登录与定时任务，持续监控时间误差。

操作步骤与验证

1. 盘点网络、存储、权限、虚拟机定义与集群配置，区分配置备份和客体数据备份。
2. 按平台支持方式导出并加密保存，配置可能包含 token 或存储凭据，限制读取权限。
3. 记录从空白主机恢复所需版本和步骤，在测试环境演练后才能认为备份完整。

操作步骤与验证

1. 同时观察客体与宿主指标，客体 CPU 等待或磁盘延迟可能由宿主争用引起。
2. 核对 CPU 权重、内存限制、磁盘和网络限额，避免只在客体内扩容应用线程。
3. 以代表性并发验证公平性与尾延迟，保留维护余量并监控超分后的容量风险。

操作步骤与验证

1. nvidia-smi 显示的 CUDA 信息反映驱动支持，不等于系统安装了相同版本 Toolkit。
2. 确认应用使用预编译运行时还是需要编译扩展，再按官方兼容说明选择组件。
3. 记录驱动、运行时、框架和编译器，先做小型计算验证，避免反复覆盖安装掩盖冲突。

nvidia-smi

操作步骤与验证

1. 记录宿主 GPU 编号与 UUID，容器或进程过滤后看到的编号可能重新从零开始。
2. 为每个任务明确可见设备和进程数，避免多个作业意外占用同一块卡。
3. 启动后比较进程日志、实际显存占用和设备名称，调度变更后重新验证映射。

nvidia-smi --query-gpu=index,uuid,name --format=csv

操作步骤与验证

1. 先确认硬件和框架支持的精度，权重、激活和优化器状态可能使用不同类型。
2. 低精度可减少部分内存和计算开销，但数值范围、稳定性和算子支持需要实际验证。
3. 用相同评估样本比较输出质量、损失值、吞吐量和峰值显存。如果出现 NaN，保存触发问题的输入、日志和运行配置，便于复现。

操作步骤与验证

1. 明确模型结构、上下文长度、并发和缓存精度，KV Cache 不包含在权重文件体积中。
2. 长输入和持续生成都会影响缓存峰值，应使用真实长度分布与最大允许请求测试。
3. 设置上下文、并发和排队上限，比较缓存策略对延迟与质量的影响后再扩大服务规模。

操作步骤与验证

1. 固定模型、软件版本、精度、输入及输出长度，分别记录冷启动与预热后结果。
2. 同时报告吞吐、首 token、尾延迟、错误率和显存峰值，单个跑分不能代表全部业务。
3. 记录功耗、温度及共享负载条件，用相同设置重复测试，不把一次峰值当持续承诺。

操作步骤与验证

1. 确认量化格式、框架、内核与目标 GPU 的支持关系，模型后缀相同不保证可互换。
2. 用固定样本比较原始和量化输出，覆盖长上下文、特殊字符与关键任务。
3. 记录加载峰值、吞吐和错误率，量化降低权重体积不代表所有运行状态按同比例减少。

操作步骤与验证

1. 将每步时间拆分为读取、预处理、传输和计算，低 GPU 利用率不一定是显卡问题。
2. 检查存储吞吐、小文件数量、CPU worker 与内存占用，增加 worker 也可能引发争用。
3. 使用相同训练样本调整预取和数据加载工作进程数，比较完整训练步骤的吞吐量与内存用量，不只关注某一个阶段的速度。

操作步骤与验证

1. 盘点模型下载缓存、解压副本、训练输出和检查点，权重下载可能短时占用多份空间。
2. 按任务设置缓存路径和保留份数，删除前确认没有运行进程依赖对应文件。
3. 模拟保存与恢复，监控空间和 inode，确保长训练不会因最终写入失败丢失成果。

操作步骤与验证

1. 记录温度、功耗、频率及限制原因，将性能下降与负载和环境变化对应。
2. 区分正常功耗限制与异常散热问题，不在不了解硬件约束时调整功率或风扇策略。
3. 保留监控曲线与可复现负载，通过支持渠道处理硬件异常，调整后复测稳定吞吐。

nvidia-smi --query-gpu=name,temperature.gpu,power.draw,clocks.gr --format=csv

操作步骤与验证

1. 从可信来源获取模型并记录版本、许可与校验，权重和依赖脚本可能具有不同风险。
2. 启用远程自定义代码前阅读其作用，在隔离环境测试并限制凭据、文件和网络访问。
3. 固定可复现版本并审查更新，日志与示例不要包含用户敏感输入或真实访问令牌。