检测到您已登录华为云国际站账号，为了您更好的体验，建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
检测到您已登录华为云国际站账号，为了您更好的体验，建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
OPS06-04 规范化应用日志 日志是随时间推移发生的不可变、记录时间戳的离散事件。系统需要记录关键事件和故障，以帮助诊断问题和解决故障。 风险等级 高 关键策略 对于一个系统来说，日志是非常重要的。它可以记录在系统中发生的一切，包括成功的操作、错误的操作、警告信息等等。因此，日志记录是可观测性设计中最基本的需求之一
SEC03-03 定期审视权限 定期检视和更新权限，以避免权限蔓延，持续清理无用的权限。 风险等级 高 关键策略 使用IAM用户组控制人员的访问权限，并设置权限的到期时间。 如果用户组的职责产生变化，应该及时调整用户组的权限。 当账号委托给另一个账号时，设置到期时间。 通过IAM用户的
支持Java、Php、Python、Node.js、Docker、Tomcat技术栈。支持Apache ServiceComb Java Chassis（Java Chassis）、Spring Cloud等微服务应用，让企业应用上云更简单。
各个语言的冷启动时间为JAVA>GO>.NET>Node.js>Python。 选择合适的内存 在请求并发量一定的情况下，函数内存越大，分配的CPU资源相应越多，一般冷启动表现越优。 快照冷启动 Java应用冷启动速度慢的问题尤为突出。
COST07-01 持续监控资源利用率指标 风险等级 高 关键策略 持续地在组织中定义资源的核心利用率指标（如CPU利用率，内存，CDN服务的流量，数据库的TPS），按（天、周、月）等时间周期发现规律，对低利用率资源的应用/项目进行审查。 父主题： COST07 管理和优化资源
目前支持JAVA、Python、Node.js、Go、Php和.Net应用，具体的应用监控能力概览如下表。 父主题： 卓越运营云服务介绍
PERF04-01 定义验收标准 风险等级 高 关键策略 验收标准是用于评估指定工作负载是否满足性能要求的指标，需要在性能测试前期定义合理的验收标准。 查看性能目标 性能目标定义了工作负载所需的性能级别。查看为工作负载建立的性能目标。性能目标是可能涉及响应时间、吞吐量、资源利用率或任何其他相关绩效指标的指标
RTO与RPO 灾难场景通常采用RTO和RPO目标定义： 恢复时间目标RTO：指灾难发生后应用不可用的最长时间。RTO决定了应用容灾整体架构，是采用数据备份，还是冷备、温备、热备。 恢复点目标RPO：指灾难发生后应用数据丢失的最大时间。RPO决定了数据备份频率或复制方式，是在线备份还是离线备份
卓越运营支柱简介 在华为公司，卓越运营代表着质量、效率和可持续的卓越客户体验。它帮助改进设计、开发、测试、部署、发布和运维活动，持续实现高质量的交付结果，推动了持续集成和持续交付（CI/CD）落地；同时助力打造确定性运维体系，让研发团队将更多时间用在构建让客户受益的新功能上，减少用于维护和处理突发事件的时间
RES11-04 灾难演练 通过容灾演练，可以验证灾备系统是否可用，且数据丢失时间以及恢复时间符合数据的RPO与RTO指标要求。 风险等级 高 关键策略 灾难演练着重测试服务跨AZ或跨Region故障转移能力，验证系统的容灾能力以及面对灾难时的应对能力，涉及到多个团队间配合，通常作为专项开展
COST06-02 为工作负载选择合适的计费模式 风险等级 中 关键策略 分析工作负载的每个组件。确定组件和资源是长时间运行（应享受承诺折扣，包年包月或购买资源包），还是短时间动态运行（采用 Spot 或按需定价）。使用成本管理工具中的建议对工作负载执行分析，并对这些建议应用业务规则以实现高回报
内部知识管理类应用典型部署架构（99.9%） 内部知识管理类应用通常用于内部操作，且在故障时只会对内部员工造成影响，可以承受较长的恢复时间和恢复点，其可用性目标通常要求达到99.9%，即每年中断时间可以为8.76小时。 导致业务中断的时间包含故障中断时间及由于升级配置维护等导致的中断时间
RES04-04 定期进行容灾演练，以检查恢复能否满足容灾目标 通过定期的容灾演练，可以验证灾备系统是否可用，且数据丢失时间以及恢复时间符合数据的RPO与RTO指标要求。 风险等级 高 关键策略 每年至少进行一次容灾演练；通过演练可提升操作人员的熟练程度。 演练期间需要对恢复过程计时
可用度及SLO 可用性目标用于衡量应用系统的运行时间和停机时间，其表现形式为应用系统正常运行的时间占总时间（通常是一个月或一年）的百分比（如99.9%），即： 可用度 = 可用时间 / 总时间 * 100% 常见的简单表达方式用“9”的数量或“9”的数量加“5”表示，如“三个9”表示
金融类核心应用典型部署架构（99.999%） 金融类核心应用通常比较重要，要求非常短的恢复时间和数据丢失量，其可用性目标通常要求达到99.999%，即每年故障时间可以为5.26分钟。 假定故障中断与变更中断的时长分别如下： 故障中断：由于要求的故障中断时间很短，要求尽可能自动恢复，
内部工具或公测类应用典型部署架构（99%） 内部工具类应用通常用于内部操作，且在故障时只会对内部员工造成影响，不可用时只会带来不方便，可以承受长时间的恢复时间和恢复点；公测类应用用于面向客户的实验性的工作负载，在必要时可以隐藏其功能；针对这些应用，其可用性目标通常要求不高，可达到99%
RabbitMQ性能优化 保持尽可能短的队列长度 太多的消息堆积在队列中会造成内存负载过高，为了释放内存，RabbitMQ 会把消息转存到磁盘，转存过程会耗费大量时间，造成消息处理速度下降或直接阻塞生产流程。因此队列中堆积过多的消息容易对 broker 产生负面效应。除此之外，如果节点崩溃后重启
Kafka性能优化 Kafka性能优化 优化客户端配置 生产者配置建议 可参考配置建议。 消费者配置建议 参数 推荐值 说明 max.poll.records 500 消费者一次能消费到的最大消息数量，默认为500，如果每条消息处理时间较长，建议调小该值，确保在max.poll.interval.ms
PERF03-09 选择合适的RabbitMQ 风险等级 中 关键策略 版本选择：RabbitMQ服务版本随时间更迭，选择版本时需注意查看不同版本状态与区分，详情可参考官方公告。 规格选择：RabbitMQ服务提供了不同规格实例可供选择，建议按照业务需求对比，选择合适的规格型号，具体实例规格请参考官方文档
RES02-01 识别和备份应用中所有需要备份的关键数据 不同数据的重要性不一样，针对应用系统内的所有数据，需要明确其重要性及对应的RPO/RTO指标要求。比如对于重要数据，通常允许数据丢失的时间会比较少，从而需要更频繁的备份；对于一般的数据，允许数据丢失的时间比较长，可以使用较低的备份频率
长按/截图保存，微信识别二维码
或者关注公众号“华为云”
