运维要考哪些证书？

证书不是入行门槛，但能帮你系统地学一遍，也有助于简历筛选：Linux 方向常见红帽的 RHCSA、RHCE，网络方向常见华为 HCIA、HCIP 和思科 CCNA，容器方向有 CNCF 的 CKA。面试时更看重动手经验，能讲清自己处理过的故障比证书更有说服力。

运维要值夜班吗？

多数岗位要。机房运维通常倒班，系统和应用运维多为白班加轮流值守（on-call），告警在夜里响时值班人员要在约定时间内响应；较大的变更也常安排在夜间业务低峰的窗口执行。

运维工程师要会写代码吗？

至少要会 Shell，能把重复操作写成脚本；往 DevOps、SRE 方向走，要熟练掌握 Python 或 Go，能开发自动化工具、调用各种系统的 API。不写代码也能入行，但职业发展的空间会小很多。

运维是做什么的：工作内容、岗位分类和技能要求

运维是做什么的？一句话：让系统持续、稳定、安全地运行。“运维”是“运行维护”的简称，对应英文的 Operations（Ops）。开发人员把网站、App、业务系统写出来，运维人员负责把它部署到服务器上，持续监控它的状态，出了故障第一时间恢复，定期备份保证数据不丢，并在业务增长前把服务器、带宽、存储准备好。日常工作可以归为五项：上线与变更、监控告警、备份恢复、故障处理、巡检。按管理的对象不同，运维又分为系统运维、网络运维、应用运维、机房 IDC 运维，以及更偏工程化的 DevOps 和 SRE。

运维是什么意思：用可用性衡量工作成果

运维做得好不好，最直接的衡量标准是可用性：一段时间内系统能正常提供服务的时间占比。几个“9”对应的允许中断时间如下：

可用性目标	每月（按 30 天）允许中断	每年允许中断
99%	7.2 小时	87.6 小时，约 3.65 天
99.9%	43.2 分钟	8.76 小时
99.95%	21.6 分钟	4.38 小时
99.99%	4.32 分钟	约 52.6 分钟

从 99.9% 到 99.99%，每月允许的中断从 43 分钟缩到 4 分钟，这时靠人半夜爬起来重启已经来不及，必须有冗余架构、自动切换和完善的监控。所以运维工作的本质，是用流程、工具和架构，把“出问题”的概率和“出问题后的影响时间”都压下来。

运维的五项日常工作

工作	做什么	做到什么程度才算合格
上线与变更	发布新版本、改配置、扩容、升级系统和软件	每次变更有方案、有回滚步骤、有验证方法，留下记录
监控告警	采集服务器、网络、应用的指标，异常时通知值班人员	故障先由监控发现，而不是由用户投诉发现
备份恢复	定期备份数据库、文件和配置，并演练恢复	恢复演练成功过，知道恢复一次要多长时间
故障处理	接到告警或报障后定位、止损、恢复、复盘	有分级标准和响应时限，复盘后同类问题不再重复
巡检	按清单定期检查容量、性能、证书、硬件和机房环境	隐患在变成故障之前被发现

上线与变更：先想好怎么退回来

很多故障都发生在变更之后，所以变更是运维最需要流程约束的环节。一次标准的变更按这个顺序走：

写方案：改什么、影响哪些业务、操作步骤、回滚步骤、验证方法；
评审：负责人确认风险和时间窗口，重要业务同步通知相关方；
窗口内执行：例如安排在 22:00 至次日 06:00 的业务低峰，按方案逐步操作；
验证：按事先写好的方法确认业务正常，例如关键页面返回 200、错误率没有上升；
记录：结果写进变更记录，失败就按回滚步骤恢复，事后分析原因。

没有回滚方案的变更不执行，这是最朴素也最有用的一条规矩。

监控告警：先分级，再通知

监控覆盖三层：硬件和机房（温度、电源、硬盘）、系统和网络（CPU、内存、磁盘、带宽、丢包）、应用（请求量、错误率、响应时间）。常用的判断框架是 Google SRE 提出的四个黄金指标：延迟、流量、错误、饱和度。告警必须分级，否则值班人员会被大量无关紧要的消息淹没，真正的故障反而被忽略。下面是一套可参考的分级（数值是示例，按业务自行约定）：

