检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
韧性支柱 韧性支柱简介 基本概念 设计原则 问题和检查项 高可用设计 故障全面检测 故障快速恢复 过载控制 变更防差错 参考架构 云服务可靠性介绍
风险等级 高 关键策略 依据系统的安全设计文档,通过验证确保安全措施被正确地集成到系统中,并符合最佳实践和标准。 尽早检视系统的代码(此过程称为代码白盒安全检视),确保代码符合安全最佳实践,避免在后续阶段发现严重的安全漏洞。
PERF05-02 通用算法优化 风险等级 中 关键策略 算法优化是提高程序性能的关键,可以通过改进算法的设计和实现方式来提高其效率和性能。以下是一些最佳实践: 使用正确的数据结构:选择合适的数据结构可以大辐提高算法的效率。
设计建议 变更风控衡量指标:变更风控衡量指标为变更导致事件密度和变更引入重大事件数。 变更导致事件密度定义:每月变更导致对客户造成影响的事件数与总变更数的比值。 计算公式:变更导致事件密度=变更导致对客户造成影响的事件数/总变更数。
设计建议 可参考LTS最佳实践 父主题: OPS06 可观测性体系
卓越运营支柱融合了这些优秀实践,聚焦如何正确地构建软件,高效地运维软件,持续提供卓越的客户体验,包含:组织团队、设计工作负载、大规模运营工作负载和随时间变化改进工作负载的最佳实践。 父主题: 卓越运营支柱
定义权限访问要求 按需分配合适的权限 定期审视权限 安全共享资源 SEC04 如何进行网络安全设计? 对网络划分区域 控制网络流量的访问 网络访问权限最小化 SEC05 如何进行运行环境的安全设计?
因此应用应该设计过载保护机制,使得在过载状态下依然可以保证一定比例设计容量的处理能力。 通过过载保护,可以缓解客户流量突增、泛洪攻击或重试风暴所造成的大量容量峰值情况,让工作负载能够继续正常处理支持的请求量,避免出现资源耗尽而导致所有请求都不能处理的情况。
该架构主要的安全设计如下: 网络安全 防DDoS攻击使用AAD服务 Web类攻击采用WAF防护 采用SSL证书进行通信加密 互联网边界、VPC之间采用云防火墙 运行环境安全 企业主机安全服务保护主机安全和容器安全 VPC内访问控制使用网络ACL+安全组 使用漏洞扫描服务定时扫描云上各资源漏洞
PERF01-02 应用性能编程规范 风险等级 高 关键策略 性能效率是一个系统性的工程,需要综合考虑从架构、设计、编码,到编译、运行的全过程,特别是在编码实现层面,有很多编码技巧,在不影响可读性、可维护性的前提下,提升软件性能。
通常按照指标劣化程度可以设计成一般、紧急、重要三个梯度,对应每个梯度的指标配套对应的处理措施。对于敏感度或业务重要度的应用架构,可以新增一个提示级别的梯度。 相关云服务和工具: 云监控服务 CES 应用运维管理 AOM 应用性能管理APM 父主题: 性能看护
以下是OWASP总结的Web应用系统TOP10的威胁及处置措施: 相关云服务和工具 解决方案工作台 InnoStageWorkbench:使用解决方案工作台辅助进行云上架构图的可视化设计,基于架构图进行威胁分析。 父主题: SEC01 云安全治理策略
风险等级 高 关键策略 在设计网络拓扑时,仔细检查每个组件的连接要求,例如是否需要互联网可访问性(入站和出站)、连接到VPC的能力、边缘服务和外部数据中心等。除非资源必须接收来自公网的网络流量,否则不要将资源放置在VPC的公有子网中。 对于入站和出站流量,应采用深度防御方法。
接入层指标的观测 Manger的服务->Hive服务状态页面可以查看到相关的HiveServer的连接数,HQL的执行成功的统计信息。
例如一种运维组织设计是:将运维组织分为一线、二线和三线阶梯型运维支持团队,一线受理客户的服务请求,第一时间将大部分的服务请求闭环。
OPS02-01 进行需求管理和迭代开发 风险等级 高 关键策略 您的云上应用要达到卓越运营,从设计和开发阶段就需要保证可用性,可恢复性,同时也需要保证代码的质量。
应基于数据库连接数、事务处理性能等关键指标的要求以及部署设计的约束(如容灾要求)来分析; 安全方面,则要针对设计约束进行逐条评估(如访问控制、数据加密),以判断数据库云服务满足度。
数据库性能优化 以下章节我们结合一些具体建议和案例来说明如何针对数据库的使用进行性能优化: 1.优化数据库配置实践 数据库的配置参数应从具体业务诉求着手,根据实际需要进行设计;华为云在各个数据库云服务中均提供了默认的配置参数,以满足最普遍的业务需要。
OPS02-02 关联源代码版本和部署的应用版本,使用代码质量最佳实践 风险等级 高 关键策略 在代码开发阶段,需要开展代码协作设计和管理。使用现代化的代码仓管理代码,确保代码合并后,代码将保持一致,并且不会丢失任何更改。
MTTR平均恢复时长=平均发现时长+平均定界时长+平均处置时长 设计建议 面向 MTTR的可观测体系设计的核心逻辑就是寻找最短恢复路径。