企业官网建设流程全解析

那年秋天，我坐在学校的机房里，对着一个全屏的在线考试系统，右上角的倒计时一直在跳。三套试卷里，我抽到的是“滴滴出行2018校园招聘网申笔试-运维开发工程师(第三套)”。运维开发这个岗位，当年在应届生里还不像现在这么卷，但“滴滴”这两个字本身就意味着业务体量巨大，它的笔试明显不靠背诵过关，而是考你有没有一套完整的工程思维。

现在回头看这套题，核心考察的链条非常清晰：Linux系统基础、网络与数据库原理、脚本与自动化能力、监控与故障排查方法论，再加上一点系统设计思路。这篇文章我就把这几大方向的考点拆开，配上我自己踩过的坑和事后总结的备考方法，给准备走运维开发路线的学弟学妹做一个参考。无论你是刚接触Linux的应届生，还是已经有了一些服务器维护经验、想往DevOps方向转的同学，这篇复盘应该都能对得上你的需求。

1. 考前先想清楚：运维开发笔试到底在考什么

1.1 岗位定位与传统运维的差别

很多同学一看到“运维开发”四个字就以为考的是Linux命令大全，或者以为是纯后端开发，考一堆算法和框架。这两种理解都偏了。从滴滴这类互联网公司的岗位定义来看，运维开发工程师处在传统运维和业务开发之间的位置：既要懂服务器、网络、数据库这些基础设施，也要会写代码，把重复的运维工作变成自动化工具和平台。

笔试里的“开发”不是让你设计一个高并发秒杀系统，而是考察你有没有能力用Shell或Python解决实际运维问题。比如批量日志分析、定时巡检脚本、接口异常重试、一个简单的发布流程设计。这些东西看起来不大，但在真实生产环境里直接决定一个运维平台能不能跑得起来。所以备考时别一头扎进算法题里，先把“用代码解决运维问题”的感觉练出来。

1.2 2018年前后的技术环境与出题趋势

理解笔试内容，还得放到当时的行业背景里看。2018年容器化刚刚开始普及，Kubernetes在少数头部公司进入生产，但大多数公司还在用Ansible、SaltStack做自动化，OpenStack在私有云里还有不少存量。滴滴这类体量的公司，订单量千万级，服务器和容器数量非常庞大，纯靠人工去维护根本不现实，所以自研运维平台、调度系统、发布系统是必然方向。

这就决定了笔试绝对不会只考死记硬背的命令，而是更看重你懂不懂“批量操作”“服务发现”“容量管理”“故障恢复”这些概念。哪怕你Docker没看过，只要Linux、网络、数据库功底扎实，还是有很大机会。反过来，如果你简历里写了会Kubernetes，但对TCP三次握手都说不清楚，面试官反而会觉得基础不牢。

1.3 从题型分布看复习优先级

按我当时的回忆和经验，这套卷子的题型大致分四块：基础选择题、简答/场景设计题、编程题、综合逻辑题。分值权重按常规经验预估，基础原理占四成左右，编程脚本占三成，系统设计类占两成，其余是逻辑与综合。这个比例不是绝对的，但能说明一个方向：背命令细节的收益有限，理解原理和动手写代码才是大头。

这套卷子里单选题多考察概念辨析，比如HTTP和HTTPS的区别、进程和线程的区别、TCP和UDP的区别这类。简答题通常给出一个运维场景，让你描述处理思路。编程题则有明确的输入输出，需要现场写Shell或Python。复习时我建议按“基础概念不需要逐字背诵，但要做到能用自己的话讲清楚；脚本必须自己敲一遍并跑通”这个标准来准备。

2. 基础考点逐个拆解：Linux、网络与数据库

2.1 Linux不只考命令，更考系统思维

Linux部分看着都是命令题，但背后考的是对系统运行机制的理解。拿最常见的日志分析题来说，给你一个access.log，要求统计访问量Top 10的IP。正确答案其实很简短：

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

这行命令考察了四个点：awk取列、sort排序、uniq去重计数、管道串联。看起来简单，但笔试里不少同学会把uniq -c的计数值放在第二列，然后继续用$1取IP，结果错位。这里有个习惯建议：写完命令后自己心里推导一遍每一列是什么，尤其是在管道符比较多的情况下。

