路线图

面试 · 方案设计型

星辉 2026-07-02 阅读 6 min 1,113 字 路线图
面试 · 方案设计型 封面

考察目标:系统性取舍和设计能力 10 题


题目1:给你 100 台新机器,你如何从零搭建标准化的 Linux 运维环境?#

设计框架

text
1. 硬件与基础
   ├── BIOS 配置:虚拟化开启、PXE 启动顺序、电源策略
   ├── RAID 配置:系统盘 RAID1,数据盘 RAID10
   └── 带外管理 IPMI/iLO 配置

2. 系统安装
   ├── PXE/Kickstart 批量无人值守安装
   ├── 分区方案:/boot 1G、/ xfs 100G、/var xfs 100G、/data xfs 剩余
   ├── 基础包:vim、curl、htop、iotop、sysstat、iproute2(ss/ip)、rsync(net-tools 已弃用,确需 netstat/ifconfig 再单独装)
   └── 内核参数:tcp_tw_reuse、swappiness、file-max、inotify 等

3. 初始化配置(Ansible/Puppet 自动化)
   ├── SSH:禁用 root 密码登录、统一 authorized_keys
   ├── NTP/Chrony:时间同步(关键:日志关联、TLS 证书、分布式系统)
   ├── DNS:/etc/resolv.conf 统一配置
   ├── 监控 Agent:node_exporter、DCGM Exporter(GPU)
   ├── 日志采集:Promtail/Fluentd
   └── 安全基线:CIS Benchmark、关闭无用服务、firewall 规则

4. 资产管理
   ├── CMDB 录入(主机名/IP/SN/位置/配置)
   ├── 标签管理(环境/角色/团队)
   └── 监控接入(Prometheus SD 自动发现)

验证标准:新机器从上架到监控报警生效 < 30 分钟,所有机器配置完全一致(通过 Ansible 校验),安全基线 100% 通过。


题目2:设计一套日志采集和管理方案,覆盖 500 台服务器#

设计方案

text
采集层
├── 系统日志:Promtail 读 /var/log/syslog、auth.log
├── 应用日志:Promtail/Filebeat 读应用日志文件
├── Docker 日志:Docker json-file → Fluent Bit 采集
└── Journald:Promtail journal 模式采集

传输层
├── Promtail → Loki(推送,小数据量)
└── Fluent Bit → Kafka → Logstash → Elasticsearch(大数据量/全文检索)

存储层
├── Loki(S3 对象存储做长期存储)
│   ├── 热数据:SSD,7 天(高频查询)
│   └── 冷数据:S3 对象存储,90 天
├── Elasticsearch(热节点,7 天)+ 快照到 S3
└── 压缩:snappy/lz4

查询层
├── Grafana → Loki (LogQL)
├── Kibana → ES (全文检索+聚合)
└── 告警:Loki Ruler → Alertmanager

治理
├── 结构化日志:JSON 格式 + 统一字段(timestamp/level/service/trace_id)
├── 保留策略:按环境(生产 90 天,测试 7 天)
├── 成本控制:Label 基数控制(label 值不超过 1000 种)
└── 多租户:按团队分组,权限隔离

选型依据:Loki 适合低成本/与 Prometheus 联动场景,EFK 适合全文检索需求强的场景。500 台规模不考虑纯 ELK(运维成本太高),Loki + EFK 混合方案。


题目3:设计一个 Linux 服务器的监控告警体系#

设计方案

text
数据采集
├── 系统指标:node_exporter(CPU/内存/磁盘/网络/IO)
├── 进程指标:process-exporter(关键进程存活+资源)
├── GPU 指标:DCGM Exporter(SM 利用率/显存/温度/XID 错误)
├── 自定义指标:cron 脚本 + pushgateway(备份状态/证书到期等)
└── 日志指标:Loki metric query(错误率通过日志 Pattern 提取)

存储
├── Prometheus:本地 15 天(TSDB)
├── 长期:Thanos Sidecar → S3(1 年历史趋势)
└── 联邦:核心集群 Prometheus 聚合所有节点数据

