作者归档:admin

AI 编程下的舒适区不能一直呆着

上周和 GZ 大佬在群里吹水,聊到 AI 编程,其中他所在的大厂已经全面推行 Cursor,他提到在 AI 时代下依赖 AI 会导致程序员失去思考力和代码能力。

虽然 GZ 的观点有些尖锐,但其核心表述的:过度依赖这类 AI 工具,可能会导致程序员的独立思考能力和实际编码能力下降。 是有道理的,人都是有惰性的,由简入奢易,由奢入简难

AI 给编程带来了「捷径」和「舒适区」。有即时的满足感,有认知负载的降低,还有我好像什么都会了的错觉。

  • 即时满足感: AI工具能迅速生成代码、解答疑问,这种即时满足感是非常诱人的。就像以前需要自己做饭(从买菜、洗菜、切菜到烹饪),现在可以直接点外卖,省时省力,结果直接呈现。
  • 认知负荷降低: 思考是耗能的。AI 工具在很多时候替我们完成了初步的思考和构建工作,大大降低了认知负荷。大脑天然倾向于节能,所以会不自觉地依赖这种轻松模式。
  • 我好像什么都会了的错觉: 有了AI的辅助,很多以前觉得困难或耗时的任务变得简单,这容易让人产生一种「能力快速提升」的错觉,从而更愿意待在这个由AI构建的「舒适区」里。

美国心理学家 NoelTichy 提出的理论人类对外部世界的认识可分为三个区域:舒适区,学习区,恐慌区。

参考下面这张图:

图片来源:即梦 AI 生成

我们天生是喜欢舒适区的,有在 AI 的加持下慢慢滑向依赖的自然趋势。

  • 习惯的养成: 一旦习惯了 AI 带来的便利,就很难再回到过去那种凡事亲力亲为的「简朴」状态。第一次用 AI 生成复杂函数可能还会仔细研究,第十次可能就直接 Accepted 了。惰性会让我们不自觉地选择最省力的方式。
  • 「温水煮青蛙」效应: 思考能力和编码能力的退化,往往不是一蹴而就的,而是像温水煮青蛙一样,在不知不觉中慢慢发生的。每次都依赖一点点,每次都少思考一点点,日积月累,当真正需要独立面对复杂问题时,才发现「内功」已经荒废了。
  • 对「不便」的容忍度降低: 习惯了 AI 的「秒回」和「全能」,一旦遇到 AI 无法解决或需要自己深入研究的问题,可能会更容易感到沮丧、不耐烦,甚至选择回避。

当我们真的养成了这种依赖的习惯,适应了这种舒服区,就会面对能力退化后的困境

  • 核心技能的生疏: 长期依赖 AI 完成编码和调试,会导致对编程语言特性、底层原理、算法数据结构、系统设计等核心技能的生疏。就像长期开车的人,突然让他走一段远路,可能会觉得非常吃力。
  • 问题解决能力的下降: 独立分析问题、定位问题、解决问题的能力,是在一次次「啃硬骨头」的过程中锻炼出来的。如果这个过程被 AI 替代,那么这种宝贵的实战经验就会缺失。当 AI 「失灵」或给出错误方案时,便会束手无策。
  • 创新能力的抑制: 真正的创新往往源于对问题的深刻理解和多角度的尝试。如果满足于AI给出的「标准答案」,就可能失去探索更优解或全新解决方案的动力和能力。
  • 学习动力的削弱: 「反正有AI」,这种心态可能会削弱一些人主动学习新知识、钻研深层技术的动力。因为「奢华」的生活方式似乎唾手可得,何必再去「简朴」地刻苦修炼呢?

就像我们家包包公主说的,这算不算「没苦硬吃」呢?

小朋友的视角不一样,也很形象。我们再深入思考一下:

从某种程度上说,如果 AI 已经能完美、高效地解决一些重复性的、模式化的、或者我们已经非常熟悉且没有太多新学习价值的问题,我们还非要「绕过」AI,坚持用原始的、低效的方式去「硬磕」,那确实有点「没苦硬吃」的味道。这就像明明有洗衣机,还非要每一件衣服都手洗,只为了「体验劳动的艰辛」,效率上肯定是不划算的。

