3种处理DevOps瞬态故障的方法[DevOps]

DevOps旨在通过持续的业务价值来使利益相关者满意，而如何处理瞬态故障也是其中的一部分。

Bright gears connecting

在电气工程中，瞬态故障定义为在断开电源并恢复后消失的错误状态。 当强制关闭物理设备的电源，然后在充满乱码的蓝色崩溃屏幕上强制关闭或打开物理设备的电源时，这也是许多人不自觉使用的解决方法。

在云计算中，将面对越来越多的复杂性，未知的未知因素，或更糟糕的是，将永远无法接触到的未知未知的基础设施，以及以指数级速度发展的技术和连接不断扩展的数字世界的不同解决方案。 如今，虚拟用户对无响应，不可靠和性能不佳的产品的容忍度为零-每个人都希望24x7全天候正常运行时间以及不断发展并融入其生活方式的解决方案。

在这个新的虚拟世界中，不能走动并重启机器，至少不会影响数百，数千甚至数百万的用户。在当今竞争激烈的世界中，对品牌和产品的忠诚度正在迅速下降。用户可能会在单击按键时寻找替代服务，而从不回头，而不是忍受任何可衡量的停机时间。

来快速看一下两个令人沮丧的事件，这些事件提醒我们，当今的瞬时故障可能发生在心跳中，难以识别和解决，并且对利益相关者产生深远的影响。

粗略补丁：“过去半个星期在服务方面遇到了一些问题。我对此感到非常恐惧，对此我深表歉意。这是自不稳定性以来，遇到的最大事件。服务重构”，微软公司云开发服务副总裁Brian Harry在博客中写道。经过数周的不眠之夜，根本原因被确定为对访问控制服务（ACS）的请求风暴，该请求耗尽了源网络地址转换（SNAT）端口，阻止了身份验证并影响了我们的涉众。

503错误：Cellenza的Mikael Krief在ALM DevOps Rangers博客上报道说：“从Azure功能实施的开始就开始设置监视，这证实了在DevOps流程中进行监视的重要性。”同样，花了整夜不眠的夜晚，找到了重构后的扩展为何引发连接和线程风暴，破坏了Azure服务以及使利益相关方感到“ 503服务不可用”错误的根本原因。

可以为云应用程序设置故障和灾难恢复，以帮助最大程度地减少（而不是消除）由于资源故障或自然灾害造成的中断所造成的影响。但是，对于使用远程资源或与远程服务通信的解决方案，需要增加对瞬态故障的敏感性。经过精心设计的解决方案可以在发出警报之前检测并尝试对瞬态故障进行自我纠正，甚至更糟的是，它们会变得无响应并发生故障。

有几种瞬态故障处理模式，包括以下白板上显示的三种：重试，节流和断路器。

transient fault handling patterns

重试模式

重试模式是三种瞬态故障处理模式中最简单的一种，这是在日常生活中自然要做的事情。 它在跨分布式网络进行通信的解决方案中有效，以处理由网络延迟，服务过载和断电等问题引起的瞬时故障。

Retry pattern

伪码

Set failure_count = 0 Call the [micro] service If (fail) failure_count++ If (failure_count > retry_limit) or (not transient failure) FAIL Delay (delay_time) Increase delay_time by factor of failure_count Retry step 2

该模式可确保在不理想的情况下，用户的请求最终成功，在这种情况下，瞬态故障会导致立即和频繁的故障。 有关详细信息，请参见开放源代码实现，例如java-design-patterns和transient-fault-handling-application-block。

节流模式

需要保护服务免受过度使用解决方案或由于系统或逻辑故障而变得无聊的客户的侵害。 就像为六车道高速公路服务的四车道隧道一样，必须管理超过最大吞吐量（隧道）的请求（汽车）和节流端点（车道）的流量。

Throttling pattern

伪码

Increment request_count // Limit – Maximum requests within an interval // Degrade – Fail with “slow down” error or pause operation If (request_count > limit) degrade service Call the [micro] service

该模式有助于满足服务水平协议，防止单个用户过度使用系统，优化请求流以及处理突发的请求。需要增加先前模式中重试之间的延迟的原因之一是，确保不会无意中超过系统的吞吐量并触发服务质量下降。有关更多详细信息，请参见WebApiThrottle和Core.Throttling等开源实现。

断路器模式

像家中的断路器一样，断路器模式是您的最后防御。重试模式有助于自动纠正短暂的瞬态故障，但此模式更适合需要较长时间才能解决的瞬态故障。在处理网络或服务中断（例如“粗糙补丁”事件）时，重试失败的服务操作可能会使情况恶化，导致级联故障，并最终触发解决方案崩溃。断路器模式的假设是，失败的服务呼叫很可能在（且仅当）在重大延迟后自动重试时才成功。

就像在黑暗中交错进入地下室以找到断路器柜一样，可以在翻转开关之前让电气系统和潜在的静电荷恢复。

Circuit breaker pattern

伪码

// Circuit breaker has not tripped If (circuit_state == open)

Call the [micro] service If (fail) fail_count++ If (fail_count > limit) circuit_state = closed

// Circuit breaker tripped Else

If (circuit_state == closed) Start Timer

// Call back for timer event On Timer timeout

Call the [micro] service If (success) circuit_state == open

有关更多详细信息，请参见开源实现，例如Hystrix，断路器和Polly。

不要担心缺点

切记包括所有已知故障和已实施处理模式的单元测试和集成测试。触发故障处理逻辑时，单元测试必须验证解决方案是否能够正确响应。另一方面，集成测试必须模拟弹性故障，以验证集体服务解决方案可以有效地处理故障。可以使用服务虚拟化（例如Hoverfly）来模拟服务，瞬态故障和降级服务。若解决方案和相关的故障处理模式未能实现自我修复和避免灾难性崩溃的希望，那么利益相关者将不会感到高兴。

因此，故障（如故障）是无可指责的DevOps的功能，不应该担心它们。为了保持竞争力，必须提高基础架构，解决方案和问责制的质量标准，以进行根本原因级别的检测，补救和自我纠正，以维持可接受的服务级别。

例如，在下图中，微服务＃7已爆破，触发断路器和流量节流，并在继续为用户提供服务的同时允许系统恢复。从这个简单的图示中可以明显看出，故障的组合和处理故障的复杂性在切换功能标志时会变得复杂。

Transient fault example

这些模式和其他模式对于健康的DevOps思维方式的核心价值之一是强大的盟友，以“超越当今流程的界限进行改进-力求始终创新和改进，超越可重复的流程和框架”。 他们帮助我们提高了质量标准，并不断交付业务价值，并使利益相关者感到高兴。