1、linux命令简表

2、AI Agent vs ChatOps区别和联系
（1） 本质不同
AI Agent：AI 能力模型（会思考、会规划、会用工具的智能体）
ChatOps：运维协作模式 / 工作流（把操作放进聊天窗口）
（2） 关系（重点）
AI Agent 可以赋能 ChatOps，让聊天运维更智能：
传统 ChatOps：你发固定指令（如 “重启服务”）→ 机器人执行
AI Agent + ChatOps：你说自然语言（如 “订单服务最近 5 分钟报错多，帮我排查并恢复”）→ Agent 理解意图→自己查监控→自己看日志→自己定位问题→自己执行恢复→自己报告结果
（3） 一句话总结关系
ChatOps：聊天窗口当运维控制台（执行层）
AI Agent：给这个控制台装上大脑，能理解自然语言、自主排障、自动决策（智能层）
（4）极简版解释
AI Agent
基于大模型，具备自主规划、工具调用、记忆、决策能力，能目标驱动、端到端自主执行复杂任务的智能系统。
ChatOps
将运维操作、自动化、协作集成到聊天平台，以对话式指令驱动运维工作，实现聊天即操作、透明协作、可审计、快速响应的 DevOps 协作模式。

3、CDN内容分发网络

把网站的图片、视频、JS、CSS、静态资源，提前缓存到全国各地、全球各地的边缘服务器节点。用户访问时，不走远路回源站，从离自己最近的节点拿资源，速度飞快。

（1）访问速度极快
图片、视频加载飞快，网页不卡顿。
（2）减轻源服务器压力
大部分请求都被 CDN 节点承接，原始服务器很少被访问，不容易被流量打崩。
（3）抗攻击、防流量雪崩
秒杀、热搜爆量流量，CDN 先挡住，保护源站。
（4）跨地域访问快
南方用户、北方用户、海外用户，都有就近节点。

4、Devops模式

定义：DevOps = Development（开发）+ Operations（运维），它不是单一软件、不是岗位，而是一套文化理念、工作流程、工具体系，核心是拆掉开发与运维之间的部门墙，打通软件从写代码、测试、上线、运行、监控、迭代的全流程，实现更快、更稳、更高质量的软件交付。

（1）先搞懂：它解决什么痛点（传统开发的问题）
传统公司分工割裂：
开发（Dev）：只负责写代码、实现功能，写完就交给运维，不管线上环境、部署、故障。
运维（Ops）：只负责服务器、上线、保稳定，不懂代码，害怕开发频繁更新搞崩系统。
日常矛盾：
开发：我电脑上运行好好的，是你环境有问题！运维：你代码没测试、没适配生产环境，上线必崩！
导致问题：上线慢、版本迭代慢、故障多、沟通扯皮、重复手动操作多、出问题互相甩锅。
（2）DevOps 三层核心（完整体系）
1）文化层（最根本）
团队共同负责、全员协作、打破壁垒；开发也要关心线上稳定，运维也要参与交付流程，谁构建、谁负责，不再各管一段、互相推诿。
2）流程层（核心闭环）
完整生命周期：规划→开发→构建→测试→发布→运维→监控→反馈→迭代，全程自动化循环，核心四大概念：
CI 持续集成
开发频繁提交代码，自动编译、自动单元测试，尽早发现代码 bug，避免代码堆积、集成冲突。
CD 持续交付
代码测试通过后，自动打包、准备好发布包，随时可上线，无需人工繁琐操作。
持续部署
满足条件自动发布到测试 / 生产环境，实现小版本高频上线。
持续监控
线上服务实时监控、日志收集、故障告警、数据反馈，反过来优化代码。
3.）工具层（落地工具链）
靠工具实现全流程自动化，主流常用工具：

DevOps 模式：全自动智能工厂，代码提交后，自动检测、打包、测试、上线、监控、反馈，全程无人值守，高效稳定。

5、shell实践

题目：

请编写标准Shell 脚本，实现以下全部需求：
定义需要监控的 游戏服务核心端口：80、443、8080、9090
遍历检测每一个端口是否在服务器上正常监听
端口正常监听，输出格式：【正常】端口xxxx 服务运行正常
端口未监听无服务，输出告警格式：【告警】端口xxxx 未正常监听，请立即检查游戏服务进程！