但是,这里面有个核心的思考:我们「吃苦」的目的是什么?

比如,AI 能快速生成一个标准的 CRUD 代码框架,我们非要一行一行手动敲,而且这个过程对我们来说已经没有新的知识增量了,那这种「苦」可能就真的是「没必要硬吃」。时间应该花在更有价值的地方。

如果是为了「锻炼核心能力」、「深化理解」、「探索未知」而吃苦:

  • 打地基的苦: 对于初学者,或者在学习新技术、新领域时,有些基础的「苦」是必须吃的。比如,亲手搭建环境、理解底层原理、调试简单的错误。这个过程 AI 可以辅助,但不能完全替代,因为这是建立认知框架和培养解决问题直觉的过程。直接跳过,地基不牢。
  • 理解「所以然」的苦: AI 给出了一个方案,我们不满足于「知其然」,而是要去深究「所以然」——它为什么这么写?有没有其他方案?优劣何在?这个思考和验证的过程,可能需要查阅资料、动手实验,是「苦」的,但这种「苦」能让我们真正掌握知识,而不是停留在表面。
  • 攻坚克难的苦: 面对复杂的、AI 也难以完美解决的、或者需要创新性思维的问题时,我们需要自己去分析、设计、试错。这个过程无疑是「苦」的,但正是这种「苦」孕育了核心竞争力和真正的技术突破。
  • 保持「手感」和「警惕性」的苦: 就像运动员需要日常训练来保持状态一样,程序员偶尔也需要「刻意练习」一些基础技能,或者对AI的输出进行严格的审视和重构,以保持对代码的敏感度和对潜在问题的警惕性。这种「苦」是为了防止能力退化。

明明有更优解(AI能完美胜任且无损学习),却固执地选择低效、重复且对能力提升帮助不大的方式。这是一种低效的勤奋,属于没苦硬吃。为了掌握核心技能、深化理解、培养批判性思维、解决复杂问题而进行的有目的的、高价值的努力。这是一种战略性的投入。不是没苦硬吃。

回到「由简入奢易,由奢入简难」和「人的惰性」

正是因为惰性的存在,我们很容易滑向完全依赖 AI 的「奢华」生活,从而不自觉地回避了那些必要的、能提升核心能力的「苦」。这时候,有意识地去「吃一些必要的苦」,就不是「没苦硬吃」,而是对抗惰性、保持清醒、主动投资未来的表现。

举个例子:

  • AI能帮我们写单元测试。如果我们只是为了应付覆盖率,让 AI 生成然后看都不看,那可能会错过很多理解代码逻辑和边界情况的机会。
  • 但如果我们让 AI 生成初步的测试用例,然后再仔细分析这些用例是否覆盖了所有关键逻辑、边界条件、异常情况,并在此基础上进行补充和优化,甚至思考如何设计更健壮的被测试代码——这个过程虽然也「苦」,但价值巨大。

那如何对抗这种「人性」?

正因为「惰性」和「由简入奢易,由奢入简难」是人性的一部分,所以对抗它需要刻意的练习

1.保持警惕意识: 时刻提醒自己,AI 是工具,不是替代品。享受便利的同时,要警惕能力滑坡的风险。

2.刻意练习:

  • 主动「脱离」 AI : 对于一些核心模块或自己希望提升的领域,尝试不使用或少使用 AI,强迫自己独立思考和编码。
  • 深究 AI 的答案: 不满足于AI给出的结果,而是去理解它为什么这么做,它的原理是什么,有没有更好的方式。把 AI 的输出当成学习材料,而不是最终答案。
  • 复盘与总结: 即使使用了 AI,也要对过程和结果进行复盘,总结学到的东西和 AI 的局限性。

3.设定更高的目标: 将 AI 视为达到更高目标的「杠杆」,而不是满足于现有水平的「安乐椅」。比如,利用 AI 节省下来的时间去学习新的架构知识、去钻研更复杂的算法、去思考更有创造性的解决方案。让 AI 帮助我们去追求一种更高层次的、更依赖人类智慧的「奢华」。

