# 运维智能体岗位复习文档

## 一、岗位核心画像

这个岗位是：

> 传统运维能力 + 自动化脚本能力 + AI 智能体落地能力 + 客户交付能力

重点考察：

| 能力方向 | 需要掌握 |
|---|---|
| 系统运维 | Linux、网络、进程、磁盘、权限、服务部署 |
| 监控运维 | Zabbix、Prometheus、SkyWalking、ELK、告警处理 |
| 自动化 | Python、JavaScript、Ansible、Puppet、Shell |
| AI 运维 | Agent、Skill、Prompt、AI 编程工具、自动化运维场景 |
| 项目交付 | 需求分析、部署上线、故障处理、文档编写 |

不需要把 ClaudeCode、Cursor、TRAE、Hermes、Qwen、openClaw 全部学得很深。建议选择一个作为主工具，准备一个完整案例：解决什么问题、如何使用、如何控制权限和风险、提升了多少效率。

## 二、重点复习内容

### 1. Linux 系统运维

```bash
# CPU、内存、负载
top
free -h
uptime
vmstat 1
iostat

# 磁盘
df -h
du -sh /var/log/*
lsblk

# 进程
ps -ef
pgrep nginx
kill -15 PID
kill -9 PID

# 网络
ip addr
ip route
ss -lntp
ping 目标地址
curl -I http://127.0.0.1:8080
telnet 目标地址 端口
dig example.com

# 服务和日志
systemctl status nginx
systemctl restart nginx
systemctl enable nginx
journalctl -u nginx -f
journalctl --since "1 hour ago"

# 文件和权限
chmod
chown
find
grep
awk
sed
tar
rsync
```

故障排查顺序：

1. 确认现象、影响范围和发生时间。
2. 检查进程、端口和服务状态。
3. 检查 CPU、内存、磁盘、文件句柄。
4. 检查应用日志、系统日志和反向代理日志。
5. 检查数据库、Redis、消息队列和第三方接口。
6. 检查 DNS、路由、防火墙和连接超时。
7. 采取回滚、切流、扩容等低风险恢复措施。
8. 做根因分析、补充监控并完成复盘。

重点知识：

- `kill -15` 是优雅停止，`kill -9` 是强制停止。
- `load average` 表示系统运行队列压力，不等于 CPU 使用率。
- `df` 查看文件系统使用情况，`du` 查看目录或文件占用情况。
- 磁盘满但 `du` 查不到时，检查已删除但仍被进程占用的文件：`lsof | grep deleted`。

### 2. 监控体系

| 类型 | 内容 | 常用工具 |
|---|---|---|
| Metrics | CPU、内存、QPS、错误率、延迟 | Prometheus、Zabbix |
| Logs | 程序运行过程和错误信息 | ELK |
| Traces | 请求经过哪些服务以及各环节耗时 | SkyWalking |

四个黄金指标：延迟、流量、错误、饱和度。

常用 PromQL：

```promql
# 服务是否存活
up{job="node"}

# 5 分钟平均请求速率
rate(http_requests_total[5m])

# 5xx 错误率
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

# CPU 使用率
100 - avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100

# 磁盘使用率
100 * (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes)
```

一条合格告警应包含：告警名称、级别、触发条件、持续时间、影响对象、处理步骤、升级机制和恢复条件。

Zabbix 与 Prometheus 的回答要点：Zabbix 更适合传统主机、网络设备和固定监控项；Prometheus 的标签和 PromQL 更适合云原生、容器和动态服务，两者可以并存。

### 3. ELK 和 SkyWalking

ELK 流程：

```text
应用日志 -> Filebeat / Logstash -> Elasticsearch -> Kibana
```

日志建议使用结构化 JSON，并包含 `timestamp`、`level`、`service`、`trace_id`、`request_id`、`message` 和 `duration_ms`。不能打印密码、Token 等敏感信息。

接口慢时通过 SkyWalking 查看调用链，重点判断：慢 SQL、下游服务超时、线程池耗尽、连接池耗尽、网络延迟或重试放大。

### 4. 自动化运维

Python 重点：文件和 JSON/YAML 处理、HTTP API、子进程、异常处理、日志、参数解析、超时、并发和幂等操作。

运维脚本应具备：参数可配置、有日志、有超时、有异常处理、有返回码、支持重复执行、不硬编码密码、危险操作需要确认。

Ansible 重点：Inventory、Playbook、Role、Variables、Template、Handler、`when`、`register`、幂等性、`check mode`、`--limit` 和 `--tags`。

```yaml
- name: Deploy service
  hosts: app
  become: true
  tasks:
    - name: Install nginx
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Copy config
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
        mode: "0644"
      notify: Restart nginx

  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted
```

幂等性：Playbook 多次执行后，系统最终状态一致，不会重复安装、重复追加配置或重复创建资源。

### 5. AI Agent 和 Skill

Agent 基本流程：

```text
用户需求 -> 意图识别 -> 任务规划 -> 调用工具 -> 判断结果 -> 继续执行或人工确认 -> 输出结果和审计记录
```

Agent 与普通聊天机器人的区别是：Agent 能理解目标、拆分任务、调用工具、根据工具结果继续决策并处理异常。

Skill 设计模板：

```text
名称：服务故障初步诊断

触发条件：服务不可用、接口超时、错误率升高。
输入参数：服务名、环境、时间范围、主机范围。
执行步骤：检查服务、端口、日志、资源、Prometheus 指标。
安全限制：默认只读；生产操作需人工确认；不输出密码和 Token；记录审计日志。
输出格式：现象、证据、影响范围、可能原因、建议动作、风险等级。
```

高质量 Prompt 应包含：角色、背景、目标、输入、约束、执行步骤、失败处理和固定输出格式。

AI 运维必须关注：Prompt Injection、Agent 越权、生产误操作、敏感信息泄露、模型幻觉、不可审计和无限重试。

推荐策略：查询和执行权限分离；高风险动作人工审批；命令白名单；密钥不进入 Prompt；所有操作记录审计日志；失败时停止。

## 三、实战题

### 实战题一：Linux 服务故障排查

Nginx 无法访问，请判断服务、端口、配置、日志、磁盘和内存状态，并写出故障报告。

参考命令：

```bash
systemctl status nginx
ss -lntp | grep ':80'
nginx -t
journalctl -u nginx --since "30 minutes ago"
df -h
free -h
curl -I http://127.0.0.1
```

评分重点：排查顺序合理，能区分配置错误、端口冲突、磁盘满和后端异常，不是一上来就重启。

### 实战题二：Python 主机巡检脚本

检查 CPU、内存、根目录磁盘、指定端口和指定 URL，并输出 JSON。

```json
{
  "hostname": "server-01",
  "cpu_percent": 35.2,
  "memory_percent": 62.1,
  "disk_percent": 71.5,
  "port_8080": true,
  "health_check": true,
  "status": "normal"
}
```

追问：超时怎么处理？单个检查失败是否影响其他检查？如何接入 Prometheus？如何安全管理密码？

### 实战题三：设计 Web 服务监控

监控服务存活、CPU、内存、磁盘、QPS、P95 延迟、5xx 错误率和数据库连接池，并输出指标清单、PromQL、告警规则和处理手册。

告警分级可分为：P1 服务不可用；P2 延迟明显升高或部分节点异常；P3 磁盘接近阈值；P4 容量趋势和低优先级提醒。

### 实战题四：Ansible 自动化部署

使用 Ansible 部署 Python Web 服务，要求安装环境、创建用户、上传文件、配置 systemd、启动服务、健康检查、重复执行和失败回滚。

重点考察 Role、Template、Handler、变量、权限、幂等性和回滚设计。

### 实战题五：日志根因定位

某接口最近 30 分钟大量超时，请结合 ELK 和 SkyWalking 分析原因。

输出格式：

```text
问题现象：
影响范围：
时间线：
关键日志：
关键指标：
调用链路：
初步根因：
临时措施：
长期措施：
是否需要补充监控：
```

### 实战题六：设计智能运维 Agent

Agent 可以查询 Prometheus、Elasticsearch、SkyWalking、主机状态和部署记录，并生成故障报告。

建议设计三个 Skill：

- `service_health_check`：服务健康检查。
- `log_root_cause_analysis`：日志根因分析。
- `incident_report_generator`：故障报告生成。

必须说明：Agent 流程、工具权限、Prompt、异常处理、人工审批、审计和回滚机制。

### 实战题七：客户需求分析

客户提出“希望 AI 自动发现服务器问题并自动修复”。

回答应包含：确认问题范围；检查已有监控和日志；确认自动修复动作；评估生产风险；先只读诊断，再逐步开放低风险动作；选择一个高频低风险场景做 MVP；用 MTTD、MTTR 和人工时长衡量效果。

## 四、面试题与参考回答

### 1. 请做自我介绍

> 我有 X 年运维相关经验，主要负责 Linux 系统、应用部署、监控告警和故障处理。使用过 Prometheus、Zabbix、ELK 或其他监控日志工具，也编写过 Python 或 Shell 脚本进行巡检和自动化部署。最近重点关注 AI 在运维场景中的应用，例如通过 Prompt 和 Skill 将日志分析、主机巡检和故障报告生成流程标准化。我擅长从需求出发，把问题拆成监控、脚本、流程和交付文档，并通过自动化减少重复操作。

### 2. 如何排查接口超时？

先确认影响范围和时间，再检查入口网关、应用、数据库和下游服务指标。通过 SkyWalking 查看调用链，使用 ELK 按 `trace_id` 查询日志，同时检查 CPU、内存、线程池、连接池、网络和慢 SQL。影响较大时先限流、切流或回滚恢复服务，再做根因分析。

### 3. 什么是告警风暴？

