检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
COST05 优化指定策略和目标 COST05-01 分析业务趋势和优化收益 COST05-02 建立可以量化的优化目标 COST05-03 定期回顾和审核 父主题: 成本优化支柱
COST07 管理和优化资源 COST07-01 持续监控资源利用率指标 COST07-02 释放闲置资源 COST07-03 考虑不同的云资源技术选型 COST07-04 合理降配低负载资源或升配高负载资源 父主题: 成本优化支柱
COST08 进行架构优化 COST08-01 按地域规划应用架构 COST08-02 云原生架构改造 COST08-03 存算分离 COST08-04 Serverless探索 父主题: 成本优化支柱
卓越运营支柱 卓越运营支柱简介 基础概念 设计原则 问题和检查项 OPS01 建立持续改进的团队文化和标准化的运维体系 OPS02 通过CI/CD实现高效的频繁可逆的小规模变更 OPS03 完备的测试验证体系 OPS04 自动化构建和部署流程 OPS05 运维准备和变更管理 OPS06
OPS02 通过CI/CD实现高效的频繁可逆的小规模变更 OPS02-01 进行需求管理和迭代开发 OPS02-02 关联源代码版本和部署的应用版本,使用代码质量最佳实践 父主题: 卓越运营支柱
OPS06 可观测性体系 OPS06-01 建立可观测性体系 OPS06-02 定义可观测对象 OPS06-03 制定和实施可观测性指标 OPS06-04 规范化应用日志 OPS06-05 实施依赖项遥测 OPS06-06 实施分布式跟踪 OPS06-07 通过可观测性指标引入自动化措施
OPS07 进行故障分析和管理 OPS07-01 创建可操作的告警 OPS07-02 创建监控看板 OPS07-03 支持事件管理 OPS07-04 支持故障恢复流程 父主题: 卓越运营支柱
定期的大规模检视。 培训团队成员: 提供培训以确保团队成员了解如何进行有效的代码检视。 确保团队了解代码检视的目的和重要性,以及如何识别常见问题和潜在的安全漏洞,建议将常犯的TOP问题整理成清单,在开发人员编写代码后自检以及他人检视时进行对照。 选择合适的工具: 使用代码检视工具
RES12-02 制定应急预案 针对常见问题现象,提供标准化的应急恢复指导,以便在出现问题后,可以有序的完成恢复操作,避免操作失误。 风险等级 高 关键策略 需要覆盖常用典型场景。 应急恢复需要有标准的操作流程和动作,确保在事件发生时,相关干系人都能够明确自身职责和所需要采取的措施。
天起就考虑性能管理的问题,即采取系统的主动性能管理的办法来解决性能问题。除了管理上的措施外,解决性能问题需要在系统和架构设计、实现方案设计及编码实现上采取有效的技术手段来保证。 一般认为,性能问题通常由于体系架构或设计问题造成,而不是低效的编码引起的。性能问题在开发过程的早期已经
SEC06-05 执行渗透测试 渗透测试是一种安全评估方法,模拟攻击者的行为,通过模拟真实的攻击场景来评估系统、应用程序或网络的安全性。渗透测试旨在发现系统中的安全漏洞、弱点和潜在的安全风险,以帮助组织改进其安全措施、加固防御,并保护系统免受真实攻击的威胁。 风险等级 高 关键策略
OPS08-03 知识管理 风险等级 高 关键策略 日益庞大的数据量和复杂的业务系统,对运维人员的要求越来越高。为了方便运维人员获取知识,学习和解决问题,运维知识管理能力变得必要。运维知识管理应集成丰富的运维知识,可以帮助运维人员快速解决问题,提高工作效率。一般通过运维知识库系统
组建应急恢复团队 为了应对紧急故障场景,需要组建应急恢复团队,明确责任人,并进行培训。 风险等级 高 关键策略 组建应急恢复团队:其中包括应急恢复主席及所有组件及关键依赖项的恢复责任人。 应急恢复主席:在出现问题后及时组织应急恢复团队进行快速恢复处理。 组件或关键依赖项运维责任人:负责问题定位和应急恢复处理。
LTS助力某公司高效完成日常业务运维与等保合规 某公司是一家拥有IT,汽车及新能源三大产业群的新技术民营企业。2022年8月,公司入选2022年《财富》世界500强排行榜。 客户痛点: 业务部门较多,日志量较大,项目管理较为困难 云服务资源种类数量较多,监控指标和运维日志不熟悉,运维难度大
OPS03-05 进行混沌测试和演练 混沌工程(Chaos Engineering)是通过故障注入,验证故障快速恢复能力及系统可靠性的实践活动。 风险等级 高 关键策略 通过混沌工程的方法模拟可能出现的故障,进而综合验证系统在不同故障场景下的容错能力、监控能力、应急响应能力、定界定位、快速恢复等确定性恢复能力。
接入层(外部GSLB):通过外部GSLB进行域名解析与流量负载均衡,在单个AZ故障时自动将业务流量切换到另一AZ。 应用层(负载均衡器、应用软件及容器):对于无状态应用,通过负载均衡器进行故障检测与负载均衡,并可通过容器进行弹性伸缩。 中间件层:每个可用区各部署一套DCS、DMS Kafka集群。
异地恢复业务。 监控告警 支持业务运行状况、成功指标的检查,在发生故障时告警;支持ECS、DCS、Kafka、RDS、DDS等实例负载状态及资源故障切换等的监控,在负载超过阈值或状态异常时告警。 弹性扩缩容 支持自动弹性伸缩;针对ECS,通过ELB实现ECS实例的故障检测与负载均
VM中使用一个内部队列,这会消耗一定的资源。大多数场景下,使用最多5个优先级就够了。 如何确定消息大小 如何选择发往RabbitMQ的消息长度是一个常见问题。记住,每秒钟发送的消息数比消息大小更容易达到瓶颈。虽然发送大消息不是一个好的做法,但是发送多条小的消息也可能不是一个好的选择。更好的方
规和隐私保护准则,确保数据处理活动符合法律规定并尊重数据主体的权利。 风险等级 高 关键策略 使用个人数据前必须获取数据主体授权,使用范围及方法不能超出收集目的。 系统应将隐私保护的功能默认设置成保护状态。 使用个人数据过程中,必须保证个人数据的安全,如记录运营运维阶段对个人数据增删改、批量导出等操作。
应用层(负载均衡器、应用软件及虚拟机):对于有状态应用,通过SDRS服务实现跨AZ的虚拟机数据复制与容灾切换,并可通过CBR服务进行自动数据备份。 中间件层:Redis、Kafka集群跨可用区高可用部署,单个AZ故障对业务没有影响。 数据层:RDS与DDS数据库及OBS对象存储跨可用区