企业官网建设流程全解析

2018年那会儿，京东秋招技术运维工程师的笔试，在圈子里算是出了名的“硬”。不少朋友考完都说，题量大、跨度广，Linux、网络、数据库、Shell脚本一个不落，最后甚至还有一道编程题和几道让人挠头的逻辑推理。我当时也帮不少学弟学妹做过复盘整理，结合当年考生群里反馈出来的题目方向，这套笔试题的核心思路其实非常清晰：它不考死记硬背的冷门参数，而是看你有没有一个真正在生产环境干过活的“运维脑”。这篇文章我就把当年考察最集中的几个方向，连同答题思路、易错点、以及放到今天依然适用的备战方法，一并梳理出来。

1. 京东2018秋招运维笔试到底在考什么

1.1 笔试整体结构与考察思路

从当年考生反馈来看，运维岗笔试题型大致分为四块：选择题、填空题、简答题和最后的编程/综合题。选择题覆盖范围很广，从Linux命令到网络协议都有；填空题更变态，经常让你直接写命令或补全一段配置，完全没法蒙；简答题则偏重故障排查和方案设计；最后的编程题难度不算高，但如果你平时只会在Windows上点点点，那一下就能看出差距。

考点占比我根据记忆梳理了一下，大概是这个分布：

这个出题结构其实很有代表性。电商业务对稳定性要求极高，每年618、双11大促都是运维团队的“大考”，所以笔试非常看重候选人处理真实问题的能力。它不是很想招一个“只会背命令但不知道在什么场景下用”的人，而是希望候选人能快速定位问题、规范化操作、有自动化意识。

1.2 几个容易被忽略的隐藏考点

有一种题目，表面上看是在考命令，实际上是在考你对系统底层机制的理解，这类题最容易拉开差距。

比如问“磁盘空间明明充足，应用却报错无法写入”，很多人第一反应是看df -h，但真正的问题可能是inode耗尽了，要看到df -i那一行才能确认。再比如“进程用kill -9杀不掉”，十有八九是进程处于D状态（不可中断睡眠），正在等待磁盘IO返回，这种时候硬杀没用，得先解决底层存储问题。

还有一类题喜欢考配置文件加载顺序。比如/etc/profile、~/.bashrc、~/.bash_profile的区别，一个普通登录shell和一个非登录shell加载的文件完全不一样。如果你在生产环境帮别人改过环境变量，就会知道乱改全局配置可能导致所有终端异常，这种“吃过亏”的经验，笔试里是能体现出来的。

这些隐藏考点提醒我们，笔试只是把日常运维中的“坑”换了个形式呈现在卷面上。真正干过活的人，看到题目会立刻联想到当时的故障场景，答题自然就准。

2. Linux与Shell脚本：运维笔试的绝对主力

2.1 高频Linux命令与系统管理题目

Linux命令是绝对的重点，但考的往往是“理解”而不是“记忆”。比如查看系统负载，命令有uptime、top、w，这些都是基础中的基础。容易出错的点在于理解负载值的含义——1分钟、5分钟、15分钟三个负载值，不能只看当前值，要结合起来判断负载是在上升还是下降。再结合CPU核数来看，负载长期大于核数几十倍，那就要考虑扩容或者排查死循环进程了。

磁盘相关的高频题也不少。df -h看整体空间，du -sh看目录占用，这两条几乎必考。但深入一点就会问：为什么df显示空间充足，但文件创建失败？答案就是inode耗尽或者文件系统只读。这种题目一旦出现，基本就能筛掉一批没有实战经验的人。

进程管理也是常客。ps aux和ps -ef的区别，如何找出CPU占用最高的5个进程，kill -9和kill -15的区别——别小看kill，15是让进程优雅退出，9是强制杀掉，很多服务在退出前要做状态清理，直接kill -9容易留下脏数据。笔试里我见过问“如何让一个进程在退出前执行清理脚本”的题目，答案其实就是先用kill -15发SIGTERM信号，让应用自己捕获并处理。

常用命令我再列几个考得多的：

• find的-mtime、-name、-type、-size组合，比如“查找7天前修改的.log文件”
• ln -s软链接和硬链接的区别，硬链接不能跨文件系统，软链接可以
• chmod的数字权限和特殊权限位，比如setuid、setgid、sticky bit
• tar打包配合cron做定时归档，gzip压缩级别怎么选

这些题目不复杂，关键是熟练度。笔试时间紧，如果你每条命令都要现场想半天，后面的大题肯定做不完。

2.2 Shell脚本题的典型出题套路