一个底层故障导致大量关联告警同时触发。可以通过告警聚合、抑制、去重、分组、持续时间和根因告警设计来降低噪音。

### 4. 如何保证自动化脚本安全？

参数校验、最小权限、不硬编码密钥、命令白名单、dry-run、操作前备份、生产审批、操作审计、超时和回滚。

### 5. 什么是 AI Agent？

AI Agent 不只是生成文本，而是可以理解目标、拆解任务、调用工具、根据结果继续决策并完成任务。例如自动查询 Prometheus、分析 ELK 日志、查看部署记录并生成诊断报告。

### 6. Skill 和 Prompt 有什么区别？

Prompt 主要描述模型的角色、任务、约束和输出格式。Skill 是完整的可复用能力模块，还包括触发条件、输入输出、工具调用、执行步骤、权限限制、异常处理和结果验证。

### 7. 如何防止 Agent 误操作生产环境？

默认只读；查询和执行权限分离；高风险动作人工审批；命令白名单；生产环境单独授权；执行前展示命令和影响范围；执行后保存审计记录；设置超时、重试和熔断；支持回滚。

### 8. AI 给出错误结论怎么办？

要求 Agent 输出指标、日志、链路和时间线等证据。证据不足时必须标记不确定并给出下一步查询建议，不能根据模型猜测直接执行生产变更。

### 9. 如何评价 AI 运维项目是否成功？

使用 MTTD、MTTR、告警误报率、自动诊断准确率、自动化成功率、人工处理时长和重复问题减少比例进行评价。

### 10. 部署上线前检查什么？

配置、环境变量、依赖服务、数据库变更、端口权限、日志、健康检查、监控告警、备份、回滚包、测试结果和审批状态。

### 11. 上线后出现问题怎么办？

确认影响，通知相关人员，保留现场，快速止损，回滚或切流，验证恢复，进行根因分析和故障复盘。不要直接删除日志或盲目重启所有服务。

### 12. 客户需求不清楚时怎么办？

先确认现象、目标、范围、优先级、验收标准、已有系统和技术限制，再拆分 MVP，用流程图或原型确认双方理解，最后通过试点和数据迭代。

### 13. 如何编写运维文档？

文档应包含系统架构、部署说明、配置说明、启停命令、监控指标、告警处理、常见故障、回滚步骤、权限说明、联系人和变更记录。

### 14. 如何理解运维产品的运营推广？

产品上线后还要推动用户真正使用，包括培训、场景梳理、使用手册、典型案例、问题收集和持续迭代，最终通过监控覆盖率、故障定位时间和人工操作减少比例体现价值。

## 五、7 天复习计划

### 第 1 天

复习 Linux 进程、内存、磁盘、网络、systemd 和日志。

### 第 2 天

复习 Zabbix、Prometheus、指标、PromQL 和告警设计。

### 第 3 天

复习 ELK、结构化日志、SkyWalking、Trace ID 和慢请求分析。

### 第 4 天

用 Python 写巡检脚本，用 Ansible 部署一个服务。

### 第 5 天

掌握 Agent、Tool、Skill、Prompt、权限、审批和审计。

### 第 6 天

准备两个项目案例，使用 STAR 方法：背景、任务、行动、结果。

### 第 7 天

模拟自我介绍、故障排查、自动化、AI 运维设计、客户需求分析和上线回滚。

## 六、面试前准备的三个项目

### 项目一：自动化巡检平台

Python 检查主机和服务，输出 JSON 或 Markdown 报告，对接 Prometheus 或企业微信，并加入异常处理和超时。

### 项目二：智能故障诊断 Agent

查询监控、查询日志、分析链路、生成诊断结论，高风险操作人工审批并输出审计报告。

### 项目三：服务自动化部署

使用 Ansible 部署服务，配置 systemd、健康检查、版本管理、灰度发布、失败回滚和部署文档。

面试表达核心：

> 能否把客户问题拆清楚，用监控发现问题，用脚本和自动化解决问题，再用 AI 提高诊断和交付效率，同时保证生产安全。

## 七、实战题参考答案

### 实战题一参考答案：Linux 服务故障排查

#### 1. 先确认服务状态

```bash
systemctl status nginx --no-pager
ps -ef | grep '[n]ginx'
```

如果服务没有运行，继续查看启动失败原因：

```bash
nginx -t
journalctl -u nginx -n 100 --no-pager
```

#### 2. 检查端口

```bash
ss -lntp | grep ':80'
ss -lntp | grep ':443'
```

可能情况：

| 现象 | 可能原因 |
|---|---|
| 没有 80 端口 | Nginx 未启动或配置监听其他端口 |
| 端口被其他进程占用 | Apache、旧进程或其他服务占用了端口 |
| 本机能访问，外部不能访问 | 防火墙、安全组、负载均衡或网络问题 |
| Nginx 返回 502 | 后端应用未启动、端口错误或后端超时 |
| Nginx 返回 403 | 文件权限、目录权限或访问规则问题 |

