十个中断的七节课

2021-06-23 08:27:15

在他们的第一个赛季10次尸体后，汤姆和杰米反映了他们所看到的常见问题。单击详情！

我们只是通过我们的停机时间播客的首发赛季，并庆祝，我们反映了我们在我们倾注的十大中断中的许多中断中注意到的经常性主题。由于他们解决了这些事件，这是卓越的某些模式如何成为风险或作为资产 - 工程团队。

出于这些经常性模式，我们提取了我们打算进入我们自己的工程团队的课程;因此，我们已经编制了下面的五个课程，以获得任何感兴趣的读者的利益，希望您也发现他们有助于学习和准备。我们走了，我们将包括与每个主题发生的中断和集中的链接。

如果您觉得我们错过了任何主要模式，或者对我们有任何其他反馈，请发表评论。谢谢你们所有人听取停机项目的第一个赛季。

“Dogfood”的本能是一个伟大的唯一一个，如果你不会，你如何合理地希望您的客户使用您的产品和服务？如果您不符合自己的公司的生产力，您如何支持他们启用的工作流程？

但是，这种健康的本能返回当所述狗狗食品创建一个依赖周期时，您依靠自己的系统...修复您的系统。

这种依赖模式的其他实例从其他善良的座右铭中掉出：不要重复自己。为什么跑另一种数据库只是为了监控？你已经很好地运行了生产数据库，非常感谢您。所以只需将遥测数据放在那里。

这些循环也可以在中断时疼得厉害。喜欢，需要努力访问操作系统以修复身份验证的身份验证...或监视需要工作数据库以获得公制数据以发现数据库的错误。有趣的东西。

即使是客户通信系统有时被破坏，因为您使用自己的系统将系统状态传递给客户。

EP 1. Slack VS TGWS：Slack无法访问仪表板以知道其系统出现了什么问题，因为AWS Transit Gateways需要健康，以便将HTTP流量置于其仪表板。不幸的是，TGW是不健康的。

EP 3. Monzo 2019 Cassandra中断：Monzo的生产数据库已关闭，这是验证系统访问和部署代码以解决问题所必需的。

EP 10. Kinesis命中线程限制：AWS无法更新其与Kinesis相关的中断的状态页面，因为对状态页面的更新依赖于Kinesis。

EP 11. Salesforce发布了一个有争议的淘汰的后期：Salesforce无法更新他们的状态页面，因为它们托管了基于Heroku的服务，并且由于他们拥有Heroku并因此将其集成到他们的基础设施中，Heroku的正常运行时间取决于他们的系统健康

每个人都超级兴奋了解现代公共云及其无数API。弹性！编排！自动化操作，使人类不必被醒来！

但是这种热情有时有些人拥有过度自动化的系统，在那里难以测试退化案件。而且，那些未经测试的退化情况下的缺点可能比在更健康的系统状态下是自动决定的略微效率或经济上行的缺点。

但是即使自动化是明智的，因为调整经常和/或涉及的经济学是大量的，但是自动化有时缺乏必要的“恐慌模式”，识别参数在其正常范围之外的参数。在这些情况下，自动化应该停止自动化和页面运营商，因为它即将开始制作一些非常不合逻辑的决策。

EP 1. Slack VS TGWS：Slack的自动化扔掉了一堆服务器，他们“不需要”（叙述者：他们所做的）由于空闲的CPU在网络问题期间，当交通返回的流量激增时，太多了。在其系统上导致文件描述符限制。

EP 6. GitHub的43个网络分区：Github的数据库自动化在43秒的网络分区期间对跨国推广有不完整的记录。

EP 8. Auth0的严重拥挤数据库：Auth0由于数据库要求减慢时，前端旋转两倍，只需更快地加剧了更多的流量。

如果只有一切都没有状态，呃？这些讨厌的数据库始终导致我们的问题。即使在前端层中表现出自己的问题通常往往拥塞，从数据库中逐渐增加，从数据库减慢服务堆栈中的更深。

这一领域是因为我们爆发了三个子课程的物质而挣扎：

生产系统对具有低方差的平坦，均匀的负载感到满意。涉及数据库服务器时，这意味着许多非常快的查询，可能是所有索引备份，其中最坏情况绑定。

为了确保这一点，请将任意批量查询放入专用辅助服务器中，或在一些OLAP系统中，如BigQuery或Snowflake。或者，哎呀，转储到CSV和并行Grep。无论复杂程度如何让您快乐，都适合您的数据集大小和工作流程。

如果您尚未了解您的查询时间分发，以了解您是否在最终的尾部扫描了疯狂的表扫描，请停止阅读此操作并立即添加监视！

EP 2. Gitlab 2017 Postgres中断：非常昂贵的长期账户删除操作RAN在其生产数据库上实现，导致拥堵和失败。

EP 5. Auth0默默地失去了一些索引：创建索引的未调解失败导致一些查询突然变得大大增加了数据库的负荷，最终导致中断。

