您的工程组织最后一次与“恢复力”谈话是什么时候，这是什么时候有关“弹性？”的谈话。拥有你的团队开发人员，站点可靠性工程师（SRES），产品经理定义了什么“恢复力”对您的组织意味着什么？我们在现代软件中使用此术语，通常指向一组属性，该属性解释我们的系统如何生存和茁壮成长。
例如，自从Lew Cirne创立了新的遗物已经已经10年了。我们已经从一个复杂的系统到复杂的系统。我们开始了Rails Monitoring应用程序上的Scrappy Little Ruby，但现在我们是一个真正复杂的分布式系统。复杂性是不确定的，以及许多新的挑战和机遇。那么，我们如何茁壮成长和成长并留在前沿？
我们的弹性是关键，允许我们浏览所有这些关键。
更密切地探索我们如何使用“恢复力”一词可以帮助我们更加高效地思考我们的系统，以及特别是可靠性。
四个概念的弹性
在弹性的四个概念以及对恢复力工程未来的影响那大卫博士伍兹博士确定我们经常谈论弹性的四种方式。
前两个概念：
反弹：伍兹博士将其定义为系统从创伤中恢复的能力。当我们看看我们的系统从特定中断恢复如何恢复时，我们最常使用这种恢复感。
优雅的可扩展性：这一概念是指我们系统的延伸和增长的能力，以应对惊喜。微服务通常更为“弹性;”换句话说，它们比单甘醇更“可扩展”。
然而，对于这篇文章，我将专注于伍兹博士的两个剩余概念：
鲁棒性：根据伍兹博士的说法，“鲁棒性”是我们最常使用的词与“弹性”互换的词。鲁棒性大约超过我们系统从特定震荡反弹的能力;具体来说，它是关于我们的系统如何在不破坏的情况下吸收更广泛和更广泛的扰动。因此，当我们询问我们的系统是“弹性”的特殊类型的失败时，我们真的询问它们是否足以处理这些故障。
想一想桥梁。一个很好的桥梁可以承受风和天气的压力;它可以支持不断的流量;它可能会失去一定数量的支持，并仍然保持其诚信，例如峡谷。这座桥的建造者预期了任何数量的干扰，然后设计了系统能够在某些公差内承受这些干扰。
鲁棒性很重要。我们为我们的系统设计，以抵御交通尖峰。我们建立它们，以便它们可以水平扩展。我们建造n + 2冗余因此，我们可以丢失多个主机，而不会为自己或客户造成严重问题。
自适应容量：这种恢复力的概念指出了我们的系统适应和增长的能力，以应对其环境中的巨大变化。“自适应容量”包括我们如何应对失败的方式;它还包括我们能够利用新的机会和意外挑战的程度。这种弹性的概念是与复杂的分布式系统最相关的。
作为“自适应能力”的恢复力将我们带出了更确定的，工业模型进入复杂生态系统的世界。
换句话说，虽然桥梁可以随着时间的推移对许多强调稳健，但如果景观本身变化，则无法适应。但一个城市可以，而且，许多人都在做到这一点低洼沿海城市正在努力变得更加适应气候变化和海平面上升。许多城市也是利用新的机会仪器本身使用Citizens智能手机的数据改善居民的生活。
测量弹性可靠性的鲁棒性和自适应容量
在新遗物的第一年结束时，我们只使用一个产品少于十几个客户。今天，新的瑞典平台对全球数千个软件系统的运营是一体化的，其中许多人对融资，交通，医疗保健和保险等行业的现代社会的运作至关重要。
我们的客户有一个共同点：他们都想要更多的九个。他们想要持续的“正常运行时间”。从营销的角度来看，这听起来很棒 - “我们给你更多的九”。但是，如果你怀疑，像我一样，你可能会想知道，更多的九个？“更多九”是什么意思？
我们在这里询问的真实问题是我们如何以一种有用的方式测量我们可靠性的稳健性？
一个简单的正常运行时间测量可能对小型系统有用，但它在复杂的系统中旁边是无用的，就像我们在新遗物上拥有的东西一样。究竟需要“起来？”我们拥有一系列产品，每个产品由多个子系亚博最新版直播统组成，通过数千个代理将数据送入到多个摄取流水线中，将数据处理到多个数据存储中并从各种接口和API访问。
问题是可靠性不是二进制的。像我们这样的复杂系统并非“向上”或“下来”。可靠性更像是一种形貌。景观。有高可靠性的技术债务和山谷，以及快乐的平原，一切顺利，直到一天，随机拉出请求撕裂了地面的鸿沟。
当然，只是因为它很棘手并不意味着我们可以放弃测量可靠性。我们绘制边界，所以我们寻找有意义的边界，并给我们一个有意义的系统健康观点。
换句话说，我们寻找方法来使我们的软件景观自适应和强大。
如此广泛接受的衡量可靠性方式来自谷歌，如图所示站点可靠性工程书：每个服务都有服务级别指示符（SLIS）和衡量该服务健康的服务级别目标（SLO）。这种方法给出了对系统健康的细致细微颗粒状的观点。在新的遗物中，我们目前使用称为QDex的系统健康量。这是基于我们的事件数据的可用性测量。它考虑到三件事：
- 这个月的中断有多少客户受到影响？
- 影响有多严重？
- 影响持续多久了？
根据此数据，我们计算了加权可用性测量，使我们能够比较产品和团队在给定的月份的表现。亚博最新版直播
无论您是使用正式的SLIS和SLOS所有服务，还是更像我们的QDEX，您的可靠性测量应专注于客户影响，并应激励团队专注于提高其服务的鲁棒性和自适应能力，以方便让客户在他们的脑海中。
弹性可靠性鲁棒性和自适应容量的实用步骤
那么我们可以将鲁棒性和适应性能力应用于可靠性空间的实用方式是什么？
1.我们可以失败
可靠性是一个客户驱动的想法。我们不会提高可靠性，以便我们可以为月份获得更好的可靠性分数;我们提高可靠性，以改善客户的经验。
当我们失败时，我们不一定会降低所有风险，但我们确实减少了风险可能影响的客户数量。我们降低了对这些客户的影响的严重程度，我们使其成为持续的影响。
当我们失败时，我们优先考虑保护客户的工作。例如，这可能意味着，在解决不稳定的前端服务的更大的可靠性挑战之前，您可以使用登录更新404页，以便在中断期间，用户仍可登录。或者您架构师摄取最强大的数据在强化边缘案例的途径之前，携带大部分交通的途径。
我们可以失败聪明
我们的系统很复杂，充满了不确定性。我们永远无法消除这种不确定性，但我们可以选择挖掘的位置。这就是事件进来的地方：事件是我们的Dowsing Rods。它们是神奇的小事，在我们的曲目中阻止我们，并指出我们在表面下挖掘的斑点将是最富有成效的。
事件不会分心。如果我们继续将事故视为我们的“真实工作”的分心，我们我们拒绝了一个令人难以置信的丰富的洞察力。我们通过使用事件拖延不确定性并找到适应新方法的事件来最大化我们的“事件返回”。
我们可以失败更多（也许）
我们永远都会，我们所有人都有事故。无论是大还是小的，我们的生产软件系统将始终遭受中断。我们在我们的系统中遇到的问题的性质和频率将永远存在变化。
这将我们带来了鲁棒性和自适应能力之间的有趣张力。我们必须坚强，以便生存，但如果我们在特定时间点固定 - 如果我们成为也强大 - 我们变得不那么灵活。我们实际上降低了适应新的，令人惊讶的情况的能力。
在这种情况下，我们需要更多地失败。我们需要使用我们建立的一些资金来实验并推动我们的界限。这是另一种说法的方式，不要过度投资可靠性。当我们的服务变得非常强大时，也许我们已经创造了一些空间来实验和成长。我们是否在桌面上留下过多的可靠性？也许我们可以采取更多的风险并投资我们的长期灵活性和自适应能力，因此我们可以解决未来几年我们面临的具有挑战性的工作。
通过时间稳健和自适应弹性
弹性比系统如何响应即时威胁的恢复力量大致。
当我们的系统的恢复力（或缺乏）变得最可见时，事件是时刻。在一个复杂的分布式软件系统中，如新的遗物，弹性，根据许多因素来增长或死亡：硬件资源可用性，系统架构和克制，呼叫旋转和事件响应过程的成功和失败，强大或较差的工程习惯，可行的部署机制等等。
我们在新遗物中完成的一些事情以提高我们的强大和自适应弹性包括容器化我们的数据库，通过将部署工作流入集装箱面料（我们的容器编排平台）并将基础铺设到在欧洲推出整个新遗物的实例。
我们也从我们的内部获得了恢复力团队健康评估，这增加了我们团队做正确的工作和做得很好的能力。我们基于我们雇用谁，我们如何在船上，我们如何训练和教育员工。我们从无毁灭文化的心理安全和培养包容性和股权的卓越性能中获得恢复性。
我们的弹性来源延伸了十年。今天，他们在新的遗物中居住在每个人。
这篇文章受到新遗物的工作受到强烈影响Snafu捕手。
