企业云的应用

随着云计算的广泛采用，企业变得比以往更具活力。如今，许多公司的业务正在向云计算迁移。选择云提供商几乎总是确保长期供应商锁定。无论是工程师很难对应用层进行适当的抽象和概括，或者应用程序数据的大小使得迁移变得困难，所以迁移到基于云计算的系统是一项非常具有挑战性的任务。在从本地数据中心上的自托管系统迁移到云中时，应考虑以下挑战（ydotpub）。

（1）不当的抽象

在新环境中抽象失败是向云迁移过程中面临的最大挑战之一。通常，应用程序的体系结构取决于其下面的一些本地化API。这在大规模运行的系统中特别常见，因为特定的问题只能在一定的规模中才能看得见。工程团队经常使用一些类似黑客的程序和补丁来修复系统，但是黑客会在系统迁移过程中进行攻击。定期代码审核在一定程度上有助于减轻这些问题。

（2）部署过程中的差异

所有的现代持续集成和持续交付(CI/CD平台都支持多个云提供商，但这还不够。具有复杂设置和启动过程的应用程序通常需要人工干预部署。近几年来，这一点通过使用Puppet，Chef和Ansible等工具在很大程度上可以实现自动化。但是这种自动化通常与供应商特定的API联系在一起，这些API需要配置，监控和拆卸服务器。但是，除非工程团队花时间自己构建，否则这些API不适合小型的本地数据中心（ydotpub）。

（3）重新架构

现代应用程序分布在多个不同区域的多个数据中心。这是迁移到基于云计算的部署的主要好处之一。企业正在逐渐从单一的应用程序基础转变为基于微服务的方法。一个本地数据中心迁移到多地点部署需要适当地重新构建应用程序。这意味着除了开发新版本之外，工程团队还必须关心现有的安装情况。迁移系统的关键部分经常会导致停机，新的部署仍然不能保证在首次运行中取得成功。建议在出现问题时对原有部署进行故障切换，以防出错。大型迁移可能需要几个月的时间才能完成，并可能需要额外的员工来完成。

（4）传输大量的数据

想象一下，必须将移动社交应用Instagram的业务从AWS云平台迁移到微软Azure云平台上。传输这些海量的图像本身就是一项艰巨的任务。认为有时最好的措施是物理运送数据，而不是将数据上传到云计算提供商，这种行为并不疯狂。这两种策略都经过多年的分析，行业仍然没有确定哪个策略才是正确的做法。这个问题不是取决于正在迁移的系统的类型，因此不能通过仅仅改变架构来缓解。一些企业从一开始就选择使用云存储，即使涉及到基于本地数据中心的部署。当数据不太活跃或者不需要立即处理时，这种方法特别普遍。Amazon S3存储已经成为许多企业多年来的可靠存储解决方案，并且一直是这一领域的领跑者。

如今的许多企业都喜欢快速收购和出售市场型的初创公司。迁移到云端或从一个提供商转换到另一个提供商是这类业务的非常普遍的任务。通常情况下，需要使用当前的一套应用程序来制作新获得的应用程序。有时，新产品转移到新的云计算提供商或从云端迁移到自我托管的设置，以利用已经购买的合同或硬件，就像Instagram迁移到Facebook的数据中心，这实质上形成了Facebook的私有云平台。

无论是什么原因，迁移到基于云计算的系统是许多组织的必要条件。最好是以一种与供应商无关的方式编写应用程序，并在适当的地方进行适当的抽象，以便缩短可能长达几个月的考验过程。

企 业 上 云

企业“上云”计划

“企业上云”是指企业通过高速互联网络，将企业的基础系统、业务、平台部署到云端，利用网络便捷地获取计算、存储、数据、应用等服务，有利于降低企业信息化建设成本，构建工业互联网创新发展生态，促进实现制造业全过程、全产业链和产品全生命周期的优化，提升制造业与互联网融合发展水平。

“企业上云”步骤主要分为上云前的规划、设计，上云的实施以及上云后的验证和维护。具体“企业上云”流程如下：

1 上云规划

1、信息收集

“企业上云”需要进行严谨细致的调研工作，需要收集硬件及网络环境信息、现有及将来可能增加的业务各类需求、系统配置信息、应用系统信息、数据风险等。

2、需求评估

从业务需求的角度分析各业务的目前现状、存在的问题、是否可以云化、业务未来的发展需求，定制对各个业务系统迁移的目标。

从系统的角度分析各系统的目前现状，包括了主机、存储、网络及安全，分析系统存在的问题，根据评估结果进行规划。

从企业自身信息化水平的角度进行分析。对于有信息化基础并拥有信息系统硬件环境、维护开发队伍的企业，可根据企业发展规划，逐步进行新、老系统迁移。对于无信息化基础企业，以企业迫切需解决问题为导向，加快相关应用上线。

3、应用分析

应用分析是成功上云，降低业务停滞时间的关键。根据业务的负载、特性、复杂性、关联性分析确定并量化业务上云风险可能对业务造成的影响及损失，以确定业务上云的优先分批范围及上云策略。

4、风险分析

根据收集到的相关信息对目前系统进行业务上云的风险分析，分析各种潜在危险并针对可能发生的危险事件，采取相应措施。

5、上云策略

“企业上云”策略可遵循：统筹规划、分步实施、由易而难、由简单到复杂。一般顺序：（1）独立应用的系统，如邮件系统、合同系统；（2）应用堆叠的应用系统，如办公OA；（3）存在业务依赖的系统，如CRM、ERP、MES系统；

2 上云设计

1、上云计划

企业现有的信息系统分为业务高度依赖型、业务依赖型和非业务依赖型三类：

（1）7*24小时业务高度依赖的生产系统，迁移只能在线时间，迁移策略为：“在线迁移”；

（2）非7*24小时业务依赖的生产系统，迁移时可以接受一定的离线实现时间，迁移策略为：“离线迁移”；

（3）非业务依赖性的生产系统迁移可接受较长的离线时间，迁移策略是“分批次迁移”。

根据以上原则，综合考虑各应用系统及相关设备的调研分析情况，制定出详细的上云计划。

2、方案设计

方案包括：上云实施方案、应用上云方案、数据同步方案、上云回退方案等。

3 上云实施

1、模拟上云

正式上云前模拟一个批次的业务迁移（非正式迁移，业务不割接）。验证业务迁移的及时有效和正确率；针对模拟过程发现各类问题进行修正；改进业务迁移的流程和工作手册，以满足业务的实际需要。

2、系统测试

模拟上云完成后对模拟上云的业务进行一次系统测试，以确定业务迁移到云环境中后能够满足业务需求。

（1）性能测试，包括：上云后系统的应用性能测试；上云后系统的网络性能测试；上云后系统软件版本性能测试等。

（2）压力测试，包括：对上云后系统进行压力测试，并取得关键性能指标达到设计目标；从分支机构发起执行版本验证测试及必要的压力测试等。

（3）业务功能，包括：上云后系统与老系统的连接测试；对上云后系统运行批处理测试；完成数据同步后，执行批处理测试；完成数据同步后，从分支机构发起执行高风险业务功能的测试等；

（4）系统连接性测试，包括：上云后对外围系统，进行全面的连接测试；发现问题，提出整改目标；上云后系统与网络的连接测试等。

3、数据备份

正式上云前，为确保业务数据的完整性、降低上云风险，需要将业务系统及数据进行备份，为提高抗风险能力，建议采用多种备份方式、多分备份数据的方式对业务系统及数据进行备份。

4、上云部署

根据确定的业务上云方案，实施业务上云；根据业务上云方案测试迁移效果，并对业务上云后的系统参数和性能进行调整，使之满足业务系统的需要，并投入实际使用。

4 上云验证

1、上云评估

根据确定的业务上云方案，正式实施业务上云；根据业务上云方案测试业务上云效果，并对业务上云后的系统参数和性能进行调整，使之满足业务系统的需要，并投入实际使用。

2、业务检查

业务正式上云后，进行一定时间的试运行，检测业务上云后是否对业务造成影响，对出现的问题进行及时的解决。

3、问题优化

根据云上系统监控数据和业务系统发展规划，优化业务系统架构，消除性能瓶颈和风险，保障客户业务平稳运行。

5 云上维护

1、运行维护

为上云企业提供全面专业的运维/运营服务，进行资源开通、辅助上云、平台监控、故障排查、容量管理、升级重保、健康检查、性能报告等服务科目，可提供驻场服务、巡场服务和远程服务三种服务类型。

2、场景培训

针对企业客户使用场景，帮助企业熟悉和掌握云上业务操作和云服务技术，培养企业使用习惯，解答企业用户使用过程中遇到的各类问题。

觉得不错，请点赞↓↓↓

随着云计算的广泛采用，企业变得比以往更具活力。如今，许多公司的业务正在向云计算迁移。选择云提供商几乎总是确保长期供应商锁定。无论是工程师很难对应用层进行适当的抽象和概括，或者应用程序数据的大小使得迁移变得困难，所以迁移到基于云计算的系统是一项非常具有挑战性的任务。在从本地数据中心上的自托管系统迁移到云中时，应考虑以下挑战（ydotpub）。

（1）不当的抽象

在新环境中抽象失败是向云迁移过程中面临的最大挑战之一。通常，应用程序的体系结构取决于其下面的一些本地化API。这在大规模运行的系统中特别常见，因为特定的问题只能在一定的规模中才能看得见。工程团队经常使用一些类似黑客的程序和补丁来修复系统，但是黑客会在系统迁移过程中进行攻击。定期代码审核在一定程度上有助于减轻这些问题。

（2）部署过程中的差异

所有的现代持续集成和持续交付(CI/CD平台都支持多个云提供商，但这还不够。具有复杂设置和启动过程的应用程序通常需要人工干预部署。近几年来，这一点通过使用Puppet，Chef和Ansible等工具在很大程度上可以实现自动化。但是这种自动化通常与供应商特定的API联系在一起，这些API需要配置，监控和拆卸服务器。但是，除非工程团队花时间自己构建，否则这些API不适合小型的本地数据中心（ydotpub）。

（3）重新架构

现代应用程序分布在多个不同区域的多个数据中心。这是迁移到基于云计算的部署的主要好处之一。企业正在逐渐从单一的应用程序基础转变为基于微服务的方法。一个本地数据中心迁移到多地点部署需要适当地重新构建应用程序。这意味着除了开发新版本之外，工程团队还必须关心现有的安装情况。迁移系统的关键部分经常会导致停机，新的部署仍然不能保证在首次运行中取得成功。建议在出现问题时对原有部署进行故障切换，以防出错。大型迁移可能需要几个月的时间才能完成，并可能需要额外的员工来完成。

（4）传输大量的数据

想象一下，必须将移动社交应用Instagram的业务从AWS云平台迁移到微软Azure云平台上。传输这些海量的图像本身就是一项艰巨的任务。认为有时最好的措施是物理运送数据，而不是将数据上传到云计算提供商，这种行为并不疯狂。这两种策略都经过多年的分析，行业仍然没有确定哪个策略才是正确的做法。这个问题不是取决于正在迁移的系统的类型，因此不能通过仅仅改变架构来缓解。一些企业从一开始就选择使用云存储，即使涉及到基于本地数据中心的部署。当数据不太活跃或者不需要立即处理时，这种方法特别普遍。Amazon S3存储已经成为许多企业多年来的可靠存储解决方案，并且一直是这一领域的领跑者。

如今的许多企业都喜欢快速收购和出售市场型的初创公司。迁移到云端或从一个提供商转换到另一个提供商是这类业务的非常普遍的任务。通常情况下，需要使用当前的一套应用程序来制作新获得的应用程序。有时，新产品转移到新的云计算提供商或从云端迁移到自我托管的设置，以利用已经购买的合同或硬件，就像Instagram迁移到Facebook的数据中心，这实质上形成了Facebook的私有云平台。

无论是什么原因，迁移到基于云计算的系统是许多组织的必要条件。最好是以一种与供应商无关的方式编写应用程序，并在适当的地方进行适当的抽象，以便缩短可能长达几个月的考验过程。