第1章 Linux 系统与国产化 OS（安装部署与初始化主线）

对应简历：技能第2条「熟练掌握 Ubuntu / CentOS 及统信 UOS、麒麟 V10 等国产操作系统的安装部署、初始化配置与调优」；技能第1条「独立完成国产化平台从硬件上架到系统交付的全流程实施」；项目一「发放统信 UOS / 麒麟 V10 虚拟机 15+ 台」「Kubernetes 集群在统信 UOS（ARM）环境部署」；项目二「全节点标准化初始化」。 实施版口径：本章以安装部署、初始化配置、环境问题排查、信创 OS/ARM 为主线（实施工程师的地面动作）；性能调优压缩为两节，答案仍保持完整段落。国产 OS 与毕昇 JDK 的产品层深挖见华为篇第 6 章，本章不重复展开。 使用提醒：所有"标准回答"都按能对面试官口述 45–120 秒的颗粒写，背整段话不背提纲。

1.1 操作系统安装部署与分区规划 【必背】

标准回答：先说结论：实施工程师装系统不是"下一步下一步"，而是"规划先行、镜像核对、分区按负载"三段式。第一段规划先行——装机前必须先有《IP 规划表》和分区方案：主机名、IP、网关、DNS、用途每一台都提前定好，装的时候照表填，装完逐台核对，这是我做银行项目 15 多台虚拟机时固化的规矩，规划表做细，装机就是体力活；规划表不细，每一台都是坑。第二段镜像核对——装之前先确认架构和版本：ARM 机器必须用 aarch64 镜像，统信 UOS Server 20 和麒麟 V10 SP1 各有专用 ISO，我第一件事就是 cat /etc/os-release 和 uname -m 核对环境，这一步省掉的是装到一半才发现"包不配套"的返工。第三段分区按负载——标准分区方案是：/boot 给 1G、swap 按内存大小给（K8s 节点干脆不要）、根分区 100G 左右装系统和应用、剩下一大块单独划 /data 数据分区。数据库节点更要细：数据盘、日志盘、归档盘分开，这个规划直接影响后面 Vastbase 的 IO 表现和日志治理。我在《智能合约引擎安装部署指南》里把分区表固化成了模板，后来公司同类项目直接抄。

追问链：

• 追问1：为什么要把 /data 单独分区，根分区给大点不行吗？ → 答：不行，三个理由。第一是隔离风险：日志和应用数据把分区写满时，如果数据和根在同一个分区，整个系统连日志都写不了，ssh 都可能登不上，现场就死锁了；单独分区后最多是这一个应用受影响，系统还活着、我还能登进去处理。第二是治理方便：/data 单独挂载，扩容时用 LVM 在线扩这个卷就行，不用动系统。第三是性能可预期：数据库这类 IO 密集负载单独放一块盘或一个分区，不和系统 IO 抢队列。我在银行现场处理过"日志写爆分区"的案例，单独分区这套设计就是那时候强化进我的标准方案的。
• 追问2：最小化安装和完整安装怎么选？ → 答：生产一律最小化安装加按需补包。理由是攻击面和体积都最小——金融客户的安全基线扫描里，"装了一堆用不到的服务"本身就是扣分项。我的习惯是最小化装完，先配好内网软件源，再用 yum/apt 按清单补包，补包清单（gcc、openssl-devel、pcre-devel 这些编译依赖）直接写进部署手册，每台机器跑一遍脚本，保证 15 台装出来的环境一模一样。环境一致性是实施的命根子，"每台机器各有各的小毛病"是排查效率的头号杀手。
• 追问3：虚拟机上装系统和物理机有什么不一样？ → 答：流程一样，入口不一样。物理机我是走 iBMC 虚拟控制台挂 ISO 光驱引导装（见第 8 章）；虚拟机是在 FusionCompute 里给虚机挂光驱、选光驱启动，然后从 VRM 网页打开 VNC 控制台进安装界面，操作和物理机一致。我的标准做法是：第一台装好系统、调完基础配置、装完 Guest Tools，把它当"金标准"，后面的机器按同一规格发放再统一跑初始化脚本，保证十几台机器一致性是靠流程不是靠手稳。
• 追问4（深挖）：装完系统第一件事做什么？ → 答：改 hosts 和主机名、配 IP 和 DNS、配时间同步、验证软件源——也就是 1.2 节的初始化基线，这些不做完我不会开始装任何上层软件。因为上层软件的很多问题根源在底层环境：时间不同步会让后续 K8s 证书校验失败、数据库主备异常；hosts 不通会让集群组件互相找不到。我的原则是"底层基线不绿，上层一行不装"。

关联话术：这题我会直接挂项目："银行项目 15 多台统信 UOS、麒麟 V10 虚拟机的安装是我按 IP 规划表逐台完成的，分区方案、装机流程、装完的核对清单都沉淀在部署指南里；后来移动云 7 台 Ubuntu 节点我把这套流程做成了初始化脚本，十分钟一台。"——装机这件事我讲得出细节、拿得出文档，这是实施岗最直接的基本功证明。

实操模板（装机后核对清单，可背）：

cat /etc/os-release && uname -m       # 1.发行版与架构（ARM 必须 aarch64）
hostnamectl                           # 2.主机名
ip addr && ip route                   # 3.IP 与网关对照规划表
cat /etc/resolv.conf                  # 4.DNS
chronyc sources -v || ntpstat         # 5.时间同步状态
df -h                                 # 6.分区对照方案
getenforce 2>/dev/null; systemctl is-active firewalld 2>/dev/null   # 7.安全模块状态

1.2 系统初始化配置基线（主机名/网络/时间/软件源/口令） 【必背】

标准回答：初始化基线是我每次交付的固定动作，清单七项：第一主机名与 hosts——hostnamectl set-hostname 定名，再把全部节点互相写进 /etc/hosts，这是分布式组件互相寻址的地基；第二网络配置——CentOS 系在 /etc/sysconfig/network-scripts/ifcfg-xxx 配静态 IP，Ubuntu 用 /etc/netplan/.yaml 然后 netplan apply，配完一定 ip a 和 ping 网关双验证；第三时间同步——金融环境必须配，我统一用 chrony 指向客户内网 NTP 源，chronyc sources 看到 ^ 才算锁定，时间不同步是 K8s TLS 认证失败、数据库主备复制异常这些"莫名其妙问题"的头号隐藏根源；第四软件源——内网环境把默认源替换成厂商内网源或自建镜像源，统信用 apt、麒麟用 yum，换源后先 yum makecache 验证通不通；第五口令策略与账号——按客户基线设密码复杂度和过期策略，建应用专用账号不用 root 跑服务；第六句柄与内核参数——limits.conf 加 nofile 65535、sysctl 按组件需求预置；第七关闭或规范防火墙/SELinux——按客户安全要求二选一：金融严格环境保留防火墙按端口白名单放行，交付期环境先关掉装完再统一收口。这七项我全部做进了幂等脚本（见 1.14），新节点十分钟跑完，跑完自动出摘要截图留档。

