运维的能力——不是会装系统是半夜出事你敢接电话会装Nginx的、会配防火墙的、会搭监控的都不一定是好运维。好运维只有一个标准生产环境出事了你敢不敢接那个凌晨三点的电话。这篇不讲具体命令怎么敲讲的是运维这个角色真正的能力边界——自动化、权限、监控、排障、安全、备份。每一条都不是书本定义是在生产环境吃过亏之后才知道这事情很重要。文章目录运维的能力——不是会装系统是半夜出事你敢接电话一、运维不是给开发打杂的二、运维的六个能力维度1. 部署与自动化——不是手敲命令是沉淀成脚本2. 权限管理——不是锁死是该有的都有不该有的绝对没有3. 监控告警——不是装个Zabbix是真出事第一秒知道4. 排障能力——不是在正常环境里修是在极端状态下快准稳5. 安全加固——不是防火墙一开就安全6. 备份恢复——不是有备份就够了是知道能恢复到哪一秒三、全栈开发 vs 专业运维四、结语一、运维不是给开发打杂的很多开发的认知是运维的工作就是装系统、配环境、部署应用、重启服务。开发写完代码扔过来运维负责丢到服务器上跑。这只是运维最表层的工作。真正的运维要回答的问题远比服务怎么部署更深凌晨三点线上报警是先把报警屏蔽了等明天再修还是立刻排查一个服务CPU打满是先重启恢复服务还是先保留现场做dump数据库磁盘快满了是先通知开发临时控制写入量还是紧急扩容服务器被攻击了是先拔网线还是先留日志开发和运维的视角差异本质上是功能正确 vs 服务可用。开发保证代码逻辑正确运维保证这个服务在任何极端情况下都能尽可能保持可用。开发和运维天然看问题的角度不同——开发要让功能跑起来运维要让功能跑下去。不同视角往往有矛盾但在有紧迫业务需求的场景下争吵得互相让一步。二、运维的六个能力维度1. 部署与自动化——不是手敲命令是沉淀成脚本初级运维装环境打开百度搜Linux安装MySQL教程一步步照着敲命令。好运维装环境脚本写好了一行命令跑完。脚本不是省时间是省失误。凌晨三点手动敲命令少敲一个空格、删错一行配置、忘改一个参数——每一个手滑都可能让故障扩大。所有可能出错的环节都不该在凌晨三点让一个半睡半醒的人去执行。中级运维——脚本化。我装过一次MySQL主从复制改my.ini、建同步账户、CHANGE MASTER TO配log file和position、启动slave。如果不是有详细记录留下来重来一遍会漏掉不少细节。今天回过头看如果有自动化的意识应该把这些操作变成一键脚本。真正成熟的运维——将基础设施代码化。不仅应用代码有版本控制连服务器配置、数据库参数、部署流程都有版本管理。哪天换了一台新服务器不需要重新手动配环境脚本跑完看着它自己运行完就好。2. 权限管理——不是锁死是该有的都有不该有的绝对没有初级运维的权限管理就是一个root密码走天下。好运维的权限管理是分层分级分权限。一个最简单的原则应用运行时用最少权限。Tomcat跑在tomcat用户下不是root。数据库连接用专用账号不是sysdba。FTP上传用专用账号不共享密码。一台服务器上跑多个应用它们的Linux用户不同、数据库账号不同、日志目录权限不同。权限管理的本质是在安全性和便利性之间找平衡。全部锁死没人能干活全部放开出事定责分不清。原则是默认全部关闭申请审批开通定期审计权限。不是用的时候少抱怨是出了事之后追责能到人。3. 监控告警——不是装个Zabbix是真出事第一秒知道初级运维开发说系统慢了上去查。好运维CPU超过80%已经收到告警查完原因开发还没发现慢了。不是等别人告诉你系统出问题是你提前知道系统快出问题了。这才是运维的黄金标准。监控不是装几个工具就完事——磁盘空间不足、CPU飙高、连接池耗尽、慢查询突增、日志报错频率上升……你设了阈值没告警发给你了你说这个问题它自己会修复然后凌晨三点被电话打醒——这就是运维的日常。监控也不是越多越好——告警太多等于没告警。一个运维一天收到200条告警其中180条是自愈型的——Redis内存短暂超过阈值然后自动回落、网络短暂抖动恢复、定时任务超时后重试成功。这180条告警淹没了另外20条真正需要处理的。区分哪些值得告警——一次性涨了3个连接不算事但持续了10分钟涨到100个连接就真的出事了单条慢查询超过100ms不见得要告警不间断地出现就得查。经验丰富的运维不是装了多少监控工具是过滤掉不必要的信息只看真正需要关注的事。没有监控运维就是瞎子——系统在某个角落里悄悄恶化了半个月等性能雪崩的那天你突然发现原来一切本来可以更早解决。4. 排障能力——不是在正常环境里修是在极端状态下快准稳开发和运维排障的核心差异在时间约束上。开发排障功能不对debug一天找到bug修完提交代码下个版本上线。运维排障生产挂了所有人等着每多一分钟就意味着更多人受影响。你没有时间慢慢debug——你必须快速判断根因并做出不完美但有效的恢复决策。你可能先重启服务恢复可用性然后再保留现场dump回来分析到底哪里出了问题。一个真正的运维排障背后依赖的不是工具是对系统结构的根本理解——一个请求进来几层、这层的数据被谁引用、那个配置变更之后除了重启还有别的办法能生效吗。排完故障不写复盘报告的下次同样的问题还会中招。一个好运维的很多本事不是从书本上学来的是从过去每一次故障中一点一滴攒出来的。5. 安全加固——不是防火墙一开就安全初级运维的安全观装个防火墙、配个HTTPS、设置密码复杂度。好运维的安全观每一个对外暴露的端口都是潜在的攻击面。不是防火墙配了就安全——防火墙是你最后一层物理防御真正的安全是应用内部有没有路径穿越漏洞。文件上传时攻击者把文件名写成../../etc/passwd你的代码检查了吗接口加密是只防外部还是内部也防。前端和后端之间加了SM4加密但后端和数据库之间有没有明文传输日志里有没有不小心打印了密码或身份证号。开发debug时加了一行log.info(user)这行代码如果上线了所有用户信息就全暴露在日志文件里安全是一个分层防御体系不是一道防火墙能搞定的。每一层都有可能被突破但每多一层攻击成本就翻一倍。攻击者从外网穿透到内网要过防火墙从内网到数据库要过权限审计从数据库到数据本身要过加密——三层全过才能拿到明文数据。你不需要每一层都做到顶级但你不能只有一层。6. 备份恢复——不是有备份就够了是知道能恢复到哪一秒运维的备份意识应该和DBA的备份意识是同级的——都是血的教训换来的。备份的本质不是数据丢失了我能找回来是我敢在数据库上做变更操作——因为即使变错了有备份。一个不敢在数据库上做变更的运维本质上是没有可靠的备份——他知道万一失手没有退路。数据库备份是全量增量还是只有全量文件备份是定时同步还是实时同步配置文件备份改了配置有没有Git commit/push改了配置回不来怎么快速恢复备份恢复演练多久没做过了最近一次恢复的时候有没有发现备份文件是坏的有备份是底线知道备份能恢复到哪一秒是专业水平定期演练恢复过程且备份文件本身不损坏是资深运维和初级运维的分界线——很多人的备份从来没被验证过直到真正需要恢复的那天才发现备份文件是坏的。三、全栈开发 vs 专业运维维度全栈开发做运维专业运维部署能搭能配手敲命令脚本化容器化一键部署监控知道几个关键指标完整的监控告警体系告警降噪排障凭经验查日志从系统指标逐层下钻到根因自动化手动CI/CD流水线自动回滚安全基本防护分层防御定期渗透测试备份有备份备份验证灾备切换演练一个全栈开发做运维处于能搞定但不够精细的层次——能搭能配、会查日志、配过权限。中级运维比你纯运维操作熟练——自动化部署、监控告警体系、CI/CD流水线、网络故障定位、日志聚合这些比你自己做过的那样命令行加手动迁移更专门化。但你不需要在运维上成为专家因为你的优势在于架构师全栈的交叉判断力运维配好了防火墙你知道业务代码产生的文件怎么被MSMQ跨域传输运维配了监控告警你知道哪一个配置变更之后最可能触发一个意想不到的告警。四、结语运维的核心能力不是会装多少软件是对各种极端情况有预案。不是预测未来是为每一种可能的失败做好准备。一个优秀的运维工程师不是因为工具用得好是因为在无数次排障实战中磨出来的——他们从不敢说这个系统永远不会挂但他们敢说挂了我能给你弄好。这个底气不是来自技术文档是每一次故障之后复盘到凌晨三点第二天早上再爬起来继续干的积累。
运维的能力——不是会装系统是半夜出事你敢接电话
运维的能力——不是会装系统是半夜出事你敢接电话会装Nginx的、会配防火墙的、会搭监控的都不一定是好运维。好运维只有一个标准生产环境出事了你敢不敢接那个凌晨三点的电话。这篇不讲具体命令怎么敲讲的是运维这个角色真正的能力边界——自动化、权限、监控、排障、安全、备份。每一条都不是书本定义是在生产环境吃过亏之后才知道这事情很重要。文章目录运维的能力——不是会装系统是半夜出事你敢接电话一、运维不是给开发打杂的二、运维的六个能力维度1. 部署与自动化——不是手敲命令是沉淀成脚本2. 权限管理——不是锁死是该有的都有不该有的绝对没有3. 监控告警——不是装个Zabbix是真出事第一秒知道4. 排障能力——不是在正常环境里修是在极端状态下快准稳5. 安全加固——不是防火墙一开就安全6. 备份恢复——不是有备份就够了是知道能恢复到哪一秒三、全栈开发 vs 专业运维四、结语一、运维不是给开发打杂的很多开发的认知是运维的工作就是装系统、配环境、部署应用、重启服务。开发写完代码扔过来运维负责丢到服务器上跑。这只是运维最表层的工作。真正的运维要回答的问题远比服务怎么部署更深凌晨三点线上报警是先把报警屏蔽了等明天再修还是立刻排查一个服务CPU打满是先重启恢复服务还是先保留现场做dump数据库磁盘快满了是先通知开发临时控制写入量还是紧急扩容服务器被攻击了是先拔网线还是先留日志开发和运维的视角差异本质上是功能正确 vs 服务可用。开发保证代码逻辑正确运维保证这个服务在任何极端情况下都能尽可能保持可用。开发和运维天然看问题的角度不同——开发要让功能跑起来运维要让功能跑下去。不同视角往往有矛盾但在有紧迫业务需求的场景下争吵得互相让一步。二、运维的六个能力维度1. 部署与自动化——不是手敲命令是沉淀成脚本初级运维装环境打开百度搜Linux安装MySQL教程一步步照着敲命令。好运维装环境脚本写好了一行命令跑完。脚本不是省时间是省失误。凌晨三点手动敲命令少敲一个空格、删错一行配置、忘改一个参数——每一个手滑都可能让故障扩大。所有可能出错的环节都不该在凌晨三点让一个半睡半醒的人去执行。中级运维——脚本化。我装过一次MySQL主从复制改my.ini、建同步账户、CHANGE MASTER TO配log file和position、启动slave。如果不是有详细记录留下来重来一遍会漏掉不少细节。今天回过头看如果有自动化的意识应该把这些操作变成一键脚本。真正成熟的运维——将基础设施代码化。不仅应用代码有版本控制连服务器配置、数据库参数、部署流程都有版本管理。哪天换了一台新服务器不需要重新手动配环境脚本跑完看着它自己运行完就好。2. 权限管理——不是锁死是该有的都有不该有的绝对没有初级运维的权限管理就是一个root密码走天下。好运维的权限管理是分层分级分权限。一个最简单的原则应用运行时用最少权限。Tomcat跑在tomcat用户下不是root。数据库连接用专用账号不是sysdba。FTP上传用专用账号不共享密码。一台服务器上跑多个应用它们的Linux用户不同、数据库账号不同、日志目录权限不同。权限管理的本质是在安全性和便利性之间找平衡。全部锁死没人能干活全部放开出事定责分不清。原则是默认全部关闭申请审批开通定期审计权限。不是用的时候少抱怨是出了事之后追责能到人。3. 监控告警——不是装个Zabbix是真出事第一秒知道初级运维开发说系统慢了上去查。好运维CPU超过80%已经收到告警查完原因开发还没发现慢了。不是等别人告诉你系统出问题是你提前知道系统快出问题了。这才是运维的黄金标准。监控不是装几个工具就完事——磁盘空间不足、CPU飙高、连接池耗尽、慢查询突增、日志报错频率上升……你设了阈值没告警发给你了你说这个问题它自己会修复然后凌晨三点被电话打醒——这就是运维的日常。监控也不是越多越好——告警太多等于没告警。一个运维一天收到200条告警其中180条是自愈型的——Redis内存短暂超过阈值然后自动回落、网络短暂抖动恢复、定时任务超时后重试成功。这180条告警淹没了另外20条真正需要处理的。区分哪些值得告警——一次性涨了3个连接不算事但持续了10分钟涨到100个连接就真的出事了单条慢查询超过100ms不见得要告警不间断地出现就得查。经验丰富的运维不是装了多少监控工具是过滤掉不必要的信息只看真正需要关注的事。没有监控运维就是瞎子——系统在某个角落里悄悄恶化了半个月等性能雪崩的那天你突然发现原来一切本来可以更早解决。4. 排障能力——不是在正常环境里修是在极端状态下快准稳开发和运维排障的核心差异在时间约束上。开发排障功能不对debug一天找到bug修完提交代码下个版本上线。运维排障生产挂了所有人等着每多一分钟就意味着更多人受影响。你没有时间慢慢debug——你必须快速判断根因并做出不完美但有效的恢复决策。你可能先重启服务恢复可用性然后再保留现场dump回来分析到底哪里出了问题。一个真正的运维排障背后依赖的不是工具是对系统结构的根本理解——一个请求进来几层、这层的数据被谁引用、那个配置变更之后除了重启还有别的办法能生效吗。排完故障不写复盘报告的下次同样的问题还会中招。一个好运维的很多本事不是从书本上学来的是从过去每一次故障中一点一滴攒出来的。5. 安全加固——不是防火墙一开就安全初级运维的安全观装个防火墙、配个HTTPS、设置密码复杂度。好运维的安全观每一个对外暴露的端口都是潜在的攻击面。不是防火墙配了就安全——防火墙是你最后一层物理防御真正的安全是应用内部有没有路径穿越漏洞。文件上传时攻击者把文件名写成../../etc/passwd你的代码检查了吗接口加密是只防外部还是内部也防。前端和后端之间加了SM4加密但后端和数据库之间有没有明文传输日志里有没有不小心打印了密码或身份证号。开发debug时加了一行log.info(user)这行代码如果上线了所有用户信息就全暴露在日志文件里安全是一个分层防御体系不是一道防火墙能搞定的。每一层都有可能被突破但每多一层攻击成本就翻一倍。攻击者从外网穿透到内网要过防火墙从内网到数据库要过权限审计从数据库到数据本身要过加密——三层全过才能拿到明文数据。你不需要每一层都做到顶级但你不能只有一层。6. 备份恢复——不是有备份就够了是知道能恢复到哪一秒运维的备份意识应该和DBA的备份意识是同级的——都是血的教训换来的。备份的本质不是数据丢失了我能找回来是我敢在数据库上做变更操作——因为即使变错了有备份。一个不敢在数据库上做变更的运维本质上是没有可靠的备份——他知道万一失手没有退路。数据库备份是全量增量还是只有全量文件备份是定时同步还是实时同步配置文件备份改了配置有没有Git commit/push改了配置回不来怎么快速恢复备份恢复演练多久没做过了最近一次恢复的时候有没有发现备份文件是坏的有备份是底线知道备份能恢复到哪一秒是专业水平定期演练恢复过程且备份文件本身不损坏是资深运维和初级运维的分界线——很多人的备份从来没被验证过直到真正需要恢复的那天才发现备份文件是坏的。三、全栈开发 vs 专业运维维度全栈开发做运维专业运维部署能搭能配手敲命令脚本化容器化一键部署监控知道几个关键指标完整的监控告警体系告警降噪排障凭经验查日志从系统指标逐层下钻到根因自动化手动CI/CD流水线自动回滚安全基本防护分层防御定期渗透测试备份有备份备份验证灾备切换演练一个全栈开发做运维处于能搞定但不够精细的层次——能搭能配、会查日志、配过权限。中级运维比你纯运维操作熟练——自动化部署、监控告警体系、CI/CD流水线、网络故障定位、日志聚合这些比你自己做过的那样命令行加手动迁移更专门化。但你不需要在运维上成为专家因为你的优势在于架构师全栈的交叉判断力运维配好了防火墙你知道业务代码产生的文件怎么被MSMQ跨域传输运维配了监控告警你知道哪一个配置变更之后最可能触发一个意想不到的告警。四、结语运维的核心能力不是会装多少软件是对各种极端情况有预案。不是预测未来是为每一种可能的失败做好准备。一个优秀的运维工程师不是因为工具用得好是因为在无数次排障实战中磨出来的——他们从不敢说这个系统永远不会挂但他们敢说挂了我能给你弄好。这个底气不是来自技术文档是每一次故障之后复盘到凌晨三点第二天早上再爬起来继续干的积累。
