检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
影响到其他业务单元,甚至整个系统。而通过将不同的业务单元部署在独立的云账号中,企业可以有效地隔离故障和风险,防止问题的扩散。举个例子,如果某个业务系统遭遇了安全攻击,攻击者可能只能够接触到该业务系统所在的云账号中的资源,无法进一步影响到其他业务单元。这种隔离机制大大提高了整个企业的安全性和稳定性。
一个批次跨度 4~8周最合适,时间指的是(部署、迁移、切换),不包含准备阶段。 一个分批不能太大,太大增加迁移风险 根据业界最佳实践,一个批次不应超过20个应用程序、150 个服务器和30个数据库,超过这个大小挑战和风险都很大,增加失败挑战和回退风险,建议严格检查此规则的任何例外情况。
验证 数据校验 数据库的对比方法有数据库内容对比、对象对比、行数对比,文件的对比方法有文件数量对比,大小对比,内容对比。具体的数据对比的方法请参考章节数据验证的内容。 任务验证 大数据任务迁移后,要确保作业能够正常运行、产生准确的结果,并且满足性能要求。一般从如下三方面验证: 验证作业执行的成功率
人为操作不当影响切换时长和切换结果。 Runbook的每个切换操作都可能会执行失败,要提前分析每个步骤发生执行失败时的决策项,细分失败场景,决策是回退还是继续进行,防止切换当天决策组讨论时间较长,无法决策的情况发生。 回退决策点设计原则如下: 每个切换阶段设计最晚的执行完时间,超时需要决策是否进行回退。
设计云上的大数据任务调度平台部署架构时,建议参考原则如下: 优先用大数据云服务:如果源端是自建的大数据任务调度平台和组件,在目标云平台上有对应的云服务,且功能、性能、兼容性都满足,经评估改造工作量很小,建议部署架构设计时,优先采用大数据云服务。如果目标云平台上没有对应的大数据任务调度组件,部署架构设计
自动化部署和持续集成/持续交付: 微服务架构通常需要频繁地进行部署和更新。为了简化和加快部署过程,可以引入自动化部署和持续集成/持续交付(CI/CD)流程。使用适当的工具和技术,例如Jenkins、GitLab CI/CD等,来实现自动化的构建、测试和部署流程。在自动化部署和CI
下是一些常见的云采用实施阶段的反模式: 未采用自动化部署模式 该反模式是指企业依赖手动进行代码、云资源的配置和部署,效率低,人为错误高。 优化建议:采用自动化的配置和部署工具,如Terraform、CI/CD等,以提高云资源部署的效率和准确性。 未进行切换演练 该反模式是企业未进
设计云上的大数据集群部署架构时,建议参考原则如下: 优先用大数据云服务:如果源端是自建的大数据集群,在目标云平台上有对应的云服务,且功能、性能、兼容性都满足,经评估改造工作量很小,建议设计大数据集群部署架构时,优先采用大数据云服务。如果目标云平台上没有对应的大数据集群组件,部署架构设计时,
分批迁移:对于能分批迁移的,企业通常会将大规模迁移划分为多个批次进行。大规模迁移的执行主要是按照批次规划逐批次进行迁移,如下图: 图1 分批迁移 整体迁移:对于不能分批的,应用的关联关系往往非常复杂,只能选择所有业务系统整体一个批次迁移,如下图: 图2 整体迁移 父主题: 采用实施
anding Zone,部署可扩展的网络基础设施,配置安全基线和运维基线;然后将各个应用系统和大数据平台迁移或直接部署到云上,或者基于云平台进行应用现代化改造,也可以基于云平台提供的各种创新技术直接在云上进行应用和业务创新。 运维治理:将应用系统迁移或部署到云上之后就进入了运维治
以用户为中心,一站式个性化体验 无法快速响应新业务变化 面对新业务可快速组合和按需定制 新功能需求绑定大版本上线,需求交付周期长(年/月级) 快速迭代上线,交付周期缩短(周/天级) 团队规模大,传统开发模式 团队拆小,DevSecOps敏捷运作 物理服务器 容器化部署、全面上云 应用现代化
设计原则 大数据的部署架构设计包括大数据集群、大数据任务调度平台和大数据应用,其中大数据应用的部署架构请参考应用架构设计。 图1 大数据架构设计分类 大数据架构设计同样要考虑架构设计的6要素: 成本 可用性 安全性 可扩展性 可运维性 性能 图2 架构设计6要素 父主题: 大数据架构设计
多云战略的驱动力 当前多云战略正在成为一种主流趋势,越来越多的组织选择将业务系统部署在多个云服务商的云平台上,而不是依赖单一的云服务商。这种趋势的背后是多种因素的驱动,以下是一些主要的驱动力: 避免单云故障:将业务部署在单一云平台上存在单点故障风险。如果该云平台出现故障,例如大规模宕机或区
这是整个评估过程的基础。在这一阶段,您需要根据组织的现状和业务需求,确定需要评估的具体范围。由于云化转型涵盖多个评估维度和众多评估问题,您可能无法在一次评估中全部涵盖,您可以聚焦于组织当前发展阶段和业务目标最相关的方面,选择其中一部分关键维度进行评估。通过与相关业务部门、技术团队的沟
调研评估的反模式 在进行上云调研评估时,可能会遇到一些反模式,这些模式如果不加以识别和避免,可能会影响调研评估的效率,也可能会导致调研评估结果不准确,无法支撑有效决策和后续的上云方案设计。以下是一些在上云调研评估中常见的反模式。 没有选择正确的调研方法 调研开始阶段,直接发各种复杂的调研表格
建立覆盖涵盖全技术堆栈的纵深防御机制,将多种类型的安全控制应用于所有技术堆栈,包括网络边缘、VPC、云存储、ECS实例、操作系统、应用程序配置和代码等。 安全和成本平衡(Balance between Security and Cost) 尽管安全领域强调纵深防护,但越全面的安全
数据验证方法 数据分为数据库数据、中间件数据和文件数据,这三种数据的一致性验证方法和工具不同: 数据库数据一致性验证的方法如下表所示。 表2 数据库一致性对比方式 对比项 工具 描述 库和表级内容对比 DRS工具 查询对比数据库表的每一条数据,确保每一条的每一个字段都与源端数据库表一致。相较于行对比,内容对比较慢。
务创新、与业务结合并推动业务现代化的几个方面: 透明度和可信度:区块链技术通过去中心化的特点,确保所有交易和数据记录被公开透明地存储,并且无法篡改。这为企业创造了更高的数据可信度和透明度,消除了传统中介机构的需求,降低了操作风险。 智能合约和自动化执行:区块链上的智能合约是一种自
规划数据在云环境中的存储和管理方案。 选择合适的云数据库和大数据服务。 实施数据迁移和治理,维护数据质量,保障数据安全。 网络架构师 设计灵活可靠的网络架构,支持应用系统之间的连接需求。 确保网络安全和性能,满足数据传输要求。 实现网络的弹性和可扩展性,适应业务变化。 规划云网络架构,配置虚拟网络、子网、安全组等。
境进行集中化的IT治理。CCoE团队赋能应用团队全权负责业务系统所需云资源的部署和运维,这样既可以减轻CCoE团队的负担,又可以提升应用团队的自主性,进一步提升应用系统的敏捷性。为避免各业务单元独立部署和运维云资源带来的标准不统一问题,CCoE团队需要制定相应的IT治理策略强制各