Shell脚本几乎每年都有，出题方向也比较固定，总结起来就是四类：日志清理、数据备份、批量操作、日志分析。

日志清理脚本是经典中的经典，标准答案大概长这样：

#!/bin/bash LOG_DIR=/var/log/myapp find $LOG_DIR -name "*.log" -mtime +7 -exec rm -f {} \;

但实际答题时，我会建议你多想一层。直接find加-exec删除，在生产环境是有风险的，万一路径写错，可能把不该删的删了。更好的写法是先统计一下将要删除的文件列表，再执行清理：

#!/bin/bash LOG_DIR=/var/log/myapp DEL_LIST=$(find $LOG_DIR -name "*.log" -mtime +7) if [ -n "$DEL_LIST" ]; then echo "$DEL_LIST" > /tmp/cleanup_$(date +%F).log echo "$DEL_LIST" | xargs rm -f fi

这样既保留了可追溯的审计日志，又避免了误删后无据可查。答题时体现出“先备份后删除”“操作可回滚”的思路，面试官会非常加分，因为这才是生产的常态。

数据备份脚本也很常见。比如“将/var/www目录打包并保留最近7份备份”，核心是控制备份数量和文件名格式：

#!/bin/bash BACKUP_DIR=/backup tar czf $BACKUP_DIR/www_$(date +%Y%m%d_%H%M%S).tar.gz -C /var www find $BACKUP_DIR -name "www_*.tar.gz" -mtime +7 -delete

这里用$(date +%Y%m%d_%H%M%S)生成带时间戳的文件名，是运维脚本里的共识写法，既避免文件覆盖，也方便后续回溯。

批量操作类题目，比如“给100台服务器批量创建用户”，那就要用到循环和远程执行：

#!/bin/bash for ip in $(cat server_list.txt); do ssh user@$ip "useradd newuser && echo 'passwd' | passwd --stdin newuser" done

这个脚本在笔试里看起来简单，但实际运行会有无数幺蛾子——有些服务器ssh端口不同、有些host key校验过不去、有些系统没有passwd --stdin参数。所以笔试答案和真实落地是两回事，但你起码要在答案里展示出“用循环批量处理+考虑异常情况”的意识。

2.3 文本处理三剑客的实战用法

grep、sed、awk这三件套，是运维笔试里几乎绕不开的组合拳。有一道题出现的频率极高：“统计nginx access.log中访问次数最多的10个IP”，标准答案就是：

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

这条命令看着简单，但每一步都有讲究。awk默认按空格切分，日志的第一列正好是客户端IP；sort先排序是为了让uniq能正确合并相同IP；uniq -c统计出现次数；sort -rn按次数逆序排序；head -10取前10名。每一步缺了都不行，比如不用sort直接uniq -c，重复IP分散在不同的位置就统计不到一块去。

再看一个考点：用sed替换文件内容。比如把配置文件中所有“127.0.0.1”替换成“0.0.0.0”：

sed -i 's/127.0.0.1/0.0.0.0/g' /etc/nginx/nginx.conf

这里要注意的是：

• 不加g只替换每行第一个匹配
• -i是直接修改文件，不加-i只是预览输出
• 如果替换内容包含特殊字符，需要用其他分隔符，比如s#old#new#g

awk还有两个高频考点：按多个字符分隔（-F'[ :]'）、取倒数第一个字段（$NF）。比如从日志中提取响应时间这一列，可能是最后一个字段，直接用$NF就行。笔试中对awk的要求一般不高，能用它完成日志统计、字段提取就够80分了。

3. 网络基础与故障排查：判断你是不是“真运维”

3.1 网络概念题的高频命题点

网络部分的选择题和填空题，考点非常集中。TCP三次握手和四次挥手几乎是必考，TIME_WAIT尤其受欢迎，因为生产环境的连接问题十有八九和它有关。TIME_WAIT是主动关闭一方进入的状态，需要等待2MSL（最大报文段生存时间）才能完全关闭，目的是防止旧连接的数据包干扰新连接。如果线上服务器TIME_WAIT过多，一般就是短连接太频繁，解决办法是开启tcp_tw_reuse、调整tcp_fin_timeout，或者把短连接改成连接池。

HTTP状态码也是高频考点，需要记牢的有这几个：

笔试里不只是问状态码含义，还会让你根据状态码判断问题出在哪一环。502和504的排查路径就完全不同：502通常是后端进程挂了或连接数打满，504通常是后端处理超时或者PHP/Java慢查询导致。

DNS解析流程也是常客。完整的解析链路是：浏览器缓存→本地hosts文件→本地DNS服务器→根DNS服务器→顶级域服务器→权威DNS服务器。考题经常问“修改了DNS记录后为什么还没生效”，答案就是各个缓存节点的TTL还没过期，需要在TTL到期后重新解析。

