1. 写总结前先看这一年最关键的技术账本1.1 数字不会骗人全知科技2025年的核心指标年度总结如果不看数字很容易写成一篇抒情散文。所以我先把团队最关心的几个技术指标摆出来口径统一一下免得后面各说各话。指标2024年底2025年底变化影响用户的线上事故数34起11起下降约67%核心业务接口P99延迟820ms240ms降低约70%生产环境发布频率每周4次每天10次从批次发布到持续发布发布失败率约7%1.6%发布更频但更稳AI生成代码合入占比0%约35%从零到成为基础设施这里要特别说明口径P99只统计核心业务链路的接口不包含报表、后台管理这类低优先级系统。线上事故按“是否直接影响用户会话或核心订单流程”来划分P0/P1群里报过的部署告警、非核心模块抖动不计入。之所以强调口径是因为数字一旦变成KPI就会有人为了让指标好看而去改定义最后骗的只有自己。团队规模这一年基本没变还是30人上下的技术团队做的事情却比去年多了不少。这说明单个工程师的产出确实提高了杠杆来自工具、流程和AI辅助而不是靠堆人头。这也是我觉得这份总结值得写下来的原因小团队在资源有限的情况下靠方法论和基建能把稳定性提到什么程度我们的数据算是一个可参考的样本。1.2 这些数字背后的三个关键词如果非要把这一年压缩成三个词我会选稳定性、发布效率、AI渗透率。稳定性是第一位的。事故数从34起降到11起不是靠少发版、少改动换来的。恰恰相反我们的发布频率涨了将近五倍。事故下降是因为把“防止事故”的动作前置了上线前有压测、变更前有评审、配置有分级、故障有演练。如果说以前我们是靠“事后救火”维持系统可用性那今年至少有一半精力花在了“事前防火灾”上。发布效率的跃升来自自动化流水线的成熟。从代码提交到测试环境部署再到生产灰度全流程都有机器人参与人工介入的点越来越少。早期发布一次要一个后端同学盯着跑脚本现在每天的发布数量上去了人的精力反而被释放出来做代码审查和数据核对。AI渗透率是最难量化但又最真实的变量。年初大家对AI写代码的态度两极分化有人觉得是神器有人觉得是垃圾。到了年底全团队已有约35%的合入代码是在AI辅助下完成的并且这个数字还在稳步上升。它不是替代人而是把重复劳动剥离出去。这三个词基本概括了全知科技2025年的技术主线。2. 从“能跑”到“能扛”核心系统年度演进路线2.1 服务拆分终于做对了一次先划域再拆服务我们团队早年也赶过微服务的时髦但当时是按页面和功能模块拆的拆完以后问题比解决问题还多。某个“报表服务”为了展示数据直接去读用户库的订单表另一个“用户服务”又在自己的代码里拼SQL查库存表。名义上是微服务实际上就是分布式单体跨服务join满天飞谁都不敢动一张表因为不知道还有谁会来偷读。2025年我们重新做了一轮服务边界梳理核心原则只有一句话先划业务域再拆服务。团队先把业务分成四个域用户域、交易域、供应链域、数据域。每个域拥有自己的数据表和唯一对外API跨域的数据需求一律走接口不允许直连数据库。这个听起来很简单的原则执行起来花了将近三个季度。实操路径大致是这样的。第一步把现有服务调用关系图全部导出来标出跨服务join和直接读写对方库的“重灾区”。第二步按域收敛数据归属一张表只允许被一个服务写其他服务要读只能调API。第三步确定拆分顺序先拆低风险的数据读取链路再碰交易核心。第四步每个域拆分完成后灰度运行两周持续观察接口响应和错误率稳定了才动下一个。拆服务最难的从来不是改代码而是“这张表到底归谁”。只要数据边界没有理清拆出来的服务只会把原有的耦合换个位置继续存在。我们最后甚至定了一条规矩新服务上线时必须登记自己的数据域归属违反数据边界视为事故处理。规则越简单执行成本越低。2.2 容器化不是终点成本治理才是全知科技上Kubernetes挺早的但一直处于“能用”的阶段每个业务线自己申请命名空间资源配额拍脑袋填request和limit经常相差几十倍。年底一算账集群平均CPU利用率不到15%很多实例空转一整夜钱就这样无声无息地烧掉了。2025年我们把成本治理提上了日程做了三件事。第一按照业务域分配namespace并且给每个资源打上成本标签让每一分钱都能追溯到具体业务线。第二重设资源配额核心服务按QPS基线和P99要求来定request/limit非核心服务统一收紧避免“申请时往大了报用的时候用不上”。第三针对7×24小时之外的低峰期对非核心服务做定时缩容夜间副本数从6降到2早高峰前自动拉起来。效果很直接年底核算时整体云资源预算比年初规划少花了约17%同时核心服务的可用性没有下降。这里有个容易踩的坑把所有服务的requests都调低并不等于省钱反而可能因为调度不均导致节点出现资源争抢。一定要结合节点的实际水位去观察把低利用率且稳定的服务先降配再慢慢尝试削峰。成本治理是一个持续迭代的过程不是一次调参就结束了。2.3 数据库改造慢查询、主从延迟与缓存一致性数据库一直是中小团队最容易出问题的环节2025年我们集中解决了三个长期痛点。慢查询治理是最先动手的。开启慢查询日志后分析发现Top N基本都是同一张业务大表。用explain一看典型的全表扫描索引没有命中。加上复合索引后单条查询从120ms降到20ms左右连带整个接口的P99都往下走了一截。后续我们把慢查询日志接入监控每周看一次超过阈值就自动发到群里。慢查询不可怕可怕的是没人定期看它。主从延迟是第二个痛点。以前所有读写都走主库集群压力大且延迟不稳。后来明确规则强一致读走主库弱一致读走从库。订单详情这类敏感接口必须走主库而商品列表、标签页这类可以容忍秒级延迟的读取全部放从库。这个规则看着简单落地难在让每个开发知道自己的接口属于哪一类我们在代码脚手架里做了统一的读写路由方法默认不让人手动选择数据源。缓存一致性是第三个课题。我们采用Cache Aside加延迟双删的方案并通过订阅数据库binlog异步淘汰缓存把缓存与数据库的不一致窗口从秒级压缩到毫秒级。为什么不直接更新缓存而是删缓存因为并发场景下直接写缓存很容易出现旧值覆盖新值的问题删除缓存让下次读取回源反而更干净。这套组合拳打完后缓存命中率稳定在92%以上数据库压力明显缓解。3. 2025年我们踩过的最深三个坑3.1 一次配置变更引发的“半线上事故”大家都知道改代码要谨慎却经常忽略了配置中心同样能掀翻整个系统。我们今年就实打实栽过一次。某天下午告警群突然开始刷连接池报警接着陆续出现用户登录超时。团队第一反应是查最近有没有发布但发布记录显示没有任何服务上线。这时候监控面板上能看到的是大量服务同时异常曲线几乎在同一时间点起跳。这种“全量服务同时异常”的特征基本指向公共配置或基础设施变更而不是某个服务自身的问题。我们立马去配置中心翻变更记录果然发现一条新的发布记录有人在公共命名空间里调整了一个超时参数。这个公共命名空间被全团队100多个服务共同引用发布时也没有做灰度等于一根火柴点燃了整个草垛。一键回滚配置后大约20分钟各项指标恢复还好没有造成实质性的数据损失但用户侧已经感受到超时了。复盘后我们做了三项改进配置按用途拆分namespace不能再有什么都往里塞的“公共垃圾场”配置变更实施分级审批核心参数必须走两级确认配置变更与发布单关联后续排查变更时能快速定位责任人和影响范围。配置中心的杀伤力从来不亚于代码Bug因为它生效范围广、生效速度快而且平时几乎不被人注意。3.2 大促压测暴露的缓存穿透热key问题复盘大促前一次压测商品详情接口QPS峰值冲到5000然后数据库连接数直接告警。按经验这种读多写少的接口不该把数据库打垮问题必然出在缓存层。排查时先看数据库慢查询清一色是同一张商品表的单条查询。再看缓存监控发现某个热门商品key在过期前后出现一段明显的命中率断崖。原因很快就清楚了压测脚本大量并发请求同一个热门商品该key刚好到了过期时间缓存里没有数据所有请求同一时刻穿透到数据库。这是典型的热key击穿属于缓存穿透的一种特殊形态比普通的随机穿透更隐蔽也更有杀伤力。修复方案做了三层。第一层对热点key加本地缓存用Caffeine缓存30秒并通过后台线程提前刷新即使Redis中的key过期本地缓存也能抗住绝大部分流量。第二层引入布隆过滤器拦截一定不存在的数据请求这类商品下架或参数非法导致的无效查询直接在缓存层之前被挡掉。第三层服务端加限流和熔断保证极端情况下数据库只是压力增大而不是直接被拖垮。这个方案上线后压测中打到Redis的QPS从5000降到800左右数据库连接数恢复平稳。后来我把这条经验记进了团队的缓存规范不能只盯命中率还要问一句“命中率掉下来的时候系统会发生什么”。没想过这个问题就意味着缓存层可能存在事故隐患。3.3 数据迁移丢数据的那个通宵数据迁移是我个人今年最不想回忆的一段经历。订单表要做分库分表团队按常规流程执行先全量导出再通过binlog消费增量追平最后切换读流量。前面都很顺利偏偏卡在了“追平”这一步。切换前对账发现一个诡异现象表里的记录条数是对的但部分订单的状态和源库不一致。对比binlog消费记录后发现增量同步脚本的位点记录出了问题导致同一段binlog被重复消费。重复消费本身不可怕幂等处理好就行。问题出在写入逻辑用了“存在则忽略”的方式把本来应该更新的行给吞了。那个通宵排查到最后是靠对账工具定位的把源表和目标表按业务主键做哈希比对差异一目了然。修复后就地改了写入逻辑用唯一键更新而不是忽略并重新回放binlog。等数据全部对上已经是凌晨五点半。事后我们沉淀了一套标准迁移模板全量导出、增量追平、对账校验、切读流量、保留回滚位点每一步都有对应的检查和告警。数据迁移不是跑完脚本就算完成没有双向校验的迁移等于闭着眼睛打方向盘。4. AI进入日常开发以后团队的真实体验与边界4.1 从个人插件到团队级AI助手年初AI代码补全工具刚在团队里流行起来时评价是两极化的。有人用它写工具脚本非常顺手有人说生成的代码“好看但不敢用”。后来我们专门做了内部调研发现差别主要不在工具本身而在使用者给出的上下文质量。AI助手本质上是一个“读过很多代码但对你业务一无所知的实习生”。你让它写一个CRUD接口只丢一句“帮我写个订单查询”它大概率给你一个泛泛的模板。但如果你把表结构、字段含义、接口入参出参、异常分支、权限要求都写清楚它生成的代码可用率会高得多。于是团队做了一套统一的提示词模板把接口契约、数据模型、关键约束都结构化所有人按这个模板去和AI协作。一个典型的场景是后台管理系统的常规增删改查接口以前写一个需要半天包括建表、写Mapper、写Service、写Controller、再补参数校验。现在把表结构和接口文档给AI它直接生成基础代码人工只需要补充索引设计、权限校验和特殊业务分支。产出效率明显提升代码风格反而比之前更统一了。到年底AI辅助生成的代码约占总合入代码的35%这个比例还在爬升。4.2 把AI生成的测试从“样子货”变成可用的东西AI生成代码的问题解决后我们开始让它写单元测试结果经历了一轮“虚假繁荣”。它能在几分钟内生成几十个测试方法覆盖率数字很好看但仔细一看全是“断言不为空”“调用不报错”这类玩意儿。这种测试的意义只有一个让覆盖率报告变绿。我后来在团队里立了一条规矩AI写的用例必须能证明一个具体行为而不是证明“代码跑了一下没炸”。我们重新划定了AI生成测试的三个方向。第一冒烟测试验证核心链路能走通。第二契约测试验证接口入参出参是否兼容。第三异常分支测试比如超时、数据库异常、参数为空等边界情况。每个用例都需要有明确的输入输出样例一个行为对应一个用例禁止堆断言。指标上也做了调整覆盖率只做参考不设硬性指标。40%覆盖率的有效用例比90%覆盖率的假用例更能防回归。这套标准定下来之后AI生成的测试才真正开始替我们挡Bug而不是制造虚假的安全感。4.3 我们给AI划定的三条红线AI工具用久了团队内部会形成一种“让AI多干点”的自然倾向。为了防止边界失控我们明确写下了三条红线。第一条涉及资金、权限校验、安全敏感的核心逻辑AI只能生成草稿最终的关键判断必须由人重写。原因很简单AI在这个领域没有业务常识它不知道“允许管理员调用”和“允许所有人调用”之间隔着多大的责任。第二条不允许把生产环境的全量数据、明文密钥等内容喂给AI工具所有内部AI服务必须走统一的权限隔离和数据脱敏。第三条所有AI生成的代码合入前必须指定一个明确的责任人出了问题追溯不到人的代码不允许上线。红线起作用之后全知科技的AI使用状况变成了一种“有节制的渗透”普通业务代码约35%来自AI辅助而安全敏感区域的AI生成代码合入率被控制在5%以下。这个比例差是刻意的不是能力不够而是我们不想让人工复核变成走形式。5. 除了代码这一年我们沉淀下来的“组织记忆”5.1 固定发布窗口与故障演练机制很多团队把发布流程做得很重结果发布频率越来越低大家越来越怕上线。我们反其道而行把发布变成了一个“常规动作”每周二、周四下午固定发布窗口发布前30分钟做一次变更评审重大变更必须提前24小时报备。规则固定之后所有人默认遵循节奏不再需要临时的口头沟通。故障演练是今年新加的项目每季度一次。我们会主动往生产环境注入故障比如模拟CPU飙升、数据库连接池耗尽、下游服务超时然后观察团队是否能在预案指引下快速定位和恢复。第一次演练结束时大家满头大汗但从第二次开始明显熟练了。演练最大的意义不是演练本身而是让每个人在真正的故障来临之前已经知道自己的角色和动作。5.2 统一基建脚手架、日志、链路追踪年中我们发现团队有很多时间是浪费在做重复的“装修”上每个新服务都要重新配日志格式、监控采集、健康检查每个服务出问题时都要重新找日志入口。于是我们把基建沉淀成三个标准件。第一个是内部脚手架新服务生成时自带配置中心连接、日志格式、健康检查、基础监控面板五分钟内就能跑起来。第二个是统一日志规范所有服务必须输出结构化JSON日志至少包含traceId、userId、耗时、模块名。第三个是链路追踪从API网关入口生成traceId贯穿到应用层再到数据库访问排查问题时不再需要人工去拼日志。这套标准件落地以后线上问题定位时间从小时级降到了分钟级。团队里一个后端同学的原话我很认同判断一个系统好不好排查就看新同学第一次接线上问题能不能在30分钟内找到根因。我们的基建基本做到了。5.3 文档策略与新人上手路径2025年我们对文档的认知也变了。以前文档写得多但没人看后来改成“轻量但必要”的策略每次重要技术决策只写一页纸的ADR包含背景、方案对比、结论、代价。不再要求写几十页的设计文档而是鼓励在讨论最激烈的时候记录决策。新人上手路径也标准化了。入职前三天做一个Mini项目功能不一定复杂但必须完整走一遍从网关请求进入、经过服务处理、落到数据库、再到监控面板看到自己的调用记录。三天内能把这条链路跑通后面学什么都快。这个方式比丢一堆文档让新人自己啃要有效得多。6. 面向2026年我个人想做的几个技术判断6.1 AI Agent会从“能对话”走向“能干活”2025年的AI辅助还是“人提问、AI回答”的交互模式。2026年我想在团队内部试点一个值班Copilot的角色它接收告警消息自动拉取最近变更、日志、监控面板然后给出故障分析和修复建议。但这里必须加一道防线所有建议只做展示不自动执行变更由人来决定是否采纳。我认为Agent在2026年最有价值的场景不是创意设计而是重复性排障。线上告警的80%都来自有限的几种模式让Agent先把上下文梳好人只做最后判断这会大幅降低值班同学的压力。步子不能迈太大自动化执行必须建立在足够多的历史验证之上。6.2 数据价值会从“看板”走向“决策”过去我们使用数据最多的场景是监控看板和各种统计报表。2026年我打算把内部知识库、历史故障记录、架构决策文档做成可检索的语料让AI能回答“之前类似的问题是怎么解决的”这类问题。这件事最大的前置条件是数据治理。如果喂进去的知识本身是过时的、冲突的、没权限边界的AI给出再流畅的答案也只是一个有礼貌的错误。所以要先花时间把已有文档去重、打标签、设置访问权限再开始做检索增强。数据底子不干净AI落地越快错误复现越频繁。6.3 团队节奏要对抗的不是技术债务是上下文切换回看2025年的工作日志我发现团队真正消耗精力的地方不是代码难度而是被打断的次数。一个问题查到一半去开会方案写到一半要响应临时需求这种上下文切换对工程师的消耗是隐性的但极其巨大。2026年团队节奏会刻意做减法压缩会议数量能异步沟通的绝不同步开会每天固定留出两小时不受打扰的深度工作时间。宁可项目进度慢一点也要保证每个时间段只有一个核心目标。技术的瓶颈从来不在手速而在专注度。写这份全知科技2025年度总结的时候我反复在看这一年的记录最有价值的不是那些亮眼的数字而是我们愿意把三次翻车一五一十写下来的态度。技术团队的能力不体现在从不犯错而体现在每次犯错之后能不能真的长出新的机制来避免下一次。2026年不管AI工具再怎么进化、架构再怎么调整有三条底线我觉得不会变线上稳定大于一切人比流程重要AI再强也要有人负责。就这样明年再来回看。