检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
故障扩散。 风险等级 高 关键策略 对系统内组件需要定期进行健康检查,以判断其状态是否正常。 对于异常组件,需要能支持自动隔离,避免对整体业务造成影响。 相关云服务和工具 弹性负载均衡器 ELB:支持健康检查,会定期向后端服务器发送请求以测试其运行状态,并根据健康检查来判断后端服
大 等保合规要求日志长时间存储,运维部门较多,人员不足,自建ELK成本高 解决方案: 业务价值: 全量日志接入:汽车APP、软件开发、流量平台等170个业务系统接入云日志服务,全面覆盖业务、应用、中间件和基础设施。 分钟级问题定界:秒级日志查询和分钟级日志监控,可配置告警和多渠道
重试需要避免造成流量压力 RES10 您如何进行故障隔离? 应用控制平面与数据平面隔离 应用系统多位置部署 采用Grid架构 健康检查与自动隔离 RES011 您如何进行可靠性测试? 混沌测试 压力负载测试 长稳测试 灾难演练 红蓝攻防 RES012 您如何进行应急恢复处理? 组建应急恢复团队
关联源代码版本和部署的应用版本,使用代码质量最佳实践 OPS03 你是否有完备的测试验证体系? 1. 推行开发者测试 2. 使用多个环境进行集成测试,构建和生产环境相同的预生产环境 3. 性能压测 4. 生产环境拔测 5. 混沌测试和演练 OPS04 自动化构建和部署流程是否完备? 1. 有效落地持续集成
么就会在整个订购周期进行分配,每天分配1元。这种成本分配机制,更体现了成本责任制。 公共成本也应该在组织内进行分摊。比如企业内的共享资源、平台服务、支持计划、未及时标记的成本。只有将公共成本也分配下去,才能让业务团队关注这部分消费,从而合理化使用,减少不必要的浪费。 相关服务和工具
故障快速恢复 当应用系统采用华为云服务的高可用设计时,在云服务实例发生故障后,云服务能自动检测和恢复;但对于应用系统本身的故障,需要应用系统自身进行检测和快速恢复处理,以保证系统能够正常运行,从而提高系统的可靠性和稳定性。 RES08 依赖减少与降级 RES09 故障重试 RES10
包含攻击的各个路径,初始访问、执行、持久化、权限提升、防御绕过、凭证访问、信息收集、横向移动、数据采集、命令控制、数据窃取和影响破坏等。 可基于流批一体化平台,支持在线、近线和离线的各种异常行为分析模型的构建,包含身份防线,网络防线,应用防线,数据防线,运维防线和主机防线等。也可同时基于AD-H
企业不至于为了完成本优化,而牺牲自身真正的产出。 在最终实际的优化实施阶段,由于成本优化往往需要运营,运维,研发等多个部门的参与,也涉及到平台部门和业务部门的合作,故而需要确定一个各个组织成员都参与的完善流程,如释放空闲资源的流程。 企业也可以定期生成报告,并同步给干系人;同时联
RES13 过载保护 当系统流量超过一定阈值后,导致系统处于过载状态时,可能会导致部分请求失败,失败触发业务重试,会进一步增加系统的负荷,形成恶性循环,导致业务成功率远远低于系统的设计容量,甚至整体不可用。因此应用应该设计过载保护机制,使得在过载状态下依然可以保证一定比例设计容量的处理能力。
实施威胁建模分析 威胁建模是一种系统性的方法,用于识别和评估可能对系统或组织造成威胁的潜在威胁源、攻击路径和攻击手段。通过识别威胁理解系统的安全风险,发现系统设计中的安全问题,制定消减措施,降低系统风险,提升系统安全性和韧性。 风险等级 高 关键策略 以下是系统运行期间的威胁模型: 该模型中涉及的概念如下:
RES07-05 端到端跟踪请求消息 端到端跟踪请求消息的处理流程,便于分析和调试问题,并提高处理性能。 风险等级 低 关键策略 消息跟踪需要包含消息处理流程中所有组件,以便跟踪结果完整,从而进行准确分析和定位。 相关云服务和工具 应用性能管理 APM:支持调用链追踪,能够针对应
、单个服务器或单个机架等硬件故障的影响。 RDS数据库提供自动数据备份、跨AZ和跨Region的数据复制与切换。 不过,即使应用系统利用云平台能力具有了这些高可用能力,要实现较高的可用性,仍需要构建针对各种偶发故障下的恢复能力,如: 由于硬件故障导致的高可用切换或跨AZ切换过程中
安全合规使用开源软件 SEC06-02 建立安全编码规范 SEC06-03 实行代码白盒检视 SEC06-04 应用安全配置 SEC06-05 执行渗透测试 父主题: 应用安全
根据“常见IT系统SLO示意”中的表格可以得知,不同的IT系统,SLO目标是存在差异的,不是所有的应用系统都需要达到最高可用性要求。 当系统可用性目标要求升高时,所需的成本也通常会增加,因此在可用性目标制定时,需要对韧性与成本进行权衡,确定真正的可用性需求。 在系统的可用性目标明
相同的工作负载实例,分别处理完整的生产负载。第一个(蓝色)实例处理所有工作负载。第二个(绿色)实例已使用新功能进行更新并进行了内部测试。经过内部测试后,生产流量的子集从蓝色实例路由到绿色实例。与金丝雀部署一样,当您引流更多流量转移到绿色实例时,引流是渐进的。完成转出后,更新实例将
映射到Grid,并在提供灵活性的同时,弥补了Full-Mapping的不足。 Mapping代替:强制将特定key分配给特定Grid,方便测试、隔离。 进行Grid路由层设计。设计原则如下: 路由层是系统唯一的一个共享组件,因此需要尽可能的稳定,减少修改。 避免业务逻辑,保证尽可能的稳定,减少修改。
标需要能够反映出业务的需求。 确定业务优先级:不同的业务需求有不同的优先级,因此需要根据业务的重要性和紧急程度确定业务的优先级,以便在性能测试和优化时重点关注。 定期回顾和更新性能目标:业务需求会随着时间的推移而发生变化,因此需要定期回顾和更新性能目标,以确保其与业务目标保持一致。
RES09-02 客户端需要根据综合评估是否要重试 当客户端请求超时或收到错误响应时,客户端需要决定是否重试;重试有助于客户端在请求失败时,通过重复消息来获得预期的结果,避免业务失败,但也会消耗更多的服务器时间来获取所需的成功响应。 风险等级 高 关键策略 请求超时,可能是链路闪
RES09-03 重试需要避免造成流量压力 对于链路闪断等原因导致的临时性故障,客户端进行一定的重试,可取得较好的效果;对于流量过载等原因导致的故障,重试可能会导致情况进一步恶化,因此需要避免这种影响。 风险等级 高 关键策略 客户端进行重试处理时,建议: 增加指数回退和抖动方法
问题和检查项 OPS01 建立持续改进的团队文化和标准化的运维体系 OPS02 通过CI/CD实现高效的频繁可逆的小规模变更 OPS03 完备的测试验证体系 OPS04 自动化构建和部署流程 OPS05 运维准备和变更管理 OPS06 可观测性体系 OPS07 进行故障分析和管理 OPS08