Skip to content

WA-卓越运营-Operational-Excellence-202310-Summary

设计原则

collapse: close
icon: battery-0
title:  以代码形式执行操作

在云中,您可以将用于应用程序代码的相同工程规则应用于整个环境。 您可以将整个工作负载(应用程序、基础设施等)定义为代码并用代码更新。 您可以编写操作过程的脚本,并通过启动它们来响应事件来自动化其过程。 通过将操作作为代码执行,您可以限制人为错误并创建对事件的一致响应。
collapse: close
icon: battery-25
title:  进行频繁、小的、可逆的更改

设计可扩展且松散耦合的工作负载,以允许定期更新组件。 自动化部署技术与较小的增量更改一起减少了爆炸半径,并在发生故障时实现更快的逆转。 这增强了您对工作负载进行有益改变的信心,同时保持质量并快速适应市场条件的变化。
collapse: close
icon: battery-50
title:  经常改进操作流程

随着工作负载的发展,适当地改进操作。 当您使用操作程序时,寻找改进它们的机会。 定期进行审查并验证所有程序是否有效并且团队是否熟悉它们。 如果发现差距,则相应地更新程序。 向所有利益相关者和团队传达程序更新。 将您的运营游戏化,以分享最佳实践并教育团队。
collapse: close
icon: battery-75
title:  预测故障

执行“事前剖析”练习来识别潜在的故障源,以便消除或减轻故障。 测试您的故障场景并验证您对其影响的理解。 测试您的响应程序以确保其有效并且团队熟悉其流程。 设置定期比赛日来测试工作量和团队对模拟事件的反应。
collapse: close
icon: battery-100
title:  从所有运营失败中吸取教训

通过从所有运营事件和失败中吸取的经验教训来推动改进。 分享跨团队和整个组织学到的知识。
collapse: close
icon: battery-100
title:  使用托管服务

尽可能使用 AWS 托管服务来减轻运营负担。 围绕与这些服务的交互构建操作程序。
collapse: close
icon: battery-100
title:  实施可观察性以获得可行的见解

全面了解工作负载行为、性能、可靠性、成本和运行状况。 建立关键绩效指标 (KPI) 并利用可观测性遥测技术做出明智的决策,并在业务成果面临风险时迅速采取行动。 根据可操作的可观测数据主动提高性能、可靠性和成本。

问题和定义

组织
OPS 1 您如何确定自己的重点?
OPS 2 如何构建组织结构来为业务成果提供支持?
OPS 3 组织文化如何为业务成果提供支持?
准备
OPS 4 如何在工作负载中实现可观测性?
OPS 5 如何减少缺陷、简化修复和改进生产流程?
OPS 6 您如何缓解部署风险?
OPS 7 如何知道您已经准备好支持某种工作负载?
运营
OPS 8 如何在组织中利用工作负载可观测性?
OPS 9 您如何了解自己的运营状况?
OPS 10 您如何应对工作负载事件和运营事件?
发展
OPS 11 如何改进运营?

最佳实践

组织

OPS 1 您如何确定自己的重点?

评估外部客户需求

让包括业务、开发和运营团队在内的主要利益相关方参与进来,以便确定怎样将工作重心放在外部客户的需求上。这可以确保您充分了解实现您期望的业务成果所需的运营支持。

评估内部客户需求

让包括业务、开发和运营团队在内的主要利益相关方参与进来,以便确定怎样将工作重心放在内部客户的需求上。这可以确保您充分了解实现业务成果所需的运营支持。

评估监管要求

治理是公司用来实现其业务目标的一系列策略、规则或框架。从组织内部生成治理要求。它们会影响您选择的技术类型或影响您运营工作负载的方式。将组织治理要求纳入工作负载中。合规是证明您已实施治理要求的能力。

评估合规性要求

监管、行业和内部合规性要求是定义组织优先级的重要驱动因素。您的合规性框架可能会阻止您使用特定技术或地理位置。如果未确定外部合规框架,则进行尽职调查。生成验证合规性的审计或报告。

评估威胁形势

评估对业务的威胁(例如竞争、业务风险和负债、运营风险和信息安全威胁),并在风险注册表中维护当前信息。在确定工作重心时,将风险的影响考虑在内。

评估权衡

在有冲突的利益或替代方法之间做出权衡并评估其影响,以便在确定工作重心或选择行动方案时做出明智的决策。例如,加快新功能上市的速度可能会比成本优化更重要,或者您可以为非关系数据选择关系数据库,以简化迁移系统的工作,而不是迁移到针对您的数据类型优化的数据库和更新您的应用程序。

