什么是软件后期格式,您如何编写?

2020年12月30日10:55:35 发表评论 37 次浏览

本文概述

每个公司对于最高优先级的bug都有自己的名字。优先级是紧急情况, 紧急修复或紧急修复。

如果不及时处理, 有一些软件错误可能会使公司瘫痪。

骑士国会大厦集团是一家美国金融服务公司。一名技术人员忘了将一些新代码复制到计算机服务器, 此软件版本导致他们损失4.4亿美元。发生这种情况是因为其中一台计算机服务器开始在45分钟内快速购买库存(完成了超过400万次购买和销售)。

并非每个软件错误都如此严重。但是有时候, 作为软件开发人员, 你必须尽快解决错误。

最近, 我了解到一些公司发布了针对其紧急错误的可公开获取的尸体信息, 并首先涉足其中。

验尸是团队反思所做的事情出了什么问题, 并记录下来和/或修改其过程以阻止再次发生的过程。

软件版本变坏了吗?让我们分解一下开始出现问题的时间轴, 让我们反思一下如何早日发现问题。

这是最重要的一点:验尸不是指责。如果我们看骑士国会大厦集团的例子, 应该有没门让一个人忘记某事并削弱公司。

有人检查技术人员的工作的质量保证流程在哪里?他们在生产之前是否对此进行了测试?在成功部署到生产之前, 是否没有运行自动测试?

你应该发现工艺故障不个人失败.

因此, 我们可以一遍又一遍地避免犯同样的错误!

通过了解过去的失败方式, 我们提供了更强大, 无错误, 稳定的软件。

最重要的是, 我们可以捕获甚至不知道的错误。而且, 如果我们修复了易于及早导致问题的流程, 那么这些错误甚至都不会发生。

我们希望从停电和紧急情况中吸取教训, 以确保不再发生。没有什么比经验更有价值。

我想要一些各种各样的公司和语言, 因此让我们回顾一下Google, Microsoft和Flowdock的公司。

一种普通验尸模板将包含一些关键细节, 例如:

  • 当它发生
  • 拥有验尸的人(并将进行分析)
  • 一些经验教训
  • 紧急错误的大致时间表以及事后的一些动作

因此, 让我们开始吧。

谷歌

如果你在2009年1月31日太平洋标准时间上午6:30到太平洋标准时间7:25之间进行了Google搜索, 那么你会在每条结果中看到"此网站可能会损害你的计算机"的消息。

发生了什么?

如果已知该网站安装了恶意软件, 则Google会用此消息标记搜索结果。这是一项警告, 旨在保护Google用户, 并与Google的自动算法, 手动数据输入和名为StopBadWare.com.

一位开发人员更新了列表, 并意外输入了/, 这解决了每个站点!

我们知道这是人为错误, 因此, 只要文件发生更改, Google就会进行一些测试并进行检查。 (而且自2009年以来我再也没有看到过这种情况!)

完整的验尸可以找到这里.

微软

Microsoft在2012年2月29日发生了12小时的停机。

发生了什么?

微软有结构控制器可以控制约1000台服务器的计算机。它可以管理服务器的生命周期, 监视其运行状况, 并在服务器出现故障时重新启动服务器。

将所有这些服务器隔离到1, 000个服务器群集中可帮助它们保持模块化, 并将故障本地化为1个结构控制器(而不是所有服务器都关闭)。

群集中的每个服务器都有一个称为主机代理, 这由结构控制器去做它认为必要的工作。它处理的事情之一是部署SSL证书以使服务器保持使用HTTPS的方式, 这是一种加密数据的方式。

要知道何时需要重新生成这些SSL证书, 它们需要在第二天的午夜加上一年。所以如果结构控制器在1990年3月19日为服务器创建新证书, 该证书将在1991年3月20日到期。

你知道这是怎么回事吗?这些服务器尝试在a年为服务器生成一年证书。它试图将证书设置为过期2020年2月30日.

如果无法为服务器生成证书, 证书将终止。并且如果它连续终止三次, 则认为是硬件故障, 然后告知结构控制器这是错误的。

的结构控制器, 为了"修复"出故障的服务器, 会将工作移交给另一台服务器。尝试生成这些证书时, 所有服务器将一一列出错误。最终关闭了结构控制器(拥有1000台服务器!)。

这次灾难是由于代码错误造成的。有更好的方法来处理日期问题, 例如leap年和时区差异。

完整的验尸可以找到这里.

Google, 带两个

从2015年8月13日星期四到2015年8月17日星期一, Google Cloud服务存在一些错误, 并且某些硬盘的0.000001%永久丢失。

发生了什么?

当地电网连续发生四次雷击, 向为Google Cloud服务供电的Google计算机供电。

有些系统开始立即替换使用备用电池取出的电源。除了Google员工的手动干预外, 该服务已恢复, 而永久性损失最小。

Google正在进行一项升级基础架构的计划, 以使他们不易受到此类问题的影响。此后, 他们进行了分析, 涉及配电, 控制Cloud服务的软件以及所使用的Cloud硬件。

完整的验尸可以找到这里.

浮坞

在2020年4月21日至22日之间, Flowdock即时消息传递在大约32个小时内不可用。还发现了奇怪的行为, 例如某些用户无法登录。此外, 有些人发现了组织中另一个组织的用户(例如Amazon员工例如, 受污染的Microsoft)。

发生了什么?

冠状病毒使在家工作的人突然激增, 导致Flowdock的使用率比平常高。这导致很高的CPU使用率, 并导致数据库在尝试处理负载时挂起。还存在一些永久性数据丢失。

完整的验尸可以找到这里.

我读了亚马逊首席开发倡导者Adrian Hornsby的精彩文章。在里面, 他讨论了如果你曾经是某人的所有者, 则应避免一些事情, 并强调一些事情以编写最佳的验尸报告。

以下是他建议的一些内容:

  • 不要做事后谴责人员, 团队或组织。相反, 专注于过程那 未能让这些错误引起恶作剧。切勿做事后惩罚某人。这没有任何价值, 你将找不到任何改进。
  • 不要以为发生的事件比以前更容易预测。只是因为它们已经发生, 它们现在才显而易见。 (后见之明偏压)
  • 确保你足够深入。不要只是说我们在前端代码中看到错误。真正深入探究具体错误及其导致的原因。下一次该过程如何捕捉?更好的质量检查流程?更多同行评论?更好的错误记录?
  • 如果你阻止它发生的解决方法的步骤真的很模糊, 例如"改进文档"或"更好地培训", 那么你对它的理解不够清楚, 无法具体说明。使这些解决步骤可行且具体。
  • 尝试保持解决步骤, 以解决可在短期. 我们正在努力阻止这些再次发生。验尸可以产生更长期的过程更改, 但这不是你当前关注的重点。不要尝试重新架构一些基本的东西, 也不要尝试更改编写某些巨大代码库的语言。
  • 让你的验尸挑战你的团队目前认为是正确的。不要假设是因为每个人都相信某件事是真实的(通讯孟信谬论)

如何学习更多

如果喜欢, 你可以找到更多公开的验尸报告这里。这些包括我们已经讨论过的公司的验尸, 以及来自亚马逊, GitHub, Linux, Heroku, Spotify, Valve, Cloudfare, Etsy, GoCardless, Travis CI等的示例。

总结

我希望这能解释软件开发生命周期中的验尸是什么, 如何有效地编写一个, 以及编写前几个脚本时会发生的常见错误。

我分享我的文章推特如果你喜欢这篇文章并想了解更多。

一盏木

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: