语之溪
以前我更多是在接口、页面和数据之间排查问题。到了 2024 年 1 月，我开始接触一些接口之外的工程工作：竞赛平台的流程测试、服务器相关操作，以及部署环境中常见的 Linux、Shell、Nginx、Frp 和 Docker。
这些内容并不是一次性全部掌握的。它们出现在同一段工作里，但我参与的方式不同：有些是平台功能测试和问题修改，有些是通过资料学习和实际操作逐步熟悉。
先从平台流程测试开始
1 月初，我继续处理竞赛平台的问题和功能优化，包括红蓝态势中的实时攻击信息、靶机状态、比赛记录日期格式，以及用户是否已经结束比赛等状态。
随后又参与了态势推送、红蓝指挥官分配靶机接口和被占领信息等问题的修改。平台功能之间联系比较多，一个页面上的数据往往来自多个接口，修改后不能只看单个接口返回是否正常，还需要回到完整流程中继续验证。
到 1 月 22 日，测试范围进一步扩大。我参与检查后台的试题中心、试卷中心和比赛设置，也检查前台列表页、信息页、任务页和答题页等页面。答题记录、排名、前后台态势推送等接口数据在这轮测试中均正常。
这里的“正常”是这次测试记录中的结果，并不等同于平台所有功能永久没有问题。测试只能说明在当时的测试范围和条件下，相关流程通过了检查。
Linux 和 Shell 是更基础的工具
1 月 22 日到 26 日，我回顾了 Linux 基本操作，也尝试编写简单的 Shell 脚本。
对开发工作来说，Linux 命令并不只是运维人员才会使用。查看文件、检查进程、确认端口、读取日志和执行脚本，都可能成为定位问题时需要做的事情。不过，接触这些命令不等于负责整台服务器，也不等于已经建立完整的生产运维能力。
公开资料中常见的排查顺序大致可以抽象成：
确认主机和服务
-> 查看进程与端口
-> 检查日志和配置
-> 验证请求链路
-> 记录结果并继续复测这是通用排查思路，不对应内部服务器、IP 或具体命令。实际环境中的账号、路径和配置不能直接公开。
Shell 的价值则在于把重复操作组织起来。例如，检查多个服务状态、整理日志文件或执行固定的测试步骤时，脚本可以减少手工操作。但脚本在真实环境中使用前，还需要考虑权限、路径、错误处理和重复执行的影响。
Nginx 和 Frp 让我看到请求链路
这一周我也了解了 Nginx 和 Frp 反向代理相关知识。
从通用概念看，反向代理位于客户端和后端服务之间，可以接收请求，再根据配置转发到目标服务。这样一来，浏览器访问的地址、代理层和后端服务之间就形成了一条请求链路。
客户端
-> 代理层
-> 后端服务
-> 数据或其他内部服务排查接口问题时，如果只看应用代码，可能会忽略代理配置、转发路径、端口和连接方式。了解 Nginx 和 Frp 的基本作用后，我开始意识到，请求能否到达应用，并不只由 Controller 或接口方法决定。
这里的示例只用于解释公开的通用概念，不代表内部环境采用了某个具体配置。域名、IP、端口、隧道参数和服务器信息都不属于公开内容。
Docker 和 docker-compose
我还熟悉了 Docker 基本命令，以及使用 docker-compose 搭建项目的相关知识。
Docker 可以把应用及其运行环境组织在相对独立的容器中。docker-compose 则常用于用一个配置文件描述多个相关服务，以及它们的网络、端口和依赖关系。
通用的工作流程可以理解为：
准备配置
-> 构建或获取镜像
-> 启动服务
-> 查看日志和状态
-> 修改配置后重新验证实际使用时，配置文件里的镜像、端口、挂载目录和环境变量都可能涉及敏感信息，不能把内部配置直接当作文章示例。公开文章只能介绍工具的作用和一般排查思路。
开发和工程工作并不是两条完全分开的线
这一阶段让我看到，接口开发和服务器相关工作经常会互相影响。接口是否可用，可能要经过代理层；页面是否正常，可能要结合服务状态和日志；迁移或态势功能是否稳定，也可能需要在不同环境中反复测试。
但“接触到这些工程工作”和“负责完整生产运维”是两件不同的事。根据当时的工作记录，我能够确认的是：参与平台功能测试和问题修改，回顾 Linux 基本操作，学习简单 Shell 脚本、Nginx、Frp、Docker 和 docker-compose。
截至现在，我还在继续补充这些知识。对我来说，这不是从 Java 开发突然转成运维，而是开始理解一项功能从代码、服务到请求链路之间是怎样连接起来的。