比命令更难的是概念题，比如僵尸进程和孤儿进程的区别、文件描述符是什么、为什么rm删掉的文件空间没有释放。这些问题在笔试卷子里出现频率很高，因为它们在真实故障排查中真的会遇到。我记得当时复习的一个重点是lsof | grep deleted，生产环境里磁盘写满但du看不到大文件，十有八九就是某个进程持有一个已删除文件的句柄，文件空间被占用却不释放。笔试不会直接考这条命令，但会考“磁盘空间被占用但找不到文件”这个场景，答案就是这个机制。

进程管理也是重点。top和ps基础用法必须烂熟，还要理解systemd的基本概念，比如systemctl status、systemctl enable是干什么的。端口查看命令ss -lntp当时已经逐渐替代netstat，建议两个都看一眼。另外权限部分，除了chmod的基本数字法，setuid、sticky bit这些只要概念上有印象即可，笔试如果出题通常是选择题，不会让你现场实现一个ACL系统。

2.2 网络基础：从TCP握手到HTTP状态码

网络是运维开发笔试中绝对不能丢分的大项。TCP三次握手几乎年年考，但考法越来越活。不是简单问“为什么三次握手”，而是问“为什么TIME_WAIT要等2MSL”。这个问题的回答要点有两层：第一，保证最后一次ACK如果丢失，能让对方重发FIN；第二，让本次连接中所有迟到的报文在网络中自然消失，避免干扰新的连接。理解了这层，再延伸一下：高并发短连接服务会出现大量TIME_WAIT，影响新连接建立，这种场景下怎么处理，就是一个很好的简答题素材。

HTTP状态码也是高频考点，而且会结合场景出。比如用户访问网页出现502，通常意味着网关后面的服务挂了；出现504，则说明服务还在但响应超时。301与302的区别、403和404的区别，这些要能用自己的话解释清楚。有个简单记法：4xx是客户端问题，5xx是服务端问题。笔试时遇到过一道题，给出一个请求从浏览器输入URL到页面展示的完整过程，要求列出中间涉及的协议。这道题想看到的是你有没有整体网络思维，一般按这个顺序答：

1. 浏览器解析URL，检查自身缓存。
2. 发起DNS解析请求，拿到目标IP。
3. 建立TCP连接，完成三次握手。
4. 如果是HTTPS，先完成TLS握手协商密钥。
5. 浏览器发送HTTP请求，服务端返回响应。
6. 浏览器解析HTML，加载页面资源。

每一步都可能继续展开，比如DNS查询是递归还是迭代、CDN作用、Nginx反向代理怎么转发。备考时建议把这个过程反复练到能脱口而出，很多网络题都能嵌套在这个框架里。

2.3 数据库：索引、事务、主从复制都要能说清楚

数据库考察集中在MySQL，Redis也偶尔出现。MySQL索引为什么快、为什么主键推荐自增整数，这是必问点。B+树索引能减少磁盘IO次数、有序存储适合范围查询，同时叶子节点形成链表，这是核心结论。笔试简答题里让你“分析一条慢查询”，需要你能想到用EXPLAIN看执行计划，看懂type、key、rows三个字段，然后判断是不是索引失效。

索引失效的常见原因要背熟：对索引列使用函数或运算、隐式类型转换、LIKE以%开头、联合索引不满足最左前缀原则。这些知识点在选择题和场景题里反复出现。还有一个小点：SELECT *不仅浪费内存和IO，还可能让优化器放弃覆盖索引，这个印象要建立起来。

事务隔离级别是数据库部分的另一座“大山”。四个隔离级别从低到高分别是读未提交、读已提交、可重复读、串行化，它们分别解决脏读、不可重复读、幻读的问题。MySQL默认是可重复读级别，在可重复读下通过MVCC避免了大部分幻读，但在某些锁定读场景下仍然可能发生。笔试一般不会考到这么深，但你要能分辨三个术语：脏读指的是读到别的事务未提交的数据，不可重复读指的是同一查询在事务内两次结果不一致，幻读指的是新增数据导致的“凭空多出”的记录。

主从复制的原理也值得准备。它的基础逻辑不复杂：主库把变更写入binlog，从库的IO线程拉取binlog并写入relay log，SQL线程再执行relay log里的内容。笔试里可能问“主从延迟怎么解决”，你至少能说出几个方向：优化大事务、降低单表写入压力、考虑读写分离分拆、监控延迟时间并用强制读主库兜底。

Redis部分重点准备几个数据结构（string、hash、list、set、zset）和典型应用场景，以及缓存穿透、缓存击穿、缓存雪崩的区别。穿透是查询了一个不存在的key，每次都要请求数据库；击穿是热点key突然过期，大量请求直接打到数据库；雪崩是大面积key同时过期或Redis宕机导致流量打崩数据库。应对方案分别是布隆过滤器/空值缓存、互斥锁/逻辑过期、过期时间加随机值/高可用。

