障害问题的看法 (Shàng’ài wèntí de kànfǎ)

2 年 ago

清, 宇

1 minute

简要概述

障害について独自の理論やベストプラクティスを考えた

似乎已经有了系统化的理论。

目标定义

我们决定将目标设定为“最小化与障碍相关的业务损害”。

障碍相关的话题，
监控、冗余、指标、日志、健康检查…

这类话题为何会被提起，是因为最终目的是为了最小化与障碍相关的商业损失。

目标和各种因素之间的关系

我考虑了导致障碍的原因。

外界因素导致系统受损 (可通过冗余等方式控制受损程度)
-> 发现损害发生 (通过警报等)
-> 检查损害 (日志、度量等)
-> 减轻损害 (采取措施等)
-> 损害超过阈值
-> 发生故障

我尝试写了一篇关于这个关系的文章。

如果将观测系统视为监视系统的上级，整体上可以这样理解：

换句话说，监视系统被加入了反馈循环。

也许可以用这个模型来定义一个良好的系统，其在设定了适当扰动并附加了成本的情况下，最小化故障发生率。

应该在哪里进行投资？

根据预期的干扰程度，最佳投资选项会有所不同。

预计的干扰

アクセス過多

这是一个关于是微观还是宏观的问题。

举例来说，HTTP的健康检查能同时确认多个因素，例如不是由内存不足、硬件故障或网络设置错误等引起的。然而，它无法预测前兆（例如内存逐渐增加）等。每种检查方法都有各自的性质。

同時にチェック可能な範囲

自动还是监视。

硬件故障可以自动处理，但程序错误无法自动修复。如果自动处理成本较高，那么可以通过监控来处理吗？

我所考虑的最强最佳实践-

0. 用户的反应

我們需要意識到默認情況下有著對用戶反應進行監控的功能存在。

尽可能广泛地进行监视

如果我们以自动贩卖机作为例子，我们需要定期监视它是否能在投入硬币后提供美味的饮料。通过这样做，我们可以及时发现2次及之后的监视不足之处。

还可以加入其他流行的监视方式，如资源监视和HTTP状态监视等（流行的监视方式应该反映了流行的干扰分布）。

如果在0或1情况下发生障碍，应进行再发防止。

鉴于过去的事件有可能会在未来再次发生，为了预防再次发生，可以采取以下三种方法。

3. 加强监控，以捕捉前兆迹象。

在进行修正之后，为了即使修正存在缺陷，也能够通过监视来进行补充。
如果发生了由于内存不足引起的故障，就需要在修复内存不足问题之后，监视内存是否存在不足的可能。

为什么两倍数量会更好，我无法逻辑地解释，但总觉得是这样。
以两倍的成本，可以将修正错误的概率乘以2再平方。

4. 没有征兆的事物，让其产生征兆。

比如说，硬件故障很难捕捉到前兆，所以通过冗余化，使部分故障不会成为障碍而成为障碍的前兆。
对于程序逻辑等方面，可以在出现错误之前添加警告，或者即使出现错误也能勉强正常运行。

具體討論

自己研究的笔记。

ELK 企鹅

能够进行度量、可视化和警报的工具套件。
比如Elasticsearch和Kibana等工具的套件。

由于正在流通的docker-compose无法正常工作，因此我没有尝试过。

Grafana + Prometheus + cAdvisor + Node Exporter

Grafana + Prometheus + cAdvisor + Node Exporter（请提供一个选择的中文表达）

这个组件可以对度量、可视化和警报进行测量。
很好用。
这个Rails组件也很不错。
https://github.com/discourse/prometheus_exporter

prometheus_exporter: prometheusにrailsのメトリクスを送るやつ

https://app.bugsnag.com可以用中文表达为：

可以免费收集和可视化Rails的错误日志。
还可以发送警报。
是直接通过API从Rails发送的。
因为没有使用fluentd等工具，所以集成很容易。

请提供以下中文的同义词句子：

https://uptimerobot.com/

可以免费进行健康检查，还能发送警报。

杂感

我觉得这种方式本身就像是算法。
在外扰分布未知的情况下，如何以低成本使用在线算法构建一个对外扰具有强韧性的系统，这是一个问题。

因为我们本来就是通过充满自制感的操作流程进行运营的，所以我认为障碍发生是因为这个原因。我稍微调查了一下Kubernetes，但是要记住的东西非常多，所以我放弃了。我在考虑如何在不改变整个操作流程的情况下，以最小成本降低障碍发生率。这篇文章让我想起了这个问题。通过监控来构建反馈环路，以及最佳实践对我来说是一个新的发现。