4.强化元认知: 思考自己是如何思考的,学习自己是如何学习的。意识到自己可能陷入了惰性思维,并主动调整策略。

5.对「思考能力」和「代码能力」的重新定义

  • 思考能力: 可能从「如何从零开始解决问题」更多地转向「如何清晰地描述问题」、「如何将大问题分解给 AI」、「如何评估和整合 AI 提供的方案」、「如何在更高层面进行架构设计和技术决策」。
  • 代码能力: 可能从「熟练编写每一行具体代码」更多地转向「快速理解和修改 AI 生成的代码」、「保证代码质量、可维护性和安全性」、「进行有效的Code Review(即使是AI生成的代码)」。

AI 编程工具,确实像一把双刃剑。它带来的「即时满足感」和「认知负荷降低」,很容易就把我们拽进那个诱人的「舒适区」。毕竟,谁不爱走捷径呢?可问题也随之而来,长期依赖这种「外挂」,我们自己的「内功」——独立思考和编码能力,真可能在「温水煮青蛙」般的日常中,不知不觉就打了折扣。

当然,这也不是说我们就得跟 AI 划清界限,放着高效的工具不用,非得事事躬亲,那确实有点「低效勤奋」,甚至真成了「没苦硬吃」。关键在于,我们得想明白,哪些「苦」是值得吃的,是能真正提升我们核心竞争力的「战略性投入」。

  • 那些AI能完美胜任、重复性高且对我们知识增量有限的活儿,大胆交给 AI,这叫明智地利用工具,解放生产力
  • 但那些关乎「打地基」、深究「所以然」、需要「攻坚克难」的硬骨头,以及为了保持「手感」和「警惕性」的刻意练习——这些「苦」,恰恰是 AI 时代我们安身立命的本钱。它们能帮助我们构建真正的理解,培养批判性思维,并最终驾驭 AI,而不是被 AI 所定义

所以,面对AI,我们不能简单地「躺平」享受,也不能盲目地「排斥对抗」。更重要的是,要保持那份警惕意识,用刻意的练习去对抗人性的惰性

这不仅仅是关于代码怎么写得更快,更是关于我们如何重新定义自己的「思考能力」和「代码能力」,如何在 AI 的浪潮中,通过主动学习和深度思考,完成一次自我进化。说到底,AI 是工具,方向盘始终还是握在我们自己手里,是选择成为更智慧的「驾驶员」,还是满足于当一个「乘客」,这道题,得我们自己用心作答。

实在没辙了!只好祭出AI,给自己撸了个图片占位生成器

对于前端开发者而言,图片占位生成器是一个不可或缺的工具。

在实际开发中,我们经常会碰到这样的场景:产品展示页面的布局已经完成,各个模块都已就位,唯独缺少产品图片。而此时设计团队反馈:「图片素材还在制作中,预计下周交付。」

另一种常见情况是,在调试图片列表的响应式布局时,需要各种尺寸的测试图片。传统做法是通过搜索引擎寻找合适的图片,然后逐一下载、裁剪、调整尺寸。这个过程往往耗时良久,严重影响开发效率。

除了效率问题,版权风险也不容忽视。在项目中使用网络图片时,我们必须考虑:这些图片是否有版权限制?是否适合在商业项目中使用?这些问题如果处理不当,可能会给项目带来法律风险。

还有一些场景,如我们动态生成图片,在图片上显示提示的内容这种相对小众的场景。

本周刚好有一个需求是给飞书捷径做一个小功能用到了图片占位生成。梳理完需求,大概如下:

  1. 能指定宽和高
  2. 能自定义文字
  3. 能指定文本颜色和背景色
  4. 能指定图片格式输出,支持 PNG
  5. 能指定文本大小
  6. 能在飞书中使用

首先我们看一下有哪些在线的图片占位生成器可用的。

我们先让最新的 Claude-4-Opus 大模型给出 10 个地址,如下图:

