检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
RTO与RPO 灾难场景通常采用RTO和RPO目标定义: 恢复时间目标RTO:指灾难发生后应用不可用的最长时间。RTO决定了应用容灾整体架构,是采用数据备份,还是冷备、温备、热备。 恢复点目标RPO:指灾难发生后应用数据丢失的最大时间。RPO决定了数据备份频率或复制方式,是在线备
定期检视和更新权限,以避免权限蔓延,持续清理无用的权限。 风险等级 高 关键策略 使用IAM用户组控制人员的访问权限,并设置权限的到期时间。 如果用户组的职责产生变化,应该及时调整用户组的权限。 当账号委托给另一个账号时,设置到期时间。 通过IAM用户的“最近一次登录时间”,判断
早期的设计决策会对性能调节能否成功,以及是否有必要进行性能调节产生重要影响。如果开发的软件对性能非常敏感,实际上需要从设计阶段和开发周期的第一天起就考虑性能管理的问题,即采取系统的主动性能管理的办法来解决性能问题。除了管理上的措施外,解决性能问题需要在系统和架构设计、实现方案设计及编码实现上采取有效的技术手段来保证。
应遵守这些政策和流程,确保安全管理的一致性和有效性。 建立应急响应计划:开发和测试应急响应计划,以应对安全事件和紧急情况。团队应清楚知道如何应对安全威胁和处理安全事件。 父主题: SEC01 云安全治理策略
、可容灾、可过载控制、可故障管理、可变更能力、可运维、安全生产等维度,对服务可用性及运维能力提出基线要求。在服务产品开发前端构筑能力,进行相关需求规划、设计和开发工作,并在服务上线前进行生产准入审视。 具备以下核心价值: 1)准确评价产品可用性、维护能力并明确相关上线标准;不满足上云标准的服务,原则上不允许上线。
跨团队共享使用的CCE集群服务,应按照各团队分配和使用的CPU/内存等比例,将容器集群成本(包含CCE、ECS、EVS等服务成本)拆分到各个业务团队。 以上公共成本,以及其他共享资源&平台服务&服务支持&未及时标记产生的未分配成本,也可以按照一定的比例规则,比如平均分配、按消费比例分配、按约定比例分配等规则,拆分
代码白盒检视是一种软件质量保证方法,通过检视源代码的内部结构、逻辑和实现细节,以确保代码符合最佳实践、编程规范和安全标准。在代码白盒检视中,团队成员会检查代码的质量、安全性、可读性等方面,以发现潜在的问题和改进空间。 风险等级 中 关键策略 制定检视计划: 确定检视的频率和时间安排,以确保代码检视是持续的活动。
999%) 金融类核心应用通常比较重要,要求非常短的恢复时间和数据丢失量,其可用性目标通常要求达到99.999%,即每年故障时间可以为5.26分钟。 假定故障中断与变更中断的时长分别如下: 故障中断:由于要求的故障中断时间很短,要求尽可能自动恢复,没有手动触发的恢复,假定每年故障
开源软件在现代软件开发中的重要性不言而喻。越来越多的企业选择使用开源软件来开发和部署软件应用程序。开源软件的使用必须严格遵守合法合规的底线,包括开源软件的来源、漏洞管理、可追溯、归一化及生命周期管理等方面。 风险等级 高 关键策略 来源可靠。由于开源软件是公开的,因此黑客和攻击者可以更
通过将事件和错误信息记录到日志文件或数据库中,可以方便地进行故障排除和问题诊断。但是,仅仅记录日志并不足够,还需要对日志进行有效的管理和分析。如果日志太多,将会成为一个负担,因为它们需要占用存储空间,并且需要花费很长时间来查找有用的信息。因此,需要对日志进行过滤和归档,以便更好地管理它们。
故障后,快速切换到备节点并自动恢复,在异常检测和恢复期间,可能会影响业务,时间在半分钟内。 数据备份和恢复 DCS支持将当前时间点的实例缓存数据备份并存储到OBS中,以便在缓存实例发生异常后能够从备份数据进行恢复。DCS实例支持定时和手动两种备份方式,定时备份频率以天为单位,最多
到主动的诱捕溯源。 用户需求变化 产品层面:除传统的入侵防御、WAF和漏扫之外,对资产测绘、APT检测、安全情报和蜜罐的需求在不断增加。 服务层面:除保障期间的安全加固和值守服务外,对日常的安全巡检、安全培训和内部攻防演习需求不断增加。 父主题: SEC10 安全事件响应
且数据丢失时间以及恢复时间符合数据的RPO与RTO指标要求。 风险等级 高 关键策略 每年至少进行一次容灾演练;通过演练可提升操作人员的熟练程度。 演练期间需要对恢复过程计时,以确定应用系统的RPO与RTO目标能否满足。 演练期间可检查灾难恢复计划执行顺序及恢复时间并进行优化。
应用程序的性能数据(吞吐量、延迟和完成时间),通常需要通过代码采集,例如嵌入代码片段或将工具集成到应用程序代码中。通过应用的性能数据,可以识别性能瓶颈、评估系统行为、识别可用性风险、规划容量等指标。 常用应用性能监控策略有: APM 工具:可用使用云上APM 工具或者开源的APM工具和分析性能数据(指标、日志、调研链)
的负荷,形成恶性循环,导致业务成功率远远低于系统的设计容量,甚至整体不可用。因此应用应该设计过载保护机制,使得在过载状态下依然可以保证一定比例设计容量的处理能力。 通过过载保护,可以缓解客户流量突增、泛洪攻击或重试风暴所造成的大量容量峰值情况,让工作负载能够继续正常处理支持的请求
来的好处(例如分析时间与应用成本成正比)以及相应的成本是否带来正向的营收。 回顾和审核的频率应该综合考虑多种因素,包括成本优化在企业或者组织中的重要性,测试和验证成本,应用的复杂性和优化变更的难易程度。同时,在每次回顾和审核时,持续改进流程,例如,通过降低测试和变更的成本从而提升
规划企业组织,将组织结构,流程和成本管理相匹配 2. 规划IT治理体系,提高管理效率 3. 明确团队责任,建立和维护成本意识文化 4. 指定云资源管理策略和相应的权限管理机制 COST02 您是否有预算规划管理机制? 1.建立云预算与预测流程 2.精细化预算管理和跟踪 COST03 您是否将成本分配到组织单元?
选择这两种模型时,部署的每个阶段之间的时间应该足够长,以便能够监控工作负载的运行状况指标。应该提供充足的部署间隔时间(即部署组之间的时间),以确保来自不同区域的用户或执行不同任务的用户有时间使用工作负载。间隔时间应以小时和天而不是分钟来衡量。每个部署组的间隔时间也应该增加,以便考虑不同的时区和使用模式。 相关云服务和工具
您如何进行故障隔离? 应用控制平面与数据平面隔离 应用系统多位置部署 采用Grid架构 健康检查与自动隔离 RES011 您如何进行可靠性测试? 混沌测试 压力负载测试 长稳测试 灾难演练 红蓝攻防 RES012 您如何进行应急恢复处理? 组建应急恢复团队 制定应急预案 定期应急恢复演练 出现问题后尽快恢复业务
找最短恢复路径。如下图所示案例,在故障恢复 MTTR 的逻辑中,当业务发生故障,从故障发现、到故障定级和影响面分析、再到故障定界定位和故障恢复,几乎全部依赖人工处理。要想缩短时间,本质上是监控即发现、监控即定级、监控系统定界、定界即恢复——如果能达成这样的设计就能够形成 MTTR