管理收益和风险

管理收益和风险,以便在确定工作重心时做出明智的决策。例如,为了向客户提供重要的新功能,部署仍存在未决问题的工作负载是可以接受的。这可能会降低相关风险,或者允许风险继续存在可能会令人无法接受,在这种情况下,您将采取措施来化解风险。

OPS 2 如何构建组织结构来为业务成果提供支持?

确定资源所有者

工作负载的资源必须具有已确定的所有者,以便实现变更控制、故障排除和其他功能。为工作负载、账户、基础设施、平台和应用程序分配所有者。使用集中登记册或附加到资源的元数据等工具记录所有权。组件的商业价值指明应用于它们的流程和程序。

确定流程和程序所有者

了解谁对各个流程和程序的定义拥有所有权、为何使用这些特定的流程和程序,以及为什么存在这种所有权。了解使用特定流程和程序的原因将有助于发现改进机会。

确定对运营活动绩效负责的所有者

了解谁负责针对定义的工作负载执行特定活动,以及为什么负责。了解谁负责执行活动可让我们知晓谁来开展活动、验证结果并向活动所有者提供反馈。

团队成员知道自己的责任

了解您的角色具有哪些责任以及如何为业务成果做出贡献可帮助您确定任务的优先级以及自身角色的重要性。这使团队成员能够了解需求并做出适当响应。

制定用于确定责任和所有权的机制

在未确定个人或团队时,要为有权分配所有权或计划满足该需求的人定义升级路径。

制定用于请求添加、更改和例外的机制

您可以向流程、程序和资源的所有者提出请求。请求包括添加、更改和例外。这些请求都要经过变更管理流程。对收益和风险进行评估之后,做出明智的决定,批准可行和确认合适的请求。

预先定义或协商团队间的职责

团队之间具有明确或协商好的协议,规定了团队之间的合作和相互支持方式(例如响应时间、服务级别目标或服务等级协议)。记录团队间沟通渠道。了解团队工作对业务成果以及其他团队和组织的成果的影响,可以确定其任务的优先级,并帮助他们做出适当的响应。

OPS 3 组织文化如何为业务成果提供支持?

高管支持

高层领导明确为组织设定期望并评估是否成功。高层领导是采用最佳实践和组织发展的发起人、倡导者和推动者。

赋能团队成员在结果有风险时采取行动

工作负载所有者定义了指南和范围,赋能团队成员在结果有风险时做出响应。当事件超出定义的范围时,使用上报机制获取指示。

鼓励上报

团队成员具有相应机制,如果他们认为结果存在风险,鼓励他们向决策者和利益相关者上报问题。应经常尽早上报,以便能够确定风险,并防止造成意外事件。

沟通及时、清晰、可行

制定相应机制,用于将已知风险和计划内事件及时通知给团队成员。提供必要的相关信息、详细信息和时间(如果可能),为确定是否需要采取措施、需要采取什么措施以及及时采取措施提供支持。例如,提供软件漏洞通知可以加快修补过程;或者,提供计划内促销活动的通知可以实施变更冻结以避免发生服务中断的风险。可以将计划内事件记录在变更日历或维护时间表中,以便团队成员可以确定哪些活动待处理。

鼓励试验

试验是将新想法转化为产品和功能的催化剂。它可加快学习速度,并使团队成员保持兴趣和参与热情。鼓励团队成员经常试验,以便推动创新。即使出现了不希望看到的结果,我们知道什么不该做也是有价值的。团队成员不会因为试验成功但结果不理想而受到惩罚。

鼓励团队成员保持和增强他们的技能组合

团队必须增强自己的技能组合,以采用新技术;并随需求和职责的变化继续提供支持,以支持工作负载。新技术技能的增强通常能提升团队成员满意度并支持创新。支持您的团队成员获取和维护行业认证,以验证和认可他们不断增强的技能。进行交叉培训,以促进知识转移并降低在您失去熟练掌握机构知识、经验丰富的团队成员时产生重大影响的风险。专门安排时间进行学习。

为团队配置适当的资源

培养团队成员的能力,并提供工具和资源来支持工作负载需求。团队成员超负荷工作会增加人为错误导致事故发生的风险。投资于工具和资源(例如,对频繁执行的活动实现自动化)可以提高团队的效率,让他们为其他活动提供支持。

鼓励在团队内部和团队之间提出不同的观点

利用跨组织的多样性来寻求多种独特的见解。利用这种见解提高创新能力、对您的假设提出质疑,并降低确认偏差的风险。在团队内部提升包容性、多样性和可达性有助于获取有益的见解。

准备

