今天为我们解答以上问题的嘉宾，是来自浙江移动的云智能平台运维架构师史军艇老师。希望通过汇集史军艇老师的研究成果和实践经验，带大家了解云原生环境下存在的安全问题，规避云上可能会遇到的问题，保障云原生应用的运行稳定性。
史军艇
浙江移动 云智能中心运维架构师
- 8年应用优化及SRE经验，2013年起从事应用运维、稳定性提升、架构优化等工作；专注于稳定性体系建设及分布式系统架构治理。乐于研究新解决方案及新技术。目前负责浙江移动线上系统应用架构治理和稳定性体系建设工作，并作为浙江移动混沌工程负责人，推动中国移动集团内演练方案实施。
主要观点
个人认为，要解决这些问题，需要从企业层面建设一套的稳定性体系，包括架构设计、上线变更、故障抵御、线上治理，贯穿整个过程。而这其中表达的意思，稳定性不至于故障抵御，更要往前看，从架构设计开端，去做高价值交付。实践过程中，我们衍化出一些有效的工程，比如流量回放、灰度发布、混沌工程、平面逃生等，保障了每一个过程的平稳链接，确保上云风险降到最低。
Q1云原生下，如何权衡线上稳定性和敏态交付?
稳态（稳定性）和敏态，就是我们说的双态模式。我理解应该是敏态催生了云原生，而后云原生又推动了稳定性。正如我们所说，云原生是从传统“原子时代”跨越到“比特时代”的，它的具体表现形式是容器化支撑+微服务体系，配套而生的就是DevOps和持续交付，而这一切确实都是为了核心业务的快速迭代为出发点的。
因此，我们需要稳定性体系/SRE体系来给予运营端足够的信心，浙江移动在稳定性方面确实也摸索了很多年，我们算是传统行业中运维转型走得比较早的。研发眼中是DevOps，我们眼中就是OpsDev，这两者并不冲突。在整个稳定性体系中，除了基本的故障抵御体系外，Ops必须要把步子往前迈，迈过上线发布，迈到架构管控及设计，这样和线上治理组合起来才是一整套交付护航体系。其中涉及到的工程实践，就会用到灰度发布、混沌工程、多可用区之上的自智网络能力等，用此去保证交付质量、上线质量和运行质量。
Q2云环境下的灾备如何进行设计？
我这里主要聊一下应用服务的灾备设计，相信数据库的变化会相对小一点。对于应用架构，云环境下会涉及到复杂的微服务调用，以及容器云平台的计算资源控制管控，另外还有公用依赖的一些公共组件。我们会建议企业做双平面/双可用区设计，这里的平面纵深会比较深，从容器云的管理（mesos、marathon、k8s），还是公共组件、配置中心、注册中心、缓存平台等，当然还包括上层应用，都需要进行双活双平面改造。这样才能在保证流量的前提下，可以在两套不同的环境下精确倒换、逃生。
像资源相对富足的公司，或者说针对核心业务，愿意再多投入一点点资源的，可以再适配一个10%-20%的小平面，用于形成更为完善的逃生能力、发布能力、演练能力。
Q3相比于传统灾备架构，云环境的灾备架构规划会有哪些异同点？
个人觉得传统的灾备主要考虑的是高可用，我们只要关注双机房、实例冗余负载等，相对简单清晰。而如上个问题提到的，云环境下的灾备架构考虑的层次会更深，在传统架构灾备要求的前提下，需要贯通每一层的平面级拆分。另外，因为云环境从实例调用层面的可阅读性会大大降低，所以导致普通的高可用，可能在故障处置上会有一定劣势。建议采用单元化的设计，从流量入口就具备调度能力，做好准确自动的平面逃生，当然该有的观测性等配套要求也会更高。
Q4企业原先生产环境复杂，导致上云迁移和业务重构难度大。对此，有什么可参考的落地步骤和技术路线吗？
研发和SRE两条腿走路，并且要步调一致，一起走。因为大型系统的上云其实是一个非常大的工程，或者是有较大风险的工程。从研发层面，原有的复杂调用，该拆就拆，从设计方案中，去考虑拆分的可行性，而这个时候，SRE就需要一起参与，通过非功能的视角，去进行纸牌推演、沙盘推演，可以和研发互相pk。从工程保障角度，我们要确保割接方案的快速回退，老的环境并行保存等注意事项。新环境在通过纸牌推演后，进入到上线前的实战演练验收，这个时候可以通过回放的流量去模拟验证。在发布工程中，用灰度的滚动发布模式，确保平滑割接过渡。