1. **Placeholder.com【不可用】**
- **URL**: https://via.placeholder.com/
- **使用方法**: `https://via.placeholder.com/300x200`
- **特点**: 简单易用,支持自定义颜色和文字

2. **Lorem Picsum【能用,随机真实图片】**
- **URL**: https://picsum.photos/
- **使用方法**: `https://picsum.photos/200/300`
- **特点**: 提供随机的高质量真实图片

3. **Placehold.it【跳到 Placeholder.com 也不可用了】**
- **URL**: https://placehold.it/
- **使用方法**: `https://placehold.it/350x150`
- **特点**: 经典的占位图服务,支持多种格式

4. **PlaceIMG【不可用】**
- **URL**: https://placeimg.com/
- **使用方法**: `https://placeimg.com/640/480/any`
- **特点**: 可选择不同类别(动物、建筑、自然等)

5. **Dummy Image【可用,不支持中文】**
- **URL**: https://dummyimage.com/
- **使用方法**: `https://dummyimage.com/600x400/000/fff`
- **特点**: 高度可定制,支持自定义背景色和文字颜色

6. **LoremFlickr【可用,不支持自定义内容】**
- **URL**: https://loremflickr.com/
- **使用方法**: `https://loremflickr.com/320/240`
- **特点**: 基于Flickr的真实图片,支持关键词搜索

7. **Placekitten【不可用】**
- **URL**: https://placekitten.com/
- **使用方法**: `https://placekitten.com/200/300`
- **特点**: 提供可爱的猫咪图片作为占位图

8. **Unsplash Source【不可用】**
- **URL**: https://source.unsplash.com/
- **使用方法**: `https://source.unsplash.com/1600x900/?nature`
- **特点**: 使用Unsplash的高质量图片库

9. **PlaceBear【可用,不支持自定义内容】**
- **URL**: https://placebear.com/
- **使用方法**: `https://placebear.com/200/300`
- **特点**: 提供熊的图片作为占位图

10. **FakeIMG.pl【可用,不支持中文】**
- **URL**: https://fakeimg.pl/
- **使用方法**: `https://fakeimg.pl/300x200/ff0000/ffffff?text=Hello`
- **特点**: 支持自定义文字、字体和颜色

以上 10 个站点看下来,就 1 和 5 相对符合需求,但都不支持中文。

AI 不行,搜索来凑,一顿 Goole 下来,又找到以下的几个:

1.placehold.co【可用,不支持中文】

示例:https://placehold.co/600×400?text=Hello+World

2.fakeimg.pl

示例:https://fakeimg.pl/300/?text=哈哈&font=noto

fakeimg.pl 在功能上需求都能满足,不管是大小、字体、中文,但是它在飞书中作为附件使用的时候竟然出错了。使用 dummyimage 却没有这个问题。 试了几次发现怎么都绕不过去,只能另想他法。

3.tool.lu

示例:https://iph.href.lu/600×400?text=哈哈哈

tool.lu 的图片占位功能能完全满足需求,但是和 2 一样,在飞书下会报错。

4.devtool.tech

界面最好的一个生成站点,但是格式是 SVG 的

以上只是基本可用的,还不排除那些功能不满足,失效了的,各种,折腾了两个小时,能满足需求的飞书用不了,飞书能用的不支持中文,死循环了。

只能自己撸了

祭出 AI,花了两小时(代码只花了半小时,还包括框架搭建),本地运行没有问题,把代码部署到线上,能正常显示,但是飞书用不了,一样的报错:

execute error,捷径执行出错:
Error: execute原始执行结果:
捷径返回错误码: FieldCode.Success 
 转换结果:transform cell value fail

这回是自己写的代码,终于可以定位并解决问题了。对比能用的地址和不能用的地址,从头文件中发现了两个字段的差别,一个是跨域:Access-Control-Allow-Origin,一个是返回长度:Content-Length

最终试验发现是:Content-Length

可能飞书在获取图片并上传成附件的时候做了判断或者校验(就是个 BUG)。

