运维面试题及答案

Shell脚本开发能力

Shell是运维的“瑞士军刀”，面试常考：脚本健壮性（错误处理）、逻辑复杂度、可维护性。拒绝“一行流”，强调规范与可读性。

1. 错误处理机制

【真题】如何确保脚本在任意环节失败时立即退出？如何记录执行日志？

#!/bin/bash
set -euo pipefail  # -e:出错退出; -u:未定义变量报错; -o pipefail:管道中任一命令失败则整体失败
LOG_FILE="/var/log/deploy_$(date +%Y%m%d).log"
exec > >(tee -a "$LOG_FILE") 2>&1  # 将stdout/stderr重定向至日志文件
log() { echo "[$(date '+%F %T')] $*" >&2; }  # 日志函数
log "开始部署..."
[ ! -d "/opt/app" ] && { log "错误：/opt/app不存在"; exit 1; }
# 示例：部署Nginx配置
deploy_config() {
  local config="$1"
  [ ! -f "$config" ] && { log "错误：配置文件缺失"; return 1; }
  cp "$config" /etc/nginx/conf.d/ && log "配置已更新"
}
deploy_config "/tmp/nginx.conf" || { log "部署失败"; exit 1; }
log "部署完成"

2. 高级技巧：动态变量与函数封装

【真题】编写脚本：根据传入参数动态设置环境变量（如PROD/TEST），并验证配置文件路径是否存在。

#!/bin/bash
set -euo pipefail
# 动态环境变量映射
declare -A ENV_CONFIG=(
  ["PROD"]="/etc/app/prod.conf"
  ["TEST"]="/etc/app/test.conf"
  ["DEV"]="/etc/app/dev.conf"
)
# 检查环境参数
check_env() {
  local env="$1"
  if [[ ! -v "ENV_CONFIG[$env]" ]]; then
    echo "错误：无效环境 '$env'，支持环境：${!ENV_CONFIG[*]}" >&2
    return 1
  fi
  local config_path="${ENV_CONFIG[$env]}"
  if [ ! -f "$config_path" ]; then
    echo "警告：配置文件 '$config_path' 不存在" >&2
    return 2
  fi
  echo "$config_path"
}
# 主流程
main() {
  local target_env="${1:-TEST}"
  local config_file
  config_file=$(check_env "$target_env") || exit $?
  echo "使用配置：$config_file"
  # 动态加载配置（安全方式）
  source "$config_file"
  echo "环境变量已加载：APP_VERSION=$APP_VERSION, LOG_LEVEL=$LOG_LEVEL"
}
main "$@"

【避坑指南】避免使用eval解析配置，易导致代码注入；动态变量访问用${!VAR[@]}而非eval echo \$$var；错误码统一用exit 1（非0即错），关键操作用||处理。

网络与安全防护体系

运维安全已从“防火墙+杀毒软件”升级为“零信任架构”，面试重点考察：协议原理理解、故障排查路径、安全实践落地。

1. TCP连接状态排查

【真题】“服务器出现大量TIME_WAIT连接，如何优化？SYN Flood攻击时如何应急？”

2. 零信任安全实践

【案例】某金融企业要求所有运维操作必须通过跳板机（Bastion Host）认证，且每次登录需二次验证。其架构如下：
〈用户终端〉→ 〈SSH证书认证〉→ 〈跳板机（基于OpenSSH 8.4+ Certificate机制）〉→ 〈目标服务器（仅信任跳板机证书）〉

【关键点】
① 跳板机生成短期证书（有效期≤1小时），自动轮换
② 目标服务器配置CertificateAuthority验证跳板机签名
③ 操作全程录像+命令审计（如OpenSSH的ForceCommand记录whoami与history）

Docker容器技术深度

Docker已成为运维标配，但面试常聚焦“原理”与“生产级实践”，避免停留在docker run层面。

1. 容器网络模型

【真题】“容器间通信有哪几种方式？bridge模式下如何实现固定IP？”

【固定IP实现】

# 创建自定义bridge网络
docker network create --driver bridge --subnet=172.20.0.0/16 mynet
# 启动容器指定IP
docker run --net mynet --ip 172.20.0.10 -d nginx:alpine
# 验证IP分配
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' nginx

2. 安全加固实践

【生产建议】
① 非root运行：USER appuser（在Dockerfile中）
② 只读根文件系统：docker run --read-only + 挂载临时卷
③ 限制资源：--memory=512m --cpus=1.0
④ 镜像扫描：docker scan 或集成Trivy到CI流水线

Kubernetes运维实战

K8s面试已从“部署集群”转向“高可用设计”与“故障自愈”，重点考察对控制平面、网络插件、存储卷的理解深度。

1. 控制平面高可用设计

【真题】“K8s集群中etcd为何必须是奇数节点？如何备份恢复？”

# 备份（在etcd节点执行）
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key
# 恢复（集群完全宕机时）
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db \
  --data-dir=/var/lib/etcd-backup \
  --name=etcd-0 \
  --initial-cluster=etcd-0=https://10.0.0.10:2380,etcd-1=https://10.0.0.11:2380,etcd-2=https://10.0.0.12:2380 \
  --initial-advertise-peer-urls=https://10.0.0.10:2380

2. 网络策略与故障排查

【场景】某Service无法访问Pod，检查步骤：
① kubectl get endpoints → 确认Endpoint是否存在
② kubectl exec -it pod -- curl -v http://svc:80 → 观察DNS解析（/etc/resolv.conf）
③ tcpdump -i any port 53 → 检查CoreDNS是否响应
④ iptables -L -n -v | grep kube-proxy → 验证kube-proxy规则

