卓越运营支柱-华为云

云架构中心-基础概念

基础概念名称名词解释确定性运维确定性运维旨在构建可防、可控、可治的运维管理体系。首先是通过高质量的产品开发，严谨的运维流程和制度来降低故障的概率，要挑战零故障，同时也要有技术手段对可能发生的故障，将间隔、影响范围及故障恢复时间做到可防、可控、可治，要把数字化带来的“不确定性”通过运维变成“确定性”。 IaC 基础设施即代码基础设施即代码（IaC）是指使用代码而不是手动流程和设置来配置和支持基础设施的能力。任何应用程序环境都需要许多基础设施组件，例如操作系统、数据库连接和存储。开发人员必须定期设置、更新和维护基础设施，以开发、测试和部署应用程序。手动管理基础设施既耗时又容易出错，尤其是在大规模管理应用程序时。 CI/CD 持续集成/持续交付持续集成是一种编码理念和一套实践，它促使开发团队频繁地实施小的代码更改并将其签入版本控制存储库。大多数现代应用程序都需要使用各种平台和工具来开发代码，因此团队需要一种一致的机制来集成和验证更改。持续集成建立了一种自动化的方式来构建、打包和测试他们的应用程序。拥有一致的集成流程可以鼓励开发人员更频繁地提交代码更改，从而实现更好的协作和代码质量。持续交付从持续集成结束的地方开始，并自动将应用程序交付到选定的环境，包括生产、开发和测试环境。持续交付是一种将代码更改推送到这些环境的自动化方式。 Telemetering 遥测遥测是对被测量对象的参数进行远距离测量的一种技术。是将对象参数的近距离测量值传输至远距离的测量站来实现远距离测量的技术，并把测得结果传送到接收地点进行记录、显示和处理的活动。 CMDB 配置管理数据库（configuration management database）简称CMDB，是信息技术基础架构库（ITIL）用语，是组织用来储存软体硬体资产（常称为形态项目，CI）资讯的数据库。用CMDB来追踪资产（例如产品、系统、软体、设备、人员）的状态，例如这些资产在特定的时间点是否存在，以及各资产之间的关系，并通过公开的接口支持IT管理各种业务数据消费。 MTTR MTTR（Mean Time to Repair）平均恢复时长，平均修复时间指从故障发生到验证确认故障恢复的耗时。MTTR 分为三个维度：MTTI（Mean Time To Identify）平均发现时长、MTTK（Mean Time to Know）平均诊断时长、MTTF（Mean Time to Fix）平均修复时长变更风险控制在变更作业过程中，建立事前检查、事中拦截和事后验证的能力，防止异常行为。安全生产安全生产目的是为了持续保障现网“安全、稳定、高质量”，从人员、工具、产品能力、流程规范等方面在安全预防、过程监控、结果稽查等维度进行端到端管理，减少或防止现网故障的发生，其中如何防止异常行为导致的事件是安全生产的重要目标。故障快速恢复故障快恢是以故障模式库为基础，建立应急预案，提升故障恢复效率、降低故障恢复时长，结合混沌工程演练把不确定的恢复时长做到确定的。资源生命周期管理指的资源的申请、创建、交付、运维以及最终的销毁释放过程。故障演练故障演练指通过沉淀通用的故障场景和可控成本在线上故障重放，以持续性的演练和回归方式的运营来暴露问题，不断验证和推动系统、工具、流程、人员能力的提升，从而提前发现并修复可避免的重大问题，或通过验证故障发现手段、故障修复能力来达到缩短故障修复时长的作用。运维托管运维托管服务是一种针对企业或组织的IT基础设施进行全面管理和维护的专业服务，旨在提高IT系统的可用性、可靠性和安全性。该服务涵盖了多个方面，包括系统监控、故障排除、系统优化、安全防护等。父主题：卓越运营支柱

云架构中心卓越运营支柱

云架构中心-设计原则:通过可观测性进行持续改进

通过可观测性进行持续改进可观测性是指通过观察系统的外部输出，推断其内部状态的能力。一般来说，云上应用的可观测性通常使用三种核心手段，一：指标，指标是系统状态的定量度量，例如 TPS、请求延迟、调用量等。二: 日志：日志是系统事件的人可读记录，例如应用程序的运行信息，运行错误、安全事件等。三：跟踪（Trace)，跟踪可以追踪单个请求或事务在系统中的路径，帮助我们了解系统的执行情况。对于构建在云上的应用，通过可观测性，可以快速发现和解决系统故障，从而提高系统从故障中的恢复速度。进一步地，可以提前发现系统的问题，例如性能，容量瓶颈，提前解决问题。更进一步地，您可以通过联动可观测性带来的告警和上文中的自动化流程，通过主动式响应，包括动态缩扩容，流控，主动切流，节点的迁移等，消灭问题于无形之间。