这个功能已经作为免费的服务放到了开发哥网站(还记得之前 Vibe Coding 写的那个网站不):

https://www.kaifage.com/tools/placeholder

以上。

多说一句,即梦 3.0 生图中的汉字越来越精细了。

1:29:300!这个「魔鬼定律」正在预告你的下一次线上故障

无论是深夜被夺命连环 call,还是眼睁睁看着用户反馈铺天盖地而来,那种感觉,相信大家或多或少都体验过。

当我们不幸经历了一次「刻骨铭心」的线上故障。痛定思痛,除了常规的复盘,我们也许要从一个更系统、更底层的视角,和团队的同学一起探讨:故障,究竟为何而来?我们又该如何防微杜渐?

今天,我们聊下安全管理领域的「老法师」——海恩法则(Heinrich’s Law),以及它的一众「智慧亲友团」。

海恩法则:事故背后的「1:29:300」金字塔

海恩法则的来历

海恩法则由美国工业安全先驱赫伯特·威廉·海因里希(Herbert William Heinrich) 在上世纪30年代提出。他在为保险公司工作时,通过分析数千份工伤事故报告,总结出了这个惊人的规律。最初应用于工业安全领域,但其揭示的事故发生规律具有普遍性,早已跨界影响到航空、医疗、乃至我们软件工程等多个领域。

海恩法则指出:

在一件重大的事故背后,平均有 29 次轻微事故,以及 300 个无伤害的隐患或未遂事件。

这个法则通常以 1:29:300 的金字塔比例来形象展示。

海恩法则的核心思想

  1. 事故是可以预防的:严重事故并非天降横祸,而是此前一系列小问题和风险累积、演变的结果。如果我们能有效管理「29」和「300」,就能大概率避免「1」的发生。
  2. 重视「未遂先兆」:那 300 个「隐患」和 29 个「轻微事故」是重大事故的「报警器」。忽视它们,就等于给灾难开了绿灯。很多时候,我们只关注已经发生的「1」,却对冰山下的「29」和「300」视而不见。
  3. 安全管理需系统化:事故的发生往往与管理体系的漏洞、流程的缺陷、安全文化的缺失等系统性问题相关。预防事故需要从整个系统的角度出发,进行持续改进。

海恩法则的应用实例

  • 工业生产:工厂通过定期的安全检查、员工安全行为规范、隐患上报奖励等机制,主动排查和消除那「300 个隐患」,处理「29 起轻微事故」,从而避免重大生产安全事故。
  • 航空安全:每一次飞行前的详细检查、飞行员的严格培训、对飞行过程中任何微小异常的记录与分析,都是海恩法则的体现。一个螺丝的松动(隐患)如果不被发现,可能导致部件故障(轻微事故),极端情况下甚至引发空难(重大事故)。
  • 医疗安全:医院对用药错误、手术流程中的小差错等「未遂事件」进行记录和分析,改进流程,以防止严重的医疗事故。

对于线上故障,海恩法则给我们的启发与教训

海恩法则对于我们维护线上系统稳定性,尤其是复杂的线上应用,具有极其深刻的指导意义。

教训与经验借鉴:

  1. 「小问题」绝不小觑:线上一个偶发的 null 指针异常、某个非核心接口超时频率略增、用户反馈的一个「不太影响使用」的小 Bug,都可能是「29」或「300」的信号。如果仅仅是临时「hotfix」或者因为优先级不高而搁置,这些「小债」累积起来,迟早会引发“大雷”。
  2. 「未遂」也是宝贵数据:一次灰度发布中发现的问题并回滚、一次压力测试暴露的瓶颈、一次配置错误在生效前被发现……这些都是「未遂事件」。它们暴露了流程或系统中的薄弱环节,是改进的绝佳机会,不能因为「没出事」就庆幸了事。
  3. 故障复盘不能止于表面:发生故障后,不能仅仅定位到直接原因(比如某行代码写错了),更要深挖根本原因:为什么这行错误的代码能上线?测试为何没发现?Code Review 为何遗漏?发布流程是否有问题?这才是触及「300个隐患」层面的思考。
  4. 建立「隐患上报」的文化:鼓励团队成员主动暴露系统中的潜在风险、不合理的设计、流程上的缺陷,即使这些问题短期内没有引发故障。要营造一个「说出问题是贡献」的安全文化氛围。