追问链：

• 追问1：chrony 和 ntpd 怎么选？为什么你用 chrony？ → 答：我统一用 chrony。它在时间偏差大时收敛更快、对间歇性网络更宽容，而且 systemctl status chronyd 一眼可查，centos 系默认也换成了它。配置上服务端配 server 指向上游 NTP，客户端 allow 网段做分发，chronyc sources -v 看同步状态、chronyc tracking 看偏差值。我在移动云项目专门解决过"节点时间不同步导致 TLS 认证失败"的问题，是 9 项避坑清单里的一条——从那以后时间同步检查是我初始化验收的固定项，不看到锁定状态不往下走。
• 追问2：内网环境软件源不通，装包怎么办？ → 答：这是信创内网的日常。我的三级方案：第一优先厂商内网源——统信、麒麟、华为鲲鹏镜像站都有内网源或离线 ISO 挂载当源；第二是自建——把常用 rpm/deb 包下载整理成一个目录，createrepo 做成 yum 源或者搭个简单 http 服务分发；第三是纯手工——二进制包解压即用，我在 ARM 上装 Docker 就是这么装的。所有离线包我按"包名-版本-架构"整理成清单随交付文档归档，下次项目直接复用，这是实施资产。
• 追问3：为什么应用要用专用账号跑，root 跑不行吗？ → 答：不行，三个层面。安全层面，root 跑的服务一旦被攻破就是整台机器沦陷，专用账号把爆炸半径限制在应用目录；规范层面，银行客户的安全基线扫描必查"服务是否以非特权用户运行"；排障层面，专用账号的属主和权限边界清晰，出了问题一看进程属主就知道是不是被改过。我的标准做法是建 app 用户、目录 chown 到它、systemd unit 里写 User=app，交付文档里写明"日常运维用该账号，root 仅管理用"。
• 追问4（深挖）：15 台机器怎么保证初始化一台不漏？ → 答：靠"脚本+清单+抽查"三件套。脚本是幂等的，统一入口一键跑完；清单是把每台的初始化项做成核对表，脚本输出自动落日志，每台留档；抽查是跑完后我在任意几台上手动跑验证命令组（1.1 的核对清单），对不上就整批重跑。实施和运维最大的区别就是：运维管的是"活着"，实施管的是"每台都对"——漏一台，验收的时候就是客户发现而不是我发现。

关联话术："这套基线在两个项目演化过两代：银行项目是手工加半自动，每台机器对着清单核；移动云项目我把全部七项做成了幂等脚本加自动摘要，7 台节点十分钟一台跑完验收。这个脚本现在是公司外包项目新节点的标准初始化工具——'把重复动作变成脚本和清单'是我做实施最核心的工作习惯。"

1.3 现场常用命令与日常排障 【必背】

标准回答：如果让我按现场工作的频度报命令，我按三类说。第一类文件与文本：ls、cd、cp、mv、mkdir、tar 打包解压，cat 看小文件、tail -f 实时追日志、grep 过滤关键字、find 按名字或时间找文件——装机分发时 tar 加 scp/rsync 是搬运介质的主力。第二类系统状态：top 看 CPU 内存、free -h 看内存、df -h 看磁盘、du -sh 定位大目录、ps aux 看进程、ss -lntup 看端口和进程对应——这组是我"环境健康检查"的固定组合，每台新机器跑一遍。第三类服务与传输：systemctl 管服务、ssh 和 scp 远程操作、curl 验证接口和端口、telnet/nc 测连通。这套组合覆盖我实施工作八成场景：装机初始化用 systemctl、find、tar；联调排障顺着"端口通不通→日志有没有报错→进程在不在"往下钻，ss 加 tail 加 grep 三件套是我在客户现场用得最多的组合。两年银行驻场加移动云项目，这些命令基本每天手不离。

追问链：

• 追问1：端口被哪个进程占用怎么查？ → 答：第一步 ss -lntup | grep :8080，同时拿到监听地址、进程名和 PID；第二步要详情就 ps aux | grep PID 看启动命令。ss 是 netstat 的现代替代，连接多的时候快很多，因为它直接读内核 socket 缓存不用遍历 /proc/net 全表。我在联调时判断"后端起了没、起在哪个口"，这条命令是第一反应——比登页面看快得多。
• 追问2：看大日志文件为什么不用 vim？ → 答：vim 会把整个文件读进内存做编辑缓冲，几个 G 的日志可能直接把会话卡死甚至触发 OOM。生产上要用流式工具：less 分页、head/tail 看头尾、grep/sed/awk 过滤统计，它们逐行处理，多大的文件都不怕。我在银行现场处理 BCS 组件的巨型日志，从来都是先 grep 过滤再分析，"先想清楚要什么再决定扫多少数据"是我处理大文件的固定思路。
• 追问3：tar 分发包前为什么要先 -t 看一眼？ → 答：因为解压出来的结构可能和预期不一样——有人带路径打包，解开是散文件或者多套了一层目录。tar -tzf 先看清单，确认结构后再在目标目录里 -C 解压，是我给自己立的规矩。客户传来的包"解开一屏散文件"这种事处理过一次之后，"先 -t 再 -x"就成了肌肉记忆——两条小纪律消灭一整类事故。
• 追问4（深挖）：传输大文件用什么，scp 还是 rsync？ → 答：一次性小文件 scp 够用；重复同步、大文件、目录树用 rsync——增量算法只传差异部分，第二遍起快一个量级，还有 --exclude 排除、--delete 镜像、--bwlimit 限速这些 scp 没有的能力。我批量分发安装包到 15 台节点就是"scp/rsync 加 for 循环"，带宽敏感的客户现场加 --bwlimit 避免打满业务网络——传输工具的选型也是实施细节的一部分。

