★ FEATURED ARTICLE 1. 从零到一运维实习第一阶段到底在练什么很多人对运维实习第一阶段的理解是“装装系统、看看日志、重启服务”说实话我刚开始也这么想。真正进入这个阶段之后才发现第一阶段的核心根本不是让你掌握多少高深技术而是把你从一个“会用电脑的人”变成一个“对生产环境有敬畏感的人”。这个转变听起来很虚但它决定了你后面能不能走远。运维实习第一阶段通常持续两到四周不同团队节奏不一样。有的团队会让你先花一周时间熟悉监控面板和工单系统有的团队第二天就把你拉进值班群让你看告警。不管节奏快慢这个阶段要解决的核心问题就三个第一你得知道线上环境长什么样第二你得知道出了问题去哪里看第三你得知道哪些操作绝对不能碰。这三个问题看起来简单但真正做好需要大量的观察、记录和反复确认。我见过不少实习生在第一阶段特别着急觉得天天看文档、看监控、跟着导师后面记笔记太无聊想赶紧上手操作。结果呢要么是在测试环境里乱改配置导致其他人没法用要么是在生产环境里执行了一条看起来无害的命令把某个服务的日志刷爆了。这些坑我都踩过或者见别人踩过所以这篇文章我想把第一阶段该做的事情、该建立的思维习惯、该掌握的最小技能集按照我自己的经验完整地梳理一遍。这篇文章适合几类人看刚入职或刚进入实习期的运维新人、从其他方向转运维的开发者、以及带实习生的一线工程师。我会尽量把每个环节背后的“为什么”讲清楚不只是告诉你做什么还要告诉你为什么这么做、不这么做会怎样。文章里涉及的命令和配置都是通用示例不涉及任何具体公司的内部系统你可以放心参考。2. 第一阶段的知识底座不是学工具是建立三层认知2.1 第一层认知知道你的系统由哪些东西组成很多实习生一上来就开始学某个具体工具比如监控系统怎么配、日志平台怎么查。这其实顺序反了。你应该先搞清楚你负责的系统整体架构是什么样的。不需要深入到每个模块的代码实现但至少要能画出这样一张图用户请求从入口进来经过哪些组件最终落到哪里数据存在什么地方哪些组件之间会互相通信。我当时的做法是找导师要了一份系统架构的简要说明然后自己对着监控面板上的服务列表一个一个去确认每个服务是干什么的。遇到不懂的就记下来攒够五个问题一起去问。这样效率比随时打断别人要高得多。你不需要第一天就全部搞懂但第一周结束的时候你应该能对着架构图说出每个主要组件的职责。这里有个很实用的技巧把系统里的服务按“入口层、应用层、中间件层、存储层”分类。入口层通常是负载均衡和网关应用层是你负责的业务服务中间件层包括消息队列和缓存存储层就是数据库和对象存储。分类之后你会发现大部分告警和问题都能归到某一层里排查的时候就有了方向。2.2 第二层认知知道每个组件的关键指标是什么知道系统由什么组成之后下一步是知道每个组件的健康状态怎么看。这就是监控面板存在的意义。但监控面板上的指标很多你不可能一开始就全部记住。我的建议是先盯住每个组件的“黄金指标”。对于应用服务黄金指标通常是四个请求量、错误率、响应时间、资源使用率。请求量突然掉了可能是上游出了问题错误率飙升可能是代码发布引入了bug响应时间变长可能是下游依赖变慢资源使用率逼近上限可能是容量不够了。这四个指标能覆盖大部分常见问题。对于数据库重点看连接数、慢查询数量、主从延迟。对于消息队列重点看堆积量和消费速率。对于缓存重点看命中率和内存使用率。你不需要背下来但要在监控面板上把这些指标找出来知道它们在哪里、正常范围大概是多少。这样当告警来的时候你能快速定位到是哪个组件出了问题。2.3 第三层认知知道出了问题第一步该做什么这是最容易被忽视但最重要的一层认知。很多新人看到告警的第一反应是“我赶紧去修”但正确的第一反应应该是“我先确认影响范围”。影响范围决定了你处理的优先级和方式。如果只是内部测试环境的一个服务挂了你可以慢慢排查如果是核心业务的生产环境出了问题你需要立刻上报并按照预案处理。第一阶段你不需要独立处理生产故障但你需要知道流程是什么。通常的流程是确认告警真实性确认影响范围上报给值班负责人按照指示执行操作记录处理过程。这个流程看起来简单但在紧张的情况下很容易乱。我建议你在第一阶段就找一张纸把这个流程写下来贴在工位上形成肌肉记忆。注意第一阶段最重要的不是“能修多少问题”而是“知道什么问题不该自己动手”。遇到不确定的情况先问再动这句话值得刻在脑子里。3. 日常操作的最小技能集哪些命令必须练到不假思索3.1 文件与目录操作别小看ls和cd你可能会觉得文件操作太基础了有什么好练的。但我在实习第一周就见过有人因为用错了rm命令的路径把测试环境的一个配置文件删了。基础命令之所以重要是因为它们使用频率最高一旦出错影响也最直接。第一阶段你需要练到不假思索的命令包括ls的各种参数组合-l、-a、-h、-t、cd的绝对路径和相对路径切换、cp和mv的安全用法、rm的确认习惯。特别是rm我建议你在第一阶段养成一个习惯执行rm之前先用ls确认路径或者用mv到临时目录代替直接删除。这个习惯看起来麻烦但能帮你避免绝大多数误删事故。还有一个容易被忽视的命令是find。你需要知道怎么按文件名、按修改时间、按大小来查找文件。比如日志文件太多需要清理时你会用到find加上-mtime参数来筛选。这些操作在后面的日常工作中会反复出现。3.2 文本查看与过滤grep、tail、less的实战组合运维工作中大量时间花在看日志上所以文本查看和过滤命令必须熟练。tail -f是最常用的实时查看日志的方式但你要知道怎么配合grep来过滤关键字。比如你想看某个服务的错误日志可以用tail -f加上grep来只显示包含ERROR的行。grep的常用参数需要记住几个-i忽略大小写、-r递归搜索目录、-c统计匹配行数、-v反向匹配。这些参数组合起来能帮你快速从海量日志里找到关键信息。less命令用来分页查看大文件你需要知道怎么在里面搜索按/然后输入关键字、怎么跳到文件末尾按G、怎么退出按q。我个人的经验是把常用的命令组合写成alias或者小脚本能大幅提升效率。比如我会把“查看某个服务最近100行错误日志”写成一个简短的函数需要的时候直接调用。第一阶段不要求你写多复杂的脚本但要有这个意识。3.3 进程与资源查看top、ps、df、free的日常巡检每天到工位之后花五分钟做一次快速巡检是个好习惯。巡检的内容包括用top或htop看CPU和内存的整体使用情况用ps确认关键进程还在不在用df -h看磁盘空间有没有快满的用free -h看内存余量。这些命令的输出你需要能快速读懂。比如top里面load average的三个数值分别代表1分钟、5分钟、15分钟的平均负载如果1分钟的值远高于15分钟的值说明系统正在经历突发压力。df -h的输出里重点看Use%这一列超过80%就需要关注了。free -h里面available那一列才是真正可用的内存buff/cache虽然被算作已使用但实际上是可回收的。这些巡检动作看起来机械但坚持做能让你对系统的“正常状态”有一个基准认知。当系统出问题时你才能快速判断是哪里不对劲。4. 监控与告警从“看热闹”到“看懂门道”4.1 监控面板的阅读顺序第一次打开监控面板你可能会被满屏的图表吓到。我建议你按照固定的顺序来看这样不容易漏掉关键信息。我的习惯顺序是先看总览面板上的核心业务指标确认有没有明显的异常波动然后看基础设施层面的CPU、内存、磁盘、网络最后看中间件和数据库的专项面板。看图表的时候重点看趋势而不是单点数值。一个指标突然从平稳变成持续上升比它本身数值高低更值得关注。另外要注意对比比如今天的请求量和昨天同一时段相比是多了还是少了这种同比环比的变化往往能提前发现问题。4.2 告警信息的拆解方法收到告警之后不要急着去点“确认”或者“忽略”。先花三十秒把告警内容读清楚。一条典型的告警会包含这些信息告警名称、触发时间、当前值、阈值、影响的实例或服务、告警级别。你需要从这些信息里快速判断出这是不是一个真实的问题影响范围有多大需不需要立即处理。有些告警是“抖动”引起的比如某个指标瞬间超过阈值又马上恢复了。这种告警通常不需要处理但你需要确认它确实恢复了。有些告警是“持续性”的指标超过阈值后一直没降下来这种就需要认真对待了。我建议你在第一阶段准备一个简单的记录表每次收到告警就记一笔时间、告警名称、你的判断、最终处理方式。坚持记两周你就能总结出哪些告警是高频但低危的哪些是低频但需要高度警惕的。这个记录习惯对你后面独立值班非常有帮助。4.3 告警背后的常见原因分类大部分告警的原因可以归到几类里流量突增、代码发布引入问题、依赖组件故障、资源容量不足、配置变更出错。你在第一阶段不需要能修复所有这些问题但需要能大致判断告警属于哪一类。这个判断能力决定了你后续的排查方向。比如同样是错误率上升的告警如果伴随请求量突增那可能是流量问题如果请求量平稳但错误率突然飙升那很可能是刚发布了新代码。再比如响应时间变长的告警如果同时看到数据库慢查询增多那瓶颈可能在数据库如果数据库正常但应用服务的CPU使用率很高那瓶颈可能在应用本身。这种分类判断需要经验积累但你可以通过观察导师的处理过程来加速学习。每次导师处理告警的时候你在旁边看他是怎么一步步缩小范围的这比你自己瞎琢磨效率高得多。5. 工单与协作运维不是单打独斗5.1 工单系统的使用规范运维团队通常会有自己的工单系统用来跟踪变更请求、故障处理、日常任务等。第一阶段你需要学会怎么正确地创建工单、更新工单、关闭工单。这听起来是行政流程但实际上工单记录是你工作留痕的重要方式。创建工单的时候标题要写清楚做什么描述里要包含背景、操作步骤、预期结果、回滚方案。特别是回滚方案很多人会忽略但这是变更安全的关键保障。如果操作出了问题你能按照回滚方案快速恢复而不是手忙脚乱。更新工单的时候要记录实际执行情况和结果。如果操作过程中遇到了意外情况也要如实记录。这些记录在后续复盘或者交接的时候非常有价值。5.2 交接班信息的写法如果你所在的团队有交接班制度第一阶段你可能会跟着导师一起做交接。交接班信息的核心是“让接班的同学知道当前系统状态和需要注意的事项”。一份好的交接班信息应该包含当前有没有未处理的告警、有没有正在进行的变更、有没有需要特别关注的服务或指标。写交接班信息的时候要假设看信息的人对当前情况一无所知。所以不要写“那个服务还是老样子”这种模糊的话要写清楚具体是哪个服务、什么状态、需要注意什么。这个习惯能帮你避免很多因为信息不对称导致的问题。5.3 向导师提问的正确姿势实习生提问是正常的但提问的方式会影响你获得的帮助质量。我总结了一个提问模板先说你遇到了什么问题再说你已经尝试了哪些方法然后说你观察到的现象是什么最后说你怀疑的原因是什么。这样导师能快速理解你的处境给出有针对性的指导。最忌讳的提问方式是“这个怎么办”或者“那个报错了”没有任何上下文。导师还得反过来问你一堆问题才能搞清楚状况效率很低。另外提问之前先自己查一下文档和搜索一下实在找不到答案再问。这不是说不让你提问而是说带着思考去提问你能学到更多。6. 第一阶段最容易踩的五个坑6.1 在生产环境执行未经确认的命令这是最危险也是最常见的坑。生产环境和测试环境看起来一样但影响完全不同。在测试环境删一个文件可能只是影响你自己的测试在生产环境删一个文件可能导致服务不可用。我的建议是第一阶段任何生产环境的操作都要经过导师确认。哪怕你觉得这个命令很安全也要先问一句。这不是能力问题是流程问题。等你对系统足够熟悉之后再逐步独立操作。6.2 忽略变更记录和回滚方案很多新人觉得变更记录是形式主义回滚方案是浪费时间。但真正出过事故的人都知道这两样东西在关键时刻能救命。变更记录让你知道系统最近发生了什么变化回滚方案让你在出问题时能快速恢复。我自己的习惯是任何变更之前先想清楚如果这个操作失败了我怎么恢复如果恢复不了影响是什么想清楚这两个问题再动手能避免很多冲动操作。6.3 只看告警不关注趋势告警是已经发生的问题但很多问题在变成告警之前是有征兆的。比如磁盘空间不是一瞬间满的它是逐渐增长的内存泄漏也不是一瞬间发生的它是慢慢累积的。如果你只盯着告警看就会错过这些趋势信号。第一阶段养成看趋势图的习惯每天花几分钟看看关键指标的变化曲线。当某个指标呈现持续上升或下降的趋势时提前介入处理比等告警响了再处理要从容得多。6.4 不记录问题和解决方案运维工作中会遇到大量重复性的问题。如果你不记录每次遇到都要重新排查一遍效率很低。我建议你从第一阶段就开始建一个自己的知识库可以用最简单的文本文件记录你遇到的问题、排查过程、最终解决方案。这个知识库不需要多正式关键是坚持记录。三个月后你回头看会发现很多问题都是类似的有了记录就能快速定位和解决。而且这个知识库在你写转正汇报或者离职交接的时候是非常有价值的材料。6.5 忽视文档和沟通运维不是一个人对着屏幕敲命令它需要和开发、测试、产品等多个角色沟通。第一阶段你要学会怎么把技术问题用非技术人员能听懂的话说清楚怎么在工单里准确描述问题怎么在群里同步进展。这些软技能看起来不如技术重要但实际上它们决定了你的工作能不能顺利推进。一个技术很强但沟通很差的人在运维团队里会非常吃力。反过来技术中等但沟通顺畅的人往往能走得更远。7. 从第一阶段到第二阶段的过渡信号7.1 什么时候可以开始独立处理简单告警当你对系统架构、监控指标、常见问题类型都有了基本认知之后就可以尝试独立处理一些简单的告警了。判断标准是你能在五分钟内判断出这个告警的原因分类并且知道对应的处理方式。如果做不到说明还需要继续积累。独立处理告警不代表没人兜底你处理完之后还是要让导师确认一下。这个阶段的目标是建立信心和判断力而不是追求完全独立。7.2 什么时候可以参与变更操作变更操作比告警处理风险更高因为它是你主动对系统做出的修改。参与变更操作的前提是你完整地旁观过至少三次变更过程理解变更的流程和风险点并且能独立写出变更方案和回滚方案。刚开始参与变更的时候你可能是执行者而不是决策者。导师告诉你做什么你就做什么但你要理解为什么这么做。随着经验积累你会逐渐参与到变更方案的讨论和制定中。7.3 什么时候可以带更新的实习生当你能够独立处理常见告警、参与变更操作、并且有自己的知识库积累时你就具备了带新人的基础。带新人是最好的学习方式因为你要把你知道的东西讲清楚这个过程会逼着你把模糊的理解变得清晰。不过带新人也要注意分寸不要把自己还没完全搞懂的东西教给别人。遇到不确定的问题和新人一起查资料、一起讨论这样双方都能成长。8. 一些让我少走了弯路的习惯8.1 每天写工作日志我在第一阶段养成了写工作日志的习惯每天下班前花十分钟记录今天做了什么、遇到了什么问题、学到了什么。这个习惯看起来简单但坚持下来收获很大。工作日志不仅帮你回顾和总结还能在写转正汇报或者绩效总结的时候提供素材。日志不需要写得多正式关键是真实和具体。比如不要写“今天学习了监控系统”要写“今天学会了在监控面板上查看服务的错误率指标知道了正常范围是0.1%以下超过1%需要关注”。8.2 建立自己的命令速查表运维涉及的命令和参数很多不可能全部记住。我建议你建一个自己的命令速查表把常用的命令和参数组合记下来需要的时候直接查。这个速查表可以按场景分类比如“查看日志”“检查磁盘”“排查网络”等。速查表的内容可以来自你自己的实践也可以来自文档和别人的分享。关键是要用自己的话重新组织一遍这样才记得住。8.3 定期复盘每周花半小时复盘一下这周的工作想想哪些做得好、哪些可以改进、下周重点提升什么。复盘不需要很复杂三个问题就够了这周最有收获的一件事是什么这周遇到的最大困难是什么下周想重点提升什么这个习惯能帮你保持方向感避免陷入日常琐事中迷失方向。运维工作很容易被各种告警和工单推着走定期复盘能让你跳出来看看自己是不是在正确的轨道上。8.4 保持好奇心但控制动手欲运维需要好奇心看到不懂的东西要去搞清楚。但同时也要控制动手欲特别是在生产环境。看到一个新工具或者新配置先在测试环境试确认没问题再考虑用到生产环境。这个平衡很难把握但很重要。好奇心驱动你学习成长控制动手欲保证你不闯祸。第一阶段尤其要注意这一点因为你对系统的了解还不够深很多操作的风险你评估不了。9. 关于工具选型的一些个人看法第一阶段你可能会接触到各种运维工具监控用的是什么、日志用的是什么、配置管理用的是什么。我的建议是不要急着去学所有工具先把团队正在用的工具用熟。工具是解决问题的手段不是目的。你把团队现有的工具用好了比学一堆用不上的新工具更有价值。当然了解一些主流工具的设计理念是有好处的。比如监控工具大致分为指标监控和日志监控两类配置管理工具大致分为推送式和拉取式两类。了解这些分类能帮你理解不同工具的适用场景但不需要在第一阶段就深入每个工具的细节。如果你确实想学新工具建议在测试环境搭一个最小可用的环境跑通基本流程就行。不要一上来就追求大而全的配置那样容易迷失在细节里。先跑通核心功能再逐步扩展这个学习路径比较高效。10. 写在最后的一点个人体会回头看我的运维实习第一阶段最大的收获不是学会了多少命令或者工具而是建立了一种“对生产环境负责”的意识。这种意识体现在每一个细节里执行命令前先确认路径变更前先想好回滚方案收到告警先判断影响范围操作完成后及时记录和同步。技术可以慢慢学但意识要尽早建立。因为技术上的不足可以通过学习和练习弥补但意识上的缺失可能导致你犯下无法挽回的错误。第一阶段是你职业生涯里试错成本最低的阶段充分利用这段时间去观察、去提问、去记录、去建立好习惯。另外我想说的是运维这个方向需要耐心。很多问题不是一下子就能解决的需要你持续地观察、分析、验证。第一阶段你可能觉得做的事情很琐碎但正是这些琐碎的事情构成了运维工作的基础。把基础打牢了后面才能走得稳。如果你正在经历运维实习第一阶段或者即将开始这个阶段希望这篇文章能给你一些参考。每个人的经历不同你可能会遇到我没提到的情况但核心的思路是相通的先理解系统再理解问题最后才是解决问题。顺序对了路就好走了。
阅读完成 · 觉得有帮助？