哪些算作「轻微事故」和「隐患」?线上 BUG 怎么算?

  • 300 个隐患 – 系统中的「定时炸弹」

    • 技术债:过时的库、临时的硬编码、缺乏注释的复杂代码、糟糕的架构设计。
    • 配置风险:配置项繁多且缺乏校验、配置管理混乱、关键配置依赖人工操作。
    • 监控盲区:核心业务指标未监控、告警阈值不合理、日志信息不全或格式混乱。
    • 测试覆盖不足:单元测试覆盖率低、缺乏有效的集成测试和端到端测试、对异常场景和边缘 Case 考虑不周。
    • 流程缺陷:发布流程不规范、变更管理随意、缺乏应急预案或预案未演练。
    • 知识断层:核心模块只有少数人懂、文档严重滞后或缺失。
    • 不规范的操作习惯:随意在线上环境执行高危操作、密码弱口令或共享。
    • 线上 BUG,未直接造成服务中断或核心功能严重受损的:例如,某个页面的 UI 显示错位、某个非核心功能的计算结果在特定条件下不准确但用户感知不强。这些 BUG 本身是问题,也是系统脆弱性的体现,属于「隐患」范畴,若不修复,可能在特定条件下与其他因素叠加,引发更严重问题。
  • 29 次轻微事故 – 系统发出的「黄牌警告」

    • 短暂的服务抖动:例如,某个服务实例重启导致短时间部分请求失败。
    • 部分功能不可用或性能下降:例如,图片上传功能暂时失败、某个 API 响应时间飙升但未完全超时。
    • 告警频繁触发但能自动恢复:例如,CPU 使用率短时超阈值后回落。
    • 线上 BUG,已造成用户可感知的、轻微的功能异常或体验下降:例如,用户无法修改头像、搜索结果排序偶现不符合预期但仍可使用。这类 BUG 已经对用户产生了一定影响,属于轻微事故。
    • 资源超限警告:数据库连接池满、磁盘空间接近阈值。
  • 1 次重大故障 – 系统「拉响红色警报」

    • 核心服务长时间中断
    • 大面积用户无法使用核心功能
    • 数据丢失或严重损坏
    • 造成公司声誉或经济重大损失

哪些指标能帮我们「看到」冰山?

有效的监控和度量是发现「29」和「300」的关键。以下一些指标可以帮助我们感知系统的健康状态:

  • 线上 BUG 数量与趋势

    • 新增 BUG 数/解决 BUG 数:反映研发质量和修复效率。
    • 遗留 BUG 数量与等级分布:高等级 BUG 积压是重大风险。
    • BUG 平均解决时长 (MTTR for bugs)。
  • 代码质量指标

    • 圈复杂度:高圈复杂度的代码往往难以理解和维护,是潜在的 BUG 温床和隐患。持续监控圈复杂度的变化趋势,对超标模块进行重构。
    • 代码重复率
    • 静态代码分析告警数
  • 系统稳定性与性能指标

    • 服务可用性 (SLA/SLO)。
    • 错误率:API 错误率、特定业务操作错误率。
    • 平均响应时间 (Average Response Time) 与分位值 (e.g., P95, P99)。
    • 资源利用率与饱和度:CPU、内存、磁盘I/O、网络带宽、数据库连接池等。
  • 变更与发布相关指标

    • 变更成功率
    • 因变更引发的故障数
    • 发布频率 (高频健康的发布是敏捷和稳定的体现,但需质量保障)。
  • 告警与事件指标

    • 告警数量与级别分布:过多低价值告警会造成“告警疲劳”。
    • 平均故障检测时间 MTTD
    • 平均故障恢复时间 MTTR

海恩法则的「亲友团」:这些智慧异曲同工