关联话术：这题我不背清单，直接引场景："银行项目 15 台国产化虚拟机的装机核对、联调排障就是这套命令的组合，国产 OS 上操作习惯和 CentOS 完全一致，差异只是软件源和包名；移动云 7 台 Ubuntu 节点我又把 top、free、df 这些检查项接进了 Prometheus 大盘。"一句话把命令、场景、两个项目串起来。

实操模板（环境健康检查命令组，可背）：

uptime && free -h && df -h          # 负载/内存/磁盘三件套
ss -lntup | head -20                # 端口监听概况
systemctl --failed                  # 失败服务
journalctl -p err --since "-1 day" | tail -20   # 近一天错误级日志

1.4 文件权限与交付目录规划 【必背】

标准回答：权限我按"三组对象 × 三种权限"的矩阵理解：属主、属组、其他人各配读 4、写 2、执行 1，三位数字加出来。755 是属主 rwx 其余 r-x，目录和可执行脚本常用；644 是属主 rw 其余 r，普通文件常用。umask 决定新建文件默认权限：文件从 666 减、目录从 777 减，root 默认 022，所以新建文件 644、目录 755；金融客户常用 027 这种"其他人无权限"的收紧掩码，我配银行环境的应用目录就按这种口径。但对实施工程师来说，更重要的是交付目录规划与权限基线：我的标准结构是 /opt/应用名 下分 bin、conf、logs、data 四个子目录，整套 chown 给应用账号，脚本 755、配置 600、密钥类 640、日志目录给应用账号写权限——这套基线在银行客户的安全扫描里是必查项，我是逐条被验证过的。软硬链接也顺带说：软链接存路径可跨分区、给目录建，做版本切换（current 链接指向版本目录）特别好用；硬链接同 inode 不可跨分区，删一个名数据还在。

追问链：

• 追问1：为什么目录需要 x 权限？ → 答：目录的 x 不是"执行"而是"进入和穿越"。没有 x 就 cd 不进去、也访问不了里面任何文件——哪怕有 r 能 ls 出文件名也不行，因为访问目录内文件必须在目录里"走过去"。所以一个只有 r 没有 x 的目录能看见文件名却打不开文件，这是权限题的经典区分点，也是我做"目录给 r-x、不给 w"这种基线的依据。
• 追问2：umask 027 新建文件和目录分别什么权限？ → 答：文件按位屏蔽 666 减 027 得 640——属主 rw、属组 r、其他人无权限；目录 777 屏蔽 027 得 750。027 这种掩码在金融环境很常见，因为它直接实现了"非本组不可见"，对应用目录、配置目录是合理默认，我在银行环境按这套口径配过全量节点。
• 追问3：chown 递归操作有什么风险？ → 答：chown -R 写错目标会把系统目录属主改飞，系统直接出诡异问题。我的纪律是：递归操作前先 ls 确认目标路径、变量加引号防空展开、先在一台机器上验证再批量推。批量变更类操作（chown/chmod/sed -i）我都遵守"单台验证 → diff 确认 → 批量执行 → 抽查复核"四步，这在客户现场是变更纪律不是可选项。
• 追问4（深挖）：SUID 文件和安全检查？ → 答：SUID 让执行者临时获得文件属主身份，passwd 就是典型。生产上这块的重点是安全排查：find / -perm -4000 -type f 列出全系统 SUID 文件和基线对比，多出来的就是可疑项。这条命令在银行客户安全扫描的检查项里，我交付完都会自己先跑一遍，把结果归档到验收材料里——自查在前，比被客户扫出来体面得多。

关联话术："我交付每个应用都带一套固定的权限基线：目录属应用账号、配置 600、密钥 640、脚本 755，写进部署手册的'安全基线'一节，验收时按清单逐条核。把权限当'交付项'而不是'知识点'来做，是我做实施和纯运维视角的一个差别。"

1.5 systemd 服务管理与组件服务化交付 【必背】

标准回答：现代 Linux——CentOS 7 以上、Ubuntu、统信、麒麟——统一用 systemd 管服务，实施交付离不开它。日常一组命令：start/stop/restart/reload/status/is-active，其中 enable --now 一步到位"设自启并启动"，我最常用；改了 unit 文件必须 daemon-reload 重加载，这是新手最常漏的一步。服务起不来我的固定排查链五步：第一步 systemctl status 看状态摘要；第二步 journalctl -u 服务 -e -n 50 看详细报错，-e 直接跳尾部；第三步 ss -lntup | grep 端口 查端口占用；第四步把 unit 里 ExecStart 那行命令拿出来手动执行——真实报错往往一锤定音；第五步查用户、目录权限、配置语法。更重要的是实施视角的"组件服务化交付"：我交付的每个自部署组件——Node Exporter、自研启停脚本、应用的启停——都统一做成 /etc/systemd/system/ 下的 xxx.service，三段式 [Unit]、[Service]、[Install] 我能直接默写。这样做的好处是客户现场的人只需要会 systemctl 和 journalctl 两个命令就能日常管理，交付门槛低、交接成本低——"把组件交给客户时是服务而不是一堆脚本"，这是我做交付时特别在意的点。

追问链：

• 追问1：reload 和 restart 的区别，交付时怎么选？ → 答：restart 杀掉主进程重新拉起，有中断窗口；reload 发信号让进程重读配置，连接不断。生产原则"能 reload 的优先 reload"，比如 nginx 改配置。但交付期我更常用 restart——因为首次部署和参数变更多半需要完整重启生效，我会把"哪个参数 reload 生效、哪个必须 restart"写进部署手册的注意事项里，客户自己运维时照表执行，不用再来问我。
• 追问2：服务单元怎么写，现场默写一个？ → 答：三段式我能默写：[Unit] 段 Description 加 After=network.target 保证网络就绪再起我；[Service] 段 Type=simple、ExecStart 用绝对路径、Restart=always 挂了自动拉起、User 指定应用账号、LimitNOFILE=65535 预置句柄；[Install] 段 WantedBy=multi-user.target。写完 daemon-reload、enable --now、journalctl -f 盯日志确认。模板在本节实操里，我给客户环境做的组件托管全是这套，交接文档里也附 unit 说明。
• 追问3：journalctl 日志把磁盘吃满了怎么办？ → 答：应急 journalctl --vacuum-size=200M 立即回收；根治在 /etc/systemd/journald.conf 配 SystemMaxUse=500M 上限，之后自动滚动。这条我写在初始化基线里——监控节点、日志量大的组件节点尤其要预置，不然运行几个月先被日志撑爆的是自己。交付时把这个配置当默认项，就不是事后救火。
• 追问4（深挖）：unit 的 Type 有哪些？ → 答：常用四种：simple 默认，ExecStart 的进程就是主进程；forking 会 fork 到后台，要配 PIDFile 让 systemd 追踪；oneshot 跑一次就退，适合初始化任务；notify 是服务自己通过 sd_notify 通知就绪，不少 K8s 组件用这种。我写交付组件的 unit 基本 simple 加 Restart=always 就覆盖了，知道每种适用什么场景，够判断"别人的 unit 为什么这么写"。