告警规则(分级)
├── P0 立即 page
│   ├── 节点 down(up==0 持续 2min)
│   ├── 根分区 > 95%
│   ├── 内存 available < 5%
│   └── GPU XID error > 0
├── P1 工作时间内处理
│   ├── 磁盘 > 85%
│   ├── CPU load > 核数*2 持续 15min
│   └── OOM kill 事件
├── P2 趋势告警/日报
│   ├── 磁盘 30 天增长趋势 > 阈值
│   └── 证书 30 天内到期

告警通知
├── P0:PagerDuty/电话 + 钉钉群
├── P1:钉钉群 + 工单
└── P2:日报邮件

治理
├── 所有告警规则在 Git 中管理(PrometheusRule CRD)
├── 每季度审计告警噪声率,>30% 噪声的规则降级或删除
└── On-call 目标:每周 page < 5 次

关键设计:告警分级的依据是"用户影响 + 紧急程度"。节点 down 影响所有 Pod → P0;单个磁盘 85% 仍可工作 → P1。


题目4:设计一个批量备份方案,覆盖 200 台服务器的关键数据#

设计方案

text
备份内容
├── 配置:/etc 目录(rsync 每日增量)
├── 数据库:mysqldump + binlog / pg_dump(每日全量 + 持续备份)
├── 应用数据:/data 目录(rsync 每日增量)
├── K8s 资源:velero 备份 etcd + PV
└── 排除:/tmp、/proc、/sys、日志文件夹

备份策略
├── 全量:每周日凌晨 2:00
├── 增量:每日凌晨 3:00
├── 保留:每日 7 份、每周 4 份、每月 12 份
└── 异地:备份完成后 rsync 到异地机房/S3

工具选型
├── 文件:rsync + hardlink(--link-dest 去重,节省 80% 空间)
├── 数据库:原生 dump 工具 + xtrabackup(MySQL)
├── 编排:systemd timer / cron + Ansible 统一管理
└── 加密:gpg 对称加密备份文件

验证
├── 健康检查:备份完成后自动验证文件完整性(md5sum)
├── 恢复演练:每季度随机抽取 1 台做全流程恢复测试
├── 监控:Prometheus 采集备份状态 → 失败告警
└── 备份报告:每日邮件汇总成功/失败/耗时/大小

题目5:你需要把一台运行中的 CentOS 7 服务器原地升级到 RHEL/Rocky 9,如何设计零停机方案?#

设计方案

text
方案选择:不做原地升级(风险太大),做蓝绿迁移
├── 背景:CentOS 7 已于 2024-06-30 EOL,无安全更新,迁移是刚需(非可选)
├── CentOS 7 → Rocky 9 跨大版本原地升级 99% 会挂
└── 推荐:新装 → 迁移数据 → 切流量 → 下线旧节点

迁移步骤:
1. 新装 Rocky 9 节点
   ├── 相同的分区方案
   ├── 同样的网络配置(IP 可以不同)
   └── Ansible 跑初始化剧本(5 分钟)

2. 数据迁移
   ├── 配置文件:rsync /etc/app → 新节点
   ├── 静态数据:rsync /data → 新节点
   ├── 数据库:从主从复制中拿数据(或 dump + restore)
   └── 验证:在新节点 dry-run 启动应用

3. 切换
   ├── 修改 DNS/负载均衡指向新节点
   ├── 旧节点 keepalived 降 priority 或直接下线
   ├── 观察 30 分钟:监控指标正常
   └── 回滚方案:DNS 指回旧节点(TTL 设为 60s)

4. 下线旧节点
   ├── 旧节点保留 48 小时(应急回滚)
   ├── 无异常后关机、回收
   └── 更新 CMDB

关键设计:30 分钟监控观察期 + 48 小时保留期 + DNS TTL 60s 快速回滚

题目6:设计一个用户权限管理体系,适用于 50 人运维团队管理 200+ 服务器#

