是石科技运维工程师

Admin

13 Sep 2026 — 9 min read

1. 常用运维命令有哪些？

系统类：

负载/内存/磁盘：top / htop 看负载，free -h 看内存，df -h 和 du -sh 看磁盘，uptime 看负载均值
进程排查：ps aux 配合 grep 找进程
端口/连接：netstat 或 ss
系统加固：用户权限管理（useradd、passwd）、权限设置（chmod、chown）
日志查看：tail -f 实时跟踪、grep 过滤，配合 journalctl 查 systemd 日志

网络类：

ping 测连通性，ip addr / ip route 看地址和路由
traceroute 定位网络故障点
netstat / ss 看 TCP 连接状态
排查不通时从本机环回 → 网关 → DNS 逐层往下查

数据库类（以 MySQL 为例）：

会写 SQL、做表设计、看慢查询
熟悉主从复制和备份恢复流程：mysqldump 做备份、binlog 做恢复

容器 & K8s（运维核心）：

Docker：docker ps 看容器、docker images 看镜像、docker logs 看日志、docker exec 进容器、docker-compose 起服务
K8s：kubectl get nodes、kubectl get pods、kubectl get svc、kubectl logs、kubectl describe 定位 Pod 状态

文件类：

看内容 cat、实时跟踪 tail -f
文本处理 grep、awk、sed
找文件 find，压缩解压 tar

2. CPU 占用高如何排查？

核心分三步：

先看 top，确认是否真是 CPU 忙。 注意 us、sy、wa 指标——如果 wa 高，那不是 CPU 问题，而是磁盘 IO 拖慢的，应该去查磁盘。
定位进程。 top 里按 P 键按 CPU 排序，或用 ps aux --sort=-%cpu 锁定占用进程；想更细就用 top -Hp 进程号 看具体是哪个线程，配 pidstat 也可以。
判断正常还是异常。 对比该进程平时的基准占用，看是不是周期性任务或业务高峰期。正常负载一般不动或考虑扩容；异常情况（死循环、频繁 GC、可疑进程）才处理。

补充：CPU 莫名飙高有时是安全事件的信号，会顺带排查有没有异常进程或外连。

3. 磁盘 100% 故障排查

先判断是"满了"还是"忙了"。

满了（空间耗尽）：

用 df -h 看各分区使用率，定位到 100% 的分区
用 du -sh 加路径或 * 逐层往下，找出占用空间的目录和文件
常见大户：日志文件、临时文件、数据库 binlog、core dump
针对性清理：日志归档清理、删临时文件、清理 docker 镜像和容器数据；涉及业务时先确认，避免误删生产数据

忙了（IO 高）：

iostat 看 %util 和 await
iotop 定位是哪个进程在疯狂读写
常见原因：大查询、备份任务、日志刷盘、应用扫表

4. 服务启动失败怎么排查

按从近到远的顺序排查：

先看报错（最快路径）。 systemctl status 看服务状态和最近日志，或用 journalctl -u 服务名 看启动日志。多数问题日志里写得明明白白：配置文件写错、端口被占用、依赖服务没起来。
看资源。 磁盘满了、内存不够、文件句柄超限也会导致起不来，用 df、free、ulimit 查。
看配置和权限。 配置语法对不对、关键目录和文件权限属主对不对（比如 systemd 里有没有写错路径）。
前台直接跑命令。 如果服务本身起不来，直接前台执行可执行文件，能看到交互式报错，比看日志更直观。

原则：先读日志、先确认原因再动手，不盲目重启掩盖问题。定位根因后针对性修复，修完重启验证状态，确认稳定再交付。

5. ping 通但 telnet 端口不通有哪些原因？

ping 通说明网络层是通的，端口不通问题基本出在传输层或应用层，按四个方向排查：

服务没起来或端口没监听。 在目标机器上用 ss -lnt 或 netstat 确认端口是否有 LISTEN，服务没起端口自然不通。
防火墙拦截（常见）。 本机 iptables/firewalld 或云安全组没放行端口，数据到了但被拦。用 firewall-cmd --list-all 或 iptables -L 查规则，安全组查入站规则。
服务只监听了特定地址。 比如只绑了 127.0.0.1 而非 0.0.0.0，外网或跨机器就连不上。用 ss -lntp 看监听地址。
代理或中间设备拦截。 可能性较低，排查优先级靠后。

排查顺序：从本机到目标、从服务到网络，一层层查。

6. 排查网络故障的思路

核心思路是"自下而上、分层定位"，从底层往上逐步缩小范围：

