Git要换SHA-256了，代价谁算过
Posted by quentin 在 Friday, 2 October 2026博客分类:
Git 3.0计划将默认哈希算法从SHA-1切换为SHA-256，密码学层面的升级理由成立，但生态碎片化的隐性成本被严重低估。真正昂贵的不是迁移本身，而是新旧共存的过渡期。从技术管理者视角看，升级决策应该跟着威胁模型走，而不是跟着密码学论文走。
Linux
流水线不会骗人
Posted by quentin 在 Sunday, 20 September 2026博客分类:
CI流水线的问题十有八九是组织问题。构建时间膨胀、跨团队失败、没人敢跳过无效步骤——这些CI坏味道暴露的是团队沟通结构的裂缝。技术管理者应该把CI当组织诊断工具来用。
敢吃自己的狗粮吗
Posted by quentin 在 Friday, 18 September 2026博客分类:
Cloudflare花六年才把每天90亿请求的cdnjs迁移到自家平台。技术能力不是瓶颈，组织勇气才是。大部分公司的dogfooding停留在安全区，真正的内部验证需要有人愿意为事故兜底。不敢用自己的东西，问题可能不在产品。
平台不是越大越好
Posted by quentin 在 Thursday, 3 September 2026博客分类:
平台工程的核心矛盾不是能不能做更多，而是该不该做这么多。认知负荷超载导致影子系统滋生，平台的合理规模由组织消化能力决定。
地图画不对，事故查不清
Posted by quentin 在 Friday, 28 August 2026
架构该拆了，你准备好了吗
Posted by quentin 在 Thursday, 27 August 2026博客分类:
Netflix 最近分享了如何重新设计其实时服务依赖地图，核心不是技术细节，而是拆分决策的时机和方式。做了很多年技术管理，我发现架构该不该拆、什么时候拆、怎么拆，是最考验技术管理者判断力的问题。多数团队在两个极端之间摇摆：要么忍着不动直到系统崩溃，要么一上来就大规模重构然后烂尾。
开源不是技术选型，是组织能力
Posted by quentin 在 Wednesday, 19 August 2026博客分类:
先讲一个场景
我见过一个团队，技术选型会上，Leader 说"这个组件我们用开源的，社区活跃、文档齐全"。然后呢？然后就没了。没有维护计划，没有贡献策略，没有 license 审计。三个月后，依赖的库作者跑路了，代码里留着几十个 GitHub issue 没人管。更尴尬的是，这个库的 license 是 GPL，法务找上门来问"咱们的代码是不是也要开源"。
别急着加机房
Posted by quentin 在 Tuesday, 28 July 2026上个月参加一个架构评审会，有个团队提出要在新加坡加一个机房。理由很充分——东南亚用户访问我们的服务，延迟大概在 250 毫秒左右，体验不够好。加一个区域，理论上能降到 30 毫秒以内。
方案看起来很完美，PPT 里的数据也很漂亮。但我问了一个问题：你们拆解过这 250 毫秒里，有多少是真的花在网络传输上的吗？
没人答得上来。
这件事让我想到一个越来越普遍的现象：很多团队在做多区域部署决策的时候，把"加机房"当成了万能解。延迟高？加机房。用户远？加机房。容灾不够？加机房。但很少有人认真算过，加一个区域的真实成本是什么，以及——有没有更便宜的方案能达到同样的效果。
250 毫秒里，真正的网络传输只占一半
这是很多人不愿意相信的事实：用户感受到的端到端延迟，有接近一半跟地理距离无关。
一个请求从用户手机出发，经过 DNS 解析、TLS 握手、TCP 连接建立，到达服务器后被处理，再把结果返回。这整个链路里，真正受光速限制、必须靠物理距离来解决的，只有网络传播那一段。其他部分——DNS 查询、TLS 协商、连接池等待、服务间调用链、数据库查询、应用层序列化——这些都可以通过架构优化来解决，不需要搬家。
开会成瘾的技术团队，病根不在日历
Posted by quentin 在 Friday, 5 June 2026博客分类:
上周清理日历的时候顺手做了个统计——我所在的技术团队，10个人，一周62个会议。人均每周6.2个，平均每天1.2个。如果按每个会议40分钟算，将近四小时。还没算上会前准备和会后消化，还没算上那些"5分钟碰一下"的临时通话。
这不是个别现象。我跟同行聊过，金融科技领域尤其严重——合规对齐要开会，风险评审要开会，跨团队排期要开会。一个需求的开发周期里，真正写代码的时间可能还不到一半。
很多团队的第一反应是"减会"——砍掉每日站会，缩短周会，设立无会议日。然后呢？信息断了，对齐塌了，出问题的概率反而上升。砍完的会议像野草一样换个形式长回来。
我后来想明白了这件事：会议不是问题，会议是症状。就像发烧不是病，是身体在对抗感染。你把体温压下去，不等于治好了。
每个砍不掉的会，都在替系统还债
技术团队里的会议，大致可以分几类。每一类背后都藏着不同的问题。你不可能一刀切地减掉它们，因为砍掉会议后露出来的那个洞，可能比会议本身更危险。
同步会：你的模块边界画错了
两个子系统需要"定期同步"，这是最常见的一种会。前端和后端每周对齐，A团队和B团队双周同步。听起来很合理，但仔细想想——如果两个模块之间需要定期人工同步，说明什么？
前端状态管理的终极错觉：我们都在重新发明数据库
Posted by quentin 在 Monday, 1 June 2026前端的现状有点荒诞：我们嘴上说自己在写 UI，实际上大部分时间在跟数据较劲。Redux、Zustand、React Query、SWR、Dva、Pinia——每出一个新方案，大家就觉得"这次终于对了"。但如果你把所有这些方案放在一起，去掉它们的外壳看本质，会发现一个尴尬的事实：它们解决的问题，数据库几十年前就解决了，而且解决得更好。
我们不是在做状态管理，我们是在重新发明数据库。只是发明得很差。
一个 Redux Store 就是一个简化版数据库
Redux 可能是最明显的例子。你写一个 Redux store 的时候，本质上在做什么？
定义一个全局的数据结构——这叫 Schema。写 reducer 处理 action——这叫事务（Transaction），action 本身就是 WAL 日志。写 selector 查询数据——这叫查询引擎。写 middleware 拦截 action——这叫触发器（Trigger）。用 normalize 归一化数据——这不就是数据库范式吗？