可观测性系统构建

现代运维依赖“指标+日志+链路”三位一体的可观测性（Observability），面试重点考察：监控指标设计、告警策略优化、根因分析（RCA）。

1. 关键指标设计原则

【黄金信号（Google SRE方法论）】
① 延迟（Latency）：服务响应时间（如HTTP 200的P99延迟）
② 流量（Traffic）：请求速率（如QPS）
③ 错误（Errors）：失败请求比例（如HTTP 5xx率）
④ 饱和度（Saturation）：资源使用率（CPU/内存/连接数）

【反模式警示】
❌ 仅监控CPU使用率 → 忽略I/O等待、上下文切换
❌ 告警阈值固定 → 应结合业务周期动态调整（如大促期间自动放宽阈值）
✅ 正确做法：rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.01（5分钟错误率>1%告警）

2. 告警风暴治理

【案例】某次数据库主从切换引发连锁告警（连接池满→服务降级→监控探针失败）。解决方案：
① 告警分级：critical（影响用户） vs warning（潜在风险）
② 告警聚合：alertmanager配置group_by: [cluster, service]
③ 告警抑制：when db_failover=true, suppress all db_connection alerts for 5m

DevOps与自动化交付

CI/CD已从“自动构建”演变为“安全左移”，面试聚焦：流水线设计、安全集成、回滚策略。

1. 安全左移实践

【真题】“如何在CI流水线中嵌入安全扫描？”

2. 蓝绿部署与金丝雀发布

【对比】
蓝绿部署：
① 绿环境部署新版本
② 切换流量（如Nginx upstream）
③ 验证通过后销毁旧环境
→ 优点：切换快、可回滚；缺点：需双倍资源

金丝雀发布：
① 1%流量切至新版本
② 监控关键指标（错误率/延迟）
③ 按比例逐步提升（1%→5%→25%→100%）
→ 优点：风险可控；缺点：需复杂路由支持（Istio/Envoy）

主流云平台运维要点

混合云已成为企业标配，面试需掌握：IaC（基础设施即代码）、云原生服务集成、成本优化。

1. Terraform核心实践

【真题】“如何管理Terraform状态文件以支持团队协作？”

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "prod/terraform.tfstate"
    region         = "ap-southeast-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}
# state-locking表结构（DynamoDB）
# 主键：LockID (String)

【最佳实践】
① 状态文件加密（S3服务端加密+KMS）
② 状态锁防止并发操作（DynamoDB表）
③ 分模块管理（prod/dev分离）
④ 定期清理旧版本（terraform state rm）

2. 云成本优化策略

【真实案例】某公司AWS账单超支50%，分析发现：
① RDS预留实例未覆盖所有实例类型 → 通过Cost Explorer识别高频使用实例
② S3生命周期策略缺失 → 自动转为GLACIER存储
③ EC2spot实例使用率仅30% → 改用Spot Fleet + On-Demand混合策略

自动化运维工具链

Ansible/Puppet/Chef已成标配，但面试更关注：无Agent设计原理、配置即代码、与云平台集成。

1. Ansible核心优势

【真题】“Ansible如何实现零依赖部署？其幂等性如何保障？”

零依赖原理：
Ansible通过SSH连接目标主机，无需安装Agent；任务执行依赖Python标准库（如os/shutil），而Python是Linux系统内置组件。

幂等性保障：
模块内部封装状态检查逻辑。例如copy模块：
① 比较源文件与目标文件的MD5
② 若不一致则覆盖，并返回changed状态
③ 若一致则跳过，返回ok状态

2. 高级技巧：自定义模块

【场景】需在K8s集群中动态创建ConfigMap，但Ansible官方模块不支持YAML合并。

#!/usr/bin/python
# library/my_configmap.py
#!/usr/bin/python
from ansible.module_utils.basic import AnsibleModule
import kubernetes
from kubernetes import client, config
def main():
    module_args = dict(
        name=dict(type='str', required=True),
        namespace=dict(type='str', required=True),
        data=dict(type='dict', required=True)
    )
    result = dict(changed=False, msg='')
    module = AnsibleModule(argument_spec=module_args, supports_check_mode=True)
    try:
        config.load_incluster_config()
        v1 = client.CoreV1Api()
        # 检查ConfigMap是否存在
        try:
            existing = v1.read_namespaced_config_map(module.params['name'], module.params['namespace'])
            # 合并数据（保留原值）
            existing_data = existing.data or {}
            existing_data.update(module.params['data'])
            # 更新
            body = client.V1ConfigMap(
                data=existing_data,
                metadata=client.V1ObjectMeta(name=module.params['name'])
            )
            v1.patch_namespaced_config_map(module.params['name'], module.params['namespace'], body)
            result['changed'] = True
        except:
            # 创建
            body = client.V1ConfigMap(
                data=module.params['data'],
                metadata=client.V1ObjectMeta(name=module.params['name'], namespace=module.params['namespace'])
            )
            v1.create_namespaced_config_map(module.params['namespace'], body)
            result['changed'] = True
    except Exception as e:
        result['failed'] = True
        result['msg'] = str(e)
    module.exit_json(**result)
if __name__ == '__main__':
    main()

【使用方式】
my_configmap:
name: app-config
namespace: production
data:
DB_HOST: "mysql.prod.svc"
LOG_LEVEL: "info"

真实故障排查案例

【场景】某电商大促期间，订单服务突然无法创建，Nginx返回502，但应用日志无异常。

网友们还关心的运维面试问题