OPS 4 如何在工作负载中实现可观测性?

识别关键性能指标

要在工作负载中实现可观测性,首先要了解其状态并根据业务需求做出数据驱动型决策。确保监控活动与业务目标相一致的最有效方法之一是,定义和监控关键绩效指标(KPI)。

实施应用程序监控

应用程序遥测是实现工作负载可观测性的基础。发射遥测数据至关重要,它可以提供切实可行的见解,让您了解应用程序的状态以及技术和业务成果的实现情况。从故障排除到衡量新功能的影响或确保与业务关键绩效指标(KPI)保持一致,应用程序遥测可为您构建、操作和演进工作负载的方式提供指导。

实施用户体验遥测

深入了解客户体验以及与应用程序的交互至关重要。真实用户监控(RUM)和合成交易是实现此目的的强大工具。虽然 RUM 提供有关真实用户交互的数据,但合成交易模拟用户互动,从而帮助在潜在问题影响真实用户之前就将其检测出来。

实施依赖项遥测

要想监控您的工作负载所依赖的外部服务和组件的运行状况及性能,依赖项遥测必不可少。它提供有关与 DNS、数据库或第三方 API 等依赖项相关的可访问性、超时及其他关键事件的宝贵见解。通过检测您的应用程序以发出有关这些依赖关系的指标、日志和跟踪,您可以更清楚地了解可能影响您的工作负载的潜在瓶颈、性能问题或故障。

实施分布式跟踪

分布式跟踪提供了一种方法,可在请求通过分布式系统的各个组件时对其进行监控和可视化。通过从多个来源捕获跟踪数据并在一个统一视图中对其进行分析,团队可以更好地了解请求是如何流动的、哪里存在瓶颈以及优化工作的重点。

OPS 5 如何减少缺陷、简化修复和改进生产流程?

使用版本控制

使用版本控制来跟踪更改和发布。

测试并验证变更

部署的每一项变更都必须经过测试,以避免在生产中出现错误。此最佳实践的重点是测试从版本控制到构件构建的变更。除应用程序代码变更外,测试还应该包括基础设施、配置、安全控制和操作程序。测试有多种形式,从单元测试到软件组件分析(SCA)等等。在软件集成和交付过程中,尽早进行测试可进一步确保构件质量。

使用配置管理系统

使用配置管理系统来实现和跟踪配置更改。这些系统可以减少手动过程引起的错误,并减少部署更改的工作量。

使用构建和部署管理系统

使用构建和部署管理系统。这些系统可以减少手动过程引起的错误,并减少部署更改的工作量。

执行补丁管理

执行补丁管理以便实现功能、解决问题并保持监管合规性。实现自动补丁管理,以便减少手动过程引起的错误,进行扩展,并减少修补工作量。

共享设计标准

在不同团队间共享最佳实践,以便提高认识并最大程度地实现开发工作的效益。随着架构的发展,记录它们并使它们保持最新。如果在组织中强制实施了共享标准,则必须存在相应的机制来请求对标准进行添加、更改和例外处理。如果没有这样的机制,标准将成为创新的约束。

实施提高代码质量的实践

实施能够提高代码质量并尽可能减少缺陷的最佳实践。一些示例包括测试驱动型开发、代码审查、标准采用和结对编程。将这些实践合并到您的持续集成和交付流程中。

使用多个环境

使用多个环境来试验、开发和测试您的工作负载。当环境接近于生产环境时,逐步加强控制,以确保工作负载在部署后能够按预期运行。

频繁进行可逆的小规模更改

频繁进行可逆的小规模变更可以减少变更的范围和影响。当与变更管理系统、配置管理系统以及构建和交付系统结合使用时,频繁进行可逆的小规模更改可以减少变更的范围和影响。这样可以提高故障排除工作的效果、加快修复速度,并支持回滚更改。

完全自动化集成和部署

实现自动构建、部署和测试工作负载。这可以减少手动过程引起的错误,并减少部署更改的工作量。

OPS 6 您如何缓解部署风险?

针对不成功的更改制定计划

制定计划,以便在部署没有达到期望结果时,在生产环境中恢复到已知良好状态,或者进行修复。制定一项策略来建立这样的计划,有助于所有团队制定从失败的更改中恢复的策略。这样的策略示例包括部署和回滚步骤、更改策略、功能标记、流量隔离和流量转移。单个发布可能包括多个相关的组件更改。该策略应提供承受任何组件更改的失败或从中恢复过来的能力。

测试部署