EP 8. Auth0严重拥挤的数据库：通过在生产系统上发生的一些ad-hoc昂贵的扫描来加剧数据库问题。

低魔法（好）：使用像MySQL这样无聊的东西并处理碎片。这将糟糕，因为您必须在应用程序层中做大量额外的工作，但您可能会知道它在缺失时如何工作。这可能是10年前的正确想法，但仍然很好。

最低魔法（更好）：只需购买更大的服务器，并使用副本或两台未设置的MySQL / PostgreSQL服务器。只要你可以，这个好主意就是常绿的。

高魔法（不可否认，可能在2021+中最好）：支付云提供商以为您运行数据库，包括所有备份和故障转移等，如果您真的很喜欢，如CloudSpanner，您甚至可以使用花哨数据库，如CloudSpanner，或者dynamodb，或其他。这曾经是在第三方的完整，不透明的依赖性的不可想象，但它可能是2021年的最好的想法。这些大公司已经很擅长这东西，如果他们没有，你可能已经存在了已经存在注定无论如何你在其中一个人在其中一个人在其中一家运行，他们就好了。缺点是它会花费你，因为这些服务的标记很高。

中间魔法（用火玩火）：使用一些将声称自动解决所有缩放和故障转移问题的东西，但您仍然必须运行，并且它在它上的生产数量较少，而不是像MySQL这样无聊的东西。出现问题时，很少有人知道如何运行或了解其内部结构，足以诊断其编排流的复杂的失败模式。我们在这些中断遇到的可能嫌疑人包括MongoDB和Cassandra。

EP 3. Monzo 2019 Cassandra停电：扩展Cassandra Cluster有很多不良的配置脚枪。

EP 5. Auth0默默地失去了一些索引：在不降低现场交通的情况下，Mongo中重复复制的余额非常难以实现。

备份意味着如果您无法证明您可以恢复它，并且恢复会产生正确的记录，并且该恢复将在宇宙的热死亡前完成。

备份没有运行......永远不会发生，我正在监控！

备份ran并在s3中生成文件。就您的备份验证而言，这可能是。该文件是空的。或者它包含有用的字符串：错误：在目录/数据上拒绝权限。你的公司已经走了，而你尖叫着“但你退出零!!!”到深夜。

备份表面上包含许多大数据，但上传已损坏。你的公司走了。

备份包含有效数据库！但由于备份脚本中的循环错误，每个碎片都是碎片0。 87.5％的公司消失了。

每个备份都包含正确，有效的数据库！但从85毫秒链接下载从那个便宜的存储类将意味着恢复将需要2周。你的公司仍然消失了。

因此，请确保您证明您的恢复工作 - 自动化和监控此操作，不要一段时间内完成一次 - 并确保他们将在可接受的时间内恢复。期待它是一个糟糕的一天，如4小时，但不是公司结束，就像4天一样。确保公司政策智能公司对此恢复时间感到满意，并从您的领导地位签下，因此当工程团队需要7个小时时，他们不会感到惊讶，以便在灾难期间获得数据库。

EP 2. Gitlab的2017年Postgres中断：备份脚本每天运行，将其放入S3 ...直到软件更新打破备份脚本。修复物没有真正过测试过。

EP 6. GitHub的43个网络分区：恢复花费了很长时间（10h +），特别是在峰值流量期间，导致网站劣化了很长时间。

尽管我们的努力尽力而为，但仍将发生错误。我们将介绍错误，或误解的东西，或传播错误的防火墙规则，或者其他。

但是，阶段推出本地化问题，以便您可以在火灾蔓延之前看到烟雾并烧毁整个网站。

我们讨论的很多团队都有辅助的推出方法，使他们的公司的员工成为第一个努力为其服务进行改变的用户之一，而且只在所有的客户之前都会暴露。

向您的Dogfooding集群推出 - 每小时或每一个更改集，目前的头版部署到您的员工。这让您自己的团队在您的客户看到它之前捕获问题。

金丝雀群 - 在您的释放节奏（每天一次，也许是？），将释放候选人推出到一个小部署，使其暴露于少量用户。有些公司在几十个中将这一数据中心制作;其他人基于其user_id或类似的模数来提高userbase的一些百分比。发布经理可以仔细监控本金丝雀种群中的新版本的指标，然后继续...

生产。现在它开始出去更广泛的世界。根据服务的关键性和释放节奏，有时会一次或有时进一步交错，就像一个时代的数据中心。

对于雇用这些方法的公司，当时我们大多数人从未知道一个小问题时，有很多场合，因为它被捕获在狗食，或金丝雀或有关的东西。

但在我们播客的实例中，公司没有使用阶段的卷展栏，事情越来越不错了......写下后的球队是第一个呼唤阶段部署的差异有多少差异。

ep。 4一个微妙的正则表达式缩小了CloudFlare：CloudFlare非常快速地部署了一个更昂贵的正则表达式的规则，由于CPU耗尽而下整个站点下降

EP 11. Salesforce发布了一个有争议的后期：迅速部署DNS配置更改将其所有名称服务器脱机