查看端口占用：

```bash
ss -lntp | grep ':80'
lsof -i:80
```

#### 3. 检查配置并重新加载

```bash
nginx -t
systemctl reload nginx
```

如果 `nginx -t` 报错，应先修复配置，不要直接重启。常见错误包括：

- 配置文件少分号。
- `server_name` 或 `upstream` 配置错误。
- 引用了不存在的证书或文件。
- 端口重复监听。
- 后端地址填写错误。

#### 4. 检查日志

```bash
tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/nginx/access.log
journalctl -u nginx --since "30 minutes ago"
```

#### 5. 检查主机资源

```bash
df -h
free -h
top
uptime
```

如果磁盘满，先定位大文件。不要直接删除正在使用的日志文件：

```bash
du -sh /var/log/* 2>/dev/null | sort -h
lsof | grep deleted
```

#### 6. 检查后端应用

```bash
curl -I http://127.0.0.1:8080/health
ss -lntp | grep ':8080'
```

#### 7. 验证恢复

```bash
curl -I http://127.0.0.1
curl -I http://服务器IP
```

#### 参考故障报告

```text
故障现象：用户访问 Web 页面返回 502。
影响范围：生产环境订单服务入口，影响全部用户请求。
排查过程：Nginx 进程正常，80 端口正常，error.log 显示连接 8080 端口被拒绝。
根本原因：后端订单服务进程异常退出。
临时措施：恢复订单服务并验证健康检查。
长期措施：增加后端进程存活告警、接口错误率告警和自动拉起策略。
```

### 实战题二参考答案：Python 主机巡检脚本

安装依赖：

```bash
pip install psutil requests
```

参考实现：

```python
#!/usr/bin/env python3
import argparse
import json
import socket
from urllib.parse import urlparse

import psutil
import requests


def check_port(host: str, port: int, timeout: float = 2.0) -> bool:
    try:
        with socket.create_connection((host, port), timeout=timeout):
            return True
    except OSError:
        return False


def check_url(url: str, timeout: float = 3.0) -> bool:
    try:
        response = requests.get(url, timeout=timeout)
        return response.status_code == 200
    except requests.RequestException:
        return False


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("--port", type=int, default=8080)
    parser.add_argument("--url", default="http://127.0.0.1:8080/health")
    args = parser.parse_args()

    parsed_url = urlparse(args.url)
    port_host = parsed_url.hostname or "127.0.0.1"

    result = {
        "hostname": socket.gethostname(),
        "cpu_percent": psutil.cpu_percent(interval=1),
        "memory_percent": psutil.virtual_memory().percent,
        "disk_percent": psutil.disk_usage("/").percent,
        "port_8080": check_port(port_host, args.port),
        "health_check": check_url(args.url),
    }

    result["status"] = "normal" if all([
        result["cpu_percent"] < 90,
        result["memory_percent"] < 90,
        result["disk_percent"] < 90,
        result["port_8080"],
        result["health_check"],
    ]) else "abnormal"

    print(json.dumps(result, ensure_ascii=False, indent=2))


if __name__ == "__main__":
    main()
```

执行：

```bash
python host_check.py --port 8080 --url http://127.0.0.1:8080/health
```

生产环境改进点：

- 对每一个检查单独捕获异常，避免一个检查失败导致整个脚本退出。
- 给 HTTP、Socket 和子进程设置超时。
- 使用环境变量或密钥管理系统保存认证信息。
- 增加日志和退出码，例如正常返回 0，异常返回 1。
- 支持 `--output json`、`--output text` 等输出格式。
- 增加重试次数，但必须设置最大重试次数，避免无限重试。
- 如果接入 Prometheus，应将结果转换成指标，而不是让 Prometheus 解析普通文本。

### 实战题三参考答案：Web 服务监控

#### 1. 指标设计

| 层次 | 指标 |
|---|---|
| 主机 | CPU、内存、磁盘、网络、文件句柄 |
| 服务 | 存活状态、进程数、重启次数 |
| 应用 | QPS、错误率、P50/P95/P99 延迟 |
| 依赖 | 数据库连接池、Redis 延迟、下游错误率 |
| 业务 | 登录成功率、订单成功率、支付失败数 |

#### 2. Prometheus 配置

```yaml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: web-service
    static_configs:
      - targets: ["127.0.0.1:8080"]
```

应用需要暴露 `/metrics` 接口，或者通过 Node Exporter 等 Exporter 暴露主机指标。

#### 3. 告警规则

```yaml
groups:
  - name: web-service
    rules:
      - alert: WebServiceDown
        expr: up{job="web-service"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Web 服务不可用"
          description: "实例 {{ $labels.instance }} 已连续 2 分钟不可用"

      - alert: WebServiceHighErrorRate
        expr: |
          sum(rate(http_requests_total{job="web-service",status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total{job="web-service"}[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Web 服务 5xx 错误率超过 5%"

      - alert: HostDiskAlmostFull
        expr: |
          100 * (1 - node_filesystem_avail_bytes{mountpoint="/"}
          / node_filesystem_size_bytes{mountpoint="/"}) > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "根目录磁盘使用率过高"
```

#### 4. 告警处理手册

服务不可用时：检查 `up`、进程、端口、应用日志、主机资源和最近发布记录。

错误率升高时：按 `trace_id` 查询日志，查看 SkyWalking 调用链，确认是当前服务还是下游依赖异常。

延迟升高时：对比 P50、P95 和 P99，确认是否是少量慢请求，并检查慢 SQL、连接池和线程池。

磁盘告警时：查看大目录、日志保留策略和已删除文件，先扩容或清理经过确认的历史文件，再补充日志轮转配置。

### 实战题四参考答案：Ansible 自动化部署

推荐目录：

```text
ansible-project/
├── inventory.ini
├── site.yml
├── group_vars/
│   └── app.yml
└── roles/
    └── webapp/
        ├── tasks/main.yml
        ├── templates/webapp.service.j2
        ├── templates/app.env.j2
        └── handlers/main.yml
```

`inventory.ini`：

```ini
[app]
app01 ansible_host=192.168.1.10
app02 ansible_host=192.168.1.11
```

`site.yml`：

```yaml
- name: Deploy webapp
  hosts: app
  become: true
  serial: 1
  roles:
    - webapp
```

`roles/webapp/tasks/main.yml`：

```yaml
- name: Create application user
  ansible.builtin.user:
    name: webapp
    system: true
    create_home: false

- name: Create application directory
  ansible.builtin.file:
    path: /opt/webapp
    state: directory
    owner: webapp
    group: webapp
    mode: "0755"

- name: Upload application package
  ansible.builtin.copy:
    src: webapp.tar.gz
    dest: /opt/webapp/webapp.tar.gz
    owner: webapp
    group: webapp
    mode: "0644"
  notify: Restart webapp

- name: Install systemd unit
  ansible.builtin.template:
    src: webapp.service.j2
    dest: /etc/systemd/system/webapp.service
    mode: "0644"
  notify:
    - Reload systemd
    - Restart webapp

- name: Ensure service started
  ansible.builtin.service:
    name: webapp
    state: started
    enabled: true
```

`roles/webapp/handlers/main.yml`：

```yaml
- name: Reload systemd
  ansible.builtin.systemd:
    daemon_reload: true

- name: Restart webapp
  ansible.builtin.service:
    name: webapp
    state: restarted
```

执行前先检查：

```bash
ansible-playbook -i inventory.ini site.yml --check
ansible-playbook -i inventory.ini site.yml --limit app01
```

为什么使用 `serial: 1`：一次只发布一台，先验证健康，再发布下一台，降低全量发布风险。

回滚设计：应用包按版本保存，例如 `/opt/webapp/releases/20260908/`，通过软链接 `current` 指向当前版本。出现问题时切换软链接到上一个版本，重新启动并验证健康检查。

### 实战题五参考答案：接口超时日志分析

建议按照以下时间线处理：

1. 从告警中确认开始时间和影响服务。
2. 在 Prometheus 中查看 QPS、错误率、P95/P99 延迟。
3. 在 SkyWalking 中确认耗时最高的调用节点。
4. 使用 `trace_id` 在 Elasticsearch 查询完整请求日志。
5. 检查数据库慢查询、连接池、线程池和下游接口。
6. 对比最近发布、配置变更和流量变化。

示例日志：

```json
{
  "level": "ERROR",
  "service": "order-service",
  "trace_id": "abc123",
  "message": "database connection timeout",
  "duration_ms": 3000
}
```

如果大量日志都是 `database connection timeout`，并且连接池使用率 100%，可能原因是数据库连接未释放、数据库响应变慢或连接池配置太小。

如果应用耗时很低，但下游调用耗时很高，问题更可能在下游服务或网络。

如果请求量突然增加且 CPU、线程池同时升高，可能是流量突增或重试放大，需要限流和检查重试策略。

参考结论：

```text
现象：订单接口 P99 从 300ms 升到 3s，5xx 错误率达到 8%。
证据：SkyWalking 显示数据库调用占总耗时 90%；日志显示连接池获取超时。
根因：数据库连接池耗尽，初步判断与慢 SQL 和连接未及时释放有关。
临时措施：限制流量、暂停非核心任务、回滚最近变更，并观察连接池恢复。
长期措施：修复连接释放问题，优化慢 SQL，增加连接池使用率和获取超时告警。
```

### 实战题六参考答案：智能故障诊断 Agent

#### 1. Agent 流程

```text
接收服务名和时间范围
-> 校验环境和权限
-> 查询服务存活指标
-> 查询错误率和延迟
-> 查询日志
-> 查询调用链
-> 对比部署记录
-> 汇总证据
-> 输出可能原因和置信度
-> 需要变更时请求人工审批
```

