软件开发中的英雄问题

2025-06-10

软件开发中的英雄问题

想象一下,你的 Web 应用程序半夜宕机了。现在是凌晨 2 点,但你的业务遍布全球。你的用户遍布各个时区。他们非常愤怒。他们无法在你的网站上购物,或者正在取消订阅。你的 Web 应用程序宕机的每一分钟都在造成经济损失。

突然,你的一位开发人员接手了这个案子!这位开发人员略显焦虑,还破口大骂(毕竟是凌晨两点),但问题最终还是解决了。应用程序恢复了运行,公司也开始盈利。尽管这种情况时有发生,但你还是感到欣慰,因为有这位开发人员随时可以解决问题。这位开发人员就是你的英雄。

然而,处于这种情况的人不应该感到安心。对于一家公司来说,这是一个极其危险的处境。它会对公司里的每一位员工产生负面影响。尽管感觉自己无比重要,但它也会伤害到英雄开发者。

让我们先从公司面临的问题说起。如果某个应用程序已知存在稳定性问题,就应该予以解决。危机管理几乎从不解决根本问题。危机管理的目的在于熬过每一天。“修复”只是暂时的。真正的问题仍然需要解决。

有英雄随时待命的安慰会让那些真正的问题显得不那么紧迫。人们很容易推迟解决这些问题,转而去从事新的创收活动。

但危机管理不同于危机预防。

频繁宕机的应用程序会在用户心目中留下坏名声。这会让用户留存变得困难,最终也更难获得新用户。此外,还有可能出现英雄不在的情况。这种情况有很多种可能。比如他们生病了怎么办?或者亲戚生病了怎么办?或者他们去度假了怎么办?又或者他们只是觉得累了就辞职了怎么办?

在所有这些情况下,你的应用程序现在宕机的时间更长了(几个小时而不是几分钟,几天而不是几小时)。你可能会说,团队中的其他人可以承担起英雄的重任。这就引出了团队中其他人面临的问题。

如果您的工作出现危机而您却无能为力,您会怎么做?

处于这种情况的人会感到无助。这会损害一个人的自信心,进而影响工作表现。人们也可以请英雄教他们解决问题,但公司既然不优先解决真正的问题,又何必优先考虑英雄的教育呢?

更重要的是,人们也会变得依赖英雄。他们认为,自己的工作就是自己的工作,而英雄则是处理危机的人。他们不需要学习如何提供帮助。

对于开发人员来说,这种态度非常危险。预防危机,或者至少让危机更易于管理的最佳方法是构建易于预防或管理的软件。如果开发人员从未经历过危机,又怎么知道如何正确地应对危机呢?

他们不能。

即使英雄在危机解决后解释了技术细节,也会遗漏一些重要的细节。其中最重要的一点就是英雄在凌晨两点醒来应对危机后的情绪状态。

开发人员每天都会在代码中做出数十个微小的决策。许多这样的决策可以在危机时刻节省宝贵的几分钟甚至几小时。那些只是听说某些东西在危机中会有所帮助的人,无法真正理解其重要性,而那些在危机中亲身经历错误决策后果的人则无法理解。

例如:许多没有经历过危机的开发人员往往会写出糟糕的错误信息。他们的代码中充斥着诸如“发生错误”之类的信息。错误发生在哪里?是谁发生的?即使是像“用户 123 在 URL /home 处发生错误”这样小的问题,也会产生巨大的影响。但从未修复过关键问题的人不会理解这会带来多大的影响。他们永远不会感受到代码中这些看似微小的变化所带来的情感冲击。

编写能够有效应对危机的代码是开发人员的一项基本技能。当开发人员依赖“英雄”来解决危机时,他们就剥夺了自己提升编写更优质代码技能的机会。这不仅会在短期内影响公司,还会在长期影响开发人员的职业生涯。

最后,还有英雄面临的问题。拥有化险为夷的技能在某种程度上赋予了英雄价值。但一次又一次的危机只会让英雄培养出解决危机的技能,而不会培养预防危机的能力。如果公司不能优先考虑危机预防,英雄就没有时间去实践。这会影响英雄的职业生涯,因为他们的价值与一家公司息息相关。他们对另一家公司的价值会降低,如果他们发现自己不满意,就无法继续前进。

他们将会不高兴。

成为英雄会带来许多生活质量问题。想休假?当然可以,但要时刻准备好值班电话,并随时准备拿出笔记本电脑。想创造一些新鲜有趣的东西?当然可以,但要在危机间隙进行。想和朋友约个晚餐或约会?当然可以,但要做好取消的准备,以防万一。

我既是英雄,又是依赖英雄来拯救世界的开发者。说实话,当英雄更糟糕。起初,赞美和肾上腺素飙升的感觉很棒,但这种感觉不会持久。最终,只有疲惫、无奈和愤怒。

“怎么又坏了?!”

光解决危机而不预防危机,对开发者的成长只会事倍功半。最终,你只会一遍又一遍地解决同一种危机。这根本学不到什么。我也遇到过需要危机的情况,尽管我讨厌危机。我已经习惯了解决危机,以至于不知道在没有危机的时候该如何运作。一个人如何才能不受干扰地工作?真是奇怪!

那么,我们怎样才能摆脱英雄开发者文化呢?

这个想法很简单,即使实施起来可能充满挑战。要像对待危机一样认真对待英雄。危机发生时,要解决它。但也要至少采取一步措施,防止类似的事情再次发生。这并不能保证万无一失,但缓慢的进步也是一种进步。你最终会到达那里。

还要优先考虑对团队其他成员的教育。每次危机都要让多人参与。这或许只是与英雄同时调查问题,或许是直接与英雄配对。但一定要让他们参与进来。每个人都能从实践中学习得更好。虽然英雄可以更快地完成任务,但拥有多个能够解决未来危机的人员是值得的。

这两个步骤都不容易做到。在紧急情况下,考虑长远发展从来都不是一件容易的事。但基于上述所有原因,这些步骤非常重要,因为它们可以避免陷入“只有一个英雄来解决危机”的恶性循环,因为这个英雄是唯一一个解决过危机的人。这样做是值得的。

本文最初发表于blog.professorbeekums.com

鏂囩珷鏉ユ簮锛�https://dev.to/pbeekums/the-problem-with-heroes-in-software-development
PREV
Kubernetes 安全最佳实践
NEXT
学生参与的开源项目