运维工程师一面复盘：上线流程、Docker 与 Linux 基础

面试方向#

这次主要围绕几个方向展开：

1. 个人 PVE 环境和 Linux 发行版选择；
2. 实习项目里的服务部署、镜像构建和上线方式；
3. Nginx、Docker、Linux 命令和网络排障；
4. Shell 脚本能力；
5. Kubernetes 基础概念；
6. 运维规范、安全、备份和回滚。

面试官比较关注“真实做过什么”。如果只是背命令，或者把个人项目流程说成成熟生产流程，很容易被追问出问题。

PVE 与 Linux 发行版#

面试官先问了我的个人 PVE 环境，以及虚拟机里一般会选择哪些发行版。

这类问题主要是在判断：

• 是否真的有自己的服务器环境；
• 是否理解不同 Linux 发行版的差异；
• 是否有部署和维护服务的经验；
• 是否知道为什么选某个系统。

更稳妥的回答方式是：

我自己的 PVE 环境主要用于模拟真实运维场景，会跑多台 Linux 虚拟机，用来练习 Docker 服务部署、远程访问、监控和故障排查。

发行版选择上，Debian / Ubuntu 更适合长期服务部署，稳定、文档多；CentOS / RHEL 系更贴近企业服务器环境；Fedora / Arch 更多用于个人学习和新技术验证。选择时主要看软件包生态、维护周期、服务端稳定性、生产环境匹配程度，以及后续排障和维护成本。

这部分不要只说“我用过很多发行版”，要把选择依据说出来。

项目上线经历#

面试官重点追问了实习阶段的项目经历，包括：

• 做了哪些内容；
• 负责哪一部分；
• 项目怎么上线；
• 代码如何发布；
• 镜像如何构建和更新；
• 更新过程是否安全；
• 备份和回滚怎么做。

我当时讲的是：代码提交到 GitHub，通过 GitHub Actions 构建 Docker 镜像，服务器侧用容器部署，早期使用过 Watchtower 监测镜像更新。

这个流程可以跑通，但在企业面试里会暴露几个风险：

更合适的表达不是把它包装成成熟生产流程，而是诚实说明它偏小团队或项目制环境：

这段经历更偏小团队项目实践，不是非常标准化的大厂生产流程。我主要参与的是服务部署、镜像构建、上线协助和基础运维。

当时通过 GitHub Actions 构建 Docker 镜像，服务器侧使用容器方式部署。早期为了方便更新，用过自动检测镜像更新的方式，但后来我意识到生产环境更推荐固定版本号、测试环境验证、人工确认发布，并保留回滚版本。

如果放到更规范的企业环境，我会设计成：CI 执行测试和构建，镜像使用明确版本号，先在测试环境验证，生产发布前备份数据库、配置文件和数据卷，发布后检查日志、接口和监控，异常时回滚到上一稳定版本。

这里关键不是“显得很厉害”，而是让面试官看到风险意识和成长过程。

规范上线流程#

后续可以准备一版更工程化的上线流程：

1. 开发提交代码；
2. CI 执行测试和构建；
3. 构建带版本号的镜像；
4. 推送到镜像仓库；
5. 测试环境部署验证；
6. 发布前备份数据库、配置文件和关键数据卷；
7. 生产环境按明确版本发布；
8. 检查日志、接口、健康检查和监控；
9. 如果异常，回滚到上一稳定版本；
10. 记录变更内容和问题复盘。

如果面试官继续追问 Watchtower，可以这样答：

Watchtower 更适合个人服务或低风险轻量服务，不适合直接作为生产环境无人值守更新方案。生产环境更需要版本锁定、审批、灰度、备份、健康检查和回滚。即使使用自动化，也应该让流水线按明确版本发布，而不是容器发现新镜像后自动重建。

备份与回滚#

我这次回答里比较薄弱的一点是备份。只说“自动备份，可以回档”太模糊。

更完整的备份回答应该包括：

可以这样说：

备份要先明确对象，比如数据库、配置文件、上传文件和 Docker volume。发布前可以做一次手动备份，平时做定时备份，并设置保留策略。备份最好不要只放本机，也要考虑异地备份或对象存储。最重要的是恢复测试，否则不能证明备份真的可用。回滚时不仅要回滚镜像版本，还要考虑数据库结构和数据是否兼容。

Nginx#

面试官问了 Nginx 的功能，以及是否有反向代理实践。

我答到了静态网站和反向代理，但漏掉了负载均衡。

Nginx 常见用途包括：

• 静态资源服务；
• 反向代理；
• 负载均衡；
• HTTPS / TLS 终止；
• 请求转发；
• 访问控制；
• 限流；
• 日志记录；
• 缓存；
• gzip 压缩。

反向代理示例：

1
server {
2
    listen 80;
3
    server_name example.com;
4

5
    location / {
6
        proxy_pass http://127.0.0.1:8080;
7
        proxy_set_header Host $host;
8
        proxy_set_header X-Real-IP $remote_addr;
9
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
10
    }
11
}

负载均衡示例：

1
upstream backend {
2
    server 192.168.1.10:8080;
3
    server 192.168.1.11:8080;
4
}
5

6
server {
7
    listen 80;
8
    server_name example.com;
9

10
    location / {
11
        proxy_pass http://backend;
12
    }
13
}

更好的回答是：

Nginx 常见用途包括静态资源服务、反向代理、负载均衡和 HTTPS 证书终止。我自己主要用过静态站点部署和反向代理，比如把外部访问的域名转发到后端本地端口。反向代理可以隐藏后端服务端口，统一管理域名、证书和访问入口。如果是多台后端服务，也可以通过 upstream 做负载均衡。

top 与进程查看#

面试官问了 top 如何按 CPU / 内存占用排序。

这次我没有答出 top 内部快捷键，只用 ps aux 替代了。

需要记住：

替代命令也要会：

1
ps aux --sort=-%cpu | head
2
ps aux --sort=-%mem | head

面试里可以回答：

如果用 top，可以按 P 按 CPU 占用排序，按 M 按内存占用排序，按 1 查看每个 CPU 核心的使用情况。如果不用 top，也可以用 ps aux --sort=-%cpu | head 查看 CPU 占用最高的进程，用 ps aux --sort=-%mem | head 查看内存占用最高的进程。

网络排障#

面试官问了类似“如果 www.baidu.com 访问不了，怎么排查”。

我回答到了换设备、ping、dig 和 DNS，但没有系统化展开，也漏了在线多地域测试。

更完整的排查顺序是：

1
ip addr
2
ip route
3
ping 网关IP
4
ping 8.8.8.8

1
nslookup www.baidu.com
2
dig www.baidu.com
3
cat /etc/resolv.conf

1
curl -I https://www.baidu.com
2
curl -v https://www.baidu.com

1
traceroute www.baidu.com
2
mtr www.baidu.com

查看端口对应服务#

面试官问如何查看某个端口上运行了什么服务。

我答了：

1
lsof -i:80

面试官补充了 ss。

新系统里更推荐先用 ss：

1
ss -lntp
2
ss -lntp | grep :80

也可以用：

1
lsof -i:80
2
netstat -lntp

回答可以更简洁：

我一般用 ss -lntp 查看当前监听的 TCP 端口和对应进程，也可以用 lsof -i:端口号 查看某个端口被哪个进程占用。现在新系统里更推荐用 ss。

Docker 数据持久化#

面试官问 Docker 的两种数据存储方式，以及区别。

常见答案是：

• volume；
• bind mount。

1
docker run -v mydata:/data nginx

1
docker run -v /host/path:/container/path nginx

Shell 脚本#

这部分我当时表达得不够准确，容易让人理解成“Shell 命令也不熟”。

实际情况应该拆开说：

• 单条命令和常见命令组合有基础；
• 完整 Shell 脚本组织能力还需要补；
• 复杂脚本可以借助 Agent，但必须自己审查命令含义和执行风险。

更合适的表达是：

Shell 单条命令和常见命令组合我有一定基础，比如日志筛选、进程查看、磁盘检查、服务状态查看这些都能用。但我完整写 Shell 脚本的经验还不多，目前主要在补变量、判断、循环、函数、错误处理和脚本规范。

如果是实际运维场景，我一般会先把核心命令跑通，再逐步封装成脚本，比如加阈值判断、日志输出、退出码和定时任务。复杂脚本我也会借助 Agent 辅助生成，但会自己检查命令含义、执行路径、权限风险和是否有误删风险，不会直接复制到生产环境执行。

后续重点补这些内容：

• 变量和参数；
• if 判断；
• for / while 循环；
• 函数封装；
• 日志输出；
• 退出码；
• set -euo pipefail；
• cron 定时任务；
• 文件路径和权限风险。

基础命令也要熟：

1
df -h
2
df -i
3
du -sh *
4
systemctl status nginx
5
systemctl is-active nginx
6
journalctl -u nginx
7
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head
8
find /data/backup -mtime +7 -delete

Kubernetes#

面试官也问到了 Kubernetes。

我当时说还在学习中，但其实一些基础概念之前接触过，只是临场没有展开。

后续可以准备一个诚实但不空的回答：

Kubernetes 我目前还在学习和实践阶段，接触过 k3s、Pod、Deployment、Service、Ingress、Helm 和 Prometheus 监控相关内容。虽然还没有生产级经验，但理解它的基本作用是对容器进行编排、调度、服务发现、滚动更新、扩缩容和故障自愈。

基础概念要能说清：

简答模板：

Kubernetes 是容器编排平台，用于管理容器的部署、调度、扩缩容、服务发现、滚动更新和故障自愈。Pod 是最小调度单位，Deployment 管理 Pod 副本和滚动更新，Service 给 Pod 提供稳定访问入口，Ingress 暴露 HTTP / HTTPS 服务，ConfigMap 和 Secret 管理配置。我目前接触过 k3s、Helm、Service、Deployment 和 Prometheus 监控，还没有生产级经验，但这是我后续重点补强方向。

这次暴露的问题#

这场面试暴露出一个核心问题：

真实实践不少，但表达还不够工程化、规范化。

具体包括：

1. 项目上线流程说得太草率，容易被认为不懂生产规范；
2. Watchtower 自动更新没有主动说明风险；
3. 备份和回滚没有讲清对象、策略和恢复验证；
4. top、ss、Docker 权限差异等基础点答得不完整；
5. Kubernetes 本来接触过，但没有在面试中展开；
6. Shell 需要补到能读懂和修改常见运维脚本。

优势也有：

• 有 PVE 和虚拟化环境；
• 有 Linux、Docker、Nginx 实践；
• 能讲出真实排障经历；
• 对运维方向兴趣明确；
• 能承认不足并复盘；
• 面试官对 Agent 辅助脚本并不排斥。

后续复习优先级#

1
top
2
ps aux --sort=-%cpu
3
ps aux --sort=-%mem
4
ss -lntp
5
lsof -i:端口
6
journalctl -u 服务名
7
df -h
8
df -i
9
du -sh *

总结#

这次一面说明，我已经有一定运维入门实践，但还需要把经验从“我自己搭过、用过、踩过坑”，升级成“我理解规范流程、风险控制和企业级运维思路”。

后续准备运维面试，不能只背命令，还要能回答：

• 为什么这样做；
• 有什么风险；
• 如何回滚；
• 如何备份；
• 如何验证；
• 如何保证安全；
• 如何写进文档；
• 如何让团队可维护。

这些才是运维岗位真正关心的部分。