3.2 从一道网络故障题看排查思路

简答题非常喜欢出“故障排查”类，直接给你一个场景让你写排查步骤。我印象比较深的一道题是：“用户反馈访问公司网站间歇性超时，请描述排查思路。”这种题没有唯一答案，但好的答案必须体现“分层排查”的思路。

我通常建议的答题框架是：

1. 先确认范围：是单个用户问题还是大面积问题？先看监控大屏，判断是否有地域性、运营商差异。
2. 再走基础链路：客户端ping一下域名，看是否通、延迟多少；再用dig查DNS解析是否正常，看解析出的IP是否正确。
3. 接入层排查：如果是Nginx做入口，检查Nginx错误日志和upstream状态，看后端server是否全部在线。
4. 应用层排查：检查后端应用进程是否存活，GC是否频繁，数据库连接池是否被打满。
5. 深入网络内核：用ss统计TIME_WAIT、CLOSE_WAIT数量，看连接是否堆积；用tcpdump抓包看是否有大量重传；检查是否触发防火墙限流。

这样组织答案，面试官一眼就能看出你有过真实排障经验，而不是只会几个命令。另一种常见考法问“服务器CPU正常但页面响应慢”，那就需要换一个思路：先看网络链路时延，再看后端依赖服务是否变慢，最后用trace链路定位到具体模块。核心原则是不管什么问题，都要有顺序、有依据、有结论。

3.3 看完这篇能直接拿分的网络命令

网络命令在笔试填空里也经常出现。我按用途整理了一个速查表，方便你考前过一遍：

这里我想特别提一下curl的-w参数，很多人不知道它能输出请求各阶段耗时。笔试如果考“如何测量一个接口的响应时间”，答案除了time curl之外，更精细的就是用curl -w输出DNS时间、连接时间、首字节时间、总时间，这样能快速定位慢在哪一段。这个技巧在真实排查中非常有用，是一道性价比很高的工具题。

4. 数据库、监控与常见中间件考点

4.1 MySQL笔试基础题与易错点

数据库在运维笔试里的占比不算最高，但一旦出现就很有区分度。MySQL的索引是必考方向，一般会问“为什么MySQL用B+树而不是B树或哈希索引”。答题要点是：B+树所有数据都在叶子节点，叶子节点用链表串联，非常适合范围查询和排序，同时树的高度可控，IO次数少。哈希索引只适合等值查询，无法处理范围。

SQL编写题也经常出现，比如“统计每个用户的订单总数”“查询最近7天下单量最高的用户”。这类题没什么捷径，就是多写。但运维视角和开发视角不同，运维更关心查询效率，所以附加问法往往是“这条SQL怎么优化”，考点就是explain。

explain的输出里，type是关键，从好到差依次是system>const>eq_ref>ref>range>index>ALL。效率最差的就是ALL全表扫描。笔试里看到一个SQL，应该能判断是否需要为where、join、order by的字段建立组合索引。还有一个常见易错点：对索引列使用函数或隐式类型转换，会导致索引失效。比如idx_create_time字段上写了WHERE DATE(create_time)='2024-01-01'，这就没法走索引，要改成WHERE create_time >= '2024-01-01 00:00:00' AND create_time < '2024-01-02 00:00:00'。

主从复制也是高频题。核心流程是：主库把变更写入binlog，从库的IO线程拉取binlog并写入relay log，从库的SQL线程再执行relay log中的操作。笔试常问“主从延迟怎么排查”，答案一般包括：

• 查看Seconds_Behind_Master指标
• 查看从库磁盘IO是否占用过高
• 检查是否有大事务长时间未提交
• 检查从库是否在做备份等密集读写操作

最后还要记得：mysqldump是逻辑备份，导出来一般是SQL文件；xtrabackup是物理备份，直接拷贝数据文件，备份和恢复速度更快。生产环境大库一般用xtrabackup，小库用mysqldump就够了。

4.2 监控系统与告警策略相关考点

监控题看起来很简单，但想答出彩不容易。基础问答通常是“一个完整的监控体系应该包含哪些维度”，标准答案是：硬件层（CPU、内存、磁盘、网络、温度）、操作系统层（文件句柄、进程、负载）、应用层（接口耗时、错误率、线程池）、业务层（订单量、PV、转化率）。这个层次感很重要，因为只看CPU和内存，往往发现不了应用已经被慢SQL拖垮了。

