吃了下昨天 aws 的瓜，感觉大家都还挺宽容的，没有说 aws 什么，按理来说，这么长时间的故障以及影响范围，应该和平常说阿里云草台班子一样的力度。 大家觉得是不是真的有滤镜
 |
101
HTravel 6 天前
@untitledabc 每增加一个小数点的可用性，成本是线性增长的。单设备/单中心是 99%可靠性，那两台就是 99.99%，3 台就是 99.9999%。所以架构设计有银弹。
选主可以分场景，可以不发生脑裂的那些场景，全自动化。其余的，全部人工操作。因为大型服务，本就会配置 7x24 小时运维人员（至于小型服务，本就不重要，那就低成本放在一个区呗，挂一天就一天呗）。遇到某区故障了，各区运维人员此时就是上帝，站在上帝视角互相打个视频电话确认下切换到哪个区，然后手动切换即可。也就是说，最多也就是只有 10 分钟的服务不可用。像去年的 CrowdStrike 大规模蓝屏事件，导致机场电脑全罢工，航班全部取消了 1 天。如果只是停摆 10 分钟，几乎可以说对所有航班没影响。 另外，真正重要的大型服务，自动扩所容完全可以去掉（而且数据库这种真正存数据的持久性核心，压根也没见谁敢自动扩所容）。反正我以前做的某全国性的大型基础设施，都是建设时就配置好最大容量，压根不自动扩容。真需要扩容了怎么办，机房再建一套更大规模的，然后在凌晨把数据和服务割接过去即可。概念和操作简单到极点。 说白了就是，各种微服务以及由此带起来的各种自动化部署、管理、运维等概念和基础设施，完全可以不用。 |
 |
102
untitledabc 5 天前
@HTravel 开心就好，你这适合玩传统行业，运营商/银行都这么玩的。用不用微服务那是业务决定的，技术靠后，你这种玩法都不是云的目标用户，真的。
|
|
103
HTravel 5 天前
@untitledabc 你这评价标准就有问题啊。技术是否领先，要看构建出的应用的可用性是能达到几个 9 的。不能因为你的技术方案完美符合云服务原生要求，虽然它每年崩溃几十次（按外网统计的国外那几个云基础设施的公开记录），但依然更领先😂
|
Select Language