#### 2. 工具权限

| 工具 | 默认权限 | 是否需要审批 |
|---|---|---|
| 查询 Prometheus | 只读 | 否 |
| 查询 Elasticsearch | 只读 | 否 |
| 查询 SkyWalking | 只读 | 否 |
| 查询部署记录 | 只读 | 否 |
| 重启服务 | 执行 | 是 |
| 修改配置 | 执行 | 是 |
| 删除日志或文件 | 禁止 | 不允许自动执行 |

#### 3. Agent Prompt

```text
你是一名生产环境故障诊断助手。

目标：根据指标、日志、链路和发布记录，给出有证据支持的故障分析。

规则：
1. 只能使用工具返回的证据，不得编造数据。
2. 证据不足时必须输出“无法确定”，并给出下一步查询建议。
3. 默认只能查询，不能重启、删除、修改配置。
4. 任何生产变更必须先展示动作、影响和回滚方案，再请求人工确认。
5. 不输出密码、Token、Cookie 和其他敏感信息。

输出格式：
问题现象：
影响范围：
时间线：
关键证据：
可能原因及置信度：
建议排查：
建议动作：
风险和回滚：
```

#### 4. 合格答案标准

- 不是让模型直接猜原因。
- 每个结论都能对应指标、日志或链路证据。
- 生产默认只读。
- 有人工确认、审计和回滚。
- 有超时、最大重试次数和失败停止机制。

### 实战题七参考答案：客户需求分析

客户说“AI 自动发现服务器问题并自动修复”，不能直接开始开发，应先澄清：

1. 什么叫服务器问题，是资源问题、服务问题还是业务问题。
2. 目前有多少服务器和服务，是否有生产、测试环境区分。
3. 现有监控、日志、CMDB 和发布系统是什么。
4. 希望自动修复哪些动作，例如重启服务、清理日志还是扩容。
5. 哪些动作允许自动执行，哪些需要审批。
6. 验收标准是什么，是降低 MTTR、减少人工值守还是提高告警准确率。

推荐 MVP：先做“只读诊断 + 报告生成”，第二阶段增加低风险动作，例如重新拉取监控配置，第三阶段再评估服务重启等高风险动作。

## 八、岗位工具和中间件入门

说明：图片中的工具不全是严格意义上的“中间件”。Zabbix、Prometheus 属于监控系统，ELK 属于日志平台，SkyWalking 属于链路追踪平台，Ansible 和 Puppet 属于自动化配置管理工具，Nginx 才更接近常见的基础设施中间件。面试重点是理解它们解决什么问题、如何连接起来，不是背安装命令。

### 1. Zabbix

#### 它解决什么问题

Zabbix 用来监控服务器、网络设备、数据库和应用，例如 CPU、内存、磁盘、端口、进程和服务状态。

#### 核心组件

| 组件 | 作用 |
|---|---|
| Zabbix Server | 接收数据、计算触发器、产生告警 |
| Zabbix Agent | 安装在被监控主机上，采集主机数据 |
| Zabbix Proxy | 代理采集数据，适合跨机房或网络隔离场景 |
| Web Frontend | 管理配置、查看图表和告警 |
| Database | 保存监控数据和配置 |

#### 工作方式

```text
服务器 Agent -> Zabbix Server -> 数据库
                         -> Web 页面
                         -> 邮件、短信、企业微信
```

Zabbix 常见概念：

- Item：监控项，例如 CPU 使用率。
- Trigger：触发器，例如磁盘使用率超过 85%。
- Template：模板，把监控项、触发器和图表打包复用。
- Host：被监控的主机或设备。
- Discovery：自动发现主机、磁盘、网卡等资源。

#### 什么时候使用

传统数据中心、固定服务器、网络设备较多的企业，Zabbix 很常见。它的模板和界面比较成熟，适合运维人员使用。

#### 面试一句话

> Zabbix 是以主机和设备监控为主的综合监控平台，常通过 Agent 采集数据，再用 Item 和 Trigger 进行监控和告警。

### 2. Prometheus

#### 它解决什么问题

Prometheus 主要采集和查询时间序列指标，特别适合云原生、容器和动态服务环境。

#### 核心组件

| 组件 | 作用 |
|---|---|
| Prometheus Server | 拉取指标、保存时间序列数据、执行 PromQL |
| Exporter | 把主机或中间件数据转换成 Prometheus 指标 |
| Alertmanager | 告警分组、去重、抑制和通知 |
| Grafana | 查询 Prometheus 并绘制仪表盘 |
| Pushgateway | 接收短任务推送的指标，不适合普通长驻服务 |

#### 工作方式

```text
应用 / Exporter
        ↑ 拉取 /metrics
Prometheus Server -> Alertmanager -> 通知渠道
        ↓
     Grafana
```

Prometheus 的关键概念：

