针对高速团队的事件管理
事件管理的语言
事件管理团队的词汇表
最起码，整个科技生态系统中使用的语言都是动态的。在其他任何地方，您都找不到技术术语与科幻小说、神话、流行文化、历史和文学中的参考文献无缝交织在一起的混合体。虽然这使对话变得丰富多彩且引人入胜，但也使对话通常难以确定。
没有紧急情况发生时，这点行得通。但是，如果发生事件且严重性急剧上升，我们需要确保语言在技术上精确可行，不留任何误解的余地。
这意味着，在事件管理方面，我们需要一套明确的定义来使人们保持一致。
事件确认 (ack)
生成事件警报后，用户可以在大多数待命警报工具中确认警报。这意味着用户已对该事务负责，并正在努力解决该事务。
可操作的警报
可操作的警报是一种警报，它清楚地描述了事务及其影响，并在适当的时间发送给适当的人员，以便团队可以立即采取行动。
主动监控
配备有主动监控功能的系统会定期检查或使用软件自动监控可能导致事件的任何性能变化。
事后审查 (AAR)
事后审查是在事件发生后进行的结构化审查流程。该流程通常详细描述发生了什么，试图找出发生的原因，并查明需要改进的领域，以防止将来发生相同或相似的事件。事后审查通常也被称为事后分析或事件后审查。
约定服务时间 (AST)
约定的服务时间是服务预计可用的时间，通常以每年的小时数来衡量。该协议通常在供应商和客户之间的 SLA（服务级别协议）中概述。高可用性服务通常承诺 99.99% 的正常运行时间，每年允许不到一小时的停机。
警报
监控工具发现 IT 环境中的更改、高风险操作或故障时生成的警报或警告。
警报噪音
在短时间内创建大量警报，就会出现警报噪音，这使得响应者难以准确识别哪些服务受到影响以及确定其工作的优先级。警报噪音可能是警报疲劳的一个促成因素。
警报疲劳
当事件响应者对警报的数量或频率感到不堪重负时，就会出现警报疲劳。警报疲劳通常会导致响应缓慢或无响应，因为响应者倾向于使持续警报正常化。
始终在线的服务
预期持续运行的服务。
资产/资产管理
任何具有商业价值的系统或网络的组件。资产管理是指员工或团队盘点这些组件，以了解更新或删除系统的影响。
审计
正式检查系统或流程的可用性和使用情况，以及是否遵循了政策、指导方针和最佳实践。
可用性
当产品或系统可用并按预期运行时。也称为系统正常运行时间。
退回
将服务恢复到以前的可靠状态或基线的实践。这通常是在更新或发布破坏系统中必不可少的内容时应用的快速修复。
备份
存储的数据副本或冗余系统，可在原始数据泄露或丢失时使用。
基线
预期行为的参考点。基线可帮助团队衡量变化和改进。
基准
一个参考点，其功能类似于衡量进度或比较结果的基线。例如，如果我们行业的标准是 99.99% 的正常运行时间，这可能是我们根据竞争对手和客户期望来衡量自己的基准。
缺陷
软件、代码、程序等内容中可能导致异常行为或故障的意外问题。
业务影响分析 (BIA)
业务影响分析是对重大事件导致的服务中断和停机潜在影响的系统性评估。BIA 的目标是了解每项服务对业务的影响，并定义发生事件时的恢复要求。
容量
可在网络之间传输或通过服务交付的最大信息量。超出容量是事件的常见原因。
更改
对 IT 服务、配置、网络或流程所做的任何更改。通常在称为变更管理的实践中进行跟踪。
更改历史记录
全面记录 IT 服务、配置、网络或流程从生命周期开始到当前状态所做的变更。
变更管理
一种 IT 实践，专注于最大限度地减少关键系统和服务变更/更新期间的中断。对于某些团队来说，这种实践涵盖了变更的各个方面，从技术方面到人员和流程方面。对于其他团队（基于 ITIL 4 指导方针），变更管理侧重于管理变更的人为或文化方面，而另一种称为变更控制的实践则侧重于风险评估、计划和变更授权。
ChatOps
使用聊天和协作工具进行事件管理的实践。正如 Atlassian 的 Sean Regan 解释的那样：
“ChatOps 是一种协作模式，它将人员、工具、流程和自动化连接成一个透明的工作流程。工作流程将待完成工作、进行中工作和已完成工作衔接起来，放进一个由人员、机器人和相关工具组成的持久场所。”
关闭状态
如果已采取所有必要措施并且某个事务已关闭，则事件处于关闭状态。
冷备用（逐步恢复）
当一个系统充当另一个系统的备份时，使用冷备用。如果主系统出现故障，冷备用系统将在修复主系统时替换主系统。如果主系统故障需要逐步恢复（恢复可能需要数周时间），并且需要更换和设置计算硬件，那么这是一种特别有用的策略。
冷启动
当未运行的应用比“热”应用或已在运行的应用需要更长时间启动时，就会发生冷启动。
通信主管
事件期间负责沟通的团队成员。
合规性
与法规保持一致。通常，监控系统将编程为监控合规性问题，并在系统不合规时触发警报。
组件故障影响分析 (CFIA)
如果某个组件或配置停止按预期工作，用于确定对服务的影响的流程。
并发性
衡量一个系统中有多少相同操作同时发生的度量。例如：有多少用户正在访问相同的操作或执行相同的交易？
控制
管理风险、确保产品或服务按预期运行以及保护合规性的程序和策略。
核心服务
为用户/客户提供中心功能的服务。
对策
为保护系统或恢复操作而采取的特定被动操作。
面向客户的服务
客户使用和与之交互的服务。
Cynefin 框架
一种决策结构，已根据事件管理流程进行了调整，以帮助管理人员组织最有效的响应。该框架根据事件的复杂程度将情况分为五类，每个类别都有自己（不同的）后续步骤。
仪表板
系统、警报和事件的单屏可视化，旨在组织来自各种工具的信息呈现，并以干净、精确的格式提供上下文信息。
相关性
相互依赖的两个服务、流程或配置之间的关系。
弃用
当功能或工具停止使用、不再使用或不再更新时。
诊断
了解事件及其根本原因的过程和结果。
诊断学
导致事件诊断的症状或迹象。
停机时间/中断
服务未按预期执行或不可用的时间。
紧急变更
快速部署的更新或修补程序，通常作为事件解决的一部分。紧急变更通常会跳过变更批准流程，因为等待批准的风险大于部署变更的风险。
启用服务
核心服务运行所需的服务，但它本身并不能直接提供给客户。
测试环境*
对服务、功能、流程、配置项目等进行预期功能测试的基础架构。此环境受到严格控制，以镜像生产。
生产环境
向客户提供服务的基础架构。此环境中的交付项是实时的，有时也称为实时环境。
错误
导致配置项目或服务失败的错误。可能是设计、流程或人为错误。
上报
将事件管理任务移交给具有更多相关技能或经验的团队或个人的流程。职能上报是指将警报或事件转移给专业知识程度更高的个人或团队。等级上报是指将所述警报或事件从初级员工转移到高级员工那里。
事件
值得注意的系统或服务情况。事故通常是由用户操作或事件引起的。
异常报告
关键绩效指标 (KPI) 超过阈值或未达到预期时生成的报告。
容错
容错描述了即使配置项目或单个部件出现故障，服务仍能继续运行的能力。
故障树分析
一种技术，用于确定导致事件的事故，并预测哪些事故将来可能导致事件。它通常用于找出重大事件的根本原因。
一线支持
响应者预计将首先对事件做出反应。这通常是待命人员。
修复
修复的操作或方法。
固定资产
固定资产是企业的实物、有价值、长期的东西，例如办公室、计算机或许可证。
全天候时间表
一种客户支持或事件管理方法，跨时区轮换待命职责，以提供全天候覆盖，而无需团队在半夜待命。
取证调查
为确定事件原因而对计算机系统进行科学的、基于证据的调查。
正常运行
当服务能够按预期执行时，即为可以正常工作。
逐步恢复
逐步恢复是一个恢复过程，需要比平时更长的时间（几周，而不是几小时）。发生这种情况时，冷备用（备份系统）通常会联机以取代受影响的系统。
热备用
热备用是一种恢复选项，冗余资产可以同时运行，以便在出现故障时支持 IT 服务。如果活动系统出现故障，则表示热备用已在运行并可以取而代之，无需团队采取任何行动，也没有停机。也称为立即恢复。
修补程序
为解决问题或修复错误而应用于软件的更新。这通常用于修复客户报告的问题。
影响
衡量服务中断、事件或变更导致的（金钱、时间、声誉）成本。也称为停机成本。
不可操作的警报
不授权响应者采取行动的警报。这通常意味着警报缺少上下文信息、发送给错误的人或范围不明确。不可操作的警报可能会导致警报疲劳。
事件
造成服务质量中断或下降的事件，需要作出紧急回应。遵循 ITIL 或 ITSM 实践的团队可能会使用术语重大事件指代我们所说的事件。
事件管理
DevOps 和 IT 运营团队用来响应计划外事件或服务中断并将服务恢复到运行状态的流程。
事件指挥官
事件指挥官是负责管理事件响应的 IT 或 DevOps 团队的成员。指挥官是事件管理团队的负责人，对所有事件的决定拥有最终控制权和最终决定权。此角色通常也称为事件经理。
事件生命周期
事件从创建、检测到解决的生命周期。
I/O 指标
衡量输入和输出的指标集合。此类别中的常见指标包括 IO 等待（CPU 等待 IO 请求的时间）和 IOPS（每秒 IO 请求数）。
事件响应编排
Opsgenie 的一项功能可让团队快速有效地发现问题，通知合适的人员，推动业务部门之间的沟通，并跨团队协作进行事件管理。
事件记录
记录特定事件的详细信息和在特定事件中使用的流程。
事件响应者
负责调查和解决事件的个人和/或团队。
事件利益相关者/关注者
需要随时了解事件的个人，因为这会影响他们的工作/工作能力。这些人可能会也可能不会影响事件的解决，但他们不是主动响应者。
中级恢复
这种类型的恢复也称为热备用，通常需要 24-72 小时。数据恢复和/或硬件和软件配置通常是恢复时间相对较长的原因。
信息技术基础架构库 (ITIL)
一套记录在案、广受认可的 IT 服务最佳实践。
信息技术服务管理 (ITSM)
向客户提供 IT 服务所需的流程和程序的所有方面。这包括服务生命周期的所有方面——从设计到交付再到事件管理。
Kepner Tregoe 方法（KT 方法）
一种根本原因分析和决策方法，将问题与事务的最终决定分开评估。
关键绩效指标 (KPI)
衡量系统或产品的成功程度。KPI 是事先决定的，定期跟踪，如果偏离预期阈值，通常会生成警报。例如，如果平均故障间隔时间 (MTBF) 开始越来越短，则可能会生成警报，以便您的团队能够确定和调查问题。
已知错误
先前存在的事务，已经有了解决方法。
延迟
数据传输过程中出现的延迟。
日志
与服务或应用相关的所有活动的记录。这包括传输的数据、时间和日期、事件、更改、错误等。
可维护性
衡量成功应用于服务或功能的变更的难易程度。
手动解决方法
手动（而不是自动）实施的解决方案。
平均故障间隔时间 (MTBF)
技术产品可修复故障之间的平均间隔时间。也称为平均服务事件间隔时间 (MTBSI)。
平均确认时间 (MTTA)
从触发警报到开始解决事务所用的平均时间。
平均故障时间 (MTTF)
技术产品不可修复的故障之间的平均间隔时间。
平均维修时间 (MTTR)
修复系统（通常是技术或机械）所需的平均时间。这包括维修时间和任何测试时间。
平均恢复时间 (MTTR)
从产品或系统故障中恢复所需的平均时间。这包括整个中断时间——从系统或产品出现故障到其恢复完全运行为止。
平均解决时间 (MTTR)
完全解决故障所需的平均时间，包括确保故障不再发生所花费的时间。
平均响应时间 (MTTR)
从首次收到产品或系统故障警报开始，到从产品或系统故障中恢复所需的平均时间。这不包括警报系统中的任何延迟时间。
模型/建模
实际系统、服务、应用等的表示。
监控
检查服务或流程以确保其按预期运行的重复流程。
正常变更
一种非紧急变更，但它们并没有既定的、预先批准的流程。
待命值班表
确保无论白天还是黑夜，都有合适的人员随时待命，以快速响应事件和中断的时间表。待命时间表在医学和科技领域都很常见。
运营桥
进行 IT 服务监控的物理位置。
运营主管
负责监督日常运营的人员。在某些情况下，此人也可能是事件经理（或事件指挥官），负责领导事件解决。
结果
与 IT 相关的事件、流程或变更的结果。团队经常谈论预期结果和实际结果。
疼痛价值分析
用于确定事件业务影响的分析。这通常会考虑停机成本、事件持续时间、对用户的影响以及受影响的用户数量。
被动监控
自动监控（而不是主动或手动监控）服务功能。
和平时期
当服务和运营按预期运行而没有任何中断时。
性能降级
衡量由于事件或事故而导致系统性能下降的程度。
计划内停机
IT 服务因维护或更新而故意不可用的时间段。
手册
团队为解决特定问题、事件或目标可以采取的“重头戏”或特定操作的集合。
事后分析/事件后分析/事件后回顾
事件解决后对其进行了解的过程。事后分析的目标是改善响应流程，防止将来发生事件，并了解最近事件的原因。
优先级
事件的处理顺序。高优先级的项目比低优先级的项目需要更高的紧迫性。优先级取决于紧急程度、严重性以及对业务的潜在影响。
问题记录
问题记录是涵盖问题各个方面（从检测到解决）的文档。
服务中计划断
一份概述未来维护或测试将如何影响正常服务级别的文档。
质量保证
测试过程，以确保任何与 IT 相关的内容都符合标准，从新功能到操作指南。
质量管理体系
提供质量保证的现有框架或系统。
被动监控
针对事故或事件而进行的监控。
恢复
使服务恢复到基线功能和运行状况的流程。
恢复点目标
恢复期间允许的最大数据丢失。
恢复时间目标
允许服务中断的最长时间。
发布
已部署到用户的变更。
发布管理
变更的规划、设计、测试、时间安排、故障排除和部署。
弹性
系统抵御故障并在发生事件时快速恢复的能力。
响应时间
从生成警报到团队采取初始操作所用的时间。
风险评估
通过评估资产的价值、潜在威胁以及这些威胁的潜在影响来确定资产风险的流程。
风险管理
通过确定和控制威胁来处理威胁的过程。
根本原因
根本原因通常被认为是服务或应用故障的唯一原因。但是，通常有许多相互关联的因素会导致故障，因此团队开始争论这个术语对事件管理是否有帮助，许多人认为有多个根本原因。
运行手册
运行手册提供了事件管理的详细程序。这些通常由系统管理员或网络运营控制 (NOC) 团队维护。运行手册可以是电子版或印刷版。
范围
问题的程度、解决方案、项目、能力等
二线支持
具有额外能力（时间、经验、知识、资源）的员工，可以解决第一批响应者可能无法解决的事务。
服务变更
对服务进行的更新、修复、弃用或其他更改。
服务台
一个接受客户支持请求并充当客户与 IT 之间的联系点的团队。
服务故障分析
服务故障分析是检查服务中断以确定其原因的流程。
服务级别协议 (SLA)
提供商和客户之间关于正常运行时间、响应能力和责任等可衡量指标的协议。
服务级别协议监控 (SLAM) 图表
记录服务级别目标的进度和数据的文档。
服务级别目标 (SLO)
SLA 中关于特定指标（如正常运行时间）的协议。
严重性 (SEV) 级别
服务受事件影响的程度。通常，团队使用 3-5 级 SEV 级别结构，其中 1 表示严重性最高，3-5 表示严重性较低且不太紧急的事务。
单点故障
一个系统运行所依赖的变量。例如：基本配置项目。
规格
与 IT 相关的配置要求的正式记录。
站点可靠性工程师 (SRE)
负责运营的软件工程师。SRE 通常负责自动执行手动任务、管理 SLO 和管理事件。
标准变更
低风险、经常重复、预先批准的更改，例如添加内存或存储。
备用
可用于支持事件管理的非活动资源。
状态
服务的当前状况。
状态页
专用主页，用于传达服务的当前状况，并定期更新事件状态。
主题专家 (SME)
具有特定事务、服务等方面特定知识的个人
技术堆栈
构成应用的编程语言、软件和组件。技术堆栈有两个方面：前端（面向客户）和后端（面向开发人员）。
紧张度指标
当一个集合或点发生变化时，会对其他数据点产生负面影响的数据。
阈值
预定义的级别或数字，超出时会生成警报。例如，登录页面的加载阈值可能为三秒。如果页面加载时间较长，则会生成警报。
时间线
事故、变更、修复、结果的完整列表，以及事件期间每项发生的时间。
趋势分析
对与时间相关的模式的调查。趋势分析假设过去的模式可以预测数据中的未来模式。这使其成为预防事件的宝贵实践。
解决方法
一种成功实施快速修复的方法，即使底层事件尚未解决，也能使系统功能恢复正常运行。
工作量
提供 IT 服务所需的资源，包括人力和机器。