使用与生产环境相同的部署配置、安全控制、步骤和程序,在预生产环境中测试发布过程。验证所有部署步骤是否按预期完成,如检查文件、配置和服务。通过功能测试、集成测试和负载测试以及运行状况检查等各种监控方法,进一步测试所有更改。通过这些测试,您可以及早发现部署问题,并有机会在进入生产之前规划和缓解问题。

采用安全部署策略

在安全的生产环境滚动部署中,会对有益更改的流程进行控制,目标是尽可能减少这些更改让客户感知到的任何影响。安全控制措施提供检查机制,用于验证是否达成所期望的结果,并针对由于更改或部署失败所引入的任何缺陷,限制这些缺陷的影响范围。安全滚动部署可包括功能标记、单盒、滚动(金丝雀版本)、不可变、流量分割和蓝绿部署等策略。

自动测试和回滚

为了提高部署过程的速度和可靠性以及对该过程的信心,您需要制定一项策略,用于在预生产和生产环境中实现自动化的测试和回滚功能。在部署到生产环境时自动进行测试,模拟人与系统的交互,从而验证已经部署了更改。利用自动回滚功能,可以快速恢复到先前已知的良好状态。回滚应在预先定义的条件下自动启动,例如更改未达到期望结果或自动化测试失败时。自动执行这两项活动可以提高部署的成功率,尽可能缩短恢复时间,并减少可能对业务造成的影响。

OPS 7 如何知道您已经准备好支持某种工作负载?

确保员工能力

通过一种机制来验证您是否有适当数量训练有素的员工来支持工作负载。他们必须接受构成工作负载的平台和服务方面的培训。为他们提供运营工作负载所需的知识。您必须有足够训练有素的员工来支持工作负载的正常运营和排查发生的意外事件。拥有足够的员工轮流值班和休假,避免疲劳。

确保以一致的方式对运维准备情况进行审核

使用运维准备情况审查(ORR,Operational Readiness Review),确保可以运营您的工作负载。ORR 是 Amazon 开发的一种机制,用于验证团队可以安全地运营其工作负载。ORR 是一个使用要求核对清单进行审查和检查的过程。ORR 是一种自助服务体验,供团队用于验证其工作负载。ORR 中包含的最佳实践源自我们多年构建软件的经验教训。

使用运维手册来执行程序

运行手册是实现特定结果的书面流程。运行手册由某人为完成某件事而遵循的一系列步骤组成。早在航空发展的早期,运行手册便已用于运营。在云运营中,我们使用运行手册来降低风险并实现预期结果。简单而言,运行手册就是完成一项任务的核对清单。

使用行动手册调查问题

行动手册是用于调查事件的分步指南。发生事件时,行动手册用于开展调查,以及确定影响的范围和根本原因。行动手册可用于从失败的部署到安全事件的各种场景。在许多情况下,行动手册可确定根本原因,而运行手册可用来缓解其带来的风险。行动手册是贵组织事件响应计划的必要组成部分。

做出明智的决策来部署系统和更改

为工作负载的成功和不成功变更制定恰当的流程。故障演练是一种演习,团队模拟发生故障的情况来制定缓解策略。使用故障演练来预测故障,并在适当的时候创建程序。评估将变更部署到工作负载所获得好处和产生的风险。确认所有变更符合监管要求。

为生产工作负载创建支持计划

为生产工作负载所依赖的所有软件和服务启用支持。选择适当的支持级别以满足您的生产服务级别需求。以防出现服务中断或软件问题,这些依赖项的支持计划是必需的。记录支持计划以及如何要求所有服务和软件供应商提供支持。实施机制以确认主要支持联系人的信息保持最新。

运营

OPS 8 如何在组织中利用工作负载可观测性?

创建可行的提醒

及时检测和响应应用程序行为的偏差至关重要。尤其重要的是,识别基于关键绩效指标(KPI)的结果何时处于风险当中,或何时出现意外的异常情况。基于 KPI 的警报可确保您收到的信号与业务或运营影响直接相关。这种可操作警报的方法可促进主动响应,并有助于维护系统性能和可靠性。

分析工作负载指标

实施应用程序遥测后,定期分析收集的指标。虽然延迟、请求、错误和容量(或配额)有助于深入了解系统性能,但优先审查业务成果指标至关重要。这样可以确保您做出与业务目标相一致的数据驱动型决策。

分析工作负载日志

定期分析工作负载日志对于更深入地了解应用程序的运行至关重要。通过高效地筛选、以可视化方式呈现和解释日志数据,您可以持续优化应用程序性能和安全性。

分析工作负载跟踪

