企业上云之路-如何评估上云风险（读书笔记）

1 如何评估不可预知的云化内容

IT行业经过几十年的发展，对IT应用层面的开发和运维人员而言，已经出现了越来越多的黑盒。在被封装的部分越来越多、使用越来越便利的同时，应用层面的开发和运维人员对黑盒内部的了解也越来越少，设计、实现和交付结果之间的割裂也带来越来越多的“不可预知”的心理压力。

2 确认“不可预知”

IT行业的环境从横向分为三大类 ： 理论研究；场景、技术和框架研发；应用技术开发。纵向可以分为：基础设施；底层软件和框架；应用系统。

	理论研究	场景、技术和框架研发	应用技术开发
应用系统	区块链	以太坊	资产数字化
底层软件和框架	设计模式	微服务	分布式中间件
基础设施	量子计算	量子计算机	量子加密

企业更多关注右上角的业务。云服务厂商关注左下角，尽可能往右上角延伸。

2.1 梳理IT现状

企业上云是一个系统工程，将企业上云的过程视为一个梳理现有状态并进行战略规划的契机，然后投入相应的资源，对企业IT乃至对企业本身而言，其收益都大于投入。

以IaaS和服务器评估为例，说明如何梳理。

假设现状分析：

• 有完备的服务器使用、管理和处理流程，且确保执行––––可控。
• 企业拥有 这些服务器–––––可控。
• 服务器的日常状态有监控和巡检––––可控。
• 使用方为内部人员。––––可控。
• 性能和功能是标准化的。––––可控。
• 服务器出现问题和故障后，一般需要2小时完成处理。–––––不可控。
• 问题解决和故障修复依赖于商业服务，有SLA保障且基本达到要。––––可控。

那么上云后的分析样例：

• 形成云上的服务器使用、管理和处理流程，且确保执行––––可控。
• 企业不再拥有这些服务器。–––––不可控
• 服务器的日常状态有监控和巡检。––––可控。
• 使用方为内部人员。––––可控。
• 性能和功能是标准化的。––––可控。
• 服务器出现问题和故障后，一般需要分钟级完成处理。–––––可控。
• 问题解决和故障修复依赖于商业服务，有SLA保障且基本达到要。––––可控。

2.2 确认企业策略

企业应该基于自身的考虑需要将 不可预知的潜在风险降至最低。分析是一个过程和参考，决策仍然取决于企业的IT策略。在架构设计过程中，这个决策通常称为架构决定。

一个架构决定和一个策略一样，都需要包含如下内容：

• 场景或方案要求，需要解决的问题。
• 干系人或影响范围。
• 可选择的策略的范围。
• 历史策略制定情况。
• 当前策略。
• 当前策略决定的依据。
• 遗留的问题和其他方案补充。
• 下次回顾时间。

3 评估和应用

首先要进行分析。分析应该从如下三大类七个方面进行:

• 内部制度保障。
• 企业对技术本身的拥有、状态监控和使用三类过程。
• 技术的功能/性能、可用/可靠性和售后服务三类保障。

后续进行实践的评估，分为三个主要的步骤：

• POC阶段，相当于理论验证，确认技术符合公司的基本要求。
• 初步应用于小型系统，相当于通过一个真实的场景形成最佳实践，使之成为框架。
• 全面使用，利用上述过程，在企业中对此技术进行全面应用。

3.1 利用云平台的优势

• 弹性伸缩：前期免费试用，后期按量计费模式。
• PaaS服务和SaaS服务：选择适合的版本，优先高版本？价格因素？

3.2 利用最佳实践

如果只是苍白无力地介绍云服务产品的能力，说明其并没有很好的应用场景或最佳实践。相似的应用场景会给客户的评估带来更多的便利，即使这意味着客户要调整技术栈，但因为应用场景的相似性，也会让客户发现技术的潜在收益。

在用户对某项技术带来的不可预知性进行评估的过程中，如果有机会了解使用这些技术的最佳实践，将有助于他们做出决定，以便 更好地面对这种不可预知性。可行的途径包括：

• 与云服务商进行接触，了解和询问自己关心的不可预知性的解决途径。
• 与使用者进行接触，确认类似场景下对方的使用和处理方式。
• 与使用和评估过类似技术的技术人员接触，从而了解潜在的问题可能和处理方案。

3.3 模式降级

技术组合可以解决一些单一技术无法解决的场景，常用的方式就是模式降级，即：

• 在SaaS服务不合意的情况下使用PaaS搭建。
• 在PaaS服务不合意的情况下使用IaaS搭建。
• 在IaaS服务不合意的情况下使用混合云对接。
• 在单个产品不合意的情况下进行产品组合。

以OCR服务为例，如果现在有一个ORC需求，典型的方式是:

• 如果云服务商有现成的服务，那么直接使用。
• 如果没有现成服务，有定制服务，那么进行验证。
• 如果没有定制服务，可以使用人工智能PaaS服务。
• 如果人工智能PaaS服务不能解决，可以使用GPU服务器自建OCR。
• 极端情况下，用混合云对接自有机房，在机房内用传统方式实现需求。

3.4 基于适配器和组合模式

借鉴设计模式种的适配器和组合模式来面对不可预知的技术平台风险。

• 适配器模式：用一个已知的技术栈封装一个不可预知的技术/服务，将其转化为一个可预知技术来使用。
• 组合模式：自行开发和补充相关的能力，对不可预知的部分进行二次封装，规避可能的问题。

4 动态的不可预知性––––未来发展

• 租用/使用/计费价格变化
• 版本升级/放弃现有版本
• SaaS服务是否会忽然终止服务

如果企业使用的SaaS服务是在关键场景下的，那么定期对供应商进行评估是一种可行的策略。包括

• 形成自动化测试的脚本，定期进行自动化测试。

• 主备或者双活就绪，可以快速进行供应商切换。

• 每年进行供应商服务质量评估。

• 通过Adapter等方式，降低供应商接口调整或更换供应商带来的系统改造成本。

5 异化过程的心理保障

一般情况下，但云服务的使用能显著提升效益时，企业愿意冒险，但大部分企业的倾向是规避风险，哪怕会降低收益。

理论上的分析应该让位于实际的业务实践，如果实际情况不能坐定量分析，也无法给出绝对明确的策略。在适当的情况下，做一些反常规的测试、验证，而不是拘泥于某种行为习惯，有助于企业文化的改善，也能提供更多创新和发展的可能性。

6 商业过程

面对不可预知的风险时，一个必要的关注点是相关服务的商业化过程。包括产品的商业化和服务的商业化。

越是敢于提供内部实现架构的从，也就越表明此产品的成熟度足够高。

降低不可预知风险的另一种方式是购买相关的服务。通过服务合同的方式，将风险转嫁给服务商，从而在遇到未知问题的情况下，获得专业人员的服务。

7 加强“不可预知”的预知性

• 持续监控
• 控制版本
• 保持沟通

越强大的武器，学习曲线也越陡峭，越零依赖的产品，未来越有被替代的风险。上云是一个复杂的系统工程，风险极大，风险大也很多。企业经常面临两难的局面，不上云，很多问题似乎难以解决；上云之后解决了不少问题，但是上云过程中、上云后”系统地“引入大量新的问题，比如经典的”自主可控“。我们不应畏惧风险，关键是要将风险控制在一定的范围内。