AI时代已至，提升效率成为所有技术团队热议的话题。
但你是否有这样的困惑：为什么有些公司引入AI后如虎添翼，效率直线上升；而另一些公司却深陷泥潭，流程混乱，越“提效”问题越多？
问题的关键往往不在于AI本身，而在于其运行的基础——基础设施（Infra）。更准确地说，在于你的技术基础设施是否做好了“统一”这件最根本的事。
小团队与大团队的差异
对于一个5人左右的初创团队或小作坊而言，技术选型可以相当随意。Node.js、Django甚至PHP，什么顺手用什么。代码库不大，部署简单，出了问题直接SSH登录服务器查看日志，半小时内通常就能定位解决。在这个阶段，你跟他们大谈基础设施的重要性，无异于对牛弹琴。他们的“Infra”可能就是一台ECS云服务器、一个RDS数据库，外加一位运维“大神”的经验。这确实够用。
然而，一旦公司规模扩张，情况便急转直下。
团队增多，技术栈开始发散。A团队坚持使用Spring Boot，B团队偏爱Golang，C团队新来的技术负责人则力推Rust，理由是性能卓越。服务数量激增，微服务如同野草般蔓延，今天拆分一个，明天又新建一个。接口协议五花八门，RESTful、gRPC、甚至偷偷使用的WebSocket长连接混杂其中。
曾经的“技术百花齐放”迅速演变为“团队各自为政”。基础设施团队从此陷入无尽的“救火”状态，成员焦头烂额，但问题似乎永远也解决不完。
Infra的核心：三件事，一个逻辑
许多公司把基础设施搞得异常复杂，工具链层层堆叠，平台建了又拆，拆了又建。实际上，基础设施的本质可以归结为三件事：统一、提效、稳定。
这三者并非简单的并列关系，而是存在严格的层次逻辑。统一是地基，提效和稳定是建立在地基之上的大厦。地基不牢，楼盖得越高越危险。同时，提效和稳定本身是一对矛盾体：提效追求快速变化，稳定则要求变化可控。要让这对矛盾和平共处，同样依赖于“统一”这个坚实的底座。
大多数公司都明白提效的价值，大型企业也会高度重视稳定，但几乎所有人都严重低估了“统一”的重要性。这正是许多问题的根源所在。
第一件事：统一——艺术的约束
统一是一门关于约束的艺术，而非纯粹的技术选择。它需要回答一个核心问题：哪些东西应该自研，哪些应该拥抱社区？
这个问题如果回答错误，可能会让你在十年后追悔莫及。
一个典型的例子是Ruby on Rails。当年它横空出世，开发效率惊艳众人，许多公司选择All In。早期的Twitter和GitHub都基于Rails构建。但时至今日，Twitter早已转向Scala，GitHub的核心部分也在迁移。当年为了追求短期效率而全面投入Rails的公司，如今面临的迁移成本，远超过当初节省的那点开发时间。
反观那些当年选择了Java技术栈的公司，尽管起步可能较慢，代码略显冗长，但得益于其稳定、庞大的生态和丰富的人才储备，至今仍是企业级开发的主流。
因此，统一必须具有前瞻性，至少要能支撑未来十数年的发展。这不是保守，而是对技术债务的负责。
统一意味着为技术选型戴上“枷锁”
这话听起来可能有些刺耳。我们不是决定用Spring Boot了吗？直接用不就完了，为什么还要“戴枷锁”？
因为Spring Boot如果放任使用，很可能变成一场灾难。@EnableAutoConfiguration、@ConditionalOnClass、各种Starter随意引入，注解满天飞，AOP四处切割。最终没人能搞清楚一个应用启动时究竟加载了多少东西，出了问题也无从查起。
在一个成熟的基础设施体系里，必须建立明确的约束：例如，除了@Controller、@Service、@Repository等核心注解外，禁止随意使用其他高级注解；所有Starter必须经过基础设施团队统一封装和版本管理，业务团队不得自行引入。
这听起来很“粗暴”，但这就是统一的本质。统一不是强制所有人使用同一个工具，而是要求所有人以同一种、可控的方式来使用工具。
当这种统一达成后，后续的一切都会变得顺理成章：
- 全链路压测：统一的框架、统一的TraceID传播，压测流量染色可能只需一行配置。
- 泳道隔离：统一的服务注册发现，路由规则统一下发，业务代码无需感知。
- 可观测性：统一的日志格式、统一的Metrics采集、统一的Trace上报，无需在每个服务中安装五花八门的探针。
- 灰度发布：统一的流量管控平台，权重配置秒级生效。
- 单元化：统一的数据访问层，路由逻辑收归于中间件，业务方无需关心数据位于哪个单元。
反之，如果技术栈“百花齐放”，微服务选型“各自为政”——有的用Dubbo，有的用gRPC，有的裸调HTTP；日志格式有JSON有纯文本；数据存储有的用MySQL，有的用TiDB，有的服务直连Redis——那么，仅仅是想做一次全链路压测，就需要为每个异构系统单独适配，没有一年半载难以完工。这绝非夸张，而是残酷的现实。
第二件事：提效——全局优化，而非局部胜利
提效是永恒的目标，但许多公司的提效之路走偏了，陷入了“局部优化”的陷阱。
例如，某个团队的CI/CD流水线极其顺畅，从代码合并到部署上线只需3分钟，体验极佳。但与之协作的隔壁团队，发布流程仍是手工操作，需要邮件审批，等待时间长达两天。整个产品的发布效率，并没有因为前一个团队的“高效”而得到实质提升。
这就是局部提效的假象。每个环节看似都在优化，但全局的端到端效率依然停滞。真正的提效，必须关注从“需求提出”到“变更上线”的完整价值流，识别其中的瓶颈卡点：哪些环节在等待机器，哪些环节在等待人的审批或操作？
而这一切的优化，都深深依赖于基础设施的“地基”是否牢固。
- CMDB（配置管理数据库）：如果连自己有多少台服务器、运行了哪些服务、服务间依赖关系都理不清，提效从何谈起？
- IaC（基础设施即代码）：如果基础设施的创建、变更还在依靠手工点击控制台，所谓的“提效”只是空谈。
- PaaS/FaaS平台：如果研发人员仍需手动申请和配置测试环境，又何谈开发效率？
底子不牢，任何提效举措都像是在沙滩上建造高楼。
AI时代将这一点暴露得更加彻底。你用AI辅助生成了高质量的代码，然后呢？代码要部署到哪里？如果CMDB不准、IaC未落地、PaaS平台陈旧，那么AI生成的代码依然会卡在人工审批、手动部署的传统交付链路上。这正是许多企业在引入AI后感到“提效痛苦”的原因。问题不在AI，而在基础。AI只是一个放大器：基础好，它放大的是能力；基础差，它放大的就是早已存在、只是以往被慢速流程所掩盖的问题。
第三件事：稳定——可观测是基石
谈及稳定，其核心可归结为两个字：可观测。
你看不到，就无法掌控。无论是经典的Prometheus + Grafana监控组合，还是新兴的OpenTelemetry标准，或是专注于AI应用监控的Langfuse，其本质都是让系统内部状态变得可见、可度量、可追踪。
但可观测性有一个至关重要的前提：数据质量。
- 如果日志格式乱七八糟，JSON、纯文本、甚至堆栈信息挤在一行，如何做自动化分析？
- 如果Trace链路不完整，A服务传递了TraceID，B服务却将其丢弃，如何进行全链路问题排查？
- 如果指标命名五花八门，同样的请求数，有人叫
request_count，有人叫qps，有人叫req_total，如何跨服务聚合查看全局大盘？
可观测性依赖高质量的数据，而高质量的数据，再次依赖于统一的标准和规范。 看，又回到了“统一”。
许多公司稳定性做得不好，十有八九不是技术能力不足，而是基础数据一团糟。稳定性团队只能依靠人工盯守监控大屏、凭借经验猜测、依靠运气排查。这不叫保障稳定，这叫被动救火。
稳定与提效天生存在矛盾：一个求快，一个求稳。然而，如果基础设施的“统一”底座足够扎实，这一矛盾可以得到极大缓解。通过标准化的灰度发布、无损回滚、自动熔断机制，提效团队可以放心追求“快”，因为下面有安全网兜底。通过常态化的容量规划、全链路压测和事先演练的故障预案，稳定性团队也能做到心中有数，而非临场发挥。
稳定，不是为了阻碍提效，而是为提效保驾护航。 稳定性团队的真正价值，在于确保提效带来的业务成果能够持续，避免一次大促活动或重大变更导致系统崩溃，将数月甚至数年的提效积累一夜归零。
一个扎心的现实：统一的困境
以上所述皆是理想中的逻辑。但现实中，“统一”这项工作往往面临一个尴尬的境地：它没有直接、显性的KPI。
提效可以有数据支撑：需求吞吐量提升X%，发布频率提高X倍，研发人效提升X%。稳定也有明确的指标：故障次数下降X%，平均故障恢复时间（MTTR）从X小时缩短到X分钟，服务可用性（SLA）达到X个9。
可是，“统一”呢？你如何向老板汇报：“老板，我们今年成功将公司技术栈从8种收敛到2种，所有中间件都完成了统一封装”？老板很可能会问：“所以呢？这直接支撑了多少业务增长？带来了多少收入？”
这就是基础设施团队，尤其是推动“统一”的团队所面临的困境。统一是“基础设施的基础设施”，它的价值是乘数效应，但这种效应往往在当下难以量化，通常要到三四年后，在面对一次大规模的业务拓展或一次惊心动魄的重大故障时，人们才会幡然醒悟——当年的统一决策是做对了，还是做错了。
做得好被认为是本分，做得不好也难被追责。谁会为“防患于未然”的举措颁发奖章呢？
于是，在许多公司的现有激励模式下，基础设施便在“忙碌地解决眼前问题”中慢慢腐化。无人愿意去触碰那些周期长、成本高、见效慢、难以量化的“根本问题”。直到AI浪潮席卷而来，大家摩拳擦掌准备借力腾飞时，才猛然发现，脚下的地基如此松软，根本无法承载AI这台强大的引擎。
结语
统一、提效、稳定，是基础设施建设的三个维度，但它们并非三件孤立的事情。统一是因，提效和稳定是果。
缺乏统一，提效不过是局部优化的幻觉，稳定则是四处救火的临时补救。唯有建立在统一的基础上，提效与稳定才能相辅相成，形成正向飞轮：提效加速业务迭代，稳定保障迭代安全，而一个稳定的系统又为下一轮更深度的提效创造了空间。
只有当这个飞轮顺畅转动起来，AI所带来的效率潜能才能真正得到释放。否则，AI很可能只是一个加速暴露你系统深层问题的“照妖镜”。
技术债终须偿还，且偿还越晚，利息越高。在追逐AI浪潮之前，不妨先审视一下你的基础设施，是否已经做好了“统一”这门必修课。欢迎在云栈社区交流你的看法与实践经验。
https://mp.weixin.qq.com/s?__biz=MzA4MTc4NTUxNQ==&mid=2650526212&idx=1&sn=f2e28b660b0f4dd48d4b74d27ca505d9&scene=21#wechat_redirect
https://mp.weixin.qq.com/s?__biz=MzA4MTc4NTUxNQ==&mid=2650526193&idx=1&sn=d5062b919d398d22a451ff0190e724a7&scene=21#wechat_redirect
https://mp.weixin.qq.com/s?__biz=MzA4MTc4NTUxNQ==&mid=2650524218&idx=1&sn=fcd82999de3e20237ccf16d8afe03d3f&scene=21#wechat_redirect
https://mp.weixin.qq.com/s?__biz=MzA4MTc4NTUxNQ==&mid=2650526090&idx=1&sn=863addec29e8c2cb076288d82e902e98&scene=21#wechat_redirect
发表于 前天 08:25
|
查看: 9|
回复: 0