- Metric：指标名称，例如 `http_requests_total`。
- Label：指标标签，例如服务名、实例、状态码。
- Time Series：指标名称和标签组合形成的一条时间序列。
- Exporter：为数据库、主机、Redis 等提供指标。
- PromQL：查询、聚合和计算指标的语言。

#### 什么时候使用

Kubernetes、微服务、容器平台和动态扩缩容环境中非常常见。

#### 注意事项

- Label 不能无限增加，否则会产生高基数问题。
- 不要把用户 ID、订单 ID 等高变化字段作为 Label。
- 生产环境要规划数据保留时间和远程存储。
- 监控系统本身也需要监控，例如抓取失败和存储空间。

#### 面试一句话

> Prometheus 通过拉取模型采集带标签的时间序列指标，使用 PromQL 查询，通常配合 Exporter、Alertmanager 和 Grafana 使用。

### 3. ELK

#### 它解决什么问题

ELK 用于集中采集、存储、检索和分析大量日志，适合排查分布式系统问题。

#### 组成部分

| 名称 | 作用 |
|---|---|
| Elasticsearch | 分布式搜索和分析引擎，存储日志 |
| Logstash | 采集、解析、转换和转发日志 |
| Kibana | 查询日志、制作图表和仪表盘 |
| Beats | 轻量级采集器，例如 Filebeat |

#### 工作方式

```text
应用日志 -> Filebeat -> Logstash -> Elasticsearch -> Kibana
```

小规模场景可以省略 Logstash：

```text
应用日志 -> Filebeat -> Elasticsearch -> Kibana
```

#### 重要概念

- Index：日志索引，通常按日期或业务划分。
- Document：一条 JSON 日志记录。
- Field：日志中的字段，例如 `level`、`service`、`trace_id`。
- Mapping：字段类型定义，例如字符串、数字和时间。
- Shard：索引分片，用于分布式存储和查询。
- Replica：副本，用于容灾和提高查询能力。

#### 使用时注意

- 日志最好是 JSON 结构化格式。
- 索引应设置生命周期策略，自动删除过期日志。
- 生产环境要控制分片数量和字段数量。
- 不要把密码、Token、身份证号直接写入日志。
- Elasticsearch 磁盘接近满时可能停止写入。

#### 面试一句话

> ELK 是集中式日志平台，Filebeat 或 Logstash 负责采集和解析，Elasticsearch 负责存储检索，Kibana 负责查询和展示。

### 4. SkyWalking

#### 它解决什么问题

SkyWalking 用来做 APM，也就是应用性能监控和分布式链路追踪。它可以回答：一个请求经过哪些服务、每个服务耗时多少、哪个 SQL 或下游接口最慢。

#### 核心组件

| 组件 | 作用 |
|---|---|
| Agent | 插入应用进程，自动采集调用链和性能数据 |
| OAP Server | 接收、分析和聚合链路数据 |
| Storage | 保存链路、指标和拓扑数据 |
| UI | 展示服务拓扑、调用链、指标和告警 |

#### 工作方式

```text
应用 + SkyWalking Agent -> OAP Server -> Storage
                                      -> SkyWalking UI
```

#### 常见概念

- Service：一个应用服务。
- Instance：服务的一个实例。
- Endpoint：服务中的接口。
- Trace：一次完整请求的调用链。
- Span：调用链中的一个调用片段。
- Segment：一个服务内部的一段调用链。
- Topology：服务之间的依赖关系。

#### 排查接口慢的示例

```text
用户请求
  -> 网关 100ms
  -> 订单服务 3000ms
  -> 数据库查询 2800ms
```

此时问题重点不是网关，而是订单服务中的数据库查询。

#### 面试一句话

> SkyWalking 是分布式链路追踪和 APM 平台，通过 Agent 采集调用链，由 OAP Server 分析后在 UI 中展示服务拓扑和接口耗时。

### 5. Ansible

#### 它解决什么问题

Ansible 用于批量安装软件、修改配置、发布应用和执行巡检。它一般不需要在被管理机器上安装 Agent，控制端通过 SSH 或 WinRM 连接目标机器。

#### 核心概念

| 概念 | 作用 |
|---|---|
| Control Node | 执行 Ansible 的控制端 |
| Managed Node | 被管理的服务器 |
| Inventory | 主机清单和主机变量 |
| Module | 执行具体动作的模块 |
| Playbook | 用 YAML 描述自动化步骤 |
| Role | 可复用的目录化任务集合 |
| Handler | 配置变化后才执行的动作，例如重启服务 |

#### 工作方式

```text
控制节点 --SSH--> 多台目标服务器
```

#### 适合场景

- 批量初始化服务器。
- 批量安装 Nginx、Java、Python。
- 批量修改配置。
- 应用发布和回滚。
- 批量执行巡检。

#### Ansible 和脚本的区别

脚本通常描述“执行哪些命令”，Ansible 更强调“机器最终应该是什么状态”。因此 Ansible 更容易实现幂等、批量执行和变更审计。

#### 面试一句话

