1. 写总结前，先看这一年最关键的技术账本
1.1 数字不会骗人：全知科技2025年的核心指标
年度总结如果不看数字，很容易写成一篇抒情散文。所以我先把团队最关心的几个技术指标摆出来，口径统一一下，免得后面各说各话。
| 指标 | 2024年底 | 2025年底 | 变化 |
|---|---|---|---|
| 影响用户的线上事故数 | 34起 | 11起 | 下降约67% |
| 核心业务接口P99延迟 | 820ms | 240ms | 降低约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再强也要有人负责。就这样，明年再来回看。
