面试 · 方案设计型
考察目标:系统性取舍和设计能力 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 漂移
└── 监控:源服务可用性 + 同步延迟告警关键设计:统一软件源是安全基线的保障(所有包从统一可控源安装),也是网络隔离环境(如金融、政务)中部署软件的前提。
小结#
方案设计题考察系统性思维——不只是"能做",而是"考虑周全"。每个设计都应包含:架构方案、工具选型、安全考虑、监控验证、治理机制五个维度。面试中展现"我想到了你没问的问题"(如备份要验证、迁移要有回滚方案),是高分的核心。