> Ansible 是无 Agent 的自动化配置和部署工具，通过 Inventory 管理主机，用 Playbook 和 Module 描述目标状态。

### 6. Puppet

#### 它解决什么问题

Puppet 也是配置管理工具，主要用于声明服务器的目标状态，例如某个软件必须安装、某个服务必须启动、某个文件必须存在。

#### 核心概念

| 概念 | 作用 |
|---|---|
| Puppet Server | 保存配置并向客户端提供 Catalog |
| Puppet Agent | 定期向 Server 拉取配置并执行 |
| Manifest | Puppet 配置文件，通常使用 `.pp` |
| Resource | 文件、软件包、服务等管理对象 |
| Facter | 收集主机事实信息 |
| Catalog | 根据配置和主机信息生成的目标状态 |

#### 工作方式

```text
Puppet Agent -> Puppet Server -> 返回 Catalog -> Agent 应用配置
```

#### Puppet 和 Ansible 的区别

| 对比项 | Ansible | Puppet |
|---|---|---|
| 常见模式 | 控制端主动执行 | Agent 定期拉取 |
| 客户端 Agent | 通常不需要 | 通常需要 |
| 配置风格 | YAML Playbook | 声明式 Manifest |
| 上手难度 | 相对简单 | 需要理解 Server、Agent 和 Catalog |
| 常见场景 | 发布、批量操作、临时自动化 | 长期配置一致性管理 |

岗位面试中如果没有 Puppet 实战经验，可以诚实回答：

> 我目前 Ansible 使用更多，理解 Puppet 的核心是基于 Agent、Manifest 和目标状态进行配置管理。两者都强调幂等和配置一致性，后续可以根据团队现有体系快速迁移。

### 7. Nginx

#### 它解决什么问题

Nginx 常用于静态文件服务、反向代理、负载均衡、HTTPS 终止和限流。

#### 正向代理和反向代理

- 正向代理：客户端通过代理访问外部资源，服务器不知道真实客户端。
- 反向代理：客户端访问 Nginx，Nginx 再转发到后端应用，客户端不直接接触后端。

#### 常见架构

```text
用户 -> Nginx -> Web 服务 1
              -> Web 服务 2
              -> Web 服务 3
```

#### 关键配置

```nginx
upstream backend {
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
```

#### 常见状态码

| 状态码 | 含义 |
|---|---|
| 200 | 请求成功 |
| 301/302 | 重定向 |
| 403 | 没有权限访问 |
| 404 | 资源不存在 |
| 502 | Nginx 连接后端失败 |
| 504 | 后端响应超时 |

### 8. systemd

systemd 是 Linux 中负责系统启动和服务管理的组件。它不是监控平台，但运维岗位经常使用。

常见命令：

```bash
systemctl start app
systemctl stop app
systemctl restart app
systemctl status app
systemctl enable app
journalctl -u app -f
```

一个简单的服务文件：

```ini
[Unit]
Description=Demo Web Service
After=network.target

[Service]
User=webapp
WorkingDirectory=/opt/webapp
ExecStart=/usr/bin/python3 /opt/webapp/app.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
```

修改服务文件后：

```bash
systemctl daemon-reload
systemctl enable --now webapp
systemctl status webapp
```

### 9. Redis

Redis 是内存型 Key-Value 数据库，常用于缓存、分布式锁、Session、排行榜和消息队列。

常见风险：

- 内存不足导致淘汰或写入失败。
- 没有密码和网络隔离导致未授权访问。
- 缓存击穿、缓存穿透和缓存雪崩。
- 大 Key 或热 Key 导致性能问题。
- 持久化和高可用配置不合理。

面试回答缓存问题时要提到：过期时间、随机过期、互斥锁、空值缓存、限流、监控内存和命中率。

### 10. 这些组件如何组合

一个典型的运维平台可以是：

```text
用户请求
   -> Nginx
   -> 应用服务
      -> Redis / MySQL / 其他下游

应用和主机指标 -> Prometheus -> Alertmanager -> 通知
主机和设备监控 -> Zabbix -> 通知
应用调用链 -> SkyWalking
应用日志 -> Filebeat -> Logstash -> Elasticsearch -> Kibana
批量部署和配置 -> Ansible
故障诊断 Agent -> 查询以上系统 -> 生成报告
```

## 九、工具学习优先级

### 第一优先级：必须掌握

Linux、网络排障、Python 基础、Prometheus 基础、日志分析、Ansible 基础、部署和回滚。

### 第二优先级：需要理解

Zabbix、ELK、SkyWalking、Nginx、systemd、Redis、告警设计。

### 第三优先级：面试前形成案例

选择一个 AI 编程或 Agent 工具，完成一个“查询监控和日志并生成故障报告”的小项目。

### 暂时不必深入

不需要一开始就深入所有工具的源码、集群调优和底层实现。先做到：知道解决什么问题、会画架构、能讲数据流、会处理常见故障、能说清安全风险。