3. 脚本与自动化：运维开发的基本功

3.1 Shell脚本的常见题型与实战写法

Shell编程在笔试里出现的概率非常高，而且基本是两道题起步。一道简单的可能是“写脚本检查Nginx进程是否存在，不存在则启动并记录日志”，一道复杂的可能是“解析某个日志文件，统计每类错误次数并输出Top 5”。我当时遇到的是前者，但事后看这种题拼的不是“能不能实现功能”，而是“实现得够不够稳”。

#!/bin/bash pid=$(pgrep -f "nginx: master" | head -1) if [ -z "$pid" ]; then echo "nginx is down, restarting..." /usr/local/nginx/sbin/nginx echo "restart at $(date)" >> /var/log/nginx_check.log fi

这道题写完看起来简单，但其中有几个会被扣分的点：一是pgrep可能匹配到无关进程，最好用-f加完整字符串；二是检查命令执行结果要用退出码，不能只看输出；三是重启失败也要有处理，比如再发告警；四是脚本要加set -euo pipefail，防止中途出错继续跑。笔试环境虽然不要求那么完善，但这些细节写在注释里能让阅卷人觉得你有生产经验。

写Shell有个通用口诀：变量赋值等号两边不能有空格；字符串变量记得加双引号；在管道子shell里修改的变量不会带出子shell；bash -x是调试神器。还有一点容易被忽略：脚本开头加#!/bin/bash，否则可能默认用sh解释，语法兼容性会出问题。

3.2 Python在运维开发中的位置

如果说Shell是螺丝刀，Python就是运维开发手里的电动工具。笔试里的编程题允许用Python，但考的不是LeetCode那种算法，而是跟文件处理、日志分析、接口请求相关的题目。比如给你一个日志文件，每行包含接口名和响应时间，要求输出平均响应时间最长的三个接口，这就是一个非常典型的运维场景题。

from collections import defaultdict cost_map = defaultdict(list) with open("api.log", encoding="utf-8") as f: for line in f: parts = line.strip().split() if len(parts) < 2: continue api, cost = parts[0], float(parts[1]) cost_map[api].append(cost) result = [] for api, costs in cost_map.items(): avg_cost = sum(costs) / len(costs) result.append((api, avg_cost)) result.sort(key=lambda x: x[1], reverse=True) for api, avg_cost in result[:3]: print(api, round(avg_cost, 2))

这道题考察的地方主要是：文件读写是否健壮、空行和格式异常能否处理、数据结构选择是否合理、以及是否知道怎么排序取前三。我在实际笔试里吃过亏的是没做异常处理，日志里混了一行空行导致整个程序崩溃。后来总结经验：凡是处理外部数据的程序，第一件事就是考虑脏数据，先用try/except或者过滤逻辑把异常数据挡在外面。

Python部分还经常考一些内置库的用法，比如os、re、requests、json、subprocess。这些不用背API，但至少要能用出来。比API更重要的是思路，让脚本能应对“文件不存在”“网络请求超时”“目标服务未启动”这些异常情况。笔试时如果时间宽裕，尽量在最后补一个main()函数和异常处理框架，这会让代码看起来很工程化，分数更容易上去。

3.3 配置管理与发布流程：一套“概念+落地”组合拳

除了命令和编程，卷子里通常还会有一两道跟自动化运维相关的简答题，常见的是“请描述一次完整的发布流程”或者“请说明蓝绿部署与滚动发布的区别”。这种题考查的是你有没有亲身参与过线上变更，或者至少理解其中的关键环节。

Ansible这类工具在2018年已经是主流，核心概念是inventory、playbook、module。笔试不会让你背文档，但你要知道Ansible基于SSH、无agent、playbook采用YAML声明式写法、模块要幂等这些特点。幂等这个概念可以类比成“同一份菜谱反复做，每次做出来的菜都一样”，放到系统里就是重复执行操作不会产生副作用，这是自动化配置管理的基本要求。

发布策略是另一个要懂的点。蓝绿部署是准备两套完全相同的环境，切换流量的时候整体切过去，好处是回滚快，坏处是资源成本高。滚动发布是分批替换旧版本实例，优点是节省资源，缺点是发布和回滚过程更容易出错。金丝雀发布是最先放量到一小部分机器或一小部分用户上，观察没问题再放量。回答这类题时，一个比较讨喜的结构是：先说方案目的，再讲具体怎么操作，再补一句该方案的优缺点，最后落到“如果失败怎么回滚”。能把这四点说全，基本上分数就稳了。

