多加一个 9 要花的钱
一句话总结
可用性可以忽略不计。问题是每次再加一个9,费用大约每增加一个位数 是奔跑**。所以不是“尽可能安全地”去,而是“需要多少” 必须先确定。
为什么需要这个?
如果把所有的服务都变成相同的可用性,即使是无关紧要的功能也会进行双重化和等待资源。 会过度投资。将中断时间和数据损失对业务造成的损失分为RTO·RPO。 可以比较一下要写多少字,恢复策略的额外费用是否比实际避免的损失更小。
怎么行动
9的意义
| 可用性 | 年度允许中断 | 月度 |
|---|---|---|
| 99% | 约3.65天 | 约7小时 |
| 99.9% | 约8.8小时 | 约43分钟 |
| 99.95% | 约4.4小时 | 约22分钟 |
| 99.99% | 约52分钟 | 约4.3分钟 |
| 99.999% | 约5分钟 | 约26秒 |
99.99%是每年52分钟。如果一次分发停顿5分钟的话,每年分发10次的话 写下全部预算。所以高可用性目标自动无中断部署 要求。设定目标的瞬间就会发生随之而来的事情。
RTO和RPO
| 意思 | 问题 | |
|---|---|---|
| RTO(恢复时间目标) | 多久能再次服务 | 几分钟/小时内恢复? |
| RPO(恢复时间点目标) | 保留到多长时间的数据 | 可以丢失几分钟/小时的数据吗? |
两者是独立的。“10分钟内恢复,但丢失一天的数据”的配置, 也可以设置数据不会丢失1秒钟,但恢复需要6个小时。 每个服务都不同地确定—虽然结算员的RPO应该接近0 推荐的现金可以失去一天的时间。
战略和价值
| 战略 | RTO | RPO | 相对成本 |
|---|---|---|---|
| 备份后恢复 | 数小时~1天 | 备份周期 | 最长 |
| 试点灯 | 数十分钟 | 分秒单位 | 低 |
| 温存 | 数分钟 | 分钟单位 | 中间 |
| 活性-活性 | 几乎0 | 几乎0 | 最贵 |
试点灯是只打开DB复制,其余都关闭的方式。 在紧急情况下关闭其余部分。这是最能体现计量制价格的战略, 与成本相比效果好,在实际工作中经常被选择。
决定的顺序
- 按服务分等级—并非全部都是最高等级。 一般3个阶段就足够了(核心/重要/一般)。
- 将各等级的RTO/RPO定为数字——必须与业务方协商。 中断的话每小时会损失多少钱是依据。
- 选择满足那个数字的最小配置——不是更好,而是足够。
- 进行验证 - 不进行排练的RTO是希望事项。
4号实际上最常被省略。而且在实际故障时,RTO是计划的 会增加3倍。
彩排所揭示的东西
进行恢复训练的话,会出现文档中没有的问题。
- 恢复程序书不是最新的
- 负责人没有必要的权限。
- 有备份,但是找不到加密密钥。
- 依赖服务的恢复顺序没有确定。
- DNS·证书不指向新环境
如果在障碍中发现这个,RTO将无法得到遵守。
成本与平衡
可用性投资额超过预期损失时,就是过度投资。
기대 손실 = 연간 예상 중단 시간 × 시간당 손실
从每小时损失100万韩元的服务,降低到99.99%(年8.8小时)为99.99%(年52分钟)。 安装的话可以节省约8个小时,价格为每年800万韩元,其中构成每年3,000万韩元。 如果认为的话,那就是过度投资。如果认为不是的话,当然应该这样做。
选择快速恢复而不是购买可用性
以“99.99%”为目标的话,通常不会在预算上谈论。增加9个 因为费用不是线性的而是指数性的,所以要决定要买到什么程度,也要一起考虑对方的情况。 要看。
**首先计算停机时间的价值。**每小时的销售额、退出用户、违约金、恢复 增加花费的人的时间。这个数字出来后才知道“双重化每月200万韩元”是否贵。 可以说便宜了。如果计算大多数内部系统的话,**99.9%(每月43分钟)的话 得出“足够”的结论。
如果同样的钱的话,快速恢复的那边一般比较好。 双重化只适用于特定类型的障碍 阻止(设备故障、AZ故障)。实际经历的障碍相当多是错误的部署和设置 是变更,双重化的系统将该变更也同样分发到两边。恢复 5分钟内可以做到的能力覆盖了比双重化更广泛的范围。
**如果没有重新计算过恢复时间,那么那个数字就是希望。从备份恢复需要几分钟 要知道是否被抓住,在其他地区流行需要多长时间才能知道。**一般来说 出现文件中写着的值的二三倍。DNS TTL、下载图像、缓存为空的 状态的第一个流量全部占用时间。
单一障碍点比基础设施更经常出现在人力和程序上。可以恢复那个系统 只有一个人,或者恢复程序只有在那个人的脑海中,或者紧急账户的 没有人知道密码的状态很常见。在使用双重预算之前在工作日白天 最好一个人单独进行一次恢复训练,这样比较有价值。
**不测量可用性的可用性不被管理。**内部的可用性和用户 经历的可用性不同。服务器会退还200,但用户无法看到屏幕的情况 因为存在。即使只设置一个在外面模拟实际用户流动的合成监控, 我们曾经是99.95%,现在距离“我失败了三次”的距离越来越近。
在现场相遇的样子
- 设定“可用性99.99%的目标”,保持手动部署→用部署花掉预算。
- 每天都会备份,但没有尝试过恢复 → RTO未知数。
- 把所有的服务都改为主动-主动→无法承受费用,最终退回。
下次要看的
如何留下这些决定以便后人阅读。