1. 从一无所知到全面重构这十年如果只让我用一个词概括Infra行业的变迁我会说“天翻地覆”。最近团队里讨论AI Infra聊得火热各种AI Infra八股文也刷屏了朋友圈我突然意识到从2015年前后到现在基础设施领域走过的路比过去二十年加起来都要陡峭。这篇内容不是教科书是我作为一个在这个过程中摸爬滚打的工程师把十年间看到的、做过的、踩过的坑串起来的一次复盘。如果你正在做DevOps、SRE、平台工程或者刚刚被“AI Infra”这个词吸引过来想搞清楚基础设施到底在发生什么那这篇梳理应该能给你一个相对完整的坐标系。我们从头说起。1.1 那会儿的“基础设施”长什么样2015年左右绝大多数公司的“基础设施”是长这样的机房机柜里堆着一排又一排物理服务器有戴尔的、有惠普的偶尔混着几台IBM的小机。网络设备清一色思科防火墙、交换机、负载均衡器都靠人工配置。系统管理员和运维工程师手里握着机房的门禁卡有时候大半夜还要跑去机房处理硬件告警。那个年代没有太多花哨的概念基础设施等于硬件加手工运维。机器上线靠装系统模板扩容靠采购流程变更靠凌晨发邮件审批。一个典型的场景是业务侧提需求说“下周要上线一个活动需要新增30台服务器”于是运维同学开始走采购流程、等服务器到货、上架、接网线、装系统、配置网络、部署应用整套流程走下来最快也要一两周。赶上硬件缺货或者机房机柜不够项目延期就是家常便饭。当时所有运维操作都严重依赖经验积累。比如“这台机器负载高了就重启一下”“这个中间件参数有问题就调一下堆内存”看起来不太优雅但在那个阶段确实是最直接有效的处理方式。因为整个系统架构相对简单一台物理机上跑一个Java应用或一个MySQL实例问题定位的链路很短重启和调参往往能用。我接手公司核心交易系统运维工作的第一年印象最深的就是一台数据库服务器出现IO异常夜里两点爬起来处理在机房蹲到天亮。后来我才意识到这种“救火式”工作方式的问题不在于辛苦而在于它本质上不可持续每一次故障处理都是孤立的经验没有沉淀系统没有自我修复能力。1.2 一个扩容工单背后的真相那时做一次扩容背后涉及的角色和协调成本远超现在的想象。先是资源评估。运维要根据业务的峰值预估计算CPU、内存、磁盘和带宽的需求然后提交给采购部门。采购部门询价、比价、下单等服务器到货。到货后运维同学要把服务器接到统一的管理网络里通过远程管理卡修改BIOS设置做RAID配置然后通过PXE网络启动批量装系统。装完系统不算完还要打补丁、配监控、装Agent、设置主机名和DNS解析、加入配置管理当时流行用Puppet或Chef、同步NTP时间。等这些都搞完才开始部署业务代码和中间件。中途任何一个环节出问题比如机器型号变了导致驱动不兼容或者机房某一列机柜的交换机端口不够用了都得现场重新调整。这套流程走下来一次普通的扩容最少需要五到七个工作日。如果赶上业务侧要得急大家就只能加班加点挤时间或者拆东墙补西墙从其他项目里匀一部分机器出来先用。现在回头看当时的整个流程表面上是“流程规范”实际上存在大量隐性的返工和等待。每一次工单流转都伴随着信息损耗。业务说“要30台”运维理解成“30台4核8G”采购买回来才发现规格不对来回扯皮是常有的事。真正的问题在于所有环节都依赖人的经验在中间衔接没有人从整体角度去思考这个过程能不能被自动化、被平台化。于是当业务量快速上涨时运维团队只能靠堆人力来应对。1.3 为什么“稳定性”是那个时代的核心命题2015年前后业界对基础设施团队的考核指标很单一就三个字别宕机。“三个9”意味着一年宕机时间不能超过8.76小时“四个9”意味着一年不能超过52.6分钟。为了这几个九运维团队要做大量的预案和演练主备切换预案、机房断电演练、网络设备重启验证、数据库备份恢复测试。每一项都需要手工操作每一次演练都让人紧张因为演练本身如果不小心就可能引发真故障。我当时所在的团队每个季度都要做一次“机房级容灾演练”。演练前两周就开始准备脚本、梳理依赖关系、确认业务方的配合时间。演练当天所有相关同学守在会议室盯着大屏幕上的监控曲线。切换完成后需要一批一批验证核心链路是否正常。整个过程十几个小时非常消耗体力和心力。那段时间我总觉得哪里不对我们已经投入了这么多人力去保障稳定性为什么还是在不断救火后来才慢慢想明白根源在于整个系统的可观测性太差基础设施和业务之间的关联关系不透明导致故障发生时只能靠猜。一个问题从发现到定位往往要经历“看监控-猜原因-上机器-看日志-再猜原因”的循环效率极低。2. 上云与云原生基础设施进入“软件化”时代转机出现在2016年到2018年。以AWS、阿里云为代表的公有云服务开始在国内大规模普及公司决策层第一次认真讨论“要不要上云”。当时的讨论非常激烈。反对派说数据安全怎么办现有团队的技术栈怎么办成本会不会失控。支持派说弹性、速度、成本结构上云的逻辑其实已经不可逆了。最终从讨论到落地用了差不多半年的时间。现在回头看上云这件事真正改变的并不是服务器从物理机变成了虚拟机而是基础设施的交付模式发生了根本性的变化。2.1 从买机器到点按钮云改变了什么上云之前申请一台服务器要以“周”为单位上云之后在控制台点几下鼠标几分钟就能开出一台配置完全符合要求的实例。这种速度上的变化是表面的更深层的变化是基础设施开始变成一种“可以被编程的资源”。通过API我们可以在代码里创建、销毁、调整服务器而不需要走线下的采购流程。这让“基础设施即代码”IaC有了落地的可能。我第一次用Terraform管理云资源的时候有一种豁然开朗的感觉因为服务器、网络、安全组这些以前需要运维同学去机房操作的东西现在变成了几百行配置代码。代码可以走版本管理、可以评审、可以回滚这和写业务代码的工作流完全一致了。云时代也给团队带来了一些新的挑战。原来运维同学只需要懂物理硬件和Linux系统就行现在还需要懂VPC网络规划、安全组规则、负载均衡策略、对象存储、CDN等等。这些知识点非常琐碎而且云厂商的控制台更新频繁功能越来越多如果不主动学习和跟进很容易掉队。我记得有一次排查一个网络延迟问题查了半天都没找到原因。后来在一份云厂商的文档里看到某个实例类型的网络性能与实例规格大小强相关小规格实例的网络带宽上限比较有限我们正好踩了这个坑。类似这种“云上的性能陷阱”非常多都是传统物理机时代不太会遇到的新问题。2.2 容器编排混战Kubernetes为何胜出云解决了资源供给的弹性问题但应用部署和运维的方式仍然比较传统。我们当时在云主机上部署应用的方式和物理机时代差别不大包管理工具装好运行时环境然后启动进程、配systemd服务、用脚本做发布。这种方式在实例数量少的时候还能应付但当实例规模涨到几十上百台的时候就暴露出各种问题。于是容器技术开始进入视野。Docker让“构建一次到处运行”变成现实开发环境和生产环境的差异被压缩到最小。我至今还记得第一次把服务容器化并发布到测试环境时的场景之前每次环境问题都要花大把时间“在我机器上是好的”这句话终于不再是开玩笑。但容器解决了打包和交付的问题并没有解决运行编排的问题。容器多了以后怎么调度、怎么保证副本数、怎么做滚动更新、怎么处理网络互通这些问题都需要一个统一的编排层来解决。于是就有了那场著名的容器编排大战Swarm、Mesos、Kubernetes三足鼎立。我当时所在的团队其实最早试用的是Swarm因为它的上手门槛低和Docker的集成度最高。但随着业务复杂度上来Swarm在编排功能、故障恢复、扩展性方面的劣势越来越明显。后来我们花了大力气迁移到Kubernetes过程非常痛苦但回头看这个决定是对的。Kubernetes胜出不是因为它是功能最全的而是它从一开始就设计了一套良好的声明式API和控制器模型生态的扩展性远远超过另外两个。Kubernetes让基础设施的“软件化”又往前迈了一大步。以前我们操作的是服务器和进程现在我们操作的是Deployment、Service、Ingress这些抽象资源。系统的期望状态被描述成YAML文件控制器负责把实际状态收敛到期望状态。这个理念贯穿了整个云原生生态也是后来所有平台工具的核心思想。2.3 IaC和可观测性让基础设施变得可编程Kubernetes普及之后基础设施团队的工作重心开始从“管理机器”转向“管理资源”。资源用代码和模板来声明环境一致性通过GitOps来保证。我们开始用Helm打包应用用ArgoCD做持续交付用Prometheus和Grafana搭起一套完整的监控体系用ELK做日志的采集、存储与检索。Prometheus这套技术栈在很大程度上改变了监控的玩法。以前我们用Zabbix主要靠预先配置的模板和触发器很多场景下要到故障发生了才知道系统出问题了。Prometheus基于拉模式的指标采集和PromQL查询可以做到按需发现问题和快速定位异常。配合Grafana的仪表盘整个系统的运行状态变得非常直观。可观测性领域的另一个重要变化是分布式追踪的普及。微服务架构把单体应用拆分成几十个甚至上百个服务一次用户请求要经过多个服务的调用链。当请求变慢或者报错时传统的方法很难判断瓶颈到底在哪个环节。通过Jaeger或者Zipkin这类工具我们可以精准地看到每个环节的耗时和状态定位问题的效率提升了一个量级。这段时间的基础设施演进表面上看是工具的升级换代本质上却是基础设施团队的核心能力从“硬件运维”转向了“软件工程”。很多做运维的同学开始写代码、写Pipeline、设计系统架构这是一次非常深刻的职业能力重构。3. SRE、平台工程与成本治理Infra岗位的自我演进基础设施技术栈剧烈变化的同时Infra这个岗位本身也在被重新定义。十年前我们叫“运维工程师”后来叫“DevOps工程师”再后来叫“SRE”这两年又开始流行“平台工程师”。名称变迁的背后是基础设施团队职责范围和能力模型的一次次重构。3.1 SRE的出现把运维当成软件开发来做SRE这个概念最早来自Google其核心思想是用软件工程的方式来解决运维问题。传统运维靠人工和脚本SRE则强调通过编写代码来自动化地处理运维任务把重复性工作交给系统本身来完成。这个思想对我的影响非常大。以前处理告警我的第一反应是“赶紧看看发生了什么”然后手动去处理。但SRE的思路是系统地梳理告警来源和应对流程把常见的处理步骤自动化让告警触发后系统可以直接执行预定义的操作人工只需要处理真正需要判断的异常情况。在实践中我们团队最先落地的SRE实践是错误预算。有了错误预算的概念之后稳定性不再是一个感性的目标而变成了一个可量化的SLO。比如某个核心服务的SLO是99.95%对应的错误预算每月容忍约21.9分钟的不可用时间。当错误预算消耗过快时我们就会主动冻结变更优先处理稳定性问题而不是等到故障真的发生了再被动应对。SRE还带来了一种“事后复盘”的文化。每次故障处理完我们会写详细的故障报告记录故障的时间线、影响范围、根因、缓解措施和后续改进项。这个传统后来一直保持着团队里沉淀了大量宝贵的故障处理经验。新同学入职后通过阅读这些故障报告能快速了解系统的薄弱点和常见问题这是任何培训文档都给不了的。3.2 平台工程与IDP不再给开发添堵随着微服务和云原生技术栈的复杂度越来越高开发团队自己驾驭基础设施的成本也在急剧上升。以前开发者只需要会写接口、连数据库现在却要懂容器、Kubernetes、消息队列、分布式事务、可观测性这个学习曲线让业务开发同学叫苦不迭。这就催生了平台工程Platform Engineering的兴起。平台团队的核心任务是构建一套内部开发者平台IDP把基础设施的复杂度封装在平台内部让开发者通过简单的操作就能自助完成环境创建、应用部署、日志查看等工作。我们在搭建IDP时最核心的原则是开发者的体验必须快。以环境创建为例以前开发者要新建一套完整的测试环境需要自己折腾Kubernetes命名空间、数据库实例、配置中心、消息队列等等流程繁琐容易出错。有了平台之后开发者只需在门户上填写几个参数服务名、版本号、依赖组件剩下的工作全由平台自动化完成。整个过程从几小时缩短到十几分钟开发者的操作门槛大幅下降。平台工程和传统运维最大的不同在于服务对象变了。传统运维服务的是“系统”平台工程服务的是“人”。平台的每一个设计决策都要问一句这对开发者的体验是友好的吗这句话说起来简单做起来很难因为平台团队需要同时兼顾标准化、稳定性、安全性和灵活性这四个目标之间本身就存在冲突。3.3 FinOps从“能用就行”到“每一分钱都要花明白”基础设施进入云时代之后成本结构发生了巨大变化。以前买物理服务器是固定成本一次性投入折旧周期长。云上则是按量付费成本与使用量直接挂钩如果管理不好账单可能比预算多出好几倍。我们第一次看到月度云账单被吓到的时候意识到必须认真对待云成本治理了。于是FinOps被提上日程。所谓FinOps翻译过来就是云成本优化它是把财务、技术和业务三个视角拉齐共同管理云资源的费用。成本治理的第一步是成本可视化。把云账号的账单按项目、按部门、按服务拆分清楚让每个业务团队都能看到自己用了多少资源、花了多少钱。这一步看起来简单实际操作中难度不小因为云资源的标签体系需要提前规划好如果一开始没有资源打标签的习惯后面要补的历史成本很难准确归集。第二步是资源优化。通过分析利用率数据找出低负载的闲置资源、超大规格的过度配置资源然后进行缩容、降配或者关停。我们团队曾经做过一次集中治理关停了一批利用率长期低于5%的测试环境实例后月度成本直接下降了约三分之一。第三步是建立成本预算和告警机制。为每个项目设置月度预算和费用告警线一旦实际成本接近预算就触发通知让相关负责人及时干预。成本治理不是一次性项目而是需要持续运营的日常机制。我们把它固定在每个月的运营例会上滚动审视成本和优化方向。4. AI Infra站在新一轮浪潮的起点说完了过去十年的演进路径必须聊一聊现在最热的方向AI Infra。作为一个经历了传统运维、云原生、平台工程全过程的Infra从业者我看到AI Infra的第一反应是技术底座确实变了但底层的逻辑并没有变仍然是资源供给、调度、稳定性和成本这几个核心命题只不过这些命题的复杂度和规模都上升到了一个新的量级。4.1 AI Infra到底是什么界内对AI Infra的定义五花八门不同背景的人有不同的理解。从底层视角来看AI Infra是支撑AI应用全生命周期的基础设施层覆盖从数据准备、模型训练、模型微调、模型部署到推理服务这整条链路所需的计算资源、存储资源、网络资源和调度管理平台。如果拆解出来看AI Infra至少包含以下几个关键组成部分算力资源层GPU服务器集群、高速互联网络如InfiniBand、高性能存储。资源调度层作业调度系统、容器编排平台、GPU虚拟化与共享。数据管道层数据采集、清洗、标注、特征工程、数据版本管理等。训练与推理平台层分布式训练框架、模型管理、推理服务网关、自动扩缩容。可观测与运维层GPU监控、训练日志追踪、故障诊断、成本分析。AI Infra和我之前熟悉的传统Infra最大的不同在于硬件异构性和资源形态的多样性。传统的CPU服务器虽然也有型号差异但基本可以从同一套抽象逻辑去看待。GPU卡则完全不同单卡性能、显存大小、卡间通信带宽、机内拓扑、跨机网络拓扑每一个维度都会直接影响训练任务的实际效率。我们在写调度器和工作流时不能只看到“有多少张卡”还得看到“这些卡是怎么连的”这是一个全新的优化维度。4.2 GPU集群到底难在哪里很多人以为GPU集群的难点就是“卡不够用”但实际上等卡真的到位了更大的挑战才开始。第一个挑战是故障率远比想象的更高。在千卡甚至万卡规模的GPU集群里单卡故障、NVLink连接异常、散热问题、电源波动等硬件故障几乎是常态。一次大规模训练任务如果中途任何一个节点出问题整个训练流程都可能中断。因此容错机制和断点续训就是刚性需求你必须要在平台层面支持自动故障检测和训练任务的无缝恢复否则没法在万卡规模上谈稳定性。第二个挑战是网络拓扑的复杂性。大模型训练需要频繁做梯度同步的通信操作卡与卡之间的通信速度和稳定性直接决定训练效率。我们租用过一个有InfiniBand网络的GPU集群网络拓扑分成多个层级不同层级之间的带宽差异很大。如果调度系统没有感知到拓扑信息把通信量大的任务分散到了跨层级链路上训练效率会严重下降。后来我们干脆在调度器里加入“拓扑亲和性”的约束尽量把同一个训练任务的所有节点调度到同一个交换域内实测训练吞吐提升明显。第三个挑战是GPU资源利用率优化。GPU卡非常贵但很多时候资源利用率并不高主要原因是业务方申请资源时习惯“多申请、宽计算”导致大量GPU空闲占用。我们参考传统Infra里做CPU超卖的经验引入GPU共享和碎片整理机制把显存空闲的卡共享给多个推理任务使用对训练任务按批调度排队优先级高的任务优先获得资源。这套机制上线后集群整体利用率提升了大概20%。4.3 AI Infra“八股”当面试官开始问这些问题“AI Infra八股”这个热词最近在工程师圈子里刷屏。说白了就是因为AI相关岗位火热面试考察的知识点逐渐标准化面试官问的题目被大家整理汇总成了一份“八股文”。这份“八股”的内容覆盖了分布式训练原理、GPU通信库、模型并行策略、推理优化、资源调度算法等。网上把“AI Infra八股”当作段子讨论但作为过来人我觉得这份“八股”背后其实是有真实价值的。它至少说明了这个领域的知识体系正在形成。十年前我们面运维岗也会问“Linux内核参数有哪些”“TCP三次握手的过程是什么”这种基础问题当时也被叫作“运维八股”。问题的表象不重要重要的是你真的理解了背后的原理还是只是把标准答案背下来了。我在面试候选人的时候不太关注对方背了多少概念而是更关注三个维度一是对底层原理的理解深度比如“为什么数据并行在千卡规模下效率会下降通信瓶颈到底出在哪里”二是遇到问题时的排查思路比如“训练loss不收敛时你从哪些维度去排查”三是对成本和稳定性的敏感度比如“如果让你设计一个多租户的GPU调度器你会重点考虑哪些指标”。这些问题的背后其实都在考察一个人是否真正有“系统思维”。5. 十年Infra演进背后的底层逻辑如果把这十年的技术演进串起来再看表面上是工具变了、方法变了、岗位名称变了但内在的演进逻辑是非常清晰的。5.1 三个核心变量的驱动力第一个驱动力是业务规模的增长。用户量、数据量、请求量都在涨靠人工撑不起这么大规模的系统必须引入自动化和平台化的手段。从Puppet到Kubernetes再到IDP本质上都是在解决“规模变大之后如何继续可控”这个问题。第二个驱动力是软件架构的变迁。从单体架构到微服务再到云原生应用被拆得越来越细部署密度越来越高传统的基础设施管理方式跟不上这个变化于是容器、编排、服务网格、可观测性等新技术陆续出现形成了完整的技术栈。第三个驱动力是硬件代际的升级。从物理机到虚拟机到容器从CPU到GPU到TPU每一次硬件抽象层的提升都会带来一次基础设施的重构。AI Infra的出现本质上也是GPU这种新硬件被大量使用之后传统基础设施的抽象层无法满足需求必须建立一套全新的技术体系来管理它。这三个驱动力相互交织共同塑造了Infra行业过去十年的面貌也会继续主导未来十年的走向。5.2 演进路上踩过的坑在基础设施演进的每个关键节点上我们都踩过坑现在回头看有些坑其实是完全可以避免的。最典型的一个坑是过度追求新技术。有一段时间Kubernetes刚火起来我们头脑一热把一些不那么适合容器化的应用也强塞了进去比如有状态数据库。结果运维复杂度陡增出问题排查的难度比原来直接用云数据库高得多团队人力被白白消耗在无聊的适配工作上。后来我们做技术选型时定了一条原则技术选型不能只看热度要看它在你的具体场景里解决的是什么问题以及你的团队有没有能力去驾驭它。第二个坑是自动化做得太早。我们在对系统流程的理解还不够深刻的阶段就急着写自动化脚本结果脚本本身变成了另一种“技术债”。比如一个部署脚本里写死了环境特定的一些配置环境一换就崩一个监控告警规则配置太敏感导致告警疲劳重要告警反而不被关注。自动化应该是流程稳定之后的固化产物而不是为了自动化而自动化。第三个坑是缺少成本意识。云资源刚接入时大家比较注重功能和速度对成本控制并不敏感。到了月底看到账单才发现一个不小心测试环境就开了几十台高配实例白白跑了一个月。后来我们给所有云资源强制打了标签限制了实例规格的选择范围并要求每个项目负责人定期确认成本归属这才把成本管控做扎实。5.3 给想入行或转型的人的几个建议这几年陆陆续续有一些年轻朋友问我想做Infra方向应该怎么学习或者传统的运维DevOps是不是已经不行了。我的观点一直很明确Infra不会消失但“纯手工运维”确实在为“平台化”“工程化”让路。今天做Infra核心能力已经不是“会修机器、会配网络”而是能不能用软件工程的思维去构建和维护一套自动化系统。如果你正在考虑进入这个领域或者想从传统运维转型我会建议重点做几件事。第一件事是深入理解Linux操作系统和计算机网络。这一点听起来不够酷但它是所有上层技术的基础。无论你以后做Kubernetes、做GPU集群调度还是做平台工程遇到疑难问题最终都要回到操作系统和网络层面去找原因。这部分知识学扎实了后续很多概念会自然串联起来。第二件事是亲手把一个应用从零部署到Kubernetes上。别只看文档真正动手做一遍你会遇到一系列意想不到的问题镜像构建失败、启动探针配置不对、Pod一直重启、Ingress路由匹配不到服务……每个问题都会逼着你深入理解底层原理。做完一个最小可用的闭环之后再尝试引入GitOps、监控告警、日志采集这些工程化能力。第三件事是培养成本意识和规模意识。Infra工程师做的是资源管理资源就意味着成本。你在设计一个方案时要能说出它的大概成本结构评估一个瓶颈时要有“当前规模是什么水平、扩展之后瓶颈在哪里”的判断力。这种意识很难从书本上学到更多是依靠实战项目的经验积累但一旦建立了你的专业度会明显上一个台阶。至于AI Infra我的态度是拥抱但不盲从。AI Infra的知识体系里有一部分比如分布式调度、存储、网络、可观测性和传统基础设施是相通的值得在现有经验基础上去延伸学习另外一部分比如GPU通信原理、模型并行策略、推理优化则需要你沉下心从头补课。但可以确定的是未来几年AI Infra的人才需求量依然很大越早开始积累优势越明显。