4. 监控、日志与故障排查：运维的“眼睛”和“直觉”

4.1 监控系统设计：分层比工具更重要

监控相关的题目在笔试卷子里不一定直接问“Prometheus怎么配”，但会问“系统突然变慢，你怎么排查”“线上服务挂了，你通过什么方式发现”。这些题的根源都在监控体系上。我备考时把监控分了三层来理解，答题时会按这个顺序展开。

第一层是基础设施监控，关心CPU、内存、磁盘、网络这些机器指标。工具上，2018年Zabbix和Prometheus已经开始并行出现，Prometheus加Grafana的组合在面试中提起来会很加分。第二层是应用性能监控，关心QPS、平均响应时间、错误率、线程池饱和度，这些能反映服务本身的健康状态。第三层是业务监控，比如滴滴会关心下单成功率、支付成功率、司机接单时长，这一类指标才真正影响用户体感。

告警阈值设计也有讲究。不是说CPU到了100%才告警就合理，通常建议CPU使用率持续5分钟超过85%就触发告警，磁盘使用率超过80%就需要关注，因为不少临时文件、日志增长会在短时间内把剩余空间打满。笔试答题时提一句“告警要分级，不能所有告警都拉人，否则狼来了喊多了就没人响应”，会显得你有实战经验。

4.2 日志分析：把分散的信息串成一条线

日志是排查问题的第一手资料，也是运维开发笔试里常出现的场景。一套线上服务，前端有Nginx访问日志，应用有业务日志，数据库有慢查询日志，怎么通过日志快速定位问题是考点。理想的方案是集中式日志系统，2018年最常见的组合是ELK，也就是Elasticsearch、Logstash、Kibana。笔试不会让你搭建一套ELK，但会问“日志格式怎么设计”这类问题。

我的回答思路是：所有日志必须有统一的时间戳和唯一标识。拿请求链路来说，网关在入口生成一个request_id，后续微服务收到的请求都携带同一个request_id，这样在排查问题时只要用request_id去每个服务日志里搜索，就能把整条调用链串起来。这个思路在笔试里是可以直接写进简答题答案的，而且很加分。

另外，日志文件要定期切割和归档。很多同学不知道为什么日志要按天切割，其实一是避免单个文件过大导致磁盘爆满，二是方便按时间段排查。如果没有切割，一个几十GB的日志文件在定位问题时体验非常痛苦。笔试如果问“磁盘被日志写满了怎么办”，除了清理归档，还要想到配置logrotate这类工具，按大小或者按天自动分割日志。

4.3 经典故障排查案例：从现象到根因的思考过程

故障排查题是整套卷子里最能拉开差距的部分，因为这类题没有标准答案，考的是思路。跟我一起笔试的同学出来后抱怨说“没答完”，其实就是栽在这种开放题上。遇到这类题，最忌讳一上来就写“重启一下”，要展示从现象逐步定位根因的过程。

场景一：接口响应突然变慢。我的排查路径是先看监控大盘，判断是单机问题还是整体问题；然后登录机器执行top查看CPU和负载，再用free -h看内存；如果CPU不高，就去看慢查询和下游RPC调用耗时；如果还找不到，就用strace -p跟一下进程的系统调用。这道题的关键是让阅卷人看到你的排查顺序是有逻辑的，不是东一下西一下。