云架构中心卓越运营支柱

云架构中心-设计原则:建立持续改进的团队文化和标准化运维体系

建立持续改进的团队文化和标准化运维体系在卓越运营中，团队文化建设至关重要。运营是一门不断改进的艺术。只有不断从已有事故中学习经验，持续学习和改进，才能最终达到卓越运营。故而，团队应该培养持续学习和改进的文化，此外，在事故发生时，应该以对事不对人的态度，思考系统的改进，而不是惩罚或者指责个人。片面指责个人或者直接处罚的做法很容易引起一系列后果，例如后续的运维团队成员由于担心处罚，会隐瞒事故或者隐藏真正的事故原因，导致后续无法切实改进系统的运维能力和流程。一线的工程师也因为担心处罚，不愿意担责，不愿意做任何系统的改变。部门、组织之间由于担心事故影响部门、组织内部成员，导致了消极应对系统中隐藏的问题或者将问题推给了其他组织，部门。最终，这种文化上的高压导致整个组织和运维流程的僵化，以及系统不能持续迭代更新之后的代码、架构腐化，最终导致无法运维的系统。故而，文化上，惩前毖后，应重在总结经验，明确改进责任主体组织，不责怪个人。在总结经验上，应该将相关经验进行标准化的沉淀，即将经验总结成自动化工具，流程以及建立相应的组织体系，我们称之为标准化运维体系。非标是大规模运维的头号天敌，主要表现是运维无序，团队成员依靠自身技术各自为战，处于被动响应和疲于应付的工作状态，效率低下，人为失误多，故障处理难度大。标准化运维体系是对有效经验总结后，运维活动例行化的高效管理。通过对运维活动的标准化、流程化和工具化管理，实现从无序向有序演进，达到运维操作团队运作“最佳秩序”，简化运维交付工作，降低技能依赖，提高运维效率，降低运作成本。

云架构中心卓越运营支柱

云架构中心-设计原则:通过CI/CD实现高效的频繁可逆的小规模变更

通过CI/CD实现高效的频繁可逆的小规模变更在软件开发过程中，应该尽量使需求分析，设计，开发，测试，部署的开发周期较小，使用频繁的小型迭代进行。一个典型的实践是使用微服务和CI/CD实践，微服务架构是一种更为灵活、可扩展和易于维护的架构风格，已经逐渐成为现代应用开发的主流选择。它通过将应用程序拆分为小的、自治的服务，每个服务都负责执行特定的业务功能，可以使用不同的技术栈，由独立的团队开发，测试，部署和扩展，并通过轻量级通信机制相互交互。而在CI/CD下，同一团队以流水线的方式集成整个微服务的开发，测试和进行不同地域的部署、发布和运维。对于已经采用DevOps模式的组织，应该更进一步，不仅在软件项目的管理，而是从运维角度来看，小型频发的迭代有助于快速发现问题，一旦发现问题，也易于回滚到软件的上一版本，并降低部署失败时发生大规模问题的风险。

云架构中心卓越运营支柱

云架构中心-设计原则:X即代码，尽量自动化所有流程

X即代码，尽量自动化所有流程云上应用和传统应用的一大区别是，您可以将整个云上应用，包含应用程序自身、运行应用的云基础设施、安全策略、以及相应的运维操作视为代码。这意味着整个卓越运营的各种实践，都可以极大地使用代码自动化，例如定义应用的基础设施，部署应用自身，修改应用的配置，设置安全策略，甚至日常的运维操作，故障修复，都可以通过代码实现并执行。自动化是沉淀运维经验，建立标准运维最重要的一环，通过自动化，可以避免人为错误，标准化流程并提高效率。即使在部分自动化流程中依然需要人工干预，例如决策点。在决策点前的自动化流程依然可以确认人员权限，向人员提供必要的上下文和信息，以便做出明智的决策，比之纯手工流程，最大程度避免了错误。

云架构中心卓越运营支柱

云服务器内容精选

卓越运营支柱

7*24

备案

专业服务

退订

建议反馈

售前咨询热线