工具方面，2018年前后主流监控是Zabbix，但近几年Prometheus + Grafana已经成了事实标准。笔试如果让你选型，可以从这几个维度比较：

告警策略这类题，最要避免的就是“告警风暴”。如果每个指标都设阈值，线上会出现成百上千条告警，真正重要的反而被淹没。比较好的做法是分级告警：P0级别直接短信+电话，P1级别企业微信/钉钉推送，P2级别邮件汇总。阈值设定要结合历史基线，比如CPU使用率超过80%持续5分钟才告警，而不是瞬时超过就触发。这一部分如果你能讲出“降低误报率”和“跟踪告警闭环”这两个点，面试官会眼前一亮。

4.3 Redis、Nginx等中间件高频点

Redis也是运维笔试常客。最简单的题是“Redis有哪些常用数据结构”，答案就是String、Hash、List、Set、ZSet。但真正拉开差距的是缓存三大问题：穿透、击穿、雪崩。

• 缓存穿透：查询一个不存在的key，每次都打到数据库。解决：缓存空对象、布隆过滤器。
• 缓存击穿：某个热点key过期瞬间，大量请求打到数据库上。解决：互斥锁、热点数据永不过期配合后台更新。
• 缓存雪崩：大量key集中在同一时间过期，数据库压力瞬间暴涨。解决：过期时间加随机值，多级缓存，限流降级。

这三种问题几乎是运维面试必问三连，笔试简答题里出现概率也极高。答题时要能区分概念，别把穿透和击穿搞混。

Redis持久化同样会考，RDB是周期性快照，恢复速度快、但可能丢数据；AOF是追加写日志，数据更安全、但文件大。生产环境通常是两者结合，或者根据业务数据容忍度选择。

Nginx的考题集中在反向代理和负载均衡。负载均衡策略有轮询（默认）、权重（weight）、ip_hash（按客户端IP哈希，保证同一用户访问同一后端）、least_conn（最小连接数）。笔试让你写一个简单配置的概率也不小，我建议你把下面这段背熟：

upstream backend { server 10.0.0.1:8080 weight=3; server 10.0.0.2:8080 weight=1; keepalive 32; } server { listen 80; server_name example.com; location /api/ { 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; } }

这里的keepalive 32是为了复用后端连接，减少TCP握手开销。设置X-Real-IP和X-Forwarded-For是为了让后端应用能拿到真实客户端IP，这在访问日志分析题里特别重要。

5. 编程题与逻辑推理题：笔试中的隐形门槛

5.1 运维也会考算法？其实考的是思维

不少人在笔试前对编程题有抵触，觉得“我是运维，凭什么写代码”。但京东这类互联网公司的运维，写代码是基本功——自动化平台、发布系统、监控脚本、日志采集，哪家不是要写Shell和Python？笔试编程题根本不会出快排、动态规划那种竞赛题，更常见的是“统计日志里的error数量”“写一个脚本批量修改文件名”这种贴近工作的题目。

有一道印象很深的题：“给你一个access.log，每行格式为IP、时间、请求URL、状态码，请统计状态码为404的请求数量，并输出出现最多的3个URL。”用Python写大概就是：

from collections import Counter with open('access.log') as f: urls_404 = [] for line in f: parts = line.split() if parts[3] == '404': urls_404.append(parts[2]) print(len(urls_404)) print(Counter(urls_404).most_common(3))

这道题真正考察的不是算法，而是“你会不会按行读取文件”“字符串怎么切分”“用什么数据结构做计数”。这些能力在运维日常工作里天天都要用。如果你只背了Linux命令而不会Python，这类题基本等于送分给会的人。

5.2 典型的逻辑推理与场景设计题

逻辑推理题在2018年秋招里是一道明显的“压力题”。有人可能觉得运维考逻辑是玄学，其实不是。运维工作中，面对一台上千台服务器、无数告警的复杂系统，能不能快速缩小排查范围，靠的就是逻辑推理能力。

经典题目比如“1000瓶水里有一瓶有毒，用最少的小白鼠在24小时内找出毒水”，答案是10只小白鼠，利用二进制编码。这种题如果你没见过，现场很难想出来，所以考前准备时刷一刷逻辑题是有意义的，重点不在背答案，而在于训练“把可能性拆开，用有限信息做排除”的思路。

场景设计题更贴近运维实际，比如“双11大促前，给你一个流量预估翻5倍的系统，你怎么做容量评估”，这类题没有标准答案，但你要能从下面几个角度回答：

• 基于历史峰值数据估算QPS，再换算成所需实例数
• 梳理全链路：入口Nginx→应用→缓存→数据库，找瓶颈
• 做压测验证，不是拍脑袋
• 提前准备限流、降级、扩容预案
• 压测期间要能实时观察监控，定出安全水位线

