个人认为，要解决这些问题，需要从企业层面建设一套的稳定性体系，包括架构设计、上线变更、故障抵御、线上治理，贯穿整个过程。而这其中表达的意思，稳定性不至于故障抵御，更要往前看，从架构设计开端，去做高价值交付。实践过程中，我们衍化出一些有效的工程，比如流量回放、灰度发布、混沌工程、平面逃生等，保障了每一个过程的平稳链接，确保上云风险降到最低。 

稳态（稳定性）和敏态，就是我们说的双态模式。我理解应该是敏态催生了云原生，而后云原生又推动了稳定性。正如我们所说，云原生是从传统“原子时代”跨越到“比特时代”的，它的具体表现形式是容器化支撑+微服务体系，配套而生的就是DevOps和持续交付，而这一切确实都是为了核心业务的快速迭代为出发点的。

因此，我们需要稳定性体系/SRE体系来给予运营端足够的信心，浙江移动在稳定性方面确实也摸索了很多年，我们算是传统行业中运维转型走得比较早的。研发眼中是DevOps，我们眼中就是OpsDev，这两者并不冲突。在整个稳定性体系中，除了基本的故障抵御体系外，Ops必须要把步子往前迈，迈过上线发布，迈到架构管控及设计，这样和线上治理组合起来才是一整套交付护航体系。其中涉及到的工程实践，就会用到灰度发布、混沌工程、多可用区之上的自智网络能力等，用此去保证交付质量、上线质量和运行质量。

我这里主要聊一下应用服务的灾备设计，相信数据库的变化会相对小一点。对于应用架构，云环境下会涉及到复杂的微服务调用，以及容器云平台的计算资源控制管控，另外还有公用依赖的一些公共组件。我们会建议企业做双平面/双可用区设计，这里的平面纵深会比较深，从容器云的管理（mesos、marathon、k8s），还是公共组件、配置中心、注册中心、缓存平台等，当然还包括上层应用，都需要进行双活双平面改造。这样才能在保证流量的前提下，可以在两套不同的环境下精确倒换、逃生。

像资源相对富足的公司，或者说针对核心业务，愿意再多投入一点点资源的，可以再适配一个10%-20%的小平面，用于形成更为完善的逃生能力、发布能力、演练能力。

个人觉得传统的灾备主要考虑的是高可用，我们只要关注双机房、实例冗余负载等，相对简单清晰。而如上个问题提到的，云环境下的灾备架构考虑的层次会更深，在传统架构灾备要求的前提下，需要贯通每一层的平面级拆分。另外，因为云环境从实例调用层面的可阅读性会大大降低，所以导致普通的高可用，可能在故障处置上会有一定劣势。建议采用单元化的设计，从流量入口就具备调度能力，做好准确自动的平面逃生，当然该有的观测性等配套要求也会更高。