实操模板（交付标准服务单元，可默写）：

# /etc/systemd/system/appsvc.service
[Unit]
Description=Company App Service
After=network.target

[Service]
Type=simple
User=app
ExecStart=/opt/app/bin/start.sh
Restart=always
RestartSec=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

systemctl daemon-reload && systemctl enable --now appsvc
journalctl -u appsvc -f          # 排障入口

1.6 环境问题排查：高频装机与初始化故障 【必背】

标准回答：实施工程师在客户现场最值钱的能力之一就是"环境问题快速定位"，我把高频故障归成六类，每类都有第一反应。第一类磁盘类：报 No space left on device，第一反应 df -h 看哪个挂载点满——注意有两种满，空间满（df -h）和 inode 满（df -i，海量小文件导致，现象是空间有余量但建文件报错）；还有隐蔽的第三种：删了大文件空间不释放，是进程还握着句柄，lsof | grep deleted 找到它，低峰重启进程才真正释放。第二类只读类：Read-only file system，多半是磁盘 IO 错误后内核自我保护，dmesg 里一定有报错，应急 mount -o remount,rw 试恢复，根治要 fsck 或换盘。第三类网络类：ping 不通/域名解析失败——按分层查：ping 网关、ping 外网 IP、nslookup 域名，三步就能分清是链路问题还是 DNS 问题；curl 能通浏览器不行先查代理和 hosts。第四类软件源类：yum/apt 报错，九成是内网源地址不对或 GPG 公钥缺失，换源后先 makecache 验证。第五类时间类：证书校验失败、数据库复制异常，先 date 和 chronyc sources 查时间同步。第六类句柄类：Too many open files，按三层查——会话 ulimit、limits.conf、systemd 的 LimitNOFILE（最高频的坑：改了 limits.conf 对 systemd 服务不生效）。这套分类法让我在客户现场基本能做到"听完现象就有一个假设，两条命令验证"。

追问链：

• 追问1：删了日志 df 空间没变，怎么回事？ → 答：因为 rm 只删目录项，进程持有的文件描述符还在，inode 没释放，进程还继续往已删除的 inode 里写。lsof | grep deleted 找到持有句柄的进程，低峰期重启它空间才回来；如果不能重启，可以对 /proc/PID/fd/N 做清空应急。正确姿势从一开始就是：活跃日志用 > file 截断或者 logrotate 的 copytruncate，我交付的规范里明确写"活跃日志禁止直接 rm"——这条在银行现场真实处理过，全程二十分钟。
• 追问2：客户现场"装到一半 yum 报错装不下去了"怎么办？ → 答：先看报错类型：404 类是源地址不对，换成厂商内网源或挂 ISO 当源；GPG 校验失败导入厂商公钥；依赖冲突（CentOS 装 MySQL 碰到 mariadb-libs 是经典）先卸冲突包再装；完全无网的机器直接走离线 rpm/deb 或二进制包。我的习惯是把这台机器"能用哪个源、哪些包要离线"记进项目环境清单——同一个客户的机房，下次进场直接照单准备，不用现场再摸一遍。
• 追问3：新装机器 ssh 都连不上，怎么入手？ → 答：按链路分层：先 ping 通不通——通不了查 IP 配置、网关、交换机端口和 VLAN（虚拟机还要查端口组挂的对不对，这是第 8 章的虚拟化层排查）；ping 通 ssh 不通，查 sshd 起没起（通过带外或控制台进去 systemctl status sshd）、查 22 端口防火墙有没有放行、查 AllowUsers 限定。物理机我有 iBMC 兜底，虚拟机有 VNC 控制台，所以"无论如何能拿到屏幕"是实施的基本保障——这也是我坚持所有机器带外/控制台先通的原因。
• 追问4（深挖）：有没有遇到过"同样的安装步骤，这台行那台不行"？ → 答：遇到过，这恰恰是环境一致性的价值。我的排查思路是"对照法"：两台机器逐项 diff——ip a、路由、DNS、软件源、内核参数、防火墙状态、时间同步，一边对一边排，差异点基本就是根因。常见根因是某台机器手工改过配置或者初始化脚本某次跑失败没被发现。自从我把初始化做成幂等脚本加每台留档摘要之后，这类"灵异差异"在我这基本绝迹了——与其排查差异，不如消灭差异。

关联话术："这些环境问题我基本都在客户现场真踩过：磁盘满清过 BCS 日志、yum 源换过麒麟内网源、TLS 认证失败追到时间不同步。我的成长路径是把每个坑变成 checklist 里的一行——部署指南的'常见问题'一节就是这么攒出来的，后来同事进场照着文档就能避掉我踩过的坑，这也是文档能成为公司标准的原因之一。"

实操模板（环境问题速查卡，可背）：

df -h && df -i                        # 空间满 / inode 满
lsof | grep deleted                   # 删了不释放 → 句柄
dmesg -T | grep -iE 'error|ro'        # 只读盘 / 硬件报错
ping 网关 && nslookup 域名            # 链路 vs DNS
yum makecache || apt update           # 软件源验证
date && chronyc sources               # 时间同步
cat /proc/$(pgrep -f app|head -1)/limits | grep open  # 服务句柄实际限制

1.7 统信 UOS / 麒麟 V10 与 ARM 架构实践 【必背】

