【作者】马海明，某银行处室经理，高级工程师，主要负责智能运维体系建设及运维数字化转型相关工作。
在智能运维建设领域，我们面临着一个普遍而深刻的问题：尽管工具建设团队投入了大量的努力，用户却常常反馈他们得到的工具并不是他们真正需要的。这个问题的根源在于工具建设团队和用户之间存在立场和角度的差异。工具建设团队往往过于侧重于技术实现，追求的是工具、功能和菜单的交付，而用户则更关注于工具能否解决他们实际遇到的困难。这种差异导致了双方在需求理解和满足上的脱节，进而影响了工具的实际效用和用户满意度。
为了解决这一问题，业界开始寻求角色和思维的转变，以期构建出真正符合使用者需求的产品。在这一过程中，“运维场景”这一概念被广泛提及，被认为是缩短工具建设者与使用者之间距离的关键。然而，尽管“运维场景”的重要性被普遍认可，关于其具体定义、建设方法的深入研究却相对缺乏，这使得许多团队在实际操作中难以有效地应用这一概念。
一、什么是运维场景？
“场景”一词最早起源于戏剧领域，指的是戏剧作品中一个完整的表演单元，它由特定的地点、时间和一系列相互关联的事件组成。在戏剧中，场景是故事发展的基石，每个场景都承载着推动剧情发展的任务。基于这个概念，衍生出了业务场景、运维场景等概念。
借鉴于这一概念，我们可以将运维场景视为运维领域的一个具体单元，它不仅包含了实现运维目标所需的所有要素，还涵盖了这些要素如何在特定条件下相互作用，它是对运维工作领域中特定工作情境的抽象和概括。
为了更直观地理解运维场景，我们可以将其与戏剧中的场景概念相类比。在戏剧中，一个完整的场景通常包含三个基本要素：演员、道具和剧情。将这一概念类比到运维场景中，我们可以得出以下三个核心要素：
1.演员，即运维参与者。在运维场景中，运维人员相当于戏剧中的演员，他们负责执行具体的运维任务，如系统监控、故障诊断、维护工作等。
2.道具，即运维所依赖的工具和数据。运维工具和数据在运维场景中扮演着戏剧中的道具角色，它们是运维人员完成任务所依赖的技术手段和信息支撑。
3.剧情，即具体的运维情境。这包括运维情境的背景、运维流程、运维目标等，它们指导运维人员如何利用工具和系统来完成特定的运维任务，以实现预定的运维目标。
运维场景从具体的运维需要出发，以一致的目标、共同的语言拉齐工具建设者和使用者之间的认知鸿沟，是工具建设者和使用者之间的桥梁，它具有以下特点：
第一，以用户为中心。运维场景强调从用户的实际需求出发，设计和构建能够解决用户问题的运维工具和流程。
第二，以价值交付为目的。运维场景的目标是实现价值的交付，即通过运维活动达到既定的目标，满足使用者的实际需求。
第三，以用户体验为重点。运维场景注重用户体验，力求使运维工具和流程更加友好、易用，提升用户满意度。
二、运维场景的建设重点
在运维场景的建设过程中，基于运维场景的特点，需要处理好以下三个重点。
1、明确运维场景的受众和定位
在运维场景建设的初期，最关键的步骤是深入了解和识别用户的真实需求。这需要建立在对用户痛点的精准把握的基础上。通过与用户进行深入的沟通和交流，我们可以收集到第一手的输入信息，并在运维场景的设计过程中搞清楚这三个问题。
这个运维场景的主要受众是谁？不要想着一个运维场景包打天下，也不要想着一个运维场景满足大部分用户的需求。每个场景都有自己的定位，都有其重点解决的问题，以及都有自己的目标受众，这样才能有侧重地开展痛点的分析与解决。
这个运维场景的主要目标是什么？运维场景的核心使命是给用户带来价值，即帮忙用户解决实际问题，这就是运维场景的目标。运维场景的设计，需紧密围绕该目标开展，包括UI的设计、功能的实现、菜单的布局、能力的集成等等。
这个运维场景需要重点解决什么用户痛点？痛点意味着堵点，影响了用户价值的满足。而痛点也意味着难点，需要重点攻克，优先解决，才能最大限度保证运维场景的落地。
2、用户要真正、深度地参与运维场景的建设
用户不仅是需求的提出者，也是解决方案的参与者和最终的受益者。这个道理人人都懂，但能付诸行动者少之又少。在运维场景建设中，除了常规的场景需求沟通，用户还可以运维场景的设计中，提供操作流程和操作习惯的反馈，帮助运维团队设计出更人性化、更高效的运维流程；可以参与到运维场景的验收与反馈中，通过实际操作，发现系统的不足之处，并提供改进意见；可以参与到运维场景的推广与培训中，从用户的角度引导更多的用户理解场景、用好场景；还可以参与到运维场景的持续改进中，随着运维场景的持续深入使用，不断提出新的改进意见，永葆场景的生命力。
3、紧紧抓住连接共生的核心，做好能力的整合与流程的连接
一个优秀的运维场景，用户可以得到端到端的满足感。什么叫端到端？以员工离职流程为例，员工离职需要删除用户，需要回收终端，需要经过若干部们的盖章审批，每一项工作都有对应的应用支持，但离职过程中需要做什么，先做什么再做什么，需要员工自行摸索、自行发起流程。如果将其建设成面向员工的离职场景，在这个场景中，需要经过哪些部门的审批，部门之间的审批先后顺序事先通过流程进行定义；在需要回收终端的环节，自动发起终端回收流程；在需要删除用户的环节，员工可以全局看到自己在单位内开通的所有用户，并一键发起。
在这个场景中，场景通过对流程的整合、数据的调用，加快离职手续的工作效率，减少流程出错的概率，提升了员工离职过程中的体验，这就是场景的魅力所在。
三、运维场景的用户旅程设计方法
搞清楚了运维场景的定位和目标，明确运维场景所需要的流程及数据后，还需要开展运维场景的用户旅程设计，让操作流程更合理，让数据呈现更充分，让用户交互及体验实现1+1>2的跃迁。
用户交互与体验的规划与设计有很多方法，比如Design Thiking、用户旅程设计。下文以监控应急为例，介绍运维场景的交互及体验设计过程。
监控应急是数据中心非常核心的一个运维场景，很多数据中心提出“1-5-10”或“1-3-5”的目标，是对这个场景的量化追求。
先来看受众方面。监控应急涉及到的角色非常多，有一线值班人员、二线值班人员、值班经理、管理层、研发支持团队等，每个角色有每个角色的诉求。在进行场景设计的时候，要明确场景的受众，尽量聚焦主要受众。比如我们即将要设计的这个运维场景，就是将主要受众定位在一线值班人员身上，帮助他们快速发现故障，快速完成应急。
“帮助一线值班人员快速发现故障，快速完成应急”就是这个场景要实现的价值及目标。但这个目标很复杂，也很模糊。在面对复杂目标的时候，最有效的方法就是分解，化繁为简。我们可以将这个目标结合用户的交互过程，分解为四个目标：
1、一线值班人员在监控系统发出告警后，在1分钟内响应告警。
2、以告警信息为基础，结合其他信息快速研判告警有效性。
3、确认告警有效性后，值班人员在快速判断问题所在，是应用、数据库、存储还是网络的问题，是变更导致的，还是容量的问题，是一支交易的问题，还是全部交易的问题，是一个节点的问题，还是整个集群的问题，是一个站点的问题还是全局的问题。
4、确定了问题所在后，要第一时间调用对应的应急工具完成应急止损。
由此也同时明确了这个场景的四个阶段：响应阶段、研判阶段、定界阶段、应急阶段。并由此进一步开展每个阶段的设计，需要明确每个阶段用户需要做什么（行为），他们的交互是怎么样的（功能），目前有什么主要的痛点（痛点），如何解决这些痛点（解决方案），需要什么支撑（资源）。
（一）、响应阶段
在告警响应阶段，影响一线值班人员在1分钟内响应告警的因素，要么是告警太多，点不过来，要么是告警被其他更高级别告警、更新告警所淹没。监控系统必须具备以下三种能力：
1、告警动态升级能力。告警刚发生时，级别不一定很高。但当长时间没有响应或者处置时，应根据影响动态升级告警级别，以得到更快速地响应及处置。
2、告警动态排序功能。一般情况下，高级别告警优先于低级别告警，新告警优先于旧告警，重要系统的告警优先于次重要系统的告警，长时间得不到响应处置的告警优先于同级别告警等等。这就需要建立一个告警动态排序方法，把需要一线值班人员优先关注和响应的告警前置。
3、告警压缩降噪能力。告警风暴的抑制一直是这个领域的难题，有些单位的压降效果挺好，但大部分单位还没完全解决这个问题。但对于一线值班人员来说，这个能力必须快速建立。比如说，实现时间窗口内基于相同服务器、相同应用的特定类型的告警合并，实现时间窗口内相同依赖的特定类型的告警关联，甚至该功能可在发生风暴后由一线值班人手动开启，风暴恢复后手动关闭。
（二）、研判阶段
在告警研判阶段，一线值班人员需要基于告警详情信息，快速判定告警有效性，这就要求告警详情页的“告警研判区”提供足够的信息。对于没有明显证据证明误报者，均作为有效告警处置。
告警描述要足够清晰，要对告警进行丰富，要将技术语言转化为业务语言。
在告警详情页，除了看到告警描述，还可以看到告警指标的性能曲线，特别是与上日、上周的同比环比情况。
对于应用类的告警，能直观看到应用系统的业务运行黄金指标运行情况；对于基础设施类告警，要能看到与该基础设施对象关联的运维对象的告警情况汇总，通过趋势比对，快速研判告警有效性。
监控系统要正确处理好“采集不到数据”与“无异常数据”的关系。如“技术报错交易笔数为0”这个指标，到底是因为系统采集不到数据而为0，还是没有技术报错，监控系统要能给出明显的区分。
提供告警标注快捷按钮，对研判结果进行标注。标注交互动作控制在5个点击工作以内。
（三）、定界阶段
有太多太多的因素可能导致故障的发生，故障定界的不确定性非常高。但故障定界的速度，直接决定了应急止损的速度。在故障定界环节，场景要为一线值班人员能提供定界所需的充分信息，但是，信息要经过归纳和整理，避免一线值班人员迷失在各种信息之中。
所以，故障定界要止步于故障对象的定界，而不是故障根因的分析。故障根因分析是故障恢复后二线、研发团队要做的事情。比如说，一线值班团队要快速判定故障是否变更所致，必要情况下进行变更回退；快速判定故障的爆炸范围是一个节点，还是整个集群，是站点故障还是全局故障，不要去纠结于为什么这个节点有问题，直接将这个节点重启或者隔离就行了。如果是站点级问题，直接流量切换，让业务平稳切换至其他站点。至于原因，让其他人查去吧。
根据实践经验，故障详情页“告警定界区”应优先提供以下信息：
1、该告警所命中的标准应急预案，包括告警描述、告警指标、检查方法、应急方法。SRE团队在日常需根据历史故障、告警及经验，完成标准应急预案的梳理。
2、该告警所关联的交易链路。可直观看到链路上各个接口的交易量及报错情况、趋势。
3、该告警的爆炸范围。是单节点，还是集群问题，是站节点还是全局问题，是单只交易还是全部交易问题。
4、该告警所关联的对象过去24小时的变更执行情况（不仅看变更单）、高危操作执行情况。
当然，还有很多告警没法通过上述信息快速定界，定界区还需提供更灵活、更进一步的分析能力，包括一键体检能力，触发从应用，到系统、软件、服务器、存储设备、网络设备的健康检查；提供日志检索分析能力，对应用日志、系统日志、网络日志进行灵活分析；提供拓扑架构、部署架构、交易链路的查询分析能力。
而且，还需提供一键标注功能，允许一线值班人员对定界信息的有效性进行标注，为后续复盘改进提供输入。
（四）、应急阶段
业界将应急操作归纳为三板斧、五板斧或六板斧，无非就是切流、重启、隔离、回退、扩容、降级等。为了加快应急处置的效率，需要实现这些应急操作的菜单化、工具化、脚本化，并支持从告警直接一键触发。
在告警详情的“应急区”，需展示该告警可采纳的应急操作，一方面依赖于标准应急预案，实现告警与应急操作的关联。另一方面，基于专家规则或AI实现应急操作的推荐，从实践来看，前者的效果更优。
但实际上往往出现不敢操作的情况，这种情况的根源在于一线值班人员对应急操作能力的不信任。第一，应急操作要有一套完善的演练及一线交接流程，通过演练及交接的应急操作有鲜艳的标识，能看到这个应急操作什么时候演练过，什么时候通过交接验收。第二，要在线展示每一个应急操作的使用情况，本周、本月被使用多少次，成功率多少，上一次使用是什么时候，谁使用的，使用结果如何，用数据建立起一线值班人员的信心。
同时，很多单位容易以“页面跳转”代替“一键触达”，“页面触达”效率慢，还容易导致操作风险，本质上是应急规范确实所致。工具建设团队应建立应急操作对接规范，可以通过接口调用或页面跳转的方式，但一定要实现端到端，即不管采用哪种方式，一线值班人员无需再进一步的检索、查找、参数录入，可直接一键发起应急，且所见即所得，所有操作均有回应，能直观看到操作结果。
（五）、体验设计
整个监控应急场景涉及的环节较多，信息复杂，完成用户交互设计后，还需进一步考虑用户体验。
1、让用户优先看到最有价值的信息。要与用户充分沟通，什么样的信息对他们价值最高，那在布局上应往这方面侧重。如果信息过多，可以合理使用“完整展示”、“略缩展示”、“跳转入口”等方式，进行各种信息的差异化布局。
2、尽量减少用户的交互操作。能展示的直接展示，能让用户少一次点击就争取少一次点击。比如说，在应急预案的展示上，不要让用户跳转到知识库系统进行检索，应通过规则或AI实现告警与应急预案的直接匹配，预案中这个告警的描述是什么，在指标上有什么体现，应该采用什么检查方法，用什么方法应急，一目了然地展示。一线值班人员可以直接给该预案点赞或扔鸡蛋。
3、充分利用数据，建立用户对场景的信心。用户都有从众心理。所以，不管是告警指标的趋势展示，还是应急操作历史的展示，还是用户的点评记录，我们都是用数据告诉用户——这是一个值得信赖的场景，你不是第一个吃螃蟹的勇士，你可以大胆使用。
四、小结
在运维实践中，场景的复杂度和规模呈现出多样性，从单一的简单任务到涵盖多个阶段的复杂流程，均可构成一个运维场景。以变更管理为例，从变更准备阶段到执行阶段，最终至检查阶段，可以作为一个整体场景来考量。同时，基于用户的具体需求和定义，这一流程亦可被划分为若干独立的运维场景，例如：变更前的风险评估、变更中的自动化执行、以及变更后的技术检查。这种划分有利于对每个阶段进行更为精细化的管理和优化。
无论场景的规模如何，它们都具有一个共同的特征，都需要对工具、能力、数据和流程进行整合调用，为了满足特定的用户需求，并实现既定的目标。
欢迎点击文末阅读原文到社区原文下讨论交流
觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 “智能化运维”技术主题 ，将会不断更新优质资料、文章。地址：https://www.talkwithtrend.com/Topic/125353
*本公众号所发布内容仅代表作者观点，不代表社区立场
