检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
优化性能,减少消息响应时延和负载。 使用优先队列,优先处理高优先级用户的请求,以便在流量过载时不影响应用系统的核心功能。 流量过载时支持功能逐步降级。 被依赖项本身的功能受损时,提供缺省处理,以便应用系统仍可继续正常运行;由于缺省处理可能与实际配置有差异,此时需要告警以便通知系统管理员解决问题。
Server Kubernetes内置组件,实现Pod水平自动伸缩的功能,即Horizontal Pod Autoscaling。在kubernetes社区HPA功能的基础上,增加了应用级别的冷却时间窗和扩缩容阈值等功能。 HPA策略 CustomedHPA CCE容器弹性引擎 自研
OPS06-07 通过可观测性指标引入自动化措施 风险等级 高 关键策略 可观测与自动化运维工具联动,实现自动化的故障检测、恢复及弹性伸缩等功能,进一步提升运维响应速度和准确性,降低人为干预带来的延误,甚至错误。 父主题: OPS06 可观测性体系
些故障发生时,能最大程度地减轻故障对系统造成的影响,并持续稳定地运行,建议遵循以下设计原则。 高可用设计 单点故障会导致整个系统崩溃、主要功能受到影响、任务延误的系统轻度损坏或存在较大的故障隐患,因此系统的高可用设计非常关键。 高可用设计的主要手段是冗余,甚至是多级冗余的组合,包括异地容灾方式保证灾难情况下无单点:
且无法通过虚拟机HA功能自动恢复;针对此类问题,需要应用系统在设计时就必须要预料到偶发故障,尽可能避免使用,若必须用时需要从应用层来实现高可用,以便在所依赖的硬件故障时业务能快速恢复。 虚拟机HA:当ECS不依赖于特殊资源时,可以支持虚拟机故障自动恢复功能,在其所在物理服务器故
OPS06-01 建立可观测性体系 可观测性(observability)最初是系统理论中的一个概念,指系统的状态能否被外部观察到和重现。随着云原生、微服务架构的发展,IT系统对可观测性的需求日益增强。业界对可观测性的定义:通常是指基于对复杂系统外部输出的了解,能够了解其内部状态
RES03-04 支持容灾管理 提供容灾管理功能,实现容灾状态及RPO监控,及异常场景下的业务切换。 风险等级 高 关键策略 实时监控容灾状态,了解容灾运行状态。 支持应用级数据校验,比较AZ间数据同步差异,监控及PO指标。 典型确定性故障场景下自动容灾或切换,无需人工接入,业务不受影响,满足RPO/RTO指标。
便捷低成本获取日志,助力业务挖掘分析:DLI-Flink简易集成Connector,定点从LTS实时消费日志,做实时业务计算分析;简易化配置LTS日志转储到OBS,供DLI快速从OBS读取日志,做离线业务计算分析 父主题: 参考案例
灵活、可扩展和易于维护的架构风格,已经逐渐成为现代应用开发的主流选择。它通过将应用程序拆分为小的、自治的服务,每个服务都负责执行特定的业务功能,可以使用不同的技术栈,由独立的团队开发,测试,部署和扩展,并通过轻量级通信机制相互交互。而在CI/CD下,同一团队以流水线的方式集成整个
SEC09-04 安全态势感知 跟踪并监控对网络资源和关键数据的所有访问:通过系统的活动记录机制和用户活动跟踪功能可有效降低恶意活动对于数据的威胁程度。当系统出现错误或安全事件时,通过执行彻底地跟踪、告警和分析,可以较快地确定导致威胁的原因。 风险等级 中 关键策略 采集各类安全
用的可能性。 与依赖项的通信采用异步消息并支持超时重试,或发布/订阅消息功能将请求与响应分离,以便依赖项从短时故障中恢复。 依赖项长时间无法访问时,应用程序应能继续执行其核心功能,以便将局部故障对整体系统功能的影响减到最小。如所依赖的数据丢失时,应用程序仍能运行,但可以提供稍微陈
风险:攻击者利用脆弱性的可能性以及相应的业务影响;风险将脆弱性、威胁和利用可能性与造成的业务影响联系在一起。 资产: 任何对组织有价值的信息或资源,是安全策略保护的对象。 处置措施:包括安全角度的消减措施和韧性角度的增强措施,能够消除脆弱性或者阻止威胁,或者降低风险的影响和保护资产。 实施威胁建模,需要有
库系统承载,运维人员可以轻松地查找和获取各种运维知识,包括网络配置、服务器管理、数据库维护等方面的知识。下面将介绍运维知识库系统的五个主要功能和优势。 丰富的知识资源:运维知识库系统收集整理了大量的运维知识和经验,涵盖了各个领域和层次的内容。用户可以通过系统进行检索,查找到相关的
和用途。 与业务部门、开发团队、运维人员等进行交流,获取关于数据的详细信息。 确定数据的分布:需要确定数据存储在哪里,例如云硬盘、数据库、对象存储等。 评估数据敏感度。 确定数据的类型和内容,例如是否包含个人身份信息(如姓名、身份证号、地址等)、财务数据(如银行账号、交易记录等)
在业务初期的设计阶段,要考虑简化组件/模块/方法/类的功能设计,避免设计面面俱到的多功能组件/模块/方法/类;调用功能时,避免功能过剩、并对性能影响较大的调用;选择云服务的时候,选择合适的云服务,结合业务的特征选择合适的云服务类型和规格,利用好云弹性的特性的优势。设计功能过于复杂的组件,有时候是为了通用
容灾恢复过程自动化 由于容灾恢复场景涉及容灾站点的业务恢复、数据库的主备切换、业务到容灾站点的流量切换等,恢复过程比较复杂,因此需要提供容灾管理功能,实现容灾状态及RPO监控,以及灾难场景下的一键式自动切换,减少人工干预。 风险等级 高 关键策略 实时监控容灾状态,了解容灾运行状态。
风险,以帮助组织改进其安全措施、加固防御,并保护系统免受真实攻击的威胁。 风险等级 高 关键策略 建议在开发周期的后期执行渗透测试,使系统功能接近预期发布状态,但也要留有足够的时间来解决发现的问题。 采用结构化流程:使用结构化流程确定渗透测试的范围,基于威胁建模的模型保持场景相关性,以确保全面评估系统的安全性。
避免多个业务共用一个Redis。 强制 一方面避免业务相互影响,另一方面避免单实例膨胀,并能在故障时降低影响面,快速恢复。 禁止使用select功能在单Redis实例做多db区分。 强制 Redis单实例内多DB隔离性较差,Redis开源社区已经不再发展多DB特性,后续不建议依赖该特性。
数据完整性保护。通过定期备份和版本控制来保护您的数据,防止数据被篡改或删除。将关键数据与其他数据隔离,以保护其机密性和数据完整性。 确保存储了重要业务数据、敏感数据的OBS桶,配置为非公开可读,防止数据被非法访问。 制定风险管理计划:了解数据被意外披露、更改或删除可能会带来的业务影响,有助于制定相应的风险管理计划。
日志的统一管理,并确保透明可追溯。 风险等级 高 关键策略 跟踪并监测对网络资源和关键数据的所有访问。通过系统的活动记录机制和用户活动跟踪功能可有效降低恶意活动对于数据的威胁程度。常见的安全日志如主机安全日志、操作系统日志、堡垒机日志、IAM日志、WAF攻击日志、CFW日志、VP