滴滴校招运维笔试题复盘：从生产环境搭建到故障排查

前几天翻资料的时候看到一份滴滴出行2018年的校招网申笔试题——系统运维工程师第二套。说实话这类当年在应届生圈子里流传很广的卷子放到现在看依然很有参考价值它考察的不是某个冷门参数而是你有没有建立起一套从零搭建生产系统、并长期维护它的完整思路。如果你正在准备系统运维工程师的笔试或面试或者刚转行想系统入门运维这份复盘应该能帮你少走不少弯路。我见过太多人复习这类笔试时容易陷入背命令、刷概念题的误区。但真正到了笔试现场尤其是案例分析题考察的是你把零散知识点串成一条线的能力。这套题给我的整体感觉就是把“生产环境可靠性”和“故障排查逻辑”放在了核心位置。所以这篇内容我不打算逐题念答案而是顺着这套题的考察逻辑把系统运维这个岗位真正需要的知识体系和工作方法拆开讲清楚最后再落到一个很实际的问题上作为一个运维工程师如何在生产环境从零搭建一个系统并做好后续维护。1. 这套笔试题到底在考什么从业务倒推人才画像1.1 滴滴的业务形态决定了运维考核的侧重点先想一个问题滴滴这类出行平台它的业务特点和普通网站有什么不同答案是高并发、高实时性、强地域分布而且流量波动极其剧烈。早高峰、晚高峰、节假日、恶劣天气都可能让订单量在短时间内暴涨数倍这种“脉冲式”流量对系统稳定性提出了非常高的要求。这样的业务背景下运维工程师要解决的核心问题就不是“把机器管好”这么简单而是“在极端流量冲击下核心链路依然不挂、不慢、不错”。所以你看这套笔试题凡是涉及到架构、缓存、消息队列、监控告警、故障恢复的内容其实都是在考察你能否围绕这个核心目标做决策。另外一个容易被忽略的点是滴滴的业务链路很长。用户下单要经过App、网关、订单中心、派单引擎、计费模块、支付模块再往后还有地图、路况、司机端、乘客端等各种依赖。任何一环出现故障都可能直接导致用户叫不到车或者订单异常。于是运维岗位的另一个隐含要求浮出水面你必须具备全局视角遇到问题能快速判断是哪个环节出了岔子而不是只会盯着某一台服务器看。这也就解释了为什么校招笔试里会有大量故障排查类、日志分析类题目。出题人想看的是你有没有一套清晰的排查思路而不是碰运气式的试错。1.2 笔试常见的出题结构和答题策略这类校招运维笔试卷子一般会分成几个固定板块Linux系统基础、网络基础、数据库与中间件、脚本与自动化、监控与故障处理、最后再加一两道综合案例分析。Linux系统基础板块考的是命令掌握程度和系统理解能力。比如进程管理、文件权限、磁盘管理、系统性能排查这些都是基本功。网络基础板块则会围绕TCP/IP、HTTP、负载均衡、DNS等展开考察你理解不理解网络通信的底层逻辑。数据库与中间件板块MySQL、Redis、消息队列基本是常客。脚本与自动化板块Shell和Python二选一或者都考重点看你的逻辑思维和脚本编写能力。答题策略上我建议你养成“分层回答”的习惯。比如问到性能排查不要直接丢出一个top命令就完事而是说“我会先看整体负载再用top定位CPU或内存瓶颈接着用iostat看磁盘IO用ss看网络连接状态最后结合日志确认根因”。这种回答方式展示的是你的分析框架而不是死记硬背的命令列表。还有一个很重要的经验遇到设计类题目一定要考虑非功能性需求。比如让你设计一个系统你除了要回答“用什么组件”还要主动提到容量规划、监控告警、备份恢复、安全基线这些运维视角的内容。这既是加分项也恰恰是很多没有实际经验的同学最容易漏掉的地方。2. 核心考点逐项拆解Linux、网络、数据库与中间件2.1 Linux与系统管理从启动流程到性能排查Linux是运维的看家本领这套笔试里Linux相关的内容占比一定不低。常见的出题方向包括系统启动流程、进程管理、权限体系、文件系统、日志分析以及最经典的各种性能问题排查。系统启动流程看起来是个偏概念的问题但我建议你把它和排障结合起来理解。一个典型的启动流程是这样的服务器通电后BIOS/UEFI做硬件自检然后加载引导程序GRUBGRUB加载内核内核初始化硬件和驱动最后挂载根文件系统并启动systemdsystemd再按依赖关系拉起各类服务。这个流程的意义在于当一台机器起不来时你可以按阶段定位是硬件问题、引导问题、内核问题还是某个关键服务起不来。性能排查是笔试和面试的高频考点也是最容易看出一个人有没有实战经验的地方。我遇到过一个典型的题目“某台服务器load average突然飙高你如何排查”。很多新人的第一反应是“重启一下”这在大规模生产环境里是忌讳。我会按这样的顺序来先用top看整体负载和CPU占用再用vmstat看进程队列、内存换页情况如果CPU不高就用iostat看磁盘利用率如果磁盘也没问题检查网络连接状态和内核日志最后再定位到具体进程和日志。整个过程的核心思想是“从全局到局部先看系统再看应用”。Linux这一块我还想提醒一个常被忽视的细节文件描述符。很多线上故障的根因就是文件描述符耗尽表现为“too many open files”错误。生产环境里服务进程的ulimit -n需要根据业务量调大而不是用默认的1024。这类细节在笔试里不一定直接考但在案例分析里很影响你的综合评分。2.2 网络基础从TCP握手到负载均衡选型网络知识对运维来说难度不在概念本身而在于概念和实际现象之间的对应关系。比如TCP三次握手大家都背过但笔试真正想让你回答的往往是“握手失败会有哪些表现如何排查”。这里我分享一个自己排查过的真实场景。某个服务对外表现为“连接超时”客户端报错是连接建立失败。我当时用ss -lnt查看服务端监听端口发现监听正常再用ss -ant查看当前连接状态发现SYN_RECV状态的连接特别多。这说明半连接队列被塞满了很可能是SYN Flood攻击或者并发量突然过大导致backlog队列溢出。调整内核参数net.ipv4.tcp_max_syn_backlog和应用程序的backlog配置后问题才缓解。再往下说负载均衡几乎是必考内容。你需要搞清楚四层和七层负载均衡的区别四层工作在传输层基于IP和端口转发性能高典型代表是LVS七层工作在应用层可以基于URL、Header等做路由典型代表是Nginx。选型的时候要考虑业务需求。如果只要求IP和端口转发、吞吐量极高选四层如果要做HTTP路由、灰度发布、请求改写选七层。我做过一个对比表格分享给大家参考维度四层负载均衡七层负载均衡工作层级传输层IP端口应用层HTTP等协议性能高转发效率高相对低需要解析应用层数据路由能力按IP/端口按URL/Header/Cookie等典型方案LVS、F5Nginx、HAProxy适用场景高并发TCP/UDP流量入口HTTP API网关、Web服务路由很多同学容易忽略的一点是负载均衡不只是“分流量”这么简单它还要承担健康检查、故障摘除、会话保持等能力。健康检查尤其重要它决定了后端某台机器挂了之后流量能不能自动切走。所以在回答负载均衡相关题目时主动提到“健康检查机制”和“故障自动摘除”会明显显得更专业。2.3 数据库与缓存主从、索引、缓存三大坑数据库这块MySQL是绝对的重点。笔试常考的知识点包括索引失效、慢查询优化、主从复制、备份恢复、事务隔离级别。这些知识点单独拿出来都不难但组合起来就很容易做错。主从复制的原理是主库把数据变更写入binlog从库的IO线程拉取binlog并写入relay log再由SQL线程回放relay log完成数据同步。笔试里会问主从延迟的排查思路我通常会从这几个方向回答先看从库的Seconds_Behind_Master值再检查从库所在机器的IO和CPU负载然后看是否存在大事务、DDL操作、或主库binlog量过大最后确认主从网络延迟。很多时候主从延迟的根因其实是慢SQL在从库上执行时间太长导致SQL线程跟不上主库的写入节奏。索引这块笔试喜欢考“某条SQL为什么没走索引”。常见的索引失效场景包括对索引列使用函数或运算、隐式类型转换、like语句以通配符开头、or条件中有一个字段没有索引、联合索引不满足最左前缀原则。我建议你在复习时把这些场景整理成表格逐个记清楚笔试时答起来会快很多。Redis是缓存考察的重头戏尤其是缓存穿透、缓存击穿、缓存雪崩这三个经典问题。缓存穿透指的是查询一个根本不存在的数据请求落到数据库上解决办法是使用布隆过滤器或者缓存空值。缓存击穿指的是某个热点key在过期瞬间大量请求打到数据库解决办法是加互斥锁或者采用逻辑过期时间在后台异步刷新缓存。缓存雪崩指的是大量key在同一时间过期解决办法是给过期时间加一个随机值让过期时间分散开。这三个问题为什么值得花篇幅讲因为它们直接对应着生产环境里的真实故障。我在实际工作中遇到过缓存击穿导致数据库被打挂的情况当时的场景是某个热点商品详情页key过期一瞬间大量请求穿透到数据库数据库连接池直接打满。后来改造为“热点key永不过期后台异步更新”的方案才彻底解决。这些经验放到笔试案例题里就是很扎实的加分回答。3. 把笔试题串成一条主线生产环境从零搭建一套系统3.1 需求确认与容量规划先算账再动手聊完考点我们把视角拉远回到那个很多面试官和笔试出题人都会问的终极问题如何在生产环境从零搭建一个系统这个问题拆开来看第一步不是装软件而是先算账。需求确认阶段你要搞清楚三件事这个系统要支撑多少流量峰值是多少对延迟和可用性的要求是什么业务长期增长的空间有多大。这些数据直接决定了你的机器配置、网络带宽、组件选型和架构设计。容量规划不是拍脑袋是有计算公式的。举个例子假设一个订单服务接口的日均调用量是1000万次流量集中在4个小时内那平均QPS大概是1000万除以14400秒约等于694。考虑到峰值通常是平均值的3到5倍我们可以按2500到3500 QPS来设计容量。如果单机能够承受500 QPS那么至少需要6台机器才能扛住峰值流量再加上一定的冗余8台会更稳妥。带宽估算也一样。假设每个请求的响应包平均大小为20KBQPS为3000那每秒需要的出口带宽大约是3000乘以20KB等于60MB/s换算成带宽大概是480Mbps。这种情况下单台机器配千兆网卡不一定够需要做负载均衡分担流量。这些计算过程在笔试的架构设计题里写出来和只写“多配几台机器”是完全不同的两个档次。有了容量数据再做组件选型。用什么Web服务器用什么数据库要不要引入缓存和消息队列这些都不是看心情而是看业务场景。如果流量不大、对一致性要求高一个MySQL加两台Nginx就足够了如果流量波动大、有明显的峰值削峰需求就需要引入消息队列。3.2 系统初始化与应用部署基础决定上限确定好架构和容量之后接下来就是动手搭建。这里我要特别强调一个概念生产环境的初始化不是装完操作系统就直接跑业务的。我见过很多新人装完系统就开始部署应用结果后来被各种问题折磨得焦头烂额。一套完整的系统初始化应该包含以下内容基础配置层面设置正确的时区和NTP时间同步配置好主机名和DNS关闭不需要的系统服务更新系统补丁。这些看起来不起眼但影响深远。时钟不同步会导致日志时间对不上排查故障时苦不堪言DNS配置错误会导致服务间调用随机超时。内核与资源限制层面调整文件描述符上限优化TCP连接相关的内核参数比如tcp_tw_reuse、tcp_max_syn_backlog按业务需求设置进程的调度优先级和内存限制。这里分享一个我经常写的配置示例# /etc/sysctl.conf 生产环境常用优化项部分 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_tw_recycle 0 net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535 net.ipv4.ip_local_port_range 1024 65535 fs.file-max 6553560上面这个配置里tcp_tw_reuse开启后可以复用TIME_WAIT状态的连接对短连接很多的业务场景有明显的提升tcp_tw_recycle我建议保持关闭因为它在NAT环境下容易导致丢包问题线上踩过坑的人应该深有体会。应用部署环节生产环境和测试环境的区别在于生产环境必须考虑版本控制、回滚方案、健康检查和发布策略。以常见的Java应用为例发布流程一般是代码合并到主干触发CI构建生成可发布的包或容器镜像然后推送到发布平台先灰度一台机器验证健康检查通过后再滚动发布到全部机器。我在运维工作中深刻体会到一套可靠的发布流程比任何优化都更能保障线上稳定性。发布失败不可怕可怕的是不知道如何回滚到上一个版本。3.3 监控告警与应急预案系统交付前必须上齐的三件事很多从零搭建系统的教程讲完部署就结束了。但在生产环境中系统交付前必须把监控、告警和应急预案这三件事一起交付否则这个系统就是“裸奔”状态。监控的第一层是基础设施包括CPU、内存、磁盘、网络、负载等指标第二层是中间件比如MySQL的慢查询、Redis的命中率、消息队列的积压量第三层是应用层包括请求量、错误率、延迟最后一层是业务层比如某个核心接口的调用量突然下降那很可能是业务链路出了问题。现在业界常说的“黄金信号”指的就是延迟、流量、错误和饱和度这四类指标。你在笔试里如果能提到这套逻辑会让面试官觉得你有系统性思维。告警分级也值得好好设计。我的经验是告警不是越多越好太多告警反而会让值班人员麻木最终出现真实故障时无人处理。生产环境可以按影响范围分为P0到P2三级P0事故核心业务不可用必须立即电话通知P1故障非核心功能受损短信或IM告警P2异常资源水位偏高或某项指标波动邮件通知。告警规则要做到精确宁可漏报一次也不要每天几百条让值班人员崩溃。应急预案这块限流、降级、熔断、切流量这四个词你必须门儿清。限流是在系统入口控制请求速率保护后端不被洪峰击穿降级是在依赖服务不可用时主动关闭一些非核心功能熔断是当某个依赖连续失败时直接切断调用避免故障蔓延切流量是把用户请求从故障集群切换到存活集群。这些手段在笔试案例分析里经常出现比如“某个核心依赖服务响应变慢你会怎么处理”如果你能给出“先熔断保护自身再降级非核心功能同时扩容冗余集群”的组合方案比只答“重启一下”高出不止一个层次。4. 从“会做题”到“能应急”故障排查与日常维护的实战法4.1 一个典型的线上故障排查流程生产环境故障排查和你平时在虚拟机里做实验完全是两码事。虚拟机挂了无所谓生产环境挂了影响的是真实用户。所以我一直坚持一个原则先止损再定位。这个顺序非常容易被新人忽略但恰恰是笔试和面试中区分“背题党”和“实战党”的关键。举个例子某天线上出现“用户提交订单失败”的告警。你不会先坐下来慢慢分析日志而是第一时间看影响面是全部用户失败还是部分接口失败是入口网关的问题还是后端的订单服务挂了如果网关还活着后端订单服务报错率突然飙高最常见的止损动作是先把流量切到备用集群或者直接重启异常服务。等系统恢复用户不再受影响再开始真正的根因分析。根因分析的思路也很重要。我的习惯是时间线梳理回看告警发生前的监控曲线找到指标异常的开始时间点异常分析查看应用日志里的错误堆栈结合最近一次变更记录判断是不是新发布的版本引入了问题依赖检查确认数据库、缓存、消息队列这些外部依赖是否有异常。你会发现大部分线上故障的根因要么是变更引入的问题要么是依赖组件抖动要么是容量不足。笔试和面试遇到故障排查题你一定要把“先止损、再定位、后复盘”这个逻辑讲出来。哪怕你最后分析的方向不完美至少这个框架是对的。相比之下很多同学一上来就说“我登录服务器查日志”这在生产环境里其实是比较低效的做法。4.2 日常维护的四个高频场景系统上线之后真正的考验才开始。日常维护工作听起来不刺激但恰恰是拉开运维水平差距的地方。我把日常维护分成四个高频场景每个场景都有对应的核心技能。第一个场景是容量与性能优化。服务器CPU偏高、内存占用持续增长、数据库慢查询变多这些都需要你及时发现并处理。之前遇到过内存泄漏的问题服务运行一周后内存占用从2GB涨到8GB最后通过dump内存快照分析定位到某个静态变量不断积累数据导致的。这类问题在笔试里虽然不一定直接考但它背后考察的是你对基础指标的敏感度。第二个场景是变更管理。生产环境的任何变更小到改一个配置大到发布新版本都应该走评审流程。变更前评估影响面变更中观察核心指标变更后留足观察期。我个人的铁律是不在业务高峰期做变更不改没有备份的配置变更前必须准备回滚方案。第三个场景是备份与恢复演练。备份不是把数据拷走就完了关键是备份可不可用。我建议每隔一段时间就做一次恢复演练把备份的数据恢复到一台测试机器上验证数据库是否能正常启动、数据是否完整。没有经过恢复演练的备份只能算“心理安慰”。第四个场景是脚本化与工具化。日常巡检、日志清理、批量执行命令这些重复性工作都应该用脚本自动化。比如我写过一个批量巡检脚本用ssh遍历几十台机器采集关键指标汇总成一个表格输出。这件事如果手动做可能要四个小时脚本跑下来只要几分钟这是运维工作里性价比最高的事情。4.3 笔试之外的加分项自动化与效能说到自动化这是很多校招同学在简历上写了“熟悉Shell”却难以证明的痛点。笔试和面试真正想看的是你能不能把自动化思维应用到实际场景中。举一个很常见的例子每周要巡检30台服务器检查磁盘使用率、服务端口、进程状态。如果你只是手动登录每一台机器又慢又容易漏。一个合理的脚本会这样设计用Ansible或者简单的shell循环批量执行检查命令把结果以统一格式输出遇到异常项高亮标记。这种思路在笔试里也能体现出来比如题目让你写一个脚本检查所有机器上的Nginx进程是否存在你写的脚本里就要考虑批量执行、超时处理、异常退出码这些细节。自动化还有一个重要方向是配置管理和发布流水线。现在稍微成熟一点的公司都会用Ansible、SaltStack等工具做批量配置管理用Jenkins、GitLab CI等工具做持续集成和发布。笔试不一定会考具体工具的操作但如果你能说出自动化的整体思路“配置统一管理、发布可回滚、变更可追溯”面试官会认为你有生产级思维这是校招里很稀缺的素质。5. 常见问题与避坑清单校招与新人期的真实教训5.1 笔试和面试中容易失分的细节复盘这套笔试和大量运维面试案例我发现失分最可惜的不是不会的知识点而是一些本可以避免的细节问题。第一命令只写名称不写参数和输出含义。比如回答CPU排查时写“用top命令”却没有说要看哪几列、什么指标代表异常。正确写法是“用top查看us、sy、wa这几个CPU占比如果wa高说明磁盘IO是瓶颈”。这种细节直接反映你是在背命令还是有真实排查经验。第二故障排查缺乏顺序感。很多同学一上来就丢一堆命令不知道先看什么后看什么。生产环境的故障排查一定是先判断影响面再逐层缩小范围从外部现象逐步逼近内部根因。答题时建议按“先确认故障现象、再检查整体状态、然后定位具体进程和应用、最后查看日志和依赖”的顺序组织语言。第三忽视非功能性内容。比如设计一个高可用方案时写了负载均衡、写了集群但没有写监控告警、没有写备份恢复策略、没有写安全问题。在设计类题目里这些“周边能力”往往占了30%以上的分数。记住生产环境不是“能跑”就行而是“能稳定跑、挂了能恢复”才行。我整理了一份高频失分点速查表大家可以对照自查失分点错误示范正确思路排查类题目一上来就“重启服务”先止损、再定位、后复盘命令题只写命令名称写清楚看什么指标、什么值算异常架构设计题只列组件清单补充容量、监控、备份、安全方案故障分析题只分析一个可能原因列出优先级按可能性逐项排查MySQL题目只答“加索引”分析索引失效原因考虑代价和副作用5.2 新人上手生产环境容易踩的坑新人在生产环境踩过坑几乎每个运维工程师都有一段辛酸史。这里分享几个我印象最深、也很典型的坑。第一个坑是误操作高危命令。在错误目录下执行了rm -rf或者手滑kill掉了关键进程。这类问题要靠习惯来避免生产环境执行命令前先确认当前目录和操作对象高危命令先用echo打印出来确认能不用root就不用root。我个人的习惯是在关键目录下面加一个提示符显示当前路径降低误操作概率。第二个坑是不看磁盘空间就重启服务。服务重启后需要写日志、写临时文件如果磁盘已经满了服务不但起不来还可能留下脏数据。我遇到过一个线上事故应用崩了之后同事直接重启但因为磁盘写满启动过程中一直报错最后清理了空间才恢复。所以重启之前一定要用df -h确认磁盘用ulimit -a确认资源限制这些检查只需要一分钟但能避免多小时的故障。第三个坑是变更前不做备份。改一个配置文件之前至少把原文件复制一份数据库执行一条更新语句之前先确认影响行数并备份相关数据。很多公司现在有变更评审和发布平台但校招同学入职后接触的早期项目可能没有那么完善一定要自己养成备份习惯。第四个坑是日志信息看不全就下结论。看到日志里有一行“Connection refused”就断定数据库挂了结果其实是网络问题或者防火墙限制。正确的做法是看全上下文结合时间点、前后的其他日志、以及监控指标综合判断。这也是为什么我一直强调排查问题要看全链路而不是盯着一行日志纠结。5.3 一套值得长期积累的运维知识清单如果你现在还在准备阶段不知道从哪里下手不妨按下面这个知识清单分阶段积累。不用一口吃成胖子每个阶段都结合实际操作效果最好。第一阶段是操作系统与网络基础。Linux常用命令、文件系统与权限、进程管理、systemd、TCP/IP协议栈、HTTP协议、DNS原理。这一阶段的目标是“提到一个概念你能解释原理也能说出对应命令”。第二阶段是中间件与应用组件。MySQL的安装、主从搭建、索引调优、备份恢复Redis的持久化、集群、缓存策略Nginx的配置与负载均衡LVS四层负载均衡消息队列的选型和使用场景。这一阶段的目标是“看淡文档能独立搭建出一套可用的环境”。第三阶段是脚本与自动化。Shell脚本编写包括循环、条件判断、文本处理工具awk和sedPython基础能写简单的自动化工具至少动手用Ansible之类工具做一次批量配置管理。第四阶段是监控、日志与稳定性。了解监控指标体系部署一套开源监控系统熟悉集中式日志平台理解限流、降级、熔断、切流量这些稳定性手段的含义和使用场景。这套知识体系的积累不是为了刷题而是真正服务于那个核心场景从零搭建生产系统并做好后续维护。你会发现当你能独立完成一个小项目的部署上线、接入监控、配置告警并写出应急预案和执行过一次故障模拟演练之后再看这类笔试题很多题目几乎不用背都能答出来。6. 从这套题延伸出去的成长建议6.1 学会用“系统思维”而不是“命令堆砌”来回答问题复盘完这套滴滴出行的校招运维笔试题我最想强调的一点是运维这个岗位越往后走越拼系统思维。同一个问题“服务器负载高怎么办”初级选手会背top、vmstat、iostat、dmesg这些命令有经验的人会先说负载高的表现形式和影响范围再确定排查方向然后才引入命令去验证最后给出容量规划或优化建议。笔试的案例分析题本质上就是在模拟生产环境。出题人把真实的故障现象抽象成考题看你能不能按照生产环境的逻辑去分析。所以复习时不要只低头背题要经常问自己如果这台机器真的出现在我面前我会怎么做这个习惯会潜移默化地提升你的答题质量。另一个容易被忽略的点是沟通表达。同样一个排查思路表达得有条理和毫无逻辑得分差距很大。我做面试官时最怕听到的回答是“我觉得可能是A也可能是B还有可能是C”没有优先级没有推理过程。更好的方式是“我首先检查A因为A最可能导致这个现象而且检查成本最低如果A正常再顺着链路检查B”。这种表达展示了结构化的思维是校招面试中的高分特征。6.2 结合我自己的实际操作体会最后再分享一个建议从我个人的经验来看成为一名合格的系统运维工程师最有效的成长路径不是刷题而是亲手搭出一套“麻雀虽小、五脏俱全”的生产环境。找两台虚拟机一台作为应用服务器一台作为数据库服务器从系统初始化和内核参数调优开始部署Nginx、MySQL、Redis然后写一个简单的Web应用接进去再部署监控系统设定告警规则最后写一份应急预案模拟一次数据库宕机的故障演练。整个过程走下来你会把笔试里那些零散的知识点全部串起来。之后你会理解为什么说“从零搭建系统”和“后期维护”是运维工程师最核心的能力为什么面试官不在看你背了多少命令而是看你在复杂场景下怎么思考、怎么决策、怎么平衡成本和稳定性。如果你想把这套知识体系学得更扎实建议从手边一个很小的项目开始把“容量估算、系统初始化、应用部署、监控告警、备份恢复、故障演练”这六个环节完整跑通一遍。跑通之后再回头看这套校招笔试题你会发现题目还是那些题目但你眼里看到的东西已经完全不同了。