在任何项目中，迟早都应该努力提高服务的稳定性/可用性。 对于某些服务，在初始阶段，功能开发的速度更为重要，此刻，团队还没有完全组建，并且对技术的选择不是很仔细。 对于其他服务（通常是技术性b2b），为了获得客户的信任，首次公开发行时需要较长的正常运行时间。 但是，假设X到达的那一刻，您开始关心在报告期内服务“处于”状态的时间。 在削减的基础上，我建议您查看停机的全部原因以及如何最好地减少停机时间。
指标
显然，在改善某些功能之前，您需要了解当前的状态。 因此，如果我们开始减少停机时间，则首先需要开始进行测量。
我们不会在这里详细讨论如何具体执行此操作，以及不同方法的优缺点，但是论文过程看起来像这样：
- 我们依靠接近业务的指标（服务错误，服务响应时间，$ /秒，注册/秒等）
- 确定什么是好是坏
- 过渡好->坏是事件的开始
- 过渡不良->良好-事件结束
- 从开始到结束的时间-事件发生的持续时间（上限为我们）
- 事件发生期间的总和（月/季度/年）-停机时间
- （100-<停机时间> / <期间持续时间> * 100）=该期间的可用性百分比
在谈论正常运行时间/停机时间时，他们经常提到另一个指标：
MTTR （平均修复时间）-从事件开始到结束的平均时间。
他的问题从缩写中的第一个词开始。 鉴于所有事件均不同，因此平均持续时间无法告诉我们有关系统的任何信息。
这次我们将不会平均任何事情，而只是看看事件发生了什么。
事故的解剖
让我们看看在事件期间可以区分哪些重要步骤：
- 检测 -在服务员收到短信之前我们给用户的第一个错误之间的时间间隔
- 反应 -从收到有关问题的通知到某人开始解决此问题的那一刻（通常在那一刻，监视事件已转换为“已确认”状态）
- 调查 -从开始研究问题到了解事件原因的那一刻，我们知道恢复工作需要做什么。
- 消除 -恢复时间，例如回滚发布，提升了新的
主人 主数据库服务器
也许我们的模型是不完整的，并且还有其他一些阶段，但是我建议仅在意识到这将在实践中对我们有帮助的情况下介绍它们。 同时，请更详细地考虑每个阶段。
侦测
为什么我们花时间寻找紧急情况？ 为什么不就用户收到的第一个错误发送通知？ 实际上，我知道许多尝试这样做的公司，但几个小时后他们放弃了这个想法，为此他们收到了数十条SMS。 我认为没有一个或多或少的大型服务没有恒定的“后台”错误流。 并非所有这些都表明已发生故障，软件中还有错误，从表单获取的无效数据以及验证不足等。
结果，超过每日波动的错误级别（或其他度量标准）被用作打开事件的标准。 这正是导致以下事实的事实：负责任员工的通知晚于问题的实际发作。
但是回到我们原来的任务-减少事件持续时间。 如何缩短检测时间？ 通知更快？ 提出用于检测异常的超级逻辑？
我建议不做任何事情，而要看下一个阶段，因为实际上它们是相互联系的。
反应
在这里，我们有一个纯粹的人为因素。 我们假设监视能够检测到问题，并且我们成功唤醒了值班的工程师（整个升级在上一阶段也已完成）。
考虑到“最糟糕”的情况，我们没有专门的值班服务，并且警报捕获了安眠的管理员。 他的行为：
- 回复短信：这里，一个耳朵敏感的妻子可以为电话提供多种多样的帮助，从而增强接收短信的效果（1-5分钟）
- 做出一个决定，尽管如此，他还是会爬下床：如果没有正确设置警报，那么一个人可以等待2分钟“如果解决了，那会怎样？” 入睡（1-15分钟）
- 进入笔记本电脑，睁开眼睛，醒来，进入监视状态，按Ack：（1-15分钟）
结果，在最坏的情况下，我们得到35分钟的反应。 根据我的观察，这样的反应时间似乎是正确的。
由于在此阶段我们正在与人打交道，因此我们必须非常谨慎和周到地采取行动。 在任何情况下，您都无需编写规则，刚醒来的人应该根据该规则移动！ 让我们创建条件。
让我们摆脱工程师对问题是否会自行解决的怀疑。 这样做非常简单： 使警报条件对次要问题不敏感，并通知事件是否持续了很长时间 。 是的，我们只是增加了“检测”阶段的持续时间，但让我们看一个示例：
- 将检测时间增加5分钟
- 事件的数量减少了：所有短暂的错误突发通常在1分钟之内。 这些短事件必须记录下来，但不通知他人。 通常，它们总共会造成很大的停机时间，但是您可以在工作时间内处理它们。 对于此任务，由于问题已经结束，并且监视工具在大多数情况下不会保留历史记录，因此您需要在监视方面具有较高的粒度。
- 如果一个人被迫每月或更短的时间而不是隔天一次对警报进行响应，则他将对警报做出更充分的响应，而不是将其视为常规
- 延迟通知使一个人不去想：如果SMS到达，那么一切都是认真的，不会自行纠正。
这种方法可能会将总反应时间减少15分钟以上。 如果这样的反应时间不适合您，您应该考虑值勤服务。
调查中
当您需要了解正在发生的事情和应该做什么时，这可能是事故中最困难的阶段。 实际上，此阶段通常与采取措施的阶段相结合，因为通常该过程如下：
- 我们查看监视，日志（如果监视还不够），我们启动其他一些诊断工具
- 提出假设
- 我们通过度量标准或通过执行某些操作来检验假设（重新启动所有内容：）
- 评估变更结果
- 如果您对特定子系统的了解还不够，请与同事进行交流
直到启蒙运动或事件结束为止。
此阶段通常是事件总持续时间中最重要的阶段。 如何减少呢？
这里的一切不是很清楚，有几个向量：
- 简化您的基础架构 ：想象拥有一个数据库和一个服务的人崩溃的速度有多快
- 在团队中传播知识 ：如果在事件发生期间而不是在日常工作中进行人际交流，则是理想的选择（人际交流通常是一个漫长的过程）
- 监视 ：许多人认为监视仅在“检测”阶段起作用，但实际上它可以充当假设检验过程的优化（“数据库是否正常工作？”，“我的服务是否运行到资源中？”）并且还可以作为传输工具在团队中传播知识。 “ Serge，检查X日志中是否有关于死锁的错误？” 可以变成触发器，触发器的描述将是带有说明的Wiki链接 。
消除
就像我上面说的，这个阶段经常与上一个阶段合并。 但是，发生这种情况的原因很明显，但是恢复将非常漫长。 例如，您有一台服务器死于 主人 主数据库（很长一段时间我都无法适应它：），而且您从未升级过副本，也就是说，您将阅读文档，推出新的应用程序配置等。
自然，在每个重大事件之后，您都需要弄清楚如何防止这种情况再次发生或极大地加快恢复速度。 但是，让我们看看我们可以尝试主动制定哪些方向：
- 基础结构管理工具 ：如果要修复所有问题，则需要推出新的配置，但这至少需要20分钟才能完成-这是您的限制。 尝试提出可能发生的情况以及紧急加速某些过程的方法。 例如，在ansible中，您将serial（任务执行并行度）设置为3，但是如果您仍然撒谎，则可以使用serial = 30滚动，您需要教大家如何重新定义它（类似于kubernetes中的滚动更新策略）。
- 演练 ：如果您知道失败和恢复的可能情况不是自动化的，则应具有必须经过测试的说明 。 计划停机时间（如有必要），进行练习。 通常，在这种情况下，这种情况是自动化的，因为乍一看，即使是最复杂的程序，大多数陷阱也会在练习中得到澄清。
- 与承包商的互动 ：您应该事先知道如果托管服务提供商生病了该怎么办。 通常，对问题可能性和风险消除成本的认识会得出以下结论：“我们将等待恢复。” 但另一方面，工程师和企业将为这种情况做好准备。 例如，您可以解决将流量切换到预先准备的存根，用预先准备的字母通知用户等问题。 反之亦然，您将根据指令给主机提供30分钟的恢复时间，然后我们开始移至另一个DC，该DC已存在数据库的副本，但您需要扩展其他所有内容。 再说一次，这些教导，我们记下了移动的时间，等等。
MTBF（平均无故障时间）
正常运行时间讨论中提到的另一个常见指标。 再一次，我建议不要平均任何东西，而只是谈论在一个时间间隔内发生的事件数。
最重要的问题是您已经在多大程度上照顾了服务的容错能力：
- 基础架构中是否存在单点故障（SPOF），发生故障的概率是多少？
- 您对没有不知道的SPOF有多自信？ （这正是混沌猴子解决的问题）
- 负载均衡器工作正常吗？ （ 我的平衡报告 ）
- 网络的弹性如何？
- 数据中心的可靠性如何？
有时，为了计算/预测所有这些情况，他们会制作一个“风险图”，其中每种情况（我们可以假设，当然总会有一些我们尚不知道的情况）具有概率+影响力（短/长停机时间，数据丢失，声誉损失）等）。 然后，他们系统地处理此类卡片，首先关闭影响方面非常可能且严重的场景。
可以使用的另一种技术是过去事件的分类。 现在有很多谈论，写“事后调查”事件非常有用，它可以分析问题的原因，人们的行为，并找出可能的未来行为。 但是为了快速查看过去一段时间内所有事故的原因，可以方便地根据“问题类别”对事故的持续时间进行归类，并在停机时间最多的地方采取措施：
- 人为错误 ：减少生产中的手动操作次数，防止操作员错误的各种保护措施
- 发布不成功 ：值得改进测试（包括负载测试）
- 应用程序错误 ：修复泄漏，崩溃和其他冻结
- 网络 ：购买设备，设置，雇用网络服务商，更换承包商
- 数据库 ：雇用DBA，注意容错，购买更好的硬件
- DC ：考虑备份或重定位
- 外部影响 （ddos，阻止，证书审阅，域）：购买antiddos，代理中的库存，监视域/证书的有效性，具有来自不同CA的多个证书。
也就是说，如果您甚至不尝试预测问题的可能情况，那么绝对值得处理已发生的事件。
合计
所有事件均不同：
用于增加正常运行时间的算法与任何其他优化方法非常相似：
-> -> ->
根据我自己的经验，我可以说，对于正常运行时间的显着改善，仅要开始进行跟踪并分析事故原因就足够了。 通常，最简单的更改会带来最大的影响。
我们的监控服务不仅有助于“检测”阶段，而且还大大减少了“调查”（客户会确认）