设计方案

text
认证层
├── 中心化认证:FreeIPA / LDAP(统一账户体系)
│   ├── 用户增删改、密码策略、MFA
│   └── sudo 规则集中管理
├── SSH 密钥管理:SSH CA 签名证书(短有效期 4h)替代 authorized_keys
└── 堡垒机:Teleport / JumpServer(审计录像、会话回放)

授权层(sudo 规则)
├── 角色分组
│   ├── operator:systemctl restart/status(只读 + 重启)
│   ├── admin:全部命令,除 rm -rf / 和 dd
│   └── developer:查看应用日志、重启自己的应用
├── sudoers 模板化(通过 Ansible 分发)
└── 紧急 break-glass 账户(记录在保险柜,使用后强制轮换密码)

审计层
├── 所有 sudo 操作记入 /var/log/auth.log → 采集到 Loki
├── 堡垒机会话录像存储 90 天
├── 异常检测:非工作时间登录告警、异常 IP 登录告警
└── 定期审计:季度 review 不必要的权限

治理
├── 入职自动创建账户、加入对应组
├── 离职即时禁用(LDAP disable + 吊销证书)
├── 90 天密码轮换策略
└── 每季度权限最小化 review(revoke 不再使用的权限)

题目7:设计一个自动化巡检系统,每日检查 200 台服务器健康状况#

设计方案

text
巡检项
├── 基础健康
│   ├── CPU load < 核数*2
│   ├── 内存 available > 10%
│   ├── 根分区 / > 15GB 可用或 > 10%
│   ├── 系统运行时间 > 1 天(排除刚重启的)
│   └── NTP 同步正常(offset < 500ms)
├── 服务健康
│   ├── sshd/chronyd/containerd/kubelet 运行中
│   ├── systemctl list-units --failed(有失败的服务?)
│   └── 关键进程存活(ps aux | grep app)
├── 安全
│   ├── SSH 禁止 root 登录
│   ├── 防火墙开启
│   ├── SELinux enforcing
│   ├── 无 7 天内未更新的安全包
│   └── /etc/passwd 无 uid=0 的非 root 账户
├── 存储
│   ├── 所有挂载点可读写(touch 测试)
│   ├── LVM/VG 有 > 20% 空闲
│   └── RAID 状态正常(MegaCli/StorCli)
├── 硬件
│   ├── SMART 健康状态
│   ├── 内存 ECC 错误
│   └── dmesg 中 24 小时内的 error/warning
└── 备份验证
    └── 最近一次备份成功且 < 26 小时

技术实现
├── Ansible playbook 每天凌晨 3 点跑一次
├── 输出:JSON → Prometheus Pushgateway → Grafana 看板
├── 异常项自动创建 Jira 工单 + 钉钉通知
└── 月度汇总报告(各集群健康分、趋势)

题目8:设计一套系统性能基线方案,怎样判断"系统变慢了"?#

设计方案

text
基线指标选择
├── 系统层
│   ├── CPU:load average、%iowait、%steal
│   ├── 内存:available、swap 使用速率
│   ├── IO:磁盘 await、svctm、%util、iops
│   └── 网络:丢包率、重传率、带宽利用率
├── 应用层
│   ├── 响应时间 P50/P95/P99
│   ├── 错误率(按接口)
│   └── QPS/TPS
└── 数据库层
    ├── 慢查询数、连接数
    └── 主从延迟

基线建立方法
├── 样本窗口:至少 2 周稳定期数据
├── 去异常:排除发布/故障时间段
├── 分时段:工作日 vs 周末、白天 vs 凌晨
└── 基线值:P95 作为"正常上限"

异常判定
├── 短期异常(持续 5-15 分钟):当前值 > 3× 基线(Z-score > 3)
├── 趋势异常(持续 2 小时+):7 天滑动平均持续偏离基线 > 30%
└── 周期性异常:同一时段每天偏离(如每天 10:00 固定慢 → 定时任务?)