#!/bin/bash
# 游戏服务待监控端口数组
monitor_ports=(80 443 8080 9090)

# 遍历所有端口进行监听状态检测
for port in ${monitor_ports[@]}
do
    # 检测端口是否存在TCP监听
    if netstat -ntlp | grep -q ":${port} "
    then
        echo "【正常】端口${port} 服务运行正常"
    else
        echo "【告警】端口${port} 未正常监听，请立即检查游戏服务进程！"
    fi
done

6、游戏运维简答内容

1. 简述 SRE、DevOps 概念及二者关系
DevOps：是一套研发运维全流程理念，核心是打破开发、测试、运维团队壁垒，消除流程隔阂，通过工具链实现代码提交、构建、测试、上线、迭代全链路自动化，提升软件交付效率。SRE：站点可靠性工程，是 DevOps 理念的工程落地实践方向，以服务稳定性、SLA 指标为核心，专注于线上服务可用性保障、故障预防、故障自愈、容量规划、监控体系建设，用数据量化运维工作。二者关系：DevOps 是宏观全流程理念体系，SRE 是 DevOps 体系里线上稳定性运维方向的标准化工程方法论；DevOps 打通交付全链路，SRE 负责链路上线后的服务稳定性保障、指标管控，二者相辅相成。
2. 小游戏业务 CDN 应用价值
访问加速：小游戏海量静态资源（页面、素材、小游戏安装包）边缘节点缓存，全球用户就近访问，大幅降低访问延迟，提升打开速度。
源站减负：将海量用户静态资源请求分流至 CDN 边缘节点，极大降低 游戏源站服务器的带宽与访问压力。
高可用抗峰值：应对节假日、开服流量突发洪峰，CDN 节点承接海量边缘流量，抵御流量冲击，保障源站核心业务稳定。
全球服务覆盖：补齐多地域线路资源，实现全球不同地区用户都能高速稳定访问小游戏服务。
3. ChatOPS 定义 + AI Agent 结合的游戏运维落地价值
ChatOPS 定义：对话式运维，是以大语言模型作为交互入口，结合 AI Agent 技术，将全部运维能力集成到对话交互平台，通过自然语言对话完成全量运维工作的新型运维模式。落地价值：
操作门槛降低：运维人员用日常自然语言对话，即可完成服务器查询、端口状态、服务存活、日志检索等常规操作，无需记忆大量 Linux 命令。
告警智能处置：线上游戏服务告警触发后，自动拉取日志、分析故障根因、给出排查方案，甚至自动执行修复自愈操作。
运维效率提升：自动化完成日常巡检、资源监控、任务执行，解放重复人工运维工作。
团队协同与可追溯：统一运维操作对话平台，所有操作全程可追溯，方便团队技术共享、经验沉淀，适配团队协作运维。
4. 系统平均负载 Load Average 含义 + 高负载排查步骤
含义：单位时间内，Linux 系统中正在运行、以及等待 CPU 调度的所有进程的平均数量，是衡量服务器系统整体繁忙程度的核心指标。完整排查步骤：
1）top 命令查看整体负载数值、CPU 总体使用率，确认负载严重程度；
2）进程资源排序：top内按P排序 CPU 占用进程、M排序内存占用进程，定位高资源消耗异常进程；
3）磁盘 IO 瓶颈排查：iostat 查看磁盘读写 IO、等待队列，排查游戏大量日志写入导致的 IO 阻塞；
4）系统上下文切换分析：vmstat 查看进程等待、线程切换情况，排查进程调度瓶颈；
5）进程归属判定：区分正常游戏业务进程、后台异常进程 / 僵尸进程，针对性做限流、重启、清理处理；
6）业务侧复盘：结合游戏业务流量，分析负载高是正常业务流量，还是服务异常导致的资源占用异常。

7、服务等级协议SLA

SLA 即服务等级协议，是服务提供方与用户约定的质量保障条款，规范系统可用率、故障响应、修复时效，未达标需承担赔付责任，常用于运维、云服务、企业信息化场景。

• 可用性（可用率）系统正常能访问的时间占比例：99.9%、99.99%、99.999%

• 响应时间故障上报后，工程师多久开始处理

• 修复时间（MTTR）故障出现到完全解决、恢复业务的时长