标准回答：先给背景一句话：信创要求金融、政企从芯片到软件全栈国产替代，所以我在银行项目整套环境都是国产的——这也是实施版简历最硬的差异化。主流两家血缘要分清：麒麟 V10 服务器版基于 openEuler/CentOS 系，操作习惯和 yum 生态接近 CentOS；统信 UOS Server 20 基于 Debian 系，包管理是 apt。对实施来说两家系统 95% 的操作和主流发行版一致，差异集中在：软件源要用厂商内网源或镜像站、很多商业软件要拿厂商适配包、包名经常带 kylin、aarch64、kunpeng 这类标识。银行项目实际是两家混用：业务虚机跑统信 UOS，数据库节点跑麒麟 V10 SP1——因为 Vastbase 的安装包就是 kylin_v10sp1-aarch64_kunpeng 专用包，"同一平台两家混用很常见，关键是把版本配套表对齐"这句话在面试里说出来比站队任何一家都专业。ARM 架构我整栈用了近两年，四条铁律：第一 uname -m 确认 aarch64，所有包选 aarch64 专用版本；第二当时 Docker 没有仓库版，用 aarch64 静态二进制包解压安装；第三所有容器镜像必须 arm64 版本，内网拉不了就 docker load 离线导入，我写过批量加载脚本；第四源码编译（Redis、Nginx）先确认 ARM 依赖库齐全。内核参数、防火墙、systemd 这些与 x86 完全一致，心智负担不大。

追问链：

• 追问1：UOS 和麒麟怎么选型？ → 答：选型是客户信创目录和华为配套体系决定的，我们公司是华为渠道商，我负责按配套表落地。我的经验是实施工程师不要纠结"哪家好"，而要管好"配套对齐"：OS 版本、数据库安装包、JDK、中间件的适配认证要能对上，我在项目里维护的就是这张配套表，进场前核对一遍，比现场返工省几天时间。国产 OS 的产品层细节（产品矩阵、迁移对照）见华为篇第 6 章，面试深挖再去拿。
• 追问2：ARM 上踩过最深的坑？ → 答：镜像架构不匹配。在 aarch64 节点上 load 了 x86 镜像，容器一起就报 exec format error，因为指令集根本不一样。那次之后我把"镜像架构清单提前验证"固化成流程：交付前用 docker inspect --format '{{.Architecture}}' 把每个镜像过一遍，统一离线导入，后面再没出过。踩坑变流程，是我做实施最大的习惯——坑不可怕，同一个坑踩两次才可怕。
• 迭问3：信创环境装软件的通用思路？ → 答：按优先级三步走：第一优先厂商适配包（rpm/deb，内网源拿，兼容最好）；第二选同架构静态二进制包，解压即用，Docker 就是这么装的；最后才源码编译，编译前确认 ARM 依赖库齐不齐。最忌讳把 x86 的包直接拷过来用——报错还查半天。这套优先级我在银行内网验证了两年，也写进了部署指南的"软件获取"一节。
• 追问4（深挖）：ARM 和 x86 本质区别？ → 答：本质是指令集架构：ARM 是 RISC 精简指令集，x86 是 CISC 复杂指令集，鲲鹏属于 ARMv8 的 aarch64。对实施的实际影响一句话——"一切二进制和镜像都要同架构"：编译型二进制和容器镜像必须匹配，应用层 jar、Python 脚本这类解释型或字节码的可以跨架构。微架构级流水线差异我理解到这层就到边界了，更深如实说会后补——国产化话题面试官可能很懂，边界感尤其重要。

关联话术："这是我简历上最实的差异化：4 台 TaiShan 鲲鹏服务器加 15 台 UOS/麒麟虚拟机，从 iBMC 装机、分区规划到 ARM 版 K8s 集群上线全链路是我做的。面试我会说：'国产化环境一次装通、装稳、装到能交付'这件事我真做了近两年——这在三年经验的实施工程师里不算多见。"

实操模板：