工具实现
├── Prometheus Recording Rules 预计算基线
├── Grafana:当前值 vs 基线(同图双线,一目了然)
└── 告警:结合基线和 SLO,避免静态阈值误报

题目9:你如何规划一个团队的安全加固 Checklist?#

设计框架

text
1. 账户与认证
   ├── 禁用 root SSH 登录
   ├── 密码复杂度策略(minlen=12, 历史密码 >= 5)
   ├── 开启 fail2ban(5 次失败锁 10 分钟)
   ├── SSH 密钥认证优先(禁用密码登录)
   └── 无主账户(uid=0 的账户只有 root)

2. 网络
   ├── 最小端口开放原则(默认 deny,按需 allow)
   ├── 管理端口只在跳板机/IP 白名单开放
   ├── 禁用未使用的网络服务和协议(echo/discard 等)
   └── iptables/firewalld 开启并审查规则

3. 系统加固
   ├── SELinux enforcing(不关!配 policy 而非关 SELinux)
   ├── 禁用 unused kernel modules
   ├── /tmp noexec(mount -o remount,noexec /tmp)
   ├── 删除不必要的包(telnet、rcp、rsh)
   └── cron.allow / at.allow 白名单

4. 文件权限
   ├── 关键文件权限 600 或 400(/etc/shadow、/etc/ssh/*key)
   ├── SUID/SGID 审计(find / -perm /4000 -o -perm /2000)——优先用 capabilities 替代 SUID-root(见概念解释型 题目23)
   ├── capabilities 审计(getcap -r / 2>/dev/null 找出带特权能力的二进制)
   ├── World-writable 文件审计(find / -perm -2 -type f)
   └── 无主文件审计(find / -nouser -o -nogroup)

5. 审计与日志
   ├── auditd 配置关键系统调用监控
   ├── 日志实时采集到中心化系统(Loki/ELK)
   ├── 日志不可篡改(append-only / 远程存储)
   └── 异常行为告警(非工作时间 SSH、sudo 失败、新增 crontab)

6. 持续运营
   ├── 每月安全补丁评估与上线
   ├── 每季度 CIS Benchmark 扫描 + 修复
   ├── 每半年渗透测试
   └── 安全事件应急响应 Runbook

题目10:你需要从零搭建一套公司内部 APT/YUM 私有源,怎么设计?#

设计方案

text
1. 软件源架构
   ├── 主仓库服务器:内网高速存储,只允许出站到上游源
   ├── 缓存代理(可选):apt-cacher-ng / Nexus Proxy Repository
   └── 同步策略:每周日凌晨全量同步 + 每日安全更新增量

2. 工具选型
   ├── Nexus Repository OSS:支持 apt/yum/docker/pypi 多格式
   │   ├── Proxy 模式:代理官方源,自动缓存
   │   └── Hosted 模式:上传内部自定义包
   ├── nginx 提供 HTTP(S) 前端
   └── GPG 签名:内部包的签名密钥管理

3. 客户端配置
   ├── Ansible 统一分发 /etc/apt/sources.list 或 .repo
   ├── source list 只指向内部源(安全/网络隔离考虑)
   └── GPG 公钥部署到所有节点

4. 安全与合规
   ├── 内部源服务器不直接通互联网(通过安全代理出站)
   ├── 上传的内部包必须过安全扫描
   └── 下载日志审计

5. 高可用
   ├── 主备两台 Nexus + NFS 共享存储(或 S3)
   ├── Keepalived VIP 漂移
   └── 监控:源服务可用性 + 同步延迟告警

关键设计:统一软件源是安全基线的保障(所有包从统一可控源安装),也是网络隔离环境(如金融、政务)中部署软件的前提。


小结#

方案设计题考察系统性思维——不只是"能做",而是"考虑周全"。每个设计都应包含:架构方案、工具选型、安全考虑、监控验证、治理机制五个维度。面试中展现"我想到了你没问的问题"(如备份要验证、迁移要有回滚方案),是高分的核心。