创建云上的数据恢复计划,很重要的一点是持续跟踪基础架构,DR需求和可能的故障转移持续时间。
公有云给IT部门提供了绝佳的机会来实现业务的持续性/灾难恢复计划,而无需花费巨资构建独享的数据中心。有了云数据恢复系统之后,云就可以用作基本数据的存储库或者甚至当主要系统出问题时运行应用之处。
当构建DR计划时,第一步是查看用来交付IT服务的应用,并且决定灾难发生时需要保护什么。这意味着创建需要运行的应用和服务的清单。很多企业已经转向虚拟化作为其核心服务器的部署模型;但是,仍然需要考虑物理服务器。完善的云数据恢复计划应该包括如下:
用来交付基础架构的物理和虚拟服务器。这些包括活动目录(AD)服务器,DNS/DNCP服务器和应用。
最好提前确定基础架构服务器,因为当灾难发生时这些系统需要第一时间恢复服务。可以预配置在云上运行的AD、DNS和DNCP服务,并且和它们的内部实例同步,让DR流程更加容易,也能够更快实现。
要想让云上的DR能够成功工作,理解网络配置至关重要。这意味着需要花时间理解网络层的应用之间的相互依赖关系,包括安全和防火墙配置。云数据恢复相关的问题有:
确定云数据恢复需求
假定在灾难事件发生时,每个应用都需要立即恢复,这并不太实际。相反,应该基于一系列条件来区分应用的优先级,来决定需要多快,以及哪些同步系统和数据需要恢复运营。在决定恢复应用的服务等级时,可以使用一些标准来进行度量:
建立正确的云数据恢复需求包括和应用程序的业务所有者沟通,因为他们了解其应用的重要程度。从经验上看,业务所有者会认为其所有应用都很重要——直到他们了解恢复所需的费用为止。因此可以告诉他们不同方案的费用评估。
服务级别的最后一点是:一些严格的需求,比如零PRO,基于云的DR是无法达成的,因为本地和云位置之间会有延时。需要将这些应用排除在基于云的DR之外,并且提供更多定制的DR产品。
DR服务会运行多久?
最后需要讨论的是,服务会在公有云上运行多久。做这样的决策依赖于发生的事件类型。并非所有灾难都会导致所有在线功能的崩溃。还会存在一些边缘事件类型,比如:
有时候,服务需要移动几个小时或者几天。当整个站点都丢失时,需求可能是运行DR服务几周或者几个月,直到重建了之前的设备。云恢复服务会为所使用的活动服务计费,因此在选择DR服务时这是很重要的考核点。
好文章,需要你的鼓励
Queen's大学研究团队提出结构化智能体软件工程框架SASE,重新定义人机协作模式。该框架将程序员角色从代码编写者转变为AI团队指挥者,建立双向咨询机制和标准化文档系统,解决AI编程中的质量控制难题,为软件工程向智能化协作时代转型提供系统性解决方案。
苹果在iOS 26公开发布两周后推出首个修复更新iOS 26.0.1,建议所有用户安装。由于重大版本发布通常伴随漏洞,许多用户此前选择安装iOS 18.7。尽管iOS 26经过数月测试,但更大用户基数能发现更多问题。新版本与iPhone 17等新机型同期发布,测试范围此前受限。预计苹果将继续发布后续修复版本。
西北工业大学与中山大学合作开发了首个超声专用AI视觉语言模型EchoVLM,通过收集15家医院20万病例和147万超声图像,采用专家混合架构,实现了比通用AI模型准确率提升10分以上的突破。该系统能自动生成超声报告、进行诊断分析和回答专业问题,为医生提供智能辅助,推动医疗AI向专业化发展。