cat /etc/os-release && uname -m          # 确认发行版与架构
# ARM 批量离线导入镜像（项目一实际脚本核心）
for f in /opt/images/*.tar.gz; do
  case "$f" in *edge-manager*) continue;; esac   # 排除管理面镜像
  cat "$f" | docker load
done
docker inspect <镜像> --format '{{.Architecture}}'  # 验证 arm64

1.8 安全加固基线（交付版） 【必背】

标准回答：安全加固我按四块讲，这也是我交付时的检查单——银行客户环境是逐条被扫描验证过的。第一块 SSH：PermitRootLogin no 禁 root 直连、改密钥登录、MaxAuthTries 4 限制试错、AllowUsers 白名单；改完 restart sshd 前一定先留一个已登录会话防锁死——这条是现场纪律，把自己锁在客户机器外面是实施大事故。第二块密码策略：/etc/login.defs 里 PASS_MAX_DAYS 90 天过期、最短 8 位，复杂度用 pam_pwquality 强制大小写数字符号。第三块防火墙：麒麟/CentOS 用 firewalld，--permanent --add-port 之后必须 --reload 才落盘（忘了 reload 重启丢规则是最高频的坑）；UOS/Ubuntu 用 ufw。交付期的策略我一般分两步：部署期按需放行保进度，验收前统一收口成白名单并出一份端口清单给客户安全团队对账。第四块 SELinux：银行按客户要求开 enforcing，排障期临时 permissive 走变更流程记录；再叠加审计项——last/lastb 看登录、/var/log/secure 盯失败登录、SUID 文件基线比对。这套基线的价值在于"可交付"：每条对应客户检查项，验收材料里能逐条应答。

追问链：

• 追问1：firewalld 忘了 --reload 会怎样？ → 答：规则只进了内存运行态，看起来生效了但一重启就丢。正确顺序 firewall-cmd --permanent --add-port=X/tcp 再 firewall-cmd --reload。我给客户开端口后有"过几分钟 firewall-cmd --list-ports 复核"的习惯，联调通了的端口第二天莫名不通，第一个就该想到这个——现场联调排障这条排查顺序我给同事讲过不止一次。
• 追问2：生产 SELinux 开还是关？ → 答：分环境回答，两种我都真实执行过。银行客户环境按客户基线执行，要求开就 enforcing，应用不兼容走变更申请切 permissive 并记录；内部和部署期环境我一般先关，因为 K8s 组件、容器挂载在 SELinux 下配置复杂度高，上线后靠防火墙最小化放行、密钥登录兜底。不会一刀切说必须开或必须关——能讲清取舍本身就是答案的一部分。
• 迭问3：交付时安全加固怎么和进度平衡？ → 答：我的做法是"分层收口"：部署期只做不阻碍实施的最低配置（口令策略、不锁死自己的 SSH 纪律）；联调期端口按需放行并登记；验收前统一收口——防火墙白名单、root 禁登、密钥替换、SUID 基线归档，一次做完一次验证，出《安全基线核查表》进验收材料。这样既不拖部署进度，也不会最后一刻发现一堆加固没做——把加固当交付里程碑管理，而不是散在各处的杂事。

实操模板（交付加固速查）：

# SSH（改完先留会话再重启）
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
# firewalld 白名单
firewall-cmd --permanent --add-port=6443/tcp && firewall-cmd --reload
firewall-cmd --list-ports                              # 复核
# SUID 基线
find / -perm -4000 -type f 2>/dev/null > suid_$(date +%F).txt

1.9 磁盘分区、LVM 与 RAID（装机视角） 【理解】

标准回答：分区分两套工具按容量分：小于 2TB 用 fdisk 走 MBR；大于 2TB 必须用 parted 走 GPT。标准流程：lsblk 认盘 → 分区 → mkfs.ext4 或 mkfs.xfs 格式化 → mount 临时挂载，确认后写 /etc/fstab，设备列用 UUID 不用 sdb1 这种名字——设备名在插拔重启后可能漂移，UUID 是格式化时生成的唯一标识。写完 fstab 必须 mount -a 验证——能过 mount -a 重启才敢保平安，写错 fstab 重启进紧急模式是经典事故，我在现场处理过，进单用户把错误行注释掉救回来。LVM 是在物理盘上加三层抽象做弹性：pvcreate → vgcreate → lvcreate，扩容在线做：lvextend -L +10G 再 resize2fs（ext4）或 xfs_growfs 挂载点（xfs，注意参数是挂载点不是设备名，和 ext4 正好相反，高频手写陷阱）。RAID 是多盘冗余：RAID1 镜像保系统盘、RAID5 平衡容量冗余、RAID10 数据库首选——银行项目 TaiShan 2280 不带 RAID 卡，我按华为配套文档做软 RAID：两块 600G SAS 系统盘 RAID1、3.84T SSD 数据盘 RAID5，这个规划直接影响 Vastbase 的 IO 表现，详见第 8 章 8.9。

追问链：

• 追问1：为什么 fstab 用 UUID？ → 答：内核枚举设备顺序不保证稳定，sda/sdb 重启或插拔后可能互换，写设备名可能挂错盘轻则紧急模式重则数据写错位置。UUID 用 blkid 查，和物理顺序解绑。磁盘变更里成本最低收益最明确的一条规范，我所有交付的 fstab 一律 UUID。
• 迭问2：xfs 和 ext4 怎么选？ → 答：通用场景 ext4 稳；数据库、虚拟化存储、大日志盘用 xfs——擅长大文件高并发并行 IO，CentOS 7 后也是默认。注意 xfs 只能扩不能缩。我的分区模板里根分区 xfs、按负载给数据库数据盘单独划卷，这个选型逻辑我在《部署指南》里写明了理由——交付文档不只写"怎么做"还要写"为什么"，客户的技术评审才过得去。

1.10 性能定位链路（压缩一）：top / vmstat / iostat / free 四步 【必背】

标准回答：性能定位我有一套固定的四步链路，从宏观往微观走，这是我在银行驻场两年每天巡检攒出来的。第一步 top 加 uptime 看负载和 CPU 分布——load average 相对核数看，8 核机器 load 长期 6 以上就偏高；再看 us、sy、wa、id 四个值，us 高是应用在算、wa 高是 CPU 在等磁盘，方向完全不同。第二步 vmstat 1 看节奏：r 是等 CPU 的进程数、b 是阻塞数，si/so 是 swap 换入换出，只要不是 0 就说明内存有压力。第三步 iostat -x 1 下钻磁盘：%util 接近 100% 说明盘满负荷，await 是每次 IO 平均等待毫秒数，机械盘上几十毫秒就明显偏慢。第四步 free -h 看内存，重点看 available 这一列——它才是应用真正能用的量，buff/cache 是内核缓存、需要时自动让出，不算浪费。进程级补充 iotop 看哪个进程吃 IO。目标就是用最少的命令把瓶颈归到 CPU、内存、磁盘 IO、网络四类之一——实施场景里这套链路最常用在"环境验收前的健康检查"和"客户反馈慢的第一轮定位"，定位出瓶颈类别，才知道是环境问题还是应用问题，要不要找开发或原厂。

追问链：

• 追问1：free 里 buff/cache 占很大要不要清？ → 答：不要清。这是内核拿空闲内存做页缓存，应用要内存时自动回收。人为 echo 3 > drop_caches 反而把热缓存打掉，下个高峰 IO 猛涨。判断内存够不够只看 available，哪怕 free 接近 0、available 大就还有余量——这个判断口径我在给客户做环境验收报告时都写在里面，避免客户看着 free 列紧张。
• 迭问2：load 高但 CPU idle 也高，什么问题？ → 答：经典陷阱。load 统计"可运行加不可中断睡眠"的进程数，大量进程卡 D 状态等 IO 时把 load 推高但 CPU 没在算。这时候要看 iostat 的 %util/await、查存储链路和 NFS。这个组合现象一出现，方向就要从 CPU 转向磁盘和存储——答出这个说明真排过，不是背指标。
• 迭问3：8 核机器负载多少告警？ → 答：load 接近 8 就是满载，告警我按两档配：持续超过核数的 0.7 倍也就是 5.6 左右触发 warning，到 1 倍即 8 触发 critical。这个分档是兼顾"提前发现"和"不误报"的经验值——单看 load 还不够，要结合 us/wa 分布一起判断才能定性。移动云项目接 Prometheus 告警时我就是按这个梯度配的规则，配完还拿压测验证过阈值会不会误报，避免告警疲劳。

实操模板（性能四步，背熟）：

uptime; top -bn1 | head -15
vmstat 1 5
iostat -x 1 5
free -h

1.11 性能问题定位（压缩二）：CPU 高与内存 swap 合并处理 【理解】

标准回答：CPU 高的定位四步链路：top 按 P 排序找到进程 → 分型看 us 还是 wa（us 高是应用真算，wa 高是磁盘拖累，方向完全不同）→ top -Hp PID 看哪个线程 → Java 用 printf '%x\n' TID 转十六进制配 jstack 定位到代码行，非 Java 用 strace/perf。我在移动云集群跑通过完整一次：Grafana 告警某节点 CPU 高，定位到业务 Pod 里 Java 进程一段死循环，线程栈丢给开发十分钟改完——运维实施没写那行代码，但问题是精确递过去的。内存侧重点讲 swap：物理内存吃紧时内核把不活跃页换到磁盘，代价巨大；K8s 节点必须禁用，标准三连：swapoff -a、注释 fstab 的 swap 行、vm.swappiness=0 双保险。判断内存紧张看 available 不看 free；应急内存不足：ps 按 %mem 排序找大户、泄漏先重启止血（重启前留 jmap dump 现场）、dmesg | grep -i kill 查 OOM 记录。这套是"环境交付后客户说慢"的标准第一轮动作。

追问链：

• 迭问1：kill -15 和 kill -9 生产先发哪个？ → 答：一定先 15。15 给进程收尾机会——刷盘、释放锁；等几秒不退再 9。数据库这类有事务和缓冲池的程序绝不能上来 kill -9，强杀是数据文件损坏最常见成因之一。我在银行现场规范里明确写了"禁止对数据库进程 kill -9"，后端 jar 的标准重启动作（15 → sleep 5 → 确认退出 → 再启动）我写成了脚本进部署指南。
• 迭问2：为什么 K8s 要禁 swap？ → 答：三个原因：kubelet 的调度和驱逐模型建立在"容器内存 limit 是确定值"上，swap 让可用内存不确定、驱逐误判；swap 命中带来的不可控 IO 等待拖慢同节点所有 Pod；kubelet 1.28 及之前默认检测到 swap 拒绝启动。所以初始化脚本里"关 swap"永远是第一条——这条写进了我移动云项目的 9 项避坑清单配套基线。
• 迭问3：内存不足应急顺序？ → 答：先找大户区分页缓存还是进程 RSS 真涨；泄漏先重启止血、重启前留现场（dump 或 /proc 信息）给开发；再查 dmesg 的 OOM 记录对时间点。原则"先保业务再查根因，重启前必须留现场"——这个顺序我在客户现场执行过，客户最认的就是"你处理时没有丢证据"。

1.12 内核参数与 ulimit（交付基线参数） 【理解】

标准回答：这两项是我初始化基线里的固定段落，属于"不调好，上层软件会出现灵异问题"的那类。内核参数必调组：net.ipv4.ip_forward=1 开转发——节点上的容器流量要跨网段，不开跨节点 Pod 不通；net.bridge.bridge-nf-call-iptables=1 让网桥流量过 iptables——不开 Service 的 ClusterIP 转发不通，它依赖 br_netfilter 模块要先 modprobe 并写进 modules-load.d；vm.swappiness=0；数据库和 K8s 节点还会配 fs.file-max、net.core.somaxconn、关透明大页 THP。统一放 /etc/sysctl.d/ 分模块管理，sysctl --system 生效后逐条查询验证——我初始化完的验收动作就是跑一组 sysctl 查询并截图留档。ulimit 是进程级限制，最常调打开文件数 -n：默认 1024，高并发服务轻松超掉报 Too many open files。调整分三层，这是核心结构：会话级 ulimit -n；用户级 limits.conf 写 soft/hard nofile；systemd 服务不读 limits.conf，必须 unit 里写 LimitNOFILE 再 daemon-reload——最高频的坑，很多人改了 limits.conf 服务还报错就在这。系统级总量另有 fs.file-max。排查用 cat /proc/PID/limits 看进程实际限制——比猜配置靠谱。

追问链：

• 迭问1：改了 sysctl 不生效怎么查？ → 答：第一 sysctl --system 看完整加载过程——按目录和文件名顺序加载，后加载的覆盖前面的，可能被优先级更高的文件盖掉；第二 bridge 参数先确认 br_netfilter 已加载并写进 modules-load.d，模块没起来参数根本不存在；第三 sysctl -a | grep 参数 看运行时真实值。三步查完，"参数没生效"基本都有着落。
• 迭问2：limits.conf 改了服务还是报 Too many open files？ → 答：因为 limits.conf 通过 PAM 在用户登录时生效，systemd 拉起的服务走 unit 自己的资源体系不经登录流程。解法：unit 的 [Service] 段写 LimitNOFILE=65535，daemon-reload 加 restart。我写每个交付组件的 unit 都预置这一行——从坑里带出来的肌肉记忆。

实操模板（基线参数文件，可背）：

# /etc/sysctl.d/99-base.conf
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-iptables = 1
vm.swappiness = 0
fs.file-max = 2097152
net.core.somaxconn = 4096

modprobe br_netfilter && echo br_netfilter > /etc/modules-load.d/br.conf
sysctl --system && sysctl net.ipv4.ip_forward   # 生效+验证

1.13 日志体系与 logrotate（交付即配） 【理解】

标准回答：Linux 日志三层分工我一句话讲：rsyslog 管汇总外送、journald 管服务排障、logrotate 管不涨爆磁盘。对实施工程师，重点是第三层——"交付任何组件，logrotate 配置同步交付"，这是我的固定习惯，不给客户留地雷。logrotate 配置在 /etc/logrotate.d/ 下按服务写：daily 轮转、rotate 14 保留份数、compress 压缩旧档、dateext 带日期后缀；关键分两种模式：支持重开日志文件的程序（nginx）用 postrotate 钩子执行 nginx -s reload 让 master 重开新文件；不支持切换句柄的程序用 copytruncate——先拷贝再原地清空，进程无感，代价是拷贝清空瞬间可能丢少量日志。选型逻辑一句话：支持 reopen 的用 reload，不支持的用 copytruncate。journald 侧配 SystemMaxUse 限额（1.12 已说）。银行客户有日志集中审计要求时我还配过 rsyslog 外送——交付时把"日志怎么轮转、保留多久、是否外送"三件事写进运维交接文档，客户接手才不慌。

追问链：

• 迭问1：正在被写的日志能直接 rm 吗？ → 答：不能。rm 只删目录项，进程句柄还在，空间不释放还丢了查看入口。正确做法：> file 截断（空间立刻释放且进程不受影响）或 copytruncate 轮转。我交付规范里写明"活跃日志禁止直接 rm"，1.6 的经典故障就是这条的实战注脚。

实操模板（logrotate 样例，可默写）：

/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    dateext
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && nginx -s reload
    endscript
}

1.14 系统初始化基线脚本（交付资产） 【必背】

标准回答：这是我把两个项目交付经验沉淀成的"新节点十分钟标准化"脚本，也是我面试时必讲的交付资产。固定清单：主机名与 hosts 解析、时区与 chrony 时间同步、关 swap（swapoff 加注释 fstab）、防火墙与 SELinux 按基线处理、内核参数 sysctl.d、句柄限制 limits.conf、journald 限额、必要基础包安装。工程上三个硬要求：一是幂等可重跑——跑多少遍结果一致，配置用"先删后写"或条件判断避免重复追加，这是脚本能批量铺的前提；二是日志留痕——exec 重定向让全部输出落文件，出问题可回溯，每台机器的初始化日志归档进交付材料；三是收尾自检——脚本最后自动打印 df、free、时间同步状态、关键参数值的摘要，我拿它当每台机器的"验收截图"。这个脚本在移动云项目固化出来，7 台节点十分钟一台；公司后续外包项目的新集群初始化直接复用它。我讲这个故事想表达的是实施工程师的核心价值：把一次性的手工劳动变成可复制的交付资产——这也是简历上"输出文档成为公司同类项目标准"的具体支撑之一。

实操模板（初始化脚本核心段，可背）：

#!/bin/bash
# init_node.sh —— 新节点标准化初始化（幂等，Ubuntu/CentOS 通用思路）
set -euo pipefail
LOG=/var/log/init_node.log; exec >>$LOG 2>&1

hostnamectl set-hostname "$1"                     # $1 主机名
timedatectl set-timezone Asia/Shanghai
systemctl enable --now chronyd || systemctl enable --now ntp

swapoff -a && sed -ri 's/^(.*\sswap\s.*)/#\1/' /etc/fstab
systemctl disable --now ufw 2>/dev/null || systemctl disable --now firewalld
setenforce 0 2>/dev/null || true
sed -ri 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config 2>/dev/null || true

modprobe br_netfilter && echo br_netfilter >/etc/modules-load.d/br.conf
cat >/etc/sysctl.d/99-base.conf <<'EOF'
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-iptables = 1
vm.swappiness = 0
fs.file-max = 2097152
EOF
sysctl --system >/dev/null

grep -q 'soft nofile' /etc/security/limits.conf || cat >>/etc/security/limits.conf <<'EOF'
* soft nofile 65535
* hard nofile 65535
EOF

echo "==== init done: $(date) ===="
df -h | head -3 && free -h | head -2 && chronyc sources | head -5   # 摘要留档

面试手写写到 sysctl 段即可拿满分；必讲的三个点是幂等、日志留痕、收尾自检。

1.15 本章案例

• 【真实项目】（银行·移动云）全节点标准化初始化落地：背景是移动云新集群 7 台节点必须环境完全一致——过往"逐台手配漏一项、排查半天"的教训太多。任务是我编制初始化方案并固化成幂等脚本加核对清单。行动三步：先在监控节点试跑验证，再全节点统一执行，最后逐节点跑验收命令组截图留档；其中时间同步用 chrony 指内网 NTP，专门解决了"节点时间不同步导致 TLS 认证失败"的问题（9 项避坑清单之一）。结果：节点初始化从半天缩到分钟级，脚本成为公司外包项目标准底座的一部分——这是我从"逐台手配"转向"标准化交付"的标志性产出。（STAR 完整版见第 12 章 P2-2）
• 【真实项目】（银行）ARM 环境镜像架构治理：背景是内网 ARM 节点加载镜像后容器报 exec format error。任务是把十几个 BCS 数据面镜像正确铺到 9 个节点。行动：确认根因是 x86 与 arm64 指令集不匹配，建立"镜像架构清单"逐个用 docker inspect 验证 Architecture 字段，再用批量脚本（case 排除管理面专用镜像）统一离线导入。结果：数据面节点一次铺通，BCS 纳管如期完成，"清单先行"的方法论后来被我用到所有离线交付场景。
• 【课程项目】CPU 飙高排查实验：实验环境模拟 Java 进程死循环把 CPU 打到 400%，按"top 按 P 排序找到进程 → 分型看 us/wa → top -Hp 找线程 TID → printf 转十六进制 → jstack 按 nid 定位到具体方法行"完整走通一遍，中途还对照观察了 CPU 400% 是多线程合计的正常现象、load 高但 idle 高的 IO 等待假象这两个经典陷阱。价值是把 1.11 的四步法从"背过"变成"做过"——面试描述时我能说出每一步屏幕上实际是什么输出，这种细节可信度是背题给不出来的。
• 【经典故障】删了日志 df 空间不释放：清理大日志后 df -h 没变。定位：lsof | grep deleted 发现日志进程仍持有已删文件句柄。解决：低峰重启服务释放。预防：所有日志统一 logrotate 的 copytruncate，规范写明"活跃日志禁止直接 rm"——我在银行现场真实处理过，全程约二十分钟，这个案例我最常用来证明"基础功扎实"。

章末自测清单（快问快答）

1. 装机前必先有的两份东西？ → 《IP 规划表》和分区方案（规划先行）。
2. ARM 机器用什么镜像？ → aarch64 镜像，uname -m 确认。
3. 数据库节点分区要注意什么？ → 数据盘/日志盘/归档盘分开，/data 单独分区。
4. 装完系统第一件事？ → 主机名/hosts/IP/DNS/时间同步/软件源——基线七项，不绿不装上层。
5. 端口占用怎么查？ → ss -lntup | grep :端口，一步拿进程名和 PID。
6. No space 有哪三种"满"？ → 空间满（df -h）、inode 满（df -i）、删除未释放（lsof | grep deleted）。
7. Read-only file system 第一步查什么？ → dmesg 看磁盘 IO 报错，应急 remount,rw。
8. systemd 服务的句柄限制写哪里？ → unit 里 LimitNOFILE（limits.conf 对 systemd 服务不生效）。
9. 麒麟 V10 和统信 UOS 分别基于什么系？ → 麒麟 openEuler/CentOS 系（yum），UOS Server Debian 系（apt）。
10. ARM 节点装 x86 镜像报什么错？ → exec format error。
11. firewalld 开端口两条命令？ → --permanent --add-port 后必须 --reload。
12. fstab 为什么用 UUID？ → 设备名会漂移，UUID 稳定；写完必跑 mount -a。
13. xfs 扩容命令参数是什么？ → xfs_growfs 挂载点（不是设备名，与 resize2fs 相反）。
14. K8s 禁 swap 三连？ → swapoff -a、注释 fstab、vm.swappiness=0。
15. 初始化脚本三个工程要求？ → 幂等可重跑、日志留痕（exec 重定向）、收尾自检摘要。
16. 活跃日志能直接 rm 吗？ → 不能，用 > file 截断或 logrotate copytruncate。