分析跟踪数据对于全面了解应用程序的运营过程至关重要。通过以可视化方式呈现和理解各个组件之间的交互,可以微调性能,识别瓶颈,并增强用户体验。

创建控制面板

控制面板是以人为本的视图,可用于查看工作负载的遥测数据。虽然它们提供了重要的可视化界面,但它们不应取代警报机制,而是补充警报机制。如果精心设计,它们不仅能迅速洞察系统的运行状况和性能,还能为利益相关方提供有关业务成果和问题影响的实时信息。

OPS 9 您如何了解自己的运营状况?

使用指标衡量运营目标和 KPI

从您的组织获取定义运营成功的目标和 KPI,并确定反映这些目标和 KPI 的指标。将基线设置为参考点,并定期重新评估。制定机制,从团队那里收集这些指标以供评估。

展现状况和趋势,确保运营可见性

了解运营状况及其趋势非常有必要,这样才能确定结果何时可能面临风险、是否可以支持新增的工作,或者变更对团队的影响。在运营事件期间,拥有用户和运营团队可以参考的状态页面以获取信息,可以减轻沟通渠道的压力并主动传播信息

审查运营指标并确定改进的优先顺序

留出专门的时间和资源来审查运营状况,可确保为日常业务提供服务始终是优先事项。召集运营主管和利益相关方,定期审查指标,重申或修改长期和短期目标,并确定改进的优先顺序。

OPS 10 您如何应对工作负载事件和运营事件?

使用流程来管理事件、意外事件和问题

贵组织拥有处理事件、意外事件和问题的流程。事件是在工作负载中发生但可能不需要干预的事情。意外事件是需要干预的事件。问题是需要干预或无法解决的反复发生的事件。您需要一些流程来减轻这些事件对业务的影响,并确保做出适当的响应。

针对每个提醒设置一个流程

针对引发提醒的任何事件制定明确的响应措施(运维手册或管理手册),并明确指定负责人。这样可以确保您及时有效地响应运营事件,并防止可以针对其采取措施的事件被不重要的通知所掩盖。

根据业务影响确定运营事件的优先顺序

确保在多个事件需要干预时,优先处理对业务最为重要的事件。人身伤亡、经济损失、名誉或信任损害都是一种影响。

定义上报路径

在运维手册和管理手册中定义上报路径,包括触发上报的事件和上报程序。明确指定每项措施的负责人,以便确保有效而及时地响应运营事件。

定义中断时的客户通信计划

定义和测试系统中断时的沟通计划,您可以依赖此计划在中断期间让客户和利益攸关方了解情况。当用户使用的服务受到影响和服务恢复正常时直接传达给用户。

通过控制面板展现状况信息

提供为目标受众(例如内部技术团队、领导和客户)专门设计的控制面板,以传达业务当前的运营状况并提供值得关注的指标。

自动响应事件

自动响应事件以便减少由手动流程引起的错误,并确保响应及时并且一致。

发展

OPS 11 如何改进运营?

设置持续改进流程

根据内部和外部架构最佳实践评估您的工作负载。至少每年执行一次工作负载审核。将改进机会优先纳入您的软件开发周期。

在意外事件发生后执行分析

审核影响客户的事件,确定导致这些事件的因素和预防措施。利用这些信息来制定缓解措施,以限制或防止再次发生同类事件。制定程序以迅速有效地做出响应。根据目标受众,适当传达事件成因和纠正措施。

设置反馈环路

反馈环路提供了可操作的见解,进而推动决策的制定。将反馈环路融入过程和工作负载中。这可帮助您确定问题和需要改进的领域。它们还可以验证在改进方面所做的投入。这些反馈环路为持续改进工作负载奠定了基础。

执行知识管理

知识管理帮助团队成员找到完成他们的工作所需的信息。在学习型组织中,自由分享信息,从而增强个人的能力。可以发现和搜索信息。信息准确且保持最新。制定有创建新信息、更新现有信息和归档过时信息的机制。知识管理平台的最常见例子是像 Wiki 这样的内容管理系统。

确定推动改进的因素

确定推动改进的因素,以便评估各种机会并确定其优先顺序。

验证分析结果

与跨职能团队和业务负责人共同查看分析结果和响应措施。通过这些工作来建立共识、发现其他影响并确定行动方案。适当调整响应措施。

审核运营指标

定期与来自不同业务领域的跨团队参与者对运营指标进行回顾性分析。通过这些分析来确定改进机会和可能的行动方案,并分享经验教训。

记录和分享经验教训

记录和分享在运营活动中获得的经验教训,以便在内部和不同团队中利用。

分配时间进行改进

流程中专用的时间和资源可以实现持续增量改进。