确认链路通不通。 先 ping 目标，不通再 ping 网关，判断是本机、中间链路还是目标端问题；用 ip addr 看网卡 IP，ip route 看默认网关。
测端口。 通了不代表端口通。用 telnet IP 端口 或 nc 测端口；本机用 ss -tlnp 看是否监听、是否被防火墙挡。
查 DNS。 IP 通但域名不通多半是 DNS，用 nslookup 或 dig 确认。
抓包定位。 查不出就用 tcpdump，看 SYN、ACK、RST 标志位：SYN 发出去没回应可能是丢包或被防火墙拦，收到 RST 是被主动拒绝。
按现象分类处理。
- 完全不通 → traceroute 看卡在哪一跳
- 时通时断 → mtr 或 ping -f 查丢包
- 通但慢 → 看带宽或服务处理能力
- 通但被拒 → 优先查防火墙规则和服务状态

7. 用过什么监控系统？

最熟：Prometheus + Grafana。 实战搭过，能配置采集指标、写告警规则，用 Grafana 做可视化看板，是现在云原生环境的主流方案。
Zabbix： 了解整体监控方案，适合传统服务器和主机监控。
日志监控：ELK/EFK。 Elasticsearch、Logstash/Fluentd + Kibana，做日志采集、检索和可视化，用于排查问题和观察运行状态。

8. 会不会 Shell 脚本？

基础 Shell 会写，能完成常规运维任务，比如日志清理、批量处理文件、定时备份、遍历目录等。

但诚实地说，Shell 不是我的强项——awk、sed 这类高级文本处理和复杂正则还需要查资料。遇到没把握的语法先查再写，写完反复测试，避免在生产环境出问题。

9. 是否接受值班、夜班、故障加班？

接受。 值班、夜班、故障加班本身就是运维岗位的常态，投这个岗位就是认可并准备好接受这个节奏。

作息上没问题： 年轻、没有家庭负担，正是能扛的年纪，夜班倒班、节假日值守都能接受，不会因值班安排跟公司讲条件。
故障加班有原则： "故障就是命令"——真出了紧急问题，该连夜处理就连夜处理，不会因为下班或值班结束就撒手不管。
了解公司业务： AI 基础设施对稳定性和可用性要求高，监控、告警、应急响应基本是 7×24 的，理解并接受。
心态： 不是被动应付，而是把它当成锻炼机会——夜班和故障正是积累排障经验、提升应急能力最快的场景。

10. 期望薪资

结合运维岗位和重庆行情：

实习/入门阶段：期望月薪 3000–4000 元
正式运维工程师岗：希望 6000–8000 元

可以谈，也愿意接受基于能力和培养方案的合理定级。

11. 为什么选择是石科技？

① 赛道和公司方向。 提前了解过，是石科技是清华系背景、专注超智融合方向，核心做高性能计算和 AI 解决方案，目标是让 AI 落地到产业，最近刚完成数亿元 A 轮融资，还在布局 Token 优化工厂这类 AI 基础设施方向。做运维最看重平台的技术含量和成长性——AI 基础设施对稳定性、算力、监控要求都很高，正好是运维最能学到东西、最有价值的场景。这种高速成长、技术驱动的公司最有吸引力。

② 岗位匹配。 技术栈（Linux、数据库、容器 K8s、监控、自动化运维）正好是 AI 基础设施运维的核心能力。有一定基础不是从头学起，能较快上手、较快给团队带来帮助。

③ 稳定和长远考虑。 希望找一个能长期深耕的平台，不是干一阵就走，而是想跟着公司在 AI 路上一起成长，从运维做起，往云原生、AI 运维方向沉淀。

总结：平台有前景、方向契合技术、愿意长期留下，这三条是我选择是石科技的原因。

12. 2-3 年个人职业规划？

短期（第一年）：打牢基础、尽快独立。 把手头运维做扎实——服务器、监控告警、故障排查、值班响应，争取尽快从"有人带"到"能独立处理常规问题"，摸熟业务、系统架构、流程规范。这一年把基本功练到位，让团队放心把任务交给我。

中期（第二到三年）：往一个方向深耕、形成专长。 运维面很宽，会结合公司业务方向，往云原生、容器 K8s 深扎——AI 基础设施方向云原生、自动化、平台化运维会是主流。希望这两年把运维自动化、监控体系、稳定性保障做深，能独立负责一块系统的运维，参与架构和优化工作，慢慢从"执行者"走向"能独立负责"。

长期： 往 AI 运维、平台工程方向沉淀，成为该领域能独当一面的运维工程师。但当下更愿意先把手头的事做好，一步步来。