「云采用框架和登陆区域」
Cloud Adoption Framework
& Landing Zone
在给出定义之前，我们可以先想一下为什么会出现这两个概念？为什么需要去学习和掌握它们？首先，列举三个典型的客户场景：
1） 怎么从 IDC 快速迁移到共有云（Azure）？最佳实践是怎么样的？
2） 由于安全的黑天鹅事件和监管的进一步要求，公司新招了信息安全官来进一步加强安全管控。现有环境的资源和权限没有统筹安排，信息安全官到岗之后，不知道从哪里下手。怎么让他能够快速有效实施安全管控？
3） 上云把所有的资源都放到一个订阅里面，随着业务的增长，发现一些订阅的资源数达到了上限，没有办法再添加新资源。拆开的话，发现服务之间的依赖关系错综复杂，短时间内没有信心能处理好。有没有什么办法来应对？
除了上述需求之外，现状是云原生技术的成熟度和接受度的进一步提升，人们对公有云的使用也更加深入和多元化：
1） 虚拟化技术等技术上公有云与本地数据中心差别不大，但是在计费和安全方面有着很大的差别，怎么能够进一步用好公有云？
2） 在公有云上部署的业务越来越多，使用的技术栈越来越复杂多样，在治理和管理模式上也和本地数据中心的侧重点有很多不同，给开发运维人员带来了进一步的挑战。能否有整体架构设计和工具帮助他们越过这个鸿沟？
3） DevOps 技术进一步推广和落地。人们不再仅限于代码和配置版本管理，Infrastrure as code 或者 Infrastrure as config 的需求日益增加，Azure 提供了哪些支持？
4） 多云战略和混合云战略是绕不开的话题，这种情况下怎么去实施有效的治理和管理？
带着这些问题，让我们一起看看什么是云采用框架（Cloud Adoption Framework）、什么是登陆区域（Landing Zone），针对这些问题和挑战，它又给出了什么答案？
根据微软官方文档给出的解释，云采用框架（Cloud Adoption Framework）是一系列的文档、实施指南、最佳实践和工具的集合，都是微软经过验证的最佳实践，旨在加速客户云采用之旅，在 Azure 的体验。
根据这一介绍，我们来进一步学习和探讨它的六个阶段、五个原则和八个设计域。
云采用框架
Cloud Adoption Framework
☁️
六个阶段
1） 定义战略（Define strategy）
2） 计划（Plan）
3） 准备（Ready）
4） 采用（Adopt）
5） 治理（Govern）
6） 管理（Manage）
通过下图，可以看到具体每个阶段的任务细项。
☁️
五个设计原则
1） 订阅民主化
Subscription Democratisation
它表达的意思是订阅应该用作与业务需求和优先级相一致的管理和规模单位，避免维护订阅创建的集中控制，并允许业务部门自己创建订阅。治理模型应确保在创建订阅并将其移动到不同的管理组时，应用策略来强制实施任何必要的防护措施。
在现实中，有很多客户把很多负载都糅杂在一个订阅中，甚至开发测试和生产的内容都在一个订阅中，这给后期的扩展和维护来了很多潜在的风险。
2） 策略驱动治理
Policy Driven Governance
在Azure上，Azure Policy 提供“护栏”的作用，确保平台和部署在其上的应用程序的合规性，同时还为应用程序所有者提供足够的自由和安全畅通无阻的使用体验。
通过在引入平台和行业内置的策略的基础之上，逐步总结和整理出适合自己公司组合架构和文化的策略集合。也可以从日常运维过程中的人为错误中总结出来这些策略，保证以后不会出现同样的问题。
3） 单一的控制和管理平面
Single Control and Management Plane
企业级架构不应依赖于客户开发的门户或工具等抽象层，应为 AppOps（集中管理的运营团队）和 DevOps（专门的应用运营团队）提供一致的体验。同时把这种非功能性需求在公司层面集中处理，让业务开发人员更加专注于自己的业务，不用为网络，安全等非功能需求分担过多的精力。
4） 应用中心化和原型中立
Application Centric and Archetype-Neutral
结合自身的业务和成本等考量，选择合适的技术栈。劲量保证新开发的应用和遗留的应用保持一套技术体系，减少开发和运维的复杂度。在迁移的过程中不是纯粹的基础设施“lift and shift”式迁移（即虚拟机的移动）。尽量考虑云原生的一些技术来享受这些技术红利。
5） Azure 原生设计和与平台路线图对齐
Azure Native Design and Platform Roadmap Alignment
因为共有云本身也是一个不停在演进的平台。随着新技术和新功能的发布，公司层面也要对自身的一些架构做相应的调整保持和平台路线一致，以确保在客户云环境是最安全和最经济的状态。
03
八个设计领域
1） 企业注册 Enterprise enrolment
企业协议注册代表微软与客户组织如何使用 Azure 之间的商业关系。它为所有订阅提供计费基础并影响数字资产的管理。
通过 Azure 企业门户管理企业协议注册。注册通常代表组织的层次结构，其中包括部门、帐户和订阅。形成一套适合公司的计费和运营的层级架构是很有重要的。
2） 身份 Identity
Azure AD 租户提供身份和访问管理，这是安全的重要组成部分。企业级的身份和访问管理解决 Azure 控制平面、数据平面和应用程序层的要求。
从 Azure 平台和 Azure Active Directory 开始规划身份和访问管理。在公有云上身份是安全的第一道保障， 这是对传统网络安全关注的转变。
网络边界越来越多，边界防御无法像 BYOD 设备和云应用程序爆炸之前那样有效。企业级建议侧重于定义与客户运营模式相一致的基于角色的最低特权访问控制角色，并利用 Azure 功能应用额外的访问控制层。
3） 资源组织 Resource organization
及时准备适当的资源组织是云治理的一个非常重要的环节。这包括命名 (naming)、标记 (tagging)、订阅、资源组和管理组 (management group)等内容。只有好的设计后面的治理和管理才会更容易。在实际工作中大家对资源组和资源是比较熟悉的，但是对管理组和订阅的概念和使用可能还有些欠缺和偏差。
Azure AD 租户中，管理组有助于支持组织映射。在计划大规模采用 Azure 时必须加以考虑。管理组可用于聚合策略 (policy)和方略分配。管理组树最多可支持六个深度级别，此限制不包括根级别或订阅级别。
订阅是 Azure 中的一个管理、计费和规模单位。我们应该配置订阅配额和容量以限制 Azure 平台内的服务成本，并在选定的 Azure 区域中配置所需 SKU 的可用性。
4） 网络拓扑与连接
Network Topology & Connectivity
网络拓扑和连接性是开始构建环境前必须仔细考虑的两个因素。在弄明白流量是如何在云中连接以及如何获得访问权限之前，不能说自己在正确使用云。
企业级网络拓扑和连接解决企业 Azure 资产中的所有登陆区域建立端到端连接的需求。这个主题既广泛又复杂，可能会占用整个设计工作的很大一部分。确保了解所有设计领域和企业级建议、常见的替代解决方案以及偏离建议的影响，这对于成功交付至关重要。
5） 业务连续性和灾难恢复
Business continuity and disaster recovery
制定业务连续性和灾难恢复计划对于组织至关重要，因为它有助于组织在发生意外中断或灾难后恢复工作所需的时间。
组织需要定义其恢复时间目标 (RTO)，即组织基础设施恢复所需的时间，以及衡量应用程序和数据可用性中断或灾难后数据丢失量的恢复点目标 (RPO) 在其 BCDR 计划的规划阶段。
根据 RTO 和 RPO 要求，应用程序和数据可用性要求因组织而异。Microsoft Azure Backup服务和 Azure Site Recovery 服务都构成了 Azure 中的业务连续性和灾难恢复解决方案。
6） 治理规则 Governance disciplines
治理规则确定支持云监管、合规性审核和自动化所需的工具和方针。在设计和实施每个登陆区域之前，确定要包含的治理规则，以便尽早开始治理、安全基线和合规策略。
7） 部署选项 Deployment options
可以采用不同的方法在云采用框架中实现登陆区域。组织的正确方法是支持业务应用程序所需的服务，不需要增加额外的管理开销。Azure 为登陆区域提供了两种实现选项：
从小规模开始，然后进行扩展
企业规模 (Enterprise Scale)
8） 操作基线 Operations Baseline
操作基线包括可见性、操作合规性和保护/恢复流程等，为运营管理提供了初始基础。随着运营规模的增长，这些改进将重构登陆区域，以满足不断增长的卓越运营、可靠性和性能要求。
相信大家看完这一堆东西之后，对云采用框架有了一个全面的认识，但是可能同时觉得它太复杂，不知道从哪里下手或者已经失去信心和耐心了。但若您耐心读完《干货丨必须知道的云采用框架和登录区域那些事（二）》，说不定有意外的收获。
💡
精彩未完待续...
请期待下回分解
云原生技术
往期文章一览
作者简历
胡强辉
微软高级云方案架构师
多年从事金融、保险及零售等行业的架构设计和研发工作，并对 DevOps，云原生，大数据等有丰富的架构设计与开发经验。
点击「阅读原文」
免费获取微软案例集 充充电💡