答题时把“预估→摸底→压测→预案”这个流程写出来，基本就是标准高分回答。

5.3 如何用“运维视角”答题更稳

同样一道场景题，普通回答和运维回答的差距是很大的。举例说，“数据库连接池满了怎么办”，普通回答可能是“调大连接池数量”，但运维视角会是这样：

• 先看连接都在干什么，是否存在慢SQL占着连接不释放
• 看应用是否有连接泄漏，反复创建不归还
• 调整连接池不能解决根本问题，只能缓解
• 长效对策是设置连接超时、慢查询告警、定期重启应用

我在给新人培训时经常强调一个答题公式：“先止血，再排查，后根治，最后加监控。”笔试的简答题不要只回答一个点，要写全这个链条。比如“网站响应慢”就可以按照：先用监控定位是入口慢还是后端慢，再查日志找具体报错，恢复后分析根因，最后决定是否需要扩容或加缓存，再调整告警阈值。这样回答不仅完整，而且能体现出你对运维这个岗位的理解是体系化的。

6. 结合最新热词，重新审视运维笔试准备

6.1 2025年再看：这些考点至今仍是基本功

很多人在准备运维笔试时会犯一个错误：过度追求新技术，比如天天看Kubernetes的源码细节，结果最基础的Linux命令却说不利索。2018年京东笔试里的系统命令、网络排查、Shell脚本，放到今天依然是运维面试的必考项。尤其现在的环境变得更复杂——应用跑在容器里、Pod不停重启，底层排查思路反而更依赖网络和系统基础。

容器时代有一个普遍的痛点：服务突然无法访问了，你依然要先判断“是Pod挂了、是流量没进来、还是后端依赖挂了”，而判断这些靠的是Linux网络知识、端口连通性测试、抓包分析。所以我说，云原生改变的是运维的形态，没有改变运维的基础。笔试准备时，Linux和网络绝对不能跳过。

6.2 从最新热词看运维技能栈变化

在搜索“运维”相关热词时，你会发现一个很有意思的现象：搜索“linux常用命令大全运维”“网络运维工具箱”“桌面运维常见问题”的人非常多，这说明入门级的基础需求一直很旺盛；同时“云计算运维”“私有化运维”“智能运维AI运维”这些词也在快速增长，说明行业正在分层。

国产操作系统运维工具（比如统信UOS运维工具-LiveCD）的搜索量上升也值得注意，随着国产化替代推进，运维工程师需要掌握这些系统上的软件包管理、日志排查、LiveCD救援等技能。虽然笔试未必会直接考，但简历里写过这些能力，面试官会眼前一亮。“kubernetes如何调用containerd”这类底层调用链路的问题越来越常见，说明运维岗位不再只停留在“会部署”层面，而是要理解容器运行的完整链路。

如果你要把这些热词消化成笔试/面试优势，我建议关注三个方向：

• 云原生运维：Kubernetes基础调度原理、Pod生命周期、镜像构建、部署策略
• 平台化运维：把重复性工作脚本化、平台化、容器化，理解CI/CD流程
• 大数据/AI化运维：日志聚类、指标异常检测、告警降噪

笔试里考“传统基础+新趋势”的占比，现在基本能做到七三开，传统基础依然是大头。

6.3 一套可执行的运维笔试备战清单

如果你现在正准备运维岗位的笔试，我给你一个能直接套用的备战计划，按一个月左右来排：

学习设备方面，不用纠结，一台Linux虚拟机就够了。CentOS系和Ubuntu系至少各装一台，练习软件包管理和系统命令差异。有条件的话，自己用虚拟机搭一套论坛或者博客系统，配置Nginx、MySQL、Redis，再写脚本做日志备份，这样一套走下来，笔试里出现的多数场景你就都有体感了。

推荐的学习路径是：先跟着文档把命令跑一遍，再脱离文档做“乱搞恢复”练习，比如故意把Nginx配置改坏，再看日志修复。这种“先破坏、再修复”的玩法，对培养实战感觉特别有效，比单纯刷题强得多。

最后再多说一句，2018年那批题后来被不少人当作运维复习的范本，不是它有多高深，而是它太能代表互联网运维工程师这个岗位的真实要求了。在我带新人的这些年里，只要底子扎实，哪怕具体技术栈换成了别的，学起来也很快。准备笔试别急着海量刷题，先把手边一台Linux虚拟机用起来，把日志分析、网络排查、脚本自动化这三件事练成肌肉记忆，比什么都靠得住。