海恩法则并非孤军奋战,在安全管理和系统思维领域,还有许多理论与它遥相呼应,共同构成了我们理解和应对风险的知识体系:

  1. 墨菲定律:「凡事只要有可能出错,就一定会出错。」 它提醒我们不要抱有侥幸心理,任何潜在的风险点都可能在某个时刻爆发。

  2. 多米诺理论:同为海因里希提出,认为事故的发生像一连串倒下的多米诺骨牌,由五个阶段(社会环境/遗传因素 -> 人的失误 -> 不安全行为/条件 -> 事故 -> 伤害)连锁引发。切断其中任何一环,特别是「不安全行为/条件」,就能阻止事故。

  3. 冰山理论:事故的直接损失(如设备损坏、人员伤亡)只是冰山一角,水面下隐藏着更大的间接损失(如生产延误、声誉受损、员工士气低落等)和深层原因(管理缺陷、安全文化缺失)。与海恩法则的 1:29:300 有异曲同工之妙。

  4. 帕累托法则 80/20 法则:大约 80% 的事故是由 20% 的原因造成的。这提示我们要集中资源解决那些最关键的风险点和隐患。

  5. 鲍尔法则:系统越复杂,发生重大事故的概率越高。这警示我们在设计和维护复杂系统(如AIGC应用)时,要格外关注风险的累积和扩散。

  6. 「四不放过」原则:事故原因不查清不放过、责任人未受到处理不放过、整改措施未落实不放过、相关人员未受到教育不放过。这是事故后处理的铁律,确保从错误中学习,防止重蹈覆辙。

  7. 瑞士奶酪模型:由詹姆斯·里森(James Reason)提出。系统有多道防线(如代码规范、测试、监控),每道防线都像一片瑞士奶酪,上面有孔洞(缺陷)。当所有孔洞恰好对齐时,风险就会穿透所有防线,导致事故。这强调了单一防线的不足和多层防御的重要性。

  8. 破窗效应:环境中一个未被修复的「破窗」,会暗示这里无人管理,从而诱发更多的混乱和破坏。对应到系统中,一个小 BUG、一个不规范的操作长期被容忍,会逐渐侵蚀团队的质量意识和纪律,最终导致大问题。

从「救火」到「防火」:我们的系统性行动指南

理解了这些法则和理论,我们不能仅仅停留在「哦,原来如此」,更要将其转化为行动,从根本上提升系统的稳定性和韧性。

  1. 拥抱「小题大做」文化:对每一个「29」和「300」保持高度警惕,建立快速响应和彻底解决的机制。
  2. 建立并严格执行「故障复盘」机制:深入挖掘根本原因,落实改进措施,并跟踪效果,形成闭环。
  3. 强化「可观测性」建设:完善日志、指标、追踪体系,让系统的每一个角落都“透明可见”。利用好我们前面提到的各项指标。
  4. 投资于「看不见的角落」:积极偿还技术债,优化系统架构,完善自动化测试,加强代码审查,推广混沌工程等。
  5. 提升团队的「风险意识」与「系统思维」:让每个人都成为系统安全的守护者,理解自己的工作如何影响全局。
  6. 持续演练,常备不懈:完善应急预案,并定期组织真实场景的故障演练,提升团队应急响应能力。
  7. 数据驱动,持续改进:利用收集到的指标数据,分析趋势,识别瓶颈,指导我们的优化方向。例如,如果线上 BUG 数持续在高位,或圈复杂度高的模块频繁出问题,那就是明确的改进信号。

写在最后

线上系统的稳定性,是一场没有终点的马拉松,也是一场与熵增(系统混乱度增加的自然趋势)的持续对抗。故障不可怕,可怕的是从故障中一无所获,反复在同一个地方跌倒。

希望海恩法则和它的「亲友团」能像一盏盏明灯,照亮我们系统中的每一个阴暗角落,指引我们关注那些微小的信号和潜在的风险。通过系统性的思考、数据驱动的决策和持续不懈的改进,我们一定能逐步减少重大故障的发生,为用户提供更稳定、更可靠的服务。

以上。