确定性运维白皮书-稳定可靠篇2.0

稳定可靠篇2.稳定可靠篇2.0让运维成为智能世界变革的加速器（排名不分先后）廖声伟黎宏刚（按姓氏笔画排序）余晖杨晓赵凤海聂刚黄城景帅谢文敏雷厚卿蔡（按姓氏笔画排序）李超群吴文辉贺丽萍韩江荟（按姓氏笔画排序）本资料内容仅供参考，华为云计算技术有限公司不对本资料所有内容提供任何明示或暗示的保证，适销性或者使用与某一特定目的的保证，在法律允许的范围内，华为云计算技术有限公司在任何情况用本资料任何内容而产生的任何特殊的、间接的、继发性的损害进行赔偿，也不对任何利润、数据、节约的损失进行赔偿。（内部发行，免费赠阅）版权归属版权归华为云计算技术有限公司所有，保留一切权利。非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的CONTENTSCONTENTS前言前言---------------------------------------------------------------------------------------------01第一章确定性运维稳定可靠之路------------------------------------------------------03母母第二章运维管理体系能力实践---------------------------------------------------------07第三章运维技术体系能力实践---------------------------------------------------------09第四章高可用能力实践-------------------------------------------------------------------12 第五章持续交付能力实践----------------------------------------------------------------49CsCs第六章运维能力可信实践----------------------------------------------------------------56 第七章风险治理能力实践----------------------------------------------------------------93 第八章资源治理能力实践---------------------------------------------------------------112 第九章安全合规能力实践---------------------------------------------------------------135 当企业的IT智能化水平不高时，对IT运维运营的业务连续性要求并不严格。随着科技的进步和市场竞争的加剧，企业在数字化转型的浪潮中迎来了新的挑战与机遇。在这一转型过程中，企业的生产力发生了深刻的转移，从传统的依赖人工操作和有限的信息处理能力，转变为高度依赖智能化的IT系统和数据分析能力。传统运维模式在应对数字化业务需求时，显得力不从心。随着信息技术的迅猛发展，大对运维工作提出了更高要求。因此，从运维入手进行数字化转型，不仅是对技术的升级，更是对业务流程和管理模式的全面革新。这一变革使得企业对业务“安全可靠”的依赖程度大幅提升。在数字化时代，企业的运营数据、客户信息和业务流程都高度集中在IT系统中，一旦系统出现故障或数据泄露，将对企业的运营和声誉造成巨大损失。因此，确保IT系统的稳定运行和数据安全成为了企业不可忽视的重要任务。同时，数字化转型也提升了企业对业务“智能运营”的需求。通过大数据分析和人工智能技术，企业能够实现对业务数据的实时监控和预测分析，从而更精准地把握市场趋势和客户需求，优化业务流程和决策过程。这种智能运营能力不仅提高了企业的运营效率，还为企业带来了更多的商业机会和创新空间。此外，数字化转型还提升了企业对“资源高效”的诉求和“业务敏捷”的要求。在数字化时代，企业需要能够快速响应市场变化和客户需求，同时实现资源的优化配置和高效利用。这就要求企业具备强大的IT基础设施和灵活的运维管理能力，以确保业务的快速部署和稳定运行。确定性运维作为保障企业业务高效稳定运行的重要一环，其核心在于确保系统的稳定性、可靠性以及高效性，从而助力企业实现安全可靠、智能运营的目标。确定性运维旨在构建可防、可控、可治的运维管理体系。首先是通过高质量的产品开发，严谨的运维流程和制度来降低故障的概率，要挑战零故障，同时也要有技术手段对可能发生的故障，将间隔、影响范围及故障恢复时间做到可防、可控、可治，要把数字化带来的“不确定性”通过运维变成“确定性”。在确定性运维的推动下，企业可以实现资源的高效利用。通过合理的资源规划、分配和调度，企业能够避免资源的浪费和闲置，提高资源的利用率。此外，确定性运维还能够通过自动化、智能化的手段，降低运维成本，提高运维效率，为企业节省大量的人力和物力资源。业务的敏捷发展是确定性运维的另一大目标。随着市场竞争的加剧，企业需要能够快速响应市场需求，调整业务策略。确定性运维通过提供快速迭代、持续集成的运维环境，帮助企业加快业务创新的步伐，可以帮助企业更快地响应市场变化，提高效率和生产力，提高客户满意度。展望未来，确定性运维在数字化转型中的作用将更加凸显。随着人工智能、大数据等技术的不断发展，确定性运维将实现更高级别的自动化和智能化。通过引入机器学习算法和数据分析技术，运维人员能够更精准地预测系统性能、优化资源配置，进一步提升系统的稳定性和可靠性。在数字化转型过程中，运维团队扮演着至关重要的角色。他们需要对现有系统进行深入分析和评估，识别出潜在的优化点和改进空间。同时，还需要积极引入新技术和新工具，提升运维的自动化和智能化水平。通过构建高效的云管平台，实现资源的统一管理和优化调度，从而提高企业的运营效率和服务质量。数字化转型不仅涉及技术的升级和工具的引入，更需要对企业的组织架构和业务流程进行深度优化。通过优化组织架构，打破部门壁垒，实现跨部门协同作战，提高企业的响应速度和创新能力。同时，对业务流程进行重塑，实现业务的数字化和智能化处理，进一步提升企业的运营效率和市场竞争力。可以说，确定性运维已经成为数字世界变革的加速器，是新质生产力的核心组成部分。它不仅推动了企业数字化转型的深入发展，还为企业带来了更多的商业价值和竞争优势。从运维入手全面启动数字化转型是一个复杂而系统的工程，需要企业高层领导的重视和支持，以及全体员工的共同努力和协作。通过引入新技术、优化组织架构、重塑业务流程、保障数据安全等措施，企业可以逐步构建出符合自身特点的数字化转型路径，实现业务的全面升总之，确定性运维可以确保企业在安全可靠、智能运营、资源高效、业务敏捷四个维度上实现业务目标。而安全可靠中的稳定可靠是企业数字化转型的生命线，本册白皮书，我们将重点探讨如何从管理体系和技术体系的角度构建确定性运维稳定可靠体系，帮助企业实现运维体系的革新，支撑企业的业务数字化转型。第一章确定性运维稳定可靠之路.确定性运维的稳定可靠实现之路是一条系统性和综合性的路径，基于华为云实践总结，确定性运维的稳定可靠实现之路是一条系统性和综合性的路径，基于华为云实践总结，需要从质量文化、高可用架构、动态风险治理以及智能运维工具这四个方面全方位入手。质量文化是基础高可用架构是前提动态风险治理是保障 稳定可靠体系框架图1.质量文化质量文化是确定性运维的基石。一个注重质量的文化能够激发团队成员对运维工作的责任感和使命感，从而确保工作的精细化和标准化。为了构建高质量文化，需要：2.高可用架构高可用架构是确定性的前提，通过设计合理的架构，可以降低系统故障的风险，缩短故障恢复的时长，并且控制故障的影响范围，高可用架构的设计与落地需要关注如下三点：a.瞄准SLO的目标，运用科学的方法进行架构的设计，对可用性架构的选择以及落地时间进行管理；b.在产品规划设计、上线运行阶段，给运维团队授予相应的责权利，对开发和商用计划有所制约，确保可用c.在产品运行维护期间，有计划地对高可用设计进行验证，以确保系统符合设计要求。3.动态风险治理动态风险治理是应对不确定性和突发事件的重要保障手段。其本质也是对变更、故障模式、业务运行数据的识别开展全生命周期的主动运维和能力构建：a.针对变更作业的风险，开展全面的能力建设，包括版本发布架构体系建设、账号权限管理、自动化变更能b.针对已知和未知的故障风险，通过科学的方法梳理故障模式库（树），并目的地进行快恢能力建设，一方面制定应急预案和响应机制，确保在突发事件发生时能够迅速响应和处理，另一方面定期组织演练和复盘，验证可用性架构运行情况以及团队应急响应能力；c.业务运行态数据的智能运营，是指导团队开展工作持续改进的核心基础能力，需要构建一套实时的采集以及数据运营系统，以支撑业务决策。4.智能运维工具智能运维工具能够提高运维工作的效率和质量，降低人力成本。尤其是AI时代，通过引入自动化、智能化等技术手段，团队可以更加高效地管理和维护系统，有几个原则：a.选择合适的工具和技术，确保其与业务需求和技术栈相匹配，如自动化部署、故障预测、智能定界定位等；b.将工具与现有系统进行整合，根据实际需求进行定制和优化，以满足特定的运维需求；c.关注新兴技术和发展趋势，不断更新和升级智能运维工具，提升运维水平。确定性运维的达成确实是一个自上而下、全技术团队共同努力，以及意识、组织、文化、方法和模式的转变。转变意识是达成确定性运维的首要任务。团队成员需要认识到运维不仅仅是一个支持性的角色，而是业务连续性和稳定性的关键保障。这要求大家从传统的“救火队员”角色转变为前瞻性的“守护者”，以预防性的思维来规划和执行运维工作。2.转组织组织结构的调整对于实现确定性运维至关重要。团队需要打破传统的部门壁垒，建立跨部门协作的机制，确保从开发到运维的各个环节能够无缝衔接。同时，建立明确的责任划分和沟通渠道，确保问题能够迅速定位和解决。3.转文化企业文化的转变是实现确定性运维的重要支撑。团队需要倡导一种注重质量、向前端要质量的文化氛围。鼓励成员开放、合作、创新的文化氛围。此外，建立奖惩机制，对质量工作中表现突出的个人或团队给予表彰和激励、同时也对忽视质量的团队和个人予以警示。4.转方法方法的转变是实现确定性运维的关键环节。团队需要引入先进的运维理念和技术手段，如自动化、智能化等，提高运维效率和质量。同时，建立标准化的操作流程和监控体系，确保运维工作的规范化和一致性。此外，利用数据分析和预测技术，提前发现并解决潜在问题，降低故障发生的概率。5.转模式模式的转变是实现确定性运维的长期保障。团队需要探索并建立适合自身业务特点和技术栈的运维管理模式。这可能包括采用DevOps理念实现开发与运维的紧密结合，建立敏捷的响应机制以快速应对突发事件等。通过模式的创新，不断提高运维工作的灵活性和适应性。︵技术体系︶︵管理体系︶“︵技术体系︶︵管理体系︶“N”能力“1”标维确定性运维白皮书确定性运维白皮书稳定可靠能力全景持续交付持续交付生产准备度评审生产准备度评审监控设计架构高可用设计业务可用性度量运维组织运维组织运维能力可信运维能力可信理理测程恢警能快管沌压工障风险治理风险治理运维流程运维流程安全合规安全合规资源治理资源治理成容出成容出海运维合规安全生产本量本量管管管管理理理理运维工具运维工具稳定可靠“1+N”：“1”为标准化运维，即为管理体系，“N”为稳定可靠专基于ITIL标准构建标准化运维，建立三线运维支撑团队，建立覆盖关键运维活动的六大领域能力下有多个专项能力。一.专项能力定义N个专项能力，包括：》运维能力可信：故障快恢、混沌工程、性能压测、告警管理；》风险治理：变更风控、护航、运维驱动运二.能力体系升级数以万计的客户，虽然所运维的对象不同，但是面对的挑战却有不少的共同之处。当企业在业务快速增长、数字化转型或深入云化改造，可能遇到可用性管理、责任分工、容量管理、云资源配置、安全生产、效率提升、智能运维能力构建等问题，华为云SRE将自身的“稳定可靠”实践结合云上应用维护实践，梳理出如下适用于业务系统的“稳定可靠”体系，相较于传统运维体系，有如下变化：》传统运维关注问题快速定界定位，关注产品的可维护性，稳定可靠体系中，运维团队不仅关注可维护性，更多地参与到产品的架构设计中，落实“产品高可用架构”；》传统开发模式下版本交付经过较长周期的质量管理且变更并不频繁（趋于稳态），但现在多数企续交付”流程（趋于敏态），为保障业务稳定，须强调自动化变更及管控，以降低高频变更带来的风险；》传统业务体量小的时候，安全合规的压力并不大，业务上云后体量变大，DevOps模式下交付越发频繁，参与团队增多，安全生产的压力越来越大且能力诉求越来越高；》基础设施云化以后，面对种类繁多的云化资源（包括OS、网络、数据库、容器等），需》传统运维模式使用的工具通常以ITSM工具为主，主要满足运维管理要求。稳定可靠体系中，由运维/运营团队瞄准MTTR和效率、成本目标，基于日常活动，自行设计、集成或采购工具以提升质量和作业效率。第二章运维管理体系能力实践0101管理体系背景在确定性运维1+N体系中，“1”的能力建设称之为“管理体系”建设。随着企业数字化转型，当前运维管理体系正在面临颠覆性的变化和转型。业务范畴从保障网络、设备资源的稳定到涉及企业业务应用稳定和研发业务敏捷开发的支撑等，同时企业在快速发展过程中，多云环境以及大量业务系统需要运维管理。当前企业运维遇见一些问题：1.系统规模和复杂度增加，导致的运维难度和运维成本增加。2.多云环境下的资源管理和数据管理难度增大，业务的监控和故障排查难度增加。3.安全合规管理中所涉及人员现网操作管理，导致的更多资源精力投入。但企业发展早期形成的管理体系在分工、协作、效率、成本和可持续化发展上，通常并不能很好的适配。因此非常多的企业诉诸运维体系转型，通过引入合适的运维管理体系和先进的理念及技术，不断提升运维能力，以应对确定性运维管理体系助力运维变革，使运维成为数字化转型的生产力。运维管理体系的理论研究与企业实际转型过程中的问题并无法通过简单的推演获取，这就导致企业需要付出的高昂的经济和时间成本去摸索和积累。确定性运维管理体系来源于华为云SRE多年实践，既强调标准为纲，也重视经验总结。主要包含组织、流程、工具三个核心要素组成，规划了组织架构和岗位，优化和重构了全生命周期的流程框架，统筹布局了工具体系，使运维管理工作不断走向规范化、标准化、工具化，在质量和效率上获得提升。…运维合规管理可用性管理变更服务修复服务请求……采集工具确定性运维“一个”标准化运维体系…运维合规管理可用性管理变更服务修复服务请求……采集工具确定性运维“一个”标准化运维体系监控中心组运维管理组运维实施组可用性管理组质量管理组质量管理组………确定性运维管理体系示意图0202管理体系实践企业确定性运维管理体系优秀实践企业确定性运维管理体系优秀实践流程体系重大事故处理事件转问题实施提交变更流程体系重大事故处理事件转问题实施提交变更变更完后更新配置库 自动发现故障变更引入事故 告警管理应急演练/混沌工程-4首次上线/大版本上线小版本迭代 验收转维-应用上线/生产准备度评审-交付实施-安全生产账号权限授权管理应用上线规范版本发布组织架构组织架构工具体系流程驱动团队改进团队改进，提升流程作用流程驱动团队改进质量管理团队质量管理团队数据运营团队一线运维团队二线运维团队研发团队数字化可观测中心配置管理流程管理运营中心协同、集中、统一的运维工具体系数字化可观测中心配置管理流程管理运营中心企业确定性运维管理体系优秀实践示意图其运维组织架构是一种阶梯式的分工和协作架构，区别于传统运维架构，它大幅度缓解了高成本的人力资源投入到低价值的活动中造成的不合理投入和成本浪费，同时规避了低成本的资源由于高价值资源的投入引起的惰性和依赖性，从而滋生的一些意识形态的对抗和埋怨。此架构中，一线负责受理用户的服务请求、响应并处理客户反馈问题处理监控发现问题，部分时间处理告警、事件和故障的恢复，其余时间开展高阶主动运维活动，对现网的稳定性和可用性负责；三线聚焦解决软件版本缺陷问题。这种分工方式具备明显的阶梯型，三条线即需要独立完成相当比例的工作，也需要相互协同和促进，非常有助于消除运维的冗余和低效的环节，可以实现企业人员高效率与饱和化的运作。流程体系涵盖了产品全生命周期运维活动，它驱动了不同分工团队在业务和体系上的融合和发展。确定性运维流来避免人为因素对整体稳定性和效率的影响，提升管理体系能力。包含事件、问题、变更、回溯等多个核心运维但在企业实践中仍需充分考虑自身系统的复杂性和变化性，进行特定设计调整，并测试和验证。运维工具是管理体系和组织效能的催化剂，在效率、可靠性、安全性、可用性和管理水平等多个方面都发挥着重要作用。运维工具是实现高效、稳定、安全的运维管理和提高业务运营效率和质量的重要手段，确定性运维管理体系可运营的能力支撑。一个优秀的工具体系能够向运维人员提供集中、统一的维护界面方便运维人员的集中维护，提优秀实践案例中，企业已初步完成了基于确定性运维理念的运维体系构建。第一，运维活动在流程体系的指引下，已形成高效协同，大幅度削减了内部沟通成本。第二，运维业务根据场景分散到不同的成本中心，三线运维机制下各运维团队既可独立完成自身运维业务，也可在流程体系驱动下与上下游协同，不断的优化组织结构和流程体系。第三，运维工具覆盖日常运维业务、运营管理、质量管理等，通过持续的运维过程数据分析，不断提升运维工具能引入自动化、智能化元素，简化运维交付工作，降低技能依赖和安全合规风第三章运维技术体系能力实践在确定性运维1+N体系中，我们将在确定性运维1+N体系中，我们将N能力建设称之为“技术体系”建设，是指对基础设施、中间件、业务系统和网络进行监控、管理和维护的一系列技术手段和实践的组合。随着业务数字化转型的深入，业务规模的快速增长及业务频繁更新，现网稳定性和业务上线速度之间的冲突加剧，引领运维变革的导向和向心力，明确实施路径，构建全面确定性运维能力体系，保障业务可用性目标达成。企业存在的部分现状问题摘选：1可用性目标不清、未构建SLI指标体系，未建立SLO生命周期管理机制；产品的SLO承诺未与用户及利益相关人的期望形成互锁，导致落地效果差，无法支撑可用性运营管理及业务持2系统架构高可用未形成规范并有效执行，依靠个人经验导致高可用设计能力不足，如：可故障管理、过载控制、故障隔离、超时与重试等引发现网故障，造成企业业务损失3企业业务系统庞杂，分层监控指标覆盖不全，监控分散在不同的工具上，难以统一监控，业务的黄金可用性指标覆盖不全，无法实现异常快速感知、快速4业务系统发布上线前，非功能性需求的生产准备度评审不完善，导致风险识别和闭环不到位，部署到生5缺乏统一的故障管理标准和流程，无法实时监控和预测故障，缺乏有效的故障管6应急演练资源投入不足，覆盖范围有限，演练频率不足，影响应急预案的有效性验证，进而影响故障恢7产品发布前的测试不充分，尤其是产品性能和全链路方面。当业务量激增的情况下，现网业务稳定受到8告警数量多、告警不准确、大量无效告警引起告警泛滥，且处理效率低，导致运维资源投入增加，也影9存在变更风险审视不足引入现网事件，未有效降低变更操作的风险；当前还是依靠专家进行变更方案的缺少有效的保障机制和能力，运维风险未能有效识别和制定预案，业务高峰期，经常出现影响服务可用数据来源不统一，也未构建运维数据的标准，数据质量问题会影响数据分析和决策的准确性，运维人员通常缺乏数据分析能力，无法深入挖掘数据背后的价值，导致数据无资源利用率低，缺乏可视化和实时监控机制，预测和规划不准确资源利用率低，使用成本高，资源不可视、不可管，难以精准发放、回收，难以实现成企业业务走出国门，尤其是向欧美发展，但是没有匹配本地法律法规的运维团队和机制，有数据安全与确定性运维构建了高可用、持续交付、运维能力可信、风险治理、资源治理、安全合规六大领域的主动运维能力，涵盖了从设计态、部署态到运行态的全生命周期的技术能力。通过专项能力的实践分享指导企业解决运维过程中高可用能力是现网高质量的源头，是围绕质量结果不断溯源优化和迭代的过程。在华为云发展过程中，对高可用能力进行了优化和迭代。这个过程分为四个阶段：第一阶段重点讲事件数据在线化，主要目标是以现网数据运营为驱动力，通过收集和分析现网的数据，来发现和解决现网中的重要问题。第二阶段讲的是华为云主动识别现网问题，分析高可用架构的短板，通过混沌工程来演练和解决这些问题。第三阶段是高可用的正向设计能力，华为第四阶段重点讲量化关系研究，华为云开始研究站点质量要素与高可用质量结果之间的量化关系，建立站点熵与质量确定性之间的数学关系。华为云开始尝试用数学模型来量化站点的质量和高可用的关系，以便更好地理解和管理现网的质量。这四个阶段形成了一个迭代的过程，华为云通过不断的迭代和优化，提升了其高可用的能力。持续交付是运维全生命周期中部署态的关键过程，本次重点分享生产准备度评审(PRR)能力实践。华为云生产准备度评审借鉴业界SREPRR模型，与服务开发团队共同完成提升运维能力的相关需求规划、设计和开发工作，使产品能够高质量快速上线。在商用发布前需要进行一系列可用性评审，只有通过PRR标准基线的验收才能进行版本发布，确保版本发布质量。运维能力可信是运维全生命周期中运行态的一类技术能力，本次重点分享在故障快恢、混沌工程、性能压测、告警管理等能力的实践。故障快恢的核心构建重大事件的快速发现、快速定位和快速止血的能力，华为云在故障快恢能力上已经积累了丰富的实践经验。可观测能力的建设是面向上层的业务系统，要聚焦业务系统的运行状态进行观测感知，并辅助运维人员主动识别业务系统的健康度，构建先于客户发现故障的能力；华为云SRE事故恢复团队从冗余、容灾、超载、依赖、安全和数据备份6大场景构建了200多种故障模式库，并完成预案的开发，通过混沌工程不断进行预案的演练，确保预案的有效性和确定性。通过告警ID关联故障模式库ID，故障模式库ID来推荐已验证过的应急预案的能力，实现故障场景和恢复预案的精确匹配，实现故障的快速恢复。性能压测管理确保业务系统可以在达到设计最大负载（或QPS）时依然可以正常运行，压测管理通常包括负载测试和压力测试，以模拟生产环境中的实际负载情况。告警管理是通过减少无效告警和衍生告警的数量，提升告警准确率和先于客户发现率，减少对运维人员的干扰。运维风险治理是运维全生命周期中运行态的另一类关键技术能力。变更风控是基于“人因”方法论构建了作业可信体系，从组织、流程和工具能力进行变更风险的拦截，降低变更引入事件率。数据驱动运营是构筑确定性运维的基石，借助数据治理和数据运营能力实现察打一体“察（数字化BI看板）”“打（业务决策与执行）”，帮助运维人员构建数字化运营能力，实现提质增效的目标。资源治理从容量管理入手，建立了云资源的性能规格基线，以确保云资源的扩容有据可依。同时，我们建立了CPU、内存、磁盘、带宽等的容量水位线，通过资源管理可视化大屏，可以掌握资源利用情况，及时指导云资源的扩缩容。通过成本中心进行精细化成本管理，我们可以预测、预算、分配、监控全场景可视化，持续优化客户使用云资源成本。我们始于可视化和跟踪成本规划，并在运行时及时管控异常，避免意外高额账单。在使用过程中，我们更要关注成本分配，让业务部门成本透明。最终，通过规划与创新，我们对云上资源、数据成本进行优化，达到安全合规建设当前版本聚焦于运维安全生产和出海运维合规的建设。安全生产的目的是确保各项运维活动在满足运维管理要求的同时，提高运维管理的效率和质量，降低运维风险和成本，增强企业的安全生产能力。安全合规作为网络安全的一部分，依赖专业的技术工具及团队，从人员资质、运维通道、运维工具等方面确保运维安全可信。建设资质中心，明确华为云运维岗位人员资质的管理原则和总体要求，防止因人员资质带来的现网安全问题；运维堡垒机包含主机管理，授权管理，账号密码管理等功能，以实现安全运维和轻松审计。网络安全给全球各行业带来巨大威胁，各国积极立法进行网络安全保护实施，全球150+国家已将网络安全/数据安全保护进行立法，中资企业出海的运维合规存在诸多挑战，需探索行稳致远的合规之路。可从管理能力和技术能力等方面进行建设，保障业务稳定、数据安全、质量可靠、作业可信，全球化运维，数据处理遵从本地法规，助力业务全球扩展。通过人员外派第四章高可用能力实践4.1业务可用性度量（SLO/SLI）设计4.1.1业务可用性度量（SLO/SLI）设计目的数据为依据促进研发和运维协同不断优化业务可用性平衡各团队的指标和帮助企业更好的设计和管理业务系统可用性。在产品规划与设计阶段前，设置业务系统可用性度量评估环节，提前评估当前可承诺的真实可用性目标，以及业务系统在现网运行中验证实际可用性，并对业务4.1.2业务可用性度量(SLO/SLI)设计能力通过SLO度量，研发团队有明确的改善业务系统有效进行质量改进，因此SLO可用性度量指标的达成，需要多个组织的角色共同参与完成，严格遵循SLO中每个产品上线立项规划产品实现否是产品上线立项规划产品实现否是 是否通过产品负责人干系人可用性架构师经理业务可用性度量流程示意图SLO/SLI度量流程包含：》产品负责人或研发负责人负责产品的立项规划，需根据产品商业要求，设定SLO目标，交付可用架构师进行高可用能力设计。》SLO设计：可用性架构师根据SLO目标，》产品实现：根据SLO设计进行产品可靠与可用能力详细设计与开发，并测试验证。》产品开发通过测试后，由研发团队自评，自评通过后提起PRR上线评审。》产品上线：PRR上线评审通过后，由运维经理联合产品负责人发布评审结论，产品部署上线。业务可用性度量体系主要由两套工具来承载。能力划分如下：1.SLO可靠可用设计工具，主要给予产品、研发人员、可用性架构师角色使用和参考。SLO设计SLISLI设计可靠可用架构设计可靠可用组件库负载均衡仲裁…可用性设计管理平台功能框架图业务SLO可用性度量（SLO计算）、SLO对问题分析跟踪的运营运维角色使用和参考。SLOSLO运营SLO度量SLI监控需求跟踪可用性运营管理平台功能框架图一.业务系统架构SLO评估技术能力分析业务系统的核心功能及组成核心功能的业务单元，由每个业务单元的可用度推算出整个业务系统的可用度，因此评估方法将上溯到每个业务节点粒度进行可用度计算（物理机、虚拟机或者容器实例然后基于RBD模型框图的可用性计算为基础方法进行可用度计算。RBDRBD(ReliabilityBlockDiagram)模型1+1主备》Aa：主用单元可用度》等效的修复率简单参考主用修复率，为u。》等效失效率根据修复率和可用度采用入等效=u(1-A)获得N+1冗余A=1-czx[1-a"x(N+1-Nxa)]=N+(1-cz)x(1-a")÷(N+1)}A=A。+C*(l-A,)*A在此基础上分析其他中断因素并建模，逐项叠加到基础模型上。实现整个SLO评估模型的建模工作。同时使用CMDB应用拓扑实现业务之间的RBD框图，结合各模块SLO计算权重，并在业务SLO服务中断服务中断软件因素（含依赖服务不可用）外部因素软件因素（含依赖服务不可用）外部因素（流控/安全）运维因素（变更）基础设施因素基础设施因素串联服务可用性评估公式S(1)S(2)S(n)S(1)S(2)服务串联可靠性功能框图在串联服务中，任何依赖服务失效，都将导致本服务的业务故障。如果本服务由n个依赖服务组成，那么本服务的最终可用度指标的评估公式表示如下：——串联后的服务可用度——第i个依赖服务的可用度——依赖服务个数从串联公式，我们可以得到以下结论：》系统中任何单元的可靠性降低（提高），那么整个串联系统的可靠性降低（提高）。》系统中串联的单元数增加（减少），那么整个串联系统的可靠性降低（提高）。》串联系统的可靠性低于串联系统中任一单元的可靠性。12并联服务可用性评估公式12(a)(a)n并联结构示意图在并联服务中，所有依赖服务都是同时处理同一个业务的，任何一个依赖服务处理成功，本服务的业务处理都会成功，所以本服务的不可用是所有依赖服务同时不可用，如果本服务由n个依赖服务组成，那么本服务的最终可用度指标的评估公式表示如下：A并——并联后的服务可用度Ai——第i个依赖服务的可用度n——依赖服务个数从并联公式，我们可以得到以下结论：从并联公式，我们可以得到以下结论：》系统中任何单元的可靠性降低（提高），那么整个并联系统的可靠性降低（提高）。》系统中并联的单元数增加（减少），那么整个串联系统的可靠性提高（降低）。》并联系统的可靠性高于并联系统中任一单元的可靠性。11(a)(a)2S2SN+M主备服务可用性评估公式如下：其中的是二项系数，或者称为组合数，也会记为CNi。(a)(a)1233需要N个节点协作才能完成，M个节点冗余，故障节点数大于M，则集群整体不可用。与N+M主备的区别在于，M个冗余节点也要负荷分担的处理业务。N+M负荷分担在c：倒换率－成功倒换的概率，通过故障检测率乘以倒换成功率计算。AN+1=1-{CX[1-aNX(N+1-NXa)]+(1-C)x(1-aN+1)}SLO运营的目标：通过持续度量现网SLO，分析影响业务SLO的事件，及时响应治理，最终保障可用性目标达成。通过拨测从用户视角感知业务可用性，对影响业务可用性事件，使用RBD框图逐层下钻分析定位影响SLO的部件或根因，通过架构优化（如增加流控能力、灰度升级避免业务中断）与运维质量改进（如自动化变更避免人因操作YYN高可用架构分析架构优化运维质量改进架构优化运维质量改进持续运营持续运营SLO运营的目标：通过评估服务设计态的可用性，识别可用性的需求，形成产品的需求基线，跟踪需求的进展，最终实现产品的高可用性目标。1.SLI拨测监控模拟外部用户，基于服务关键接口进行拨测监控，实时发现服务不可用。基于拨测监控可用性计算方式：SLO=(SLI*权重)/度量时长2.SLO可用性度量基于拨测监控数据，绘制SLO看板，实时度量服务SLO可用度，并及时处理影响SLO事件。为了实现业务系统可用性准确度量，可采用以下三个层级视角：实时评估数据、可用性SLO基线、WarRoom应急响应视角第一层：大屏化呈现服务按功能SLO实时评估数据。第二层：高可用性的需求基线，按季度进行需求排序，大屏呈现各个服务的需求状态信息。》服务的高可用需求总数，接纳率，已交付率；第三层：WarRoom数据分析：服务需求的命中需求总数，非命中需求总数，遗漏需求总数，需求命中率。3.RBD框图分析依赖服务依赖服务依赖服务依赖服务数据库数据库数据库4.高可用架构分析与优化补充说明单点，灰度需要架构进行改进：详细参考架构高可用设计章节。5.WarRoom事件分析与运维质量提升违规操作、变更、攻击事件、和架构没关系的事件。4.1.3业务可用性度量(SLO/SLI)设计实践分享以中间件服务管理面的SLO评估为例，对评估过程进行示例介绍。参考2023年重点服务SLO目标，分布式消息服务2023年达标值为99.97%，挑战值为99.99%，我们对分布式消息服务的可用性SLO评估目标为挑战值二.识别被评估服务的核心功能通过获取对应服务API信息，对服务API是否核心功能进行创建实例（按需）是是是是三.基于核心功能绘制RBD模型框图通过核心功能的识别，确定相关服务和组件关系，如下RBD模型框图所示：分布式消息服务-P分布式消息服务-P分布式消息服务-分布式消息服务-A依赖服务C依赖服务C云服务依赖服务A云服务依赖服务A依赖服务依赖服务D依赖服务B分布式消息服务分布式消息服务四.按照软件集群评估故障检测和恢复能力故障检测和恢复能力的评估，需要按照节点、集群和服务层面分别评估分布式消息服务节点的故障检测和恢复能力、集群的变更中断处理能力和业务系统的流控过载能力。1.节点的故障检测和恢复能力评估通过下表对分布式消息服务的故障检测和恢复能力进行评估，可以获得故障检测率为：11.5/16=71.875%，平故障描述（供参考）2.变更中断可用度评估根据变更中断可用度计算方法，统计各个region的全年自动化变更次数和手工变更次数TOP10，根据公式计算变更中断可用度扣减值如下表，选取影响最大的region作为评估值。Region12Region2278124.2545624Region33.流控过载可用度评估根据流控过载/安全攻击可用度计算方法的评估方法：过载CheckList（管理面）（数据面）具备能力（是100%，否0，不完全50%）SLO评估项占比10%10%15%15%50%通过下表对分布式消息服务的流控过载能力进行评估可以看到，暂不具备完善的流控过载能力，有部分过载感知和过载溯源能力，通过N+M分布式可用性评估公式的计算方法可以获得流控需要扣减的时间=92分钟*[数SLO评估占比，是100%，否0，不完全50%10%15%15%50%应用平台务否不完全流量看板不完全流量看板否五.依据上述参数计算业务系统可用度根据上述规则和参数，从RBD模型框图中，可以看出分布式消息服务管理面是先并联再串联的结构，所以需要先分别计算并联节点的可用度，再计算串联后可用度，根据扣减规则进行整体扣减获得最终的预估可用度。计算分布式消息服务-A集群的可用度为99.93009357%，计算过程如下：根据N+M分布式可用性评估公式AN+M=Mi-oCNi+M(1-a)iciaN+M-i，对相关参数进行实例化。分布式消息(1-软件BUG扣减（0.000856%）)*ECS承诺可用度（99.97%）=99.969144%；参照故障检测和恢复能力的评将上述参数带入公式AN+M=Mi-oCNi+M(1-a)iciaN+M-i中，则A1+2=2i-oC3i*(1-99.969144%)i*71.875%i*99.969144%3-i=99.973968%;六.基于设计目标和实际可用度差距评估高可用需求通过串联服务可用性评估公式计算，可以获得分布式消息服务管理可用度预估为99.621184%，现评估结果与常见的高可用问题中明确的分布式消息服务可用度SLO挑战目标99.99%有0.368816%的差距，通过分析，可以获得下面的服务韧性需求及预期可用度。按需创建实例可以不依赖A服务，实现A服务去），次，变更自动化率95%，提升到99%，可以提升），附：分布式消息服务管理面容灾需求可达9 分布式消息服务云服务 七.SLO档案评审归档与需求基线化完成分布式消息服务的SLO评估档案，需要对评估过程的正确性、需求的完备性进行评审，主要参与评审角色包括服务架构、研发、运维等，并进行跟踪落地。4.2架构高可用设计4.2.1架构高可用设计目的架构高可用设计业务目的改变过去在运维段补位的状态，坚持在业务设计阶段将高可用架构设计落地到开发中，牵引架构师和开发团队做非功能的高可用架构需求设计，以减少故障发生，缩短故障中断时长，控制影响范围，增强用户体验并满足严格架构高可用设计度量指标能指标，如响应时间、可用时间百分比等，以量化描述系统应达到的可用性水平。例如，一个SLO可以是“系统的可用性达到99.99%”，表示系统每年只允许不到52分钟的停机时间。）：义了业务对数据恢复的要求，表示系统恢复后，所能恢复到的数据的时间点。较小的RPO意味着系统需要更频繁地进行数据备份或实时数据复制，以减少数据丢失。）：RTO定义了业务对系统恢复的要求，表示系统在故障后可以接受的停机时间。较小的RTO意味着系统需要更快地进行故障检测、故障恢复和业务转移，以减少业务中断时间。4.2.2架构高可用设计能力设计和实施高可用架构通常需要一个跨职能团队的合作。架构团队、研发团队和运维团队需要紧密合作以确保系统的稳定性和可靠性。需要充分理解业务需求和技术选型，确保产品满足业务战略，并实现企业所定义的可用性要求与可用性架构设计。与研发工程师和运维工程师紧密沟通，确保系统的设计能够被有效定期与可用性架构师和运维工程师沟通，以确保系统的设计和实现与运维需求相匹配，并配合可用性参与架构的设计、方案的制定，在业务上线前评审可用性能力需求，并需要在现网度量可用性架构能架构高可用设计协同机制：》制定相应的流程和运作规范，授予非功能需求一定占比的开发工作量，以确保需求得以有效执行。》建立业务实时SLO看板，为架构高可用需求的落地计划的判断提供重要依据。关键角色关键角色架构师架构高可用设计活动评审活动 可用性要求 业务需求需求澄清 技术规范不通过架构设计架构设计开发技术规范制定可用性需求梳理设计准则架构开发架构高可用设计活动流程图2.技术规范制定：根据高可用性指标，明确制定技术选型规范，包括硬件、软件、网络设备等的选择标准，确保所选技术能够满足系统高可用性的要求。制定系统架构设计的规范和最佳实故障转移策略等规范，制定系统更新和维护的规范，制定系统安全规范，并负责高可用架构模块能力建设。3.架构设计和开发：流程包括需求分析、架构设计、技术选型、开发、集成测试、上线部署、后期维护等活动。4.评审活动：架构高可用设计评审活动流程，包括架构高可用设计的标准和要求、评审的范围和计划、评审的过程管理、评审的结果发布和分享等。架构高可用设计流程评估要点：3.设计规则和设计准则是否满足可用性需求覆盖率：考核设计准则和可用性需求的匹配度。架构高可用设计架构高可用设计云资源潜在风险识别云资源可用性检查云上优化建议云资源潜在风险识别云资源可用性检查云上优化建议代码编写代码审查持续集成代码编写代码审查持续集成需求收集需求分析需求拆分需求转化需求管理管理需求收集需求分析需求拆分需求转化需求管理架构高可用设计工具特性图需求管理工具：帮助团队收集、分析和管理项目需求，包括业务需求、可用性要求和性能需求等。这些需求可以被转化为用户故事或任务，然后被添加到研发流水线工具中。研发流水线工具：将这些需求转化为实际的代码和测试任务，并将它们组织成一个可视化的工作流程。这个工作流程包括代码编写、代码审查、自动化测试、持续集成和部署等步骤，以确保代码的质量和优化顾问工具：直观的查看云上资源部署情况，一键识别云上资源潜在风险并给出优化建议，提升云上业务的稳定性。通过架构设计可以方便地画出业务架构和云上资源的部署架构，可视化资源间关联关系，同时基于可靠性检查云上资源，并针对风险结果逐一给出云上优化建议，确保业务的稳定性和可保障性、可恢复性架构高可用设计可保障性、可恢复性架构高可用设计故障降级与恢复故障降级与恢复黑盒测试应急响应能力其他关键要素故障演练可恢复性设计变更回退设计冗余设计冗余设计主备冗余负荷分担容灾多活业务不中断升级业务不中断升级金丝雀发布蓝绿发布过载控制静态流控动态流控队列优先级控制动态反压企业主机安全爆炸半径控制爆炸半径控制单元化架构组合切片断路器故障域隔离隔离舱数据高可靠数据高可靠备份恢复异步复制同步复制延迟复制双写模式周期性数据校验故障降级与恢复去服务依赖快速失败数据可恢复设计节点故障自愈避免使用超长队列架构高可用设计全景图 应用场景冗余设计—负荷分担在服务实例的N个服务单元的业务分流可以通过部署LB集群进行分流、使用微服务框架或其他方式实现服务发现能力进而实现客户端与服务单元交互。LB集群可以按照业务特点及需求采用轮询、权重、IP哈希、所有服务单元是无状态的，服务单元之间不需要数据同步，数据可视需要可外置到数据库或OBS桶等共享存储中。当一个服务单元故障时，其他正常的服务单元分担故障单元的业务处理，保持业务在切换过程不中断，达到无损容错的目的。 ……负荷分担设计图应用场景跨AZ容灾％，容灾设计—华为云Global服务容灾实践Global服务在两个Region中部署业务，在中心Region保持一份全量数据，灾备Region依赖数据库的数据复制能力从中心Region同步数据。在日常接入层无状态服务层有状态接入层无状态服务层有状态数据层有状态数据层仲裁层接入层接入层无状态无状态服务层 服务层 有状态数据层有状态数据层有状态数据层有状态数据层仲裁层仲裁层 4.2.2.2.3过载控制应用场景对外提供接口调用的服务系统均应该考虑具能区分出优先级并且需要基于客户优先级、业务优先等保障高优先级业务过载控制设计由后台服务增加向前置服务动态反馈处理能力的主动反馈机制，反馈的信息可简单基于请求处理速率信息，也可以叠加针对特定用户等级或针对业务优先级的信息，使得前置服务可以根据反馈的信息，依据算法策略对请求流量进行针对性放通和流控。动态反馈处理能力前置服务转发速率动态调整后台服务前置服务转发速率动态调整后台服务过载控制设计图》负反馈：处理能力小于发送速率时，通知前置服务降低发送速率；》正反馈：处理能力大于发送速率时，通知前置服务提高发送速率；动态反压的目的是在系统负载大时，尽早触发失败，避免浪费资源。使得已接入的请求成功率尽可能高，减少后续出现过载的可能性。应用场景针对集群模式、主备模式等使用场景的业务都应该细化到节点级所有涉及队列或类似队列的列表场景，都应该结合业务特点、消息时效性和系统结合业务处理性能、资源容量和消息的实效减少队列积压，加速故障恢复。在队列消息不能被丢弃，而且故障恢复时需要优先处理最新数据的场景下，例如监控数据，可以提供多队列或者主备队列的方案，在故障恢复时将在用队列切到备用队列进行恢复业务，并在系统稳定运行后继续消费原队列补齐历史数据。3.提供清空队列能力队列的消息可被丢弃的场景下，可通过提供白屏化的队列清空能力，应对快速恢复诉求。该能力需做好防呆和权限管控，并提供执行队列清空的评判标准。应用场景主从结构的高可用设计，对主从节点状态或数据一致性要求较高，且允许主针对核心数据故障影响面很大，需重点提升数据保护能力，或存在较频繁直接数据误删、污染等数据损坏的场景均可考虑数据存储系统在双集群间未提供原生同步能力或者需要在异构数据存储系统间同步周期性数据校验常用于数据校验的方法设计阶段，应用于数据校验或比对场景数据高可用设计存储系统存储系统存储系统存储系统同构数据设计图2.异构数据存储系统以数据库和缓存双写为例说明异构数据存储系统的数据一致性问题和方案。数据库数据库异构数据设计图在理论上，通过设定缓存过期时间，可以保证数据库与缓存的数据的最终一致性。但对一些数据一致性敏感的场景下，在缓存周期内都会导致业务出现异常，因此需要尽最大努力保持数据库与缓存的一致性。 应用场景周边服务故障时，调用服务方主动旁路该故障服务，实现业务的功根据评估结果识别周边依赖的可用性薄弱点，并针对性采用适合业务场景的去快速失败通常用于一个微服务的故障导致另一个微服务亚健康状态的情况下，故障降级设计业务系统通过调用内部微服务或其他服务的接口完成租户请求，如下图所示。在同步调用场景下，如果F微服务故障由A微服务负责调度是否重试比由C微服务进行重试更加合适，A微服务作为整个流程的调度者，更适合决策什么场景下应该进行怎样的重试，C微服务只是整个流程的一个环节，同步返回失败即可。故障降级设计图应用场景体验优化：用户体验永远是服务提供者最关心的内容，对已经落地使用的功能进升级不中断业务设计在生产环境在部署两套系统（蓝绿环境，两套系统共享有状态业务组件 绿环境 绿环境蓝环境升级中 蓝环境蓝环境升级中 蓝环境绿环境 绿环境 绿环境蓝环境 蓝环境蓝环境 蓝环境绿环境升级中蓝绿发布设计图在版本发布时，只让用户访问active的绿色环境（V1版本），把inactive境进行新版本的发布应用，并对蓝环境（V2版本）进行测试。测试验证没有问题后，把负载均衡器指向蓝环境，并持续监测蓝环境是否有故障和异常，如果有异常则通过负载均衡器快速回滚指向绿环境。应用场景组合切片模式常应用于架构与设计阶段，适用资源池场景下的多种不同类型的人因故障、HA故障导致的故障扩散。组合切片模式常与其它设计模式一起使用，用于构筑产品或物理多租类服务的数据面需特别关注底层资源类故障需要保证业务的基本可用性，重试机制是一个简单易实现的方案。组件或服景下，出现秒级的业务不连续。有限重试模式常与断路器隔离使用一组后端服务所用的资源，尤其是业务系统可以提Grid方法将逻辑垂直扩展变化成水平扩展。每一个Grid，都是一个独立的、完整的服务实例，并且有能力上限。Region级别的扩展通 应用场景网站和应用程序保护、游戏服务器保护、金融机构保护、安全设计—华为云安全优秀实践主机安全防护(HSS)。》一个运维中心(堡垒机)：内部人员操作可审计。配合公网IP最小化使用实践，彻底杜绝主机账户爆破风险。客户DCor办公区V接入层客户DCor办公区V接入层……VPC云堡垒机Subnet-D：O&M区Subnet-A：DMZ区业务一Subnet-B：业务层Subnet-C：数据层云堡垒机Subnet-D：O&M区Subnet-A：DMZ区业务一Subnet-B：业务层Subnet-C：数据层安全设计图高可用需求度量治理架构高可用运营应从开发阶段的正向设计、业务上线的PRR评审、运维阶段的度量治理相结合，保障业务高可用能力持续迭代，进而提升业务高可用需求度量治理SLO。架根据架构高可用技术规范以及业务可用度要求，设计架构高可用需求。需关注架构高可用需求满足度，避免需并做闭环治理。应用高可用BI应用高可用BI看板遗留问题改进建议高可用需求数据湖数据湖PRRPRR评审升级不中断业务冗余容灾爆炸半径控制数据高可用过载控制架构高可用度量图和级别计算。RI（RiskIndicator现网遗留风险，现网已识别但未关闭的风险度量。基于某一时刻问题的数量、级影响实例在。internetinternet4.2.3架构高可用设计实践分享…………AZ3华为云Region1APIGAZ1rAZ2地震、飓风、战争毁坏……CCETurboDRS数据同步数据同步一.华为云高可用设计实践…………AZ3华为云Region1APIGAZ1rAZ2地震、飓风、战争毁坏……CCETurboDRS数据同步数据同步华为云Region（Global）MAS-DCG 仲裁中心 仲裁中心 控制中心 Kubernetes……XXRegionKubernetes……APIG对象存储对象存储业务面请求管控面请求华为云高可用设计实践示意图方案实践），），保障数据一致性，兼容主流中间件、数据库，更具有普适性。二.系统高可用设计实践业务背景当前较多企业以传统运维方式为主，随着业务急速发展，传统运维方式存在组织架构冗余、角色分工混乱、配置管理复杂、问题界定模糊、问题恢复缓慢、可用区架构薄弱、安全管理能力欠缺、运维工具复杂、可观测性和可视化能力差、运维效能低等一系列问题。且系统越来越复杂，数据孤岛增加，版本迭代经常导致回退。如何避免系统出现故障，故障出现后如何快速恢复业务，成为客户的重点工作。通过引入确定性运维，可为客户实现系统高可用，建立高可用组织，适配架构改进，快速发现系统隐患，帮助客户完善运维体系，快速提升运维效能，切实助力企业进步，稳中向好发展。高可用架构分析通过调研客户业务全景图、业务系统组件图、组件依赖关系图和部署架构图，聚焦企业高可用架构能力建设，识别客户APP架构以及业务系统部署的潜在风险。从冗余、容灾、数据高可用、过载控制、升级不中断、爆炸半径、故障管理等高可用技术点进行评估，识别以下核心风险：》冗余：服务部署缺少冗余分析能力。》数据高可用：核心数据有定时备份，但未进行演练且数据缺少第三方备份，存在数据无法恢复风险。》升级不中断：变更流程自动化和智能化能力不足，变更过程需要中断业务。》爆炸半径：非核心组件未进行模块化部署，且依赖同一数据库。方案实践》对系统中可能出现的故障进行分析和诊断，采用冗余技术以提高系统的可靠性和容错性。》域名同时托管在多家域名运营商，单一运营商DNS故障不影响域名访问。》定期备份数据，并将备份存储在多个地方，以确保数据的安全性和可恢复性。》多级缓存减轻对外组件压力，外部组件故障时及时熔断确保主要业务正常。》负向缓存，无效AK大并发请求攻击，采用负向缓存方式，缓解客户应用负载压力。》变更或升级使用自动化工具流水线完成，采用灰度发布进行版本升级。客户收益》以业务稳定为目标，通过可用性架构体系，识别业务端到端可用性风险，各服务已有意识将SLO/SLI纳入到产》业务流程可视化，高可用架构设计能力提升，故障快速定界定位。年均故障次数降低30%。》业务10倍增长，使用华为云混沌演练平台进行演练，自动化注入故障，验证系统可用性，沉淀运维经验。三.趣丸科技MRS集群跨可用区改造案例分享集群为单可用区部署，当集群所在可用区出现故障时会导致整个集群不可用，对业务造成影响，且恢复改造前集群单可用区部署，当机房掉电、网络异常等情况发生时，会导致整个集群不可用，导致上层业务报错，从》大数据集群多可用区部署，可以保障底层数据多副本，当机房故障时，业务数据仍4.34.3监控设计4.3.1监控设计目的监控设计的业务目的监控设计是围绕确定性恢复命题展开的，监控告警体系直接决定确定性恢复能力构建与SLO达成。监控告警体系能够直接决定一些故障的恢复时长，如下图所示，MTTR平均恢复时长由平均发现时长、平均定界时长和平均处置时长三部分构成，而监控能决定的是发现时长和定界时长（经验值占比1/2左右）。在一个事件里，MTTR的恢复时长越短，那么它的整体SLO达成可能性就越高。==++想缩短时间，本质上是监控即发现、监控即定级、监控系统定界、定界即恢复——如果能达成这样的设计就能够形 面向系统监控即发现3421 定级（影响面）监控告警最短恢复路径图场景化应用事件管理发现率、定级准确率、定界时长覆盖率、有效率、一致率场景化应用事件管理发现率、定级准确率、定界时长覆盖率、有效率、一致率24563143监控ORR研发设计2551覆盖率发现率业务系统衡量指标定级准确率有效率定界一致率业务系统监控告警能力图1云厂商侧通过紧急告警或巡检手段先于客户发现的控发现数/有效War%2%3%4拉起会议到判断出故障的51-无效告警工单数/%6对客户影响达到P3级或以上事件通过SLI_WR标签自总数/监控告警拉起%4.3.2监控设计能力监控设计团队与角色职责了解技术架构和现有的监控解决方案，可提供负责监控系统的技术架构设计，包括数据采集、数据存储、数据处理、告警通知了解运维流程和现有的监控工具，可以提供关于如何集成监控系统以及如何与现负责监控系统的业务需求分析和功能规划，包括业务流程、数据模型和业务规则》业务部门和技术部门的协作：需要共同确定监控哪些指标以及如何监控，并确保监控系统与业务需求和技术架构相匹配，明确监控目标，保证监控的覆盖率和发现率。》安全部门和运维部门的协作：需要共同确保监控系统的安全性和可靠性，并确保监控数据的合规性。》运维部门和技术部门的协作：需要共同确保监控系统与业务需求和技术架构相匹配，选择合适的监控工具，设置监控指标，建立监控告警机制，定期检查监控系统，持续优化监控系统，并确保监控数据的有效率、定级准确性和一致率。选择监控工具确定监控指标告警规则设计确定监控目标监控设计方案监控阈值设定选择监控工具确定监控指标告警规则设计确定监控目标监控设计方案监控阈值设定监控评估优化监控评估优化监控设计流程示意图》确定监控目标：项目经理、研发工程师、系统架构师等根据业务部门需求确定需要监控的资源，如服务器、存储、网络等。》确定监控指标：研发、运维工程师等确定需要监控的指标，如CPU使用率、内存使用率、网络带宽等。》选择监控工具：系统架构师根据监控目标和指标，选择适合的监控工具，如华为云监控、应用运维管理、应用性能管理等。》监控阈值设定：运维、研发工程师根据需要监控的指标，配置相应的监控项，如设置CPU使用率的阈值、内存使用率的阈值等。》告警规则设计：运维工程师根据监控项的阈值，设计相应的告警规则，如当CPU使用率超过90%时，发送邮件或短信通知管理员。》监控设计方案：根据业务部门需求、既定的目标、指标、工具等，输出契合系统的设计方案。》监控评估优化：依据方案对监控目标进行落地试点，围绕监控发现率、覆盖率、一致率、定界时长、有效率、定级准确率等度量指标对监控方案进行评估、复盘，为监控设计方案的迭代更新提供依据。如何实时获取应用异常如何实时获取应用异常如何快速获取出现问题的日志如何快速获取出现问题的日志如何监控应用进程健康如何监控应用进程健康、资源状态如何监控服务器CPU、内存等资源状态如何监控服务器CPU、内存等资源状态云应用立体监控解决方案全景图》针对海量资源基础监控：为用户提供一个业务系统中基础资源的立体化监控平台。特性：秒级监控、一键告警、》针对海量资源深度监控：一站式立体化运维管理平台，实时监控应用及资源，采集各项指标、日志及事件等数据分析应用健康状态，提供告警及数据可视化功能。特性：支持跨账号统一监控、支持自定义数据储存时长（最长367天）、支持多种聚合查询、支持业务监控、应用监控、语法、更丰富的告警规则、无缝对接华为云CCE云容器引擎等。》针对应用性能问题监控场景：全链路应用性能管理服务，提供端到端的全链路应用性能管理服务，包含前端监控、应用性能监控、全面拥抱开源生态。帮助用户在复杂的业务环境下快速，发现应用性能问题，降低MTTR(平均恢复时长)，改善用户体验。》针对海量日志的监控场景：提供日志收集、实时查询、存储等功能，无需开发即可利用日志做实时决策分析，提升日志处理效率，帮助用户轻松应对日志实时采集、查询分析等日常运营、运维场景。》针对CloudNative一站式、自动化监控场景：基于可观测性实践，集预防、检测、诊断、恢复、通报和改进于一体的可观测性平台，实现故障生命周期自动化管理。特性：一站式、开箱即用、灵活的接入能力、海量数据处理分析能力、丰富的AIOps场景监控技术能力是指使用监控管理平台为用户提供立体化监控，使客户可以全面了解资源使用情况、业务运行情况，并及时收到异常告警做出反应，保证业务正常运行。监监应用监控基于应用资源管理对资源实行从应用、业务组件、到环境的分层监控，每一层对应的观测指标均不同。在应用层，主要监控业务层、应用层、中间件层以及基础设施层告警信息，同时通过绑定当前应用的仪表盘，以图表的形式展示指标源、日志源以及系统图表信息。主要进程监控是针对主机内活跃进程进行的监控，默认采集活跃进程消耗的CPU、内存，以及打开配置日志服务从日志中提取指定的关键词，便于您使用监控服务对日志中的关键指标进行监控