场景二：磁盘空间满了。先df -h确认哪块盘满，再用du -sh /path/*逐层找到大目录，排除普通文件后，如果磁盘依然显示被占用但看不到大文件，就要用lsof | grep deleted查找被删除但仍被进程占用的文件。生产环境非常经典的场景是日志文件被rm了，但进程一直持有文件句柄，空间不释放，只能重启进程或者> file清空处理。

场景三：CPU达到100%。用top定位到高CPU进程后，再用top -Hp 进程号找到具体线程，如果是Java应用，用jstack打印线程栈，配合grep找到对应线程号，就能看到在跑什么代码。这种题在笔试卷子里可能不会考到JVM那么细，但你至少要知道线程栈是排查Java程序CPU飙升的必备工具。

高频流量冲击下的系统设计也很重要。限流、降级、熔断这三个词，在2018年的运维开发笔试里已经出现。限流控制请求速率，常用令牌桶和漏桶算法，保护系统不被突发流量打垮；降级是在依赖服务不可用时返回兜底数据或直接拒绝，确保核心链路不受影响；熔断是当某个下游错误率达到阈值后快速失败，相当于给系统加了一个断路器。把这些概念讲清楚，答简答题的时候会非常出彩。

5. 笔试实战心得与备考路线

5.1 我踩过的坑，希望你别再踩

现在回看那次笔试，有几个教训特别深刻。第一是时间分配失误。我前半小时在几道概念选择题上反复纠结，结果做到编程题时只剩不到20分钟，草草写出来的代码根本没有跑通的把握。正确做法是先快速扫一遍全卷，找分多的题先做，尤其是编程题和系统设计题。选择题里面再难也就一两分，不值得用10分钟去赌。

第二是审题不够仔细。笔试题目有时候会限定“请使用Shell脚本实现”，我身边有同学平时用Python顺手，忽略了题目要求直接写了Python，结果就是整道题不给分。这个太可惜了。考试时读完题先把关键词圈出来，是Shell还是Python，是输出Top 10还是统计总数，差一个词答案就完全不同。

第三是代码不写注释且不考虑边界。在线笔试的阅卷环境虽然很多时候是人工看的，但代码的可读性会影响评分。变量命名清晰、函数拆分合理、关键步骤加注释，这些习惯都在考官眼里。还有边界条件，比如处理的文件不存在、日志为空、输入参数异常，如果你能提前在代码里过滤掉这些情况，说明你具备上线代码的基本素养。

5.2 不同基础的人，备考路线怎么走

如果你目前只会用几条命令，建议把时间花在核心命令和脚本语法上。鸟哥的Linux私房菜基础篇通读一遍，重点掌握grep、awk、sed、sort、uniq、xargs，每学一条就立刻在命令行里练一遍。网络和数据库部分可以看《TCP/IP详解卷一》的精选章节和《高性能MySQL》的索引与事务部分，不必全读，但原理要理解。

如果你已经有一些服务器维护经验，可以集中精力练编程和系统设计题。Python刷题不需要去挑战难题，重点做字符串处理、文件操作、字典统计、简单排序这类。发布流程、监控体系这些概念花半天整理成自己的话术，然后用费曼技巧讲给别人听，讲不出来的地方就是你的知识漏洞。

考前一周非常关键，不建议再啃新知识点，把之前整理的命令笔记、状态码表、索引失效场景、隔离级别对比全部过一遍。如果能把常见简答题的答案流畅地写出来，说明水平已经比较稳定了。

5.3 拿到卷子以后，我推荐的答题顺序

这算是我的“压箱底”经验。整个笔试过程大概90分钟到120分钟，我的习惯是拿到卷子先花3分钟浏览全卷，做一次“分值标记”，把编程题和规模较大的场景设计题找出来。然后按这样的顺序作答：先写编程题，因为分值高且需要思考时间；再做系统设计题，这类题写多不扣分，尽量把监控、发布、回滚都说上；最后做选择题和判断题，它们是稳定拿分项，但不要过度纠结。

简答题的回答策略我总结为“结论前置加三步展开”。比如问“线上服务挂了你怎么处理”，第一句话先给结论“先恢复再定位”，然后列步骤：看监控和告警，确定影响范围；通过日志快速定位直接原因并恢复；事后复盘和补充监控。每一步都再补一两句具体细节，整段答案看起来就有条理。还有个小技巧：遇到完全不会的题，把你能想到的相关步骤写出来，比如“我会先看内存和CPU，再查nginx error log”这种流程描述，也能拿到部分过程分。

结尾

那次滴滴笔试之后，我又陆续参加过其他几家互联网公司的运维开发笔试，套路其实大同小异。现在回头想，真正让我受益的不是某一道题的正确答案，而是备考过程中建立的体系感：遇到任何线上问题，都知道先看监控，再查日志，然后定位进程，最后落到代码和配置。运维开发这个岗位，本质上就是拿代码去解决运维问题，把一次手工操作变成可重复、可观测、可回滚的系统能力。

我后来带过不少新人，发现笔试里表现的差距，往往就是平时有没有真正管理过服务器、看过线上日志、处理过宕机决定的。如果你还在校，建议别只刷题，自己搭一台虚拟机，把Nginx跑起来，故意改坏配置再修复，模拟一次磁盘写满再清理，这些经历比任何题库都有用。等你在笔试里遇到“服务响应变慢”这类问题时，你会发现自己居然能写得停不下来。