16同行回答
真对最近一段时间内几个重量级的公有云连续出现问题，也谈谈自己的想法。我想从安全角度谈谈我的一点想法：
1、安全要求里有一个观点或者认识，就是安全是相对的，危险是绝对的。所以不论从用户角度还是运营商角度来说都不应该掉以轻心。不论是用户在选择何种公有云的时候，还是运营商在建设和运营以及管理时都应该有这个意识；在用户选择公有云的形式上应该多从可靠性方面予以考虑；运营商从此类故障的出现上也应该认识到不论是建设或者运营还有很多工作要研究，要完善。因此日常建设管理运行工作就必须倍加认真细致。
2、安全里边还有一个最小必须原则。它本意是指“最小特权原则，是指\"应限定网络中每个主体所必须的最小特权，确保可能的事故、错误、网络部件的篡改等原因造成的损失最小\"。”我这里有个想法，可否在公有云之外，在保障数据的基础上（公有云环境下的数据，一般都相对较小），搭建一个最小的，但可以满足必须业务的传统系统应用（测试）环境，在出现类似公有云问题时，可以切换回来，不至于使全系统瘫痪，影响范围这么大。
收起从近期的几个公有云服务故障来看，单独依靠公有云提供的服务确实不靠谱。如果公有云的可靠性得不到保障，那么用户的业务就会中端，所以说靠人不如靠自己，不能总是把自己公司的业务安全完全交付给别人来做，要有应急预案和应对的措施。个人建议通过以下3个措施进行应对，但是这三个方案有利有弊，需要根据实际情况选择。
1、建设自己的私有云，数据先在本地数据中心进行保存，然后再同步上传到公有云上，这样即使公有云出现问题也不会害怕丢失数据。而且公有云出现业务中断，也可以立即将业务切换到私有云上，对外提供服务。
缺点：企业需要自己搭建一套系统，浪费资源。在公有云不能提供服务时，自建的私有云在性能上可能无法满足，影响用户体验。
2、选择多个公有云服务上。部署云灾备，至少选择2家公有云服务上，计算和存储资源都一样，但是平时业务只运行在一个公有云服务商之上，如果一个公有云出现问题，立即切换到另外一个公有云上。
缺点：会增加一套公有云服务成本，两个云之间的数据同步需要购买专业的数据同步产品和服务。
3、在本地建设私有云备份服务器，实时将数据备份至本地数据中心。保证数据不丢失和业务不中断。
缺点：本地增加一套备份系统，但是相对前二个方案，成本增加相对比较小。只建设本地数据备份系统，只能保证数据安全，可能无法及时对外提供服务。
收起说实话，AWS的S3是我见过的可靠性最高的公有云对象存储服务，基于AWS的“Design for Failure”原则S3面向故障恢复做过充分设计的（详细可以去了解一下AWS的7大设计原则）。但这次人为的故障场景确实没有被覆盖，从而导致了大范围服务不可用，后续aws也作出了改进方案（最小资源数、部分重要服务最小化方便快速启动恢复等）。从整个事件的发生和后续处置和改进过程来看，公有云服务持续在各种故障和怀疑声中加速前行。另外，还需要回顾一下公有云中关于基础设施层的两个关键抽象概念：Region区域、Avaliable Zone可用区，区域是一个提供服务一致性的能力抽象；可用区可以理解为就是物理相互隔离的网络、供电等基础设施区域，作为故障隔离的边界。不同的AZ之间相互独立不受影响，而在同一个Region内的不同AZ之间的服务能力是一致的（最关键的是网络延迟很小，这个很重要）。而对于AZ内存储服务基本上都会有高可用的技术方案支持，比如数据多副本、镜像等等。
终于可以跟这个问题有些关系了：）
一、我想说的是为了避免云端存储故障带来的影响，要先问问自己要面对哪种级别的故障，RPO和RTO的需求到底是多少（书面一点叫业务影响分析）。我理解合理利用公有云本身的高可用设计远比跨云做数据容灾来的容易（很多是物理限制，比如AWS到阿里云网络延迟和带宽成本谁解决的了），最简单的就是跨AZ部署自己的应用和数据做到负载均衡，数据跨AZ进行准实时的异步复制、备份都可以；至于跨Region或者跨公有云（AWS到青云、阿里云、企业自己的私有云等）以目前的技术限制都无法实现理想的RPO，也就是说除了问题数据丢的量和恢复时间都无法达到预期。
二、数据的可靠性远大于可用性，就这次AWS S3故障而言只是影响了可用性，没有真正的丢失数据，这已经是很好的结果了。就像墨菲定律说的会出错的总会出错，小到单个企业都会有大大小小的生产事故，更何况大规模运营的公有云。所以，选择提供高数据可靠性的服务商和技术，增加自己在业务架构层面的高可用设计是我认为比较好的方法。所谓业务架构层面高可用设计我觉得除了面向跨AZ进行业务部署和逻辑架构设计，实现水平扩展的分布式架构。
最后，还需要补充业务连续性计划方面的手段，比如应急情况客服安抚、赔偿、挽回声誉等等。因为技术还在不断进步和完善，总有我们预想不到的问题发生，需要我们配以非技术手段应对。
以上是个人观点，逻辑稍乱，请见谅。
收起近几个月GitLab，Amazon S3，微软Azure相继出现丢数据和业务中断的事件，让人们对云服务提供商的数据安全和业务连续性能力提出了质疑。
通过一些列报道，可以了解到Gitlab和Amazon S3的事件多数是人为因素造成，误操作导致的事故发生。不论是云数据中心还是传统数据中心的运维团队，都应该重视数据安全。如何避免操作风险，需要通过制度，工具，人员培养等多方面加以规避。微软Azure事件官方称之为底层存储故障，但从另一层面发现Azure 的系统耦合性过高，Azure 存储故障，导致了例如Azure 媒体服务，缓存服务，搜索服务，数据库，事件中心等等十几个系统不能提供正常服务。
数据安全涵盖的范围很广，数据的备份是防止数据丢失的手段。GitLab做的已经很好，充分理解了不能只通过一种备份手段来保护数据，但是忽略了恢复的有效性，当备份数据需要恢复的时候才发现多份备份均无效，这给很多IT系统运维人员敲响了警钟，定期的恢复验证工作不能流于型式，事关真正灾难发生时是否能够成功恢复。
云环境下资源以共享为主，共享资源的同时，意味着共享了风险。评估资源间的依赖关系，适当地对资源间进行解耦，减少资源的关联风险。对关键资源进行高可用性保护，确保持续运行。资源池化并非范围越大越好，正所谓月满则亏,水满自溢，要设置可控度。
收起云计算大势所趋，相比传统的IT架构，多了灵活性、便利性等收益，减少了运维难度，卸载了自身维护的一些技术难度和风险。相对的，也少了一些可控性。从IAAS PAAS SAAS，越往上层，企业所需的技术储备越少，对it资产的可控性也越来越小。对云计算提供商的依赖性也越来越大。
平时没事还好，一旦出了问题，只能坐等服务商恢复服务。要想避免这种情况，有两条路：
1是倒回去，选择原来的自建架构。有点不现实，但可以梳理自己的应用，分类对待，一些不太重要的it轻应用类可以运行在云上，重要的选择自己维护。
2是在现有的云服务基层上做高可用或灾备，保证一方出了问题的时候，整体业务可以切换。当然，也可以选择自己做私有云或混合云。
收起其实这个是 投入 与 产出 的关系。鱼与熊掌难以兼得。
在IT业没有最好的方案，只有合适的方案。
不管是公有云还是私有云，都是客户或者厂商基于自己的目的或者诉求推出的解决方案。云解决了用户繁琐的选型、招标采购、建设的烦恼，其实其本质没变，机房运维中会出现的痛点、难点还是会存在，一样会宕机、会丢数据。。。
其实还是绕不开冗不冗余的问题，不管是前端、中段、后端，或是前置、中间件、数据库，只要一条线的蚂蚱都是跑不了谁的。
云的优点是基础设施有人给我管，而且通用性好，虚拟化，高可用，最重要是便宜，可是那云服务也分等级，投入和产出基本还是相向而行的。不可能同样的需求，一百万和五百万的服务保障是相同的。
在相同服务等级或质量的情况下，其他的就看的还是自己的设计、维护能力，云服务商给的是资源（比如是房子），怎么用（比如装修风格、买格力空调还是美的）那可就是使用者的问题了。重要的还是要冗余的，不管你是热备冷备，还是双活、单活，言而总之你要以防万一，不要到时万年想不起信息技术的领导打电话找你，你可就happy了。
再新的技术也是有源头的，干IT该干嘛干嘛，哎。。。小王该搬砖了。。。
收起