一位架构师发现，产品的一部分需要在79%的时间内可用。那么，如何才能达到这个要求呢？
什么影响系统可用性？
- 系统中的改变更新了一个版本，得到了一个回归。
- 动力学问题DB的HDD过载。
- 运行系统的基础架构或平台的问题数据中心的电源被切断。
回到这个问题-如何满足产品部分的79%可用性要求？请勿在此可用性窗口期间更新此部件。这在我们的情况下很容易，因为它很少每天使用超过5小时。如果我们需要99.999%的可用性怎么办？金丝雀和蓝绿部署模型允许更新（和回滚），宕机时间几乎为零-但在这种情况下我们不需要这样。
投资DevOps和可观察性。它们有助于最大限度地减少动态问题的影响。
设计系统时要考虑基础设施和平台的可用性。公共云声明了它们旨在达到的可用性目标。
你可以无休止地优化，但在某些时候，你必须满足于“足够好”。如果一颗小行星摧毁地球会怎样？让我们使用火星上的数据中心。你的用户将生活在哪个星球上？如果AWS关闭了，让我们也部署到Azure。当AWS关闭时，一半的互联网都关闭了。一半的互联网都断了，但我们的产品还在工作。这是胜利还是无意义？
️在低可用性期间使用产品的用户的信任度如何？低可用性周期并不意味着系统在此期间总是中断。他们只是意味着不可用的成本对企业来说接近于零。由于不可用而引起的用户投诉数量将被有关支持粗鲁的投诉数量所超过。试着在凌晨4点在网上订购食物。
️如果我们不知道我们的基础设施/平台的可用性，如何满足可用性要求？不会吧
您如何满足可用性要求？
网友热评：
1、我曾作为一名承包商在政府系统上工作过，只需要每天工作9小时，精确到分钟。下午01点到早上7点59分的任何停电都是完全正常的。
一个温和的提醒，无限可扩展和超可用的云环境并不代表整个行业。
2、想象你是个建筑设计师，要盖一栋大楼。如果画图纸的时候，你光想着把房子盖得漂亮，却忘了设计消防通道和电梯（这就是没考虑"可用性"）。等大楼都住满人了，突然发现："糟糕！没地方装电梯了！"
这时候就尴尬了：
- 住户天天催你："我们要用电梯！"（业务不让停）
- 但你又不能把整栋楼拆了重盖（不能大改）
- 只能像打补丁一样，在外墙勉强加个观光电梯（只能小块小块改）
- 最要命的是，住户说："我们还要正常生活，不能让你把整栋楼停电77天来施工！"
所以啊，就像建房子要先设计好楼梯一样，做软件系统一开始就要把"随时能用"这个特性设计进去。不然等系统上线后再修修补补，就像给行驶中的汽车换轮胎——既危险又麻烦！