级别	典型情况	响应要求（示例）	通知方式
P1	核心业务不可用，机房断电或断网	5 分钟内响应，每 30 分钟同步进展	电话加群消息，同时通知主管
P2	部分功能故障，冗余节点宕机	15 分钟内响应	电话或即时消息
P3	磁盘使用率超过 85%，证书 14 天内到期	当天工作时间内处理	即时消息或工单
P4	备份完成、计划任务结果等通知	无需即时响应	邮件或日报

备份恢复：没恢复过的备份不算备份

两个指标决定备份方案：RPO（最多能丢多长时间的数据）和 RTO（多长时间内必须恢复）。例如数据库每天凌晨全量备份、每小时备份一次增量日志，RPO 就是 1 小时。存放上遵循 3-2-1 原则：至少 3 份数据，放在 2 种不同的介质上，其中 1 份在异地。最容易被省略的是恢复演练：每季度把备份恢复到一台测试服务器上，记录实际耗时，这个时间才是你真实的 RTO。

故障处理：先恢复，再找原因

故障处理的顺序是：发现 → 确认影响范围 → 止损 → 定位根因 → 恢复验证 → 复盘。止损优先于定位：最近有变更就先回滚，单台服务器异常就先摘出负载均衡，流量异常就先限流，业务恢复了再慢慢查原因。复盘写清时间线、根因、改进项、负责人和完成期限，目的是让同类故障不再发生，而不是追究个人。

巡检：把隐患挡在故障之前

服务器每日巡检可以写成脚本，每天跑一遍，有异常再人工处理：

uptime                                              # 负载是否明显高于 CPU 核数
df -hT | awk 'NR==1 || $6+0 >= 80'                  # 使用率 80% 以上的分区
free -h                                             # 内存和 swap 使用情况
systemctl --failed                                  # 启动失败的服务
journalctl -p err --since "24 hours ago" | tail -n 20   # 近 24 小时的错误日志
journalctl -u ssh -u sshd --since "24 hours ago" | grep -c "Failed password"   # 近 24 小时 SSH 密码登录失败次数
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -enddate                    # HTTPS 证书到期时间

机房的巡检还包括温湿度、UPS 和空调运行状态、机柜和设备的告警指示灯，通常按班次记录。

运维岗位分类：五类运维各做什么

岗位	管什么	日常工作	常用工具
系统运维	服务器和操作系统	装系统、打补丁、管账号权限、性能调优、存储和备份	Linux 命令、Shell、Ansible、Zabbix 或 Prometheus
网络运维	交换机、路由器、防火墙、出口线路	配置 VLAN 和路由、排查丢包和延迟、处理线路故障、做网络变更	设备命令行、ping、mtr、tcpdump、SNMP 监控
应用运维	业务系统及其中间件	发布上线、管理 Nginx、Tomcat、MySQL、Redis 等组件，分析日志，规划容量	CI/CD 流水线、日志平台、APM
机房 IDC 运维	机房里的物理设施和硬件	设备上下架、布线、巡检、换件报修、动环告警处理、客户进出陪同	BMC 远程管理、DCIM、工单系统、动环监控
DevOps / SRE	交付流程和系统可靠性	建设 CI/CD 和基础设施即代码，制定 SLO，组织值班和复盘，用开发手段消除重复劳动	Git、Terraform、Kubernetes、Prometheus、Python 或 Go

此外，规模大的公司还会单独设数据库运维（DBA）和安全运维岗位。小公司里，一个运维往往同时兼着系统、网络和应用三块。

DevOps 和 SRE 容易混淆。DevOps 是一种协作方式，主张开发和运维共同负责从写代码到线上运行的全过程，代表实践是持续集成、持续交付和基础设施即代码。SRE（站点可靠性工程）起源于 Google，用软件工程的方法做运维：用 SLO 量化可靠性目标，用“错误预算”平衡发布速度和稳定性。例如 SLO 定为每月 99.9%，这个月的错误预算就是 43.2 分钟，用完了就暂停新功能上线、优先修稳定性问题。Google 的 SRE 实践还要求重复性的手工运维工作不超过工作时间的一半，其余时间用来写工具、改进系统。

岗位与技能要求对照：运维需要学什么

岗位	必备技能	加分项
系统运维	Linux 系统管理、Shell 脚本、存储与 RAID、常见服务的配置	Ansible 等批量管理工具，虚拟化平台
网络运维	TCP/IP、子网划分、VLAN、静态路由，至少一个厂商设备的命令行	OSPF、BGP 等路由协议，抓包分析
应用运维	Linux、Nginx 等中间件、数据库基本操作、日志分析	能读懂业务架构，CI/CD
机房 IDC 运维	服务器硬件、布线规范、BMC 使用、供电与制冷常识	网络和 Linux 基础，脚本自动化
DevOps / SRE	编程（Python 或 Go）、容器与 Kubernetes、监控体系、CI/CD	分布式系统原理，性能分析

零基础入门，建议按这个顺序学，每一步都在自己的虚拟机或便宜的云服务器上动手：

Linux 基础：文件和权限、进程、软件包、systemd 服务、日志查看；
网络基础：IP 与子网、DNS、TCP 三次握手、常用排查命令；
Shell 脚本：把一项每天手工做的检查写成脚本，放进定时任务；
一套 Web 服务：从零搭起 Nginx、应用程序和 MySQL，配好 HTTPS；
一套监控：用 Zabbix 或 Prometheus 监控上面这套服务，设置告警；
一个自动化工具：用 Ansible 把第 4 步的部署过程写成剧本，一条命令重建整套环境。

做完这六步，再按兴趣往系统、网络、应用或 SRE 方向深入。

运维工程师的一天

下面是两种岗位一个普通工作日的示例，实际安排因公司和班制而异：

时间	系统或应用运维（互联网公司）	机房 IDC 运维（白班）
09:00	看夜间告警和值班记录，确认有没有遗留问题	交接班，核对夜班处理过的工单和告警
09:30	看监控大盘：错误率、磁盘、备份任务是否成功	巡检机房：温湿度、UPS、空调、机柜告警灯
10:30	处理工单：开通账号、给数据库扩容磁盘	上架两台新服务器：接线、配 BMC 地址、录入资产台账
13:30	参加变更评审，确认晚上发版的方案和回滚步骤	按工单为客户更换故障硬盘，旧盘登记返修
15:00	写脚本，把每周手工导出的报表改成自动生成	处理报障“服务器连不上”：先看远程控制台，再查交换机端口
17:30	更新文档，交代晚上值守的注意事项	写交接记录，未完成的工单交给夜班
22:00	在变更窗口执行发版，验证后结束；本周轮到 on-call	夜班同事值守动环和网络告警

可以看出两类岗位的共同点：大量时间花在工单、告警和变更这三条线上。工作做得好的运维，会不断把重复的事交给脚本和系统，把时间留给排障和改进。

机房运维怎么用 DCIM、工单和监控系统

机房 IDC 运维的工作对象是成百上千台物理设备，靠记忆和表格很快就会管不过来，通常要靠三类系统配合：监控系统负责发现问题，工单系统负责派活和留痕，DCIM 负责记录每台设备在哪个机柜、接在哪个交换机端口、用哪些 IP。

以 DCIM 机房管理系统为例，它的能力清单里包含工单管理、故障管理、维修管理、流量监控和网络 TOP 排行：带宽异常时从实时流量图和排行里定位是哪台服务器，报修和换件的过程在故障与维修记录里留痕。上面一天工作流里“服务器连不上”这类报障，可以在 IPMI 远程管理里直接打开服务器的 VNC 控制台判断卡在哪一步，必要时远程重启或挂载镜像修复，不用先跑一趟机柜；远程会话全程录像，SSH 会话另有命令级日志，交接和事后复盘时能准确还原谁在什么时候做了什么。