第7节
持续审计最佳实践

提要

·　持续审计相对于价值链和价值体系的附加值，在于其提高了控制监控的频率，并将现有控制措施进行整合，从而识别和弥补控制漏洞。

·　在持续审计中，内部审计师的角色从控制的所有者和裁判转变为教练。

阅读指南

本节讨论了持续审计价值流中每个步骤的最佳实践，如图1.7.1所示。

一、确定TOM范围

图1.7.1描述了持续审计价值流的第一个用例。

1．目标

持续审计价值流的这一步骤，为接受持续审计的组织提供了一个对其TOM的清晰概览。基于此，可以确定哪些行政组织部门应该被纳入持续审计的范围。

2．要回答的问题

持续审计价值流中每个步骤的相关问题已在图1.5.3中给出。本节将说明如何回答这些问题。如表1.7.1所示

持续审计的范围可以通过确定TOM的相关范围来确定。表1.7.2列出了这些问题并指出了如何获得这些答案。

表1.7.3列出了表1.7.2中的命名模型如何回答问题。

3．商业模式画布模板

图1.7.2显示了商业模式画布的模板，该模板用于实现新的商业模式或改进现有的商业模式。

该模板的目标是为了提升组织的成果。

组织成果的增长离不开对客户价值主张和客户细分的精准把握。要实现这一点，我们需要深刻理解客户，并选择恰当的渠道触达目标客户群。我们可以通过调动核心活动和核心资源来创建价值主张，辅以合作伙伴的支持，为客户带来增值。在这里，收入流和成本结构则分别反映了收益和支出情况。

商业模式画布的利益相关方包括客户、供应商和核心资源。此外，还应考虑来自偶然因素的利益相关方，例如政府、工会、审计机构、认证机构等。利益相关方的利益源于商业模式画布本身。成果增长的战略是商业模型画布的核心。整个画布是基于此制定和实现的。使命和愿景是寻找新商业模式时的重要背景因素，在这一探索过程中，随着新理解的产生，使命和愿景也可能随之调整。

4．系统上下文图模板

图1.7.3显示了系统上下文图的模板。图的中心位置通常为信息系统的名称，但也可以用价值链进行替代。矩形框代表利益相关方，我们也称为参与者或实体。输入和输出流必须用箭头描述。

通过梳理组织内外信息的输入和输出流向，我们可以清晰地识别与组织产生交互的各方利益相关方。流的内容间接反映了与之相关的利益相关方的重要性，进而界定了TOM的背景，并隐含了部分面向外部的价值流。

5．价值链、价值体系和价值流的模板

图1.2.3、图1.2.4和图1.2.5展示了价值链、价值体系和价值流的模型，并对这些模型的相似之处和差异进行了讨论。我们可以基于这些模型明确选择范围。由于这些模型的逻辑关系可以自然地推导出目标，我们运用这些模型还可以简化第二步的操作。

6．平衡计分卡模板

图1.7.4显示的是平衡计分卡。这是卡普兰（Kaplan）和诺顿（Norton）在著作《领先的平衡计分卡》（2004年版）中定义的战略管理工具。1990年，他们调查了财务状况良好的公司由于破产而很快从证券交易所消失的现象。

证券交易所的股票价值不足以确定一个组织的健康状况，必须有比财务指标更多的指标。他们很快得出的结论是，除了财务指标，在确定组织的价值方面还有3个重要因素：生产过程的内部质量、创新能力和客户满意度。他们以计分卡的形式来描述这4个因素，即客户视角、财务视角、内部业务视角、创新和学习视角。计分卡内容以组织的愿景和战略为基础。

“平衡”一词代表了计分卡纵向和横向内的关系。例如，组织的盈利能力由于对创新的投资而下降，客户满意度通过对内部组织的投资来提高。每个计分卡包括长远目标、措施、阶段目标和计划。平衡计分卡本质上是管理业绩指标的分类模型。

二、选择目标

图1.7.1描述了持续审计价值流的第二个用例。

1．目标

此步骤旨在选取组织内必须通过持续审计进行保障的目标。这些目标必须在先前步骤中确定的TOM范围内。

2．要回答的问题

持续审计价值流中每个步骤的相关问题已在图1.5.3中给出。本节将说明如何回答这些问题，如表1.7.4所示。

持续审计要实现的目标可以根据多种模型来确定。实施这些模型需要先确定审计对象的范围。表1.7.5列出了这些问题并指出了如何获得这些答案。

表1.7.6描述了表1.7.5中的命名模型如何回答问题。

3．业务平衡计分卡模板

图1.7.4显示了平衡计分卡。它列出了每个视角的目标、关键成功因素（Critical Success Factor, CSF）和SMART目标，为战略提供了实质性的内容。持续审计必须不断确定是否实现了这些目标。一种有效的做法是使用CSF方案，该方案显示了为每个视角分配的CSF的连贯性，在CSF之间用箭头表示因果关系，不符合因果关系方案的CSF可能不适合使用。如图1.7.5所示。

这些CSF是确保业务目标实现的控制措施，它们必须在相关的价值流中实施并持续监控。图1.2.4和图1.2.5表明，波特的价值链可以级联到价值体系（如SVS）上，SVS是以服务组织为基础构建的。

该组织必须将业务平衡计分卡级联到自己的平衡计分卡上，该平衡计分卡应具有自己的解释，以支持业务平衡计分卡，如图1.7.6所示。这也包括为该级联平衡计分卡的CSF提供一个CSF方案，但现在是针对必须在SVS的价值流中获得的CSF。

4．价值流画布模板

除了自上而下的业务目标分析外，我们还可以通过持续审计采用自下而上的方法来确定目标。这可以使用价值流画布模板来完成，如图1.7.7所示。

（1）价值流名称

价值流的名称位于左上方，应选择能够涵盖整个价值流的名称。

（2）触发

每个价值流都是由现实中的事件触发。要知道这不是价值流的第一步，而是触发价值流第一步执行的事件。

（3）第一/最后一步

明确价值流的范围至关重要，因为通常会存在价值流链。因此，确定价值流的第一步和最后一步具有重要意义。

（4）需求率

价值流实施的问题十分重要，因为它可以确定实施改进的商业案例。这需要基于瓶颈分析进行，并运用精益六西格玛方法。精益六西格玛绩效指标也可以添加到需求率中，但也可以在用例级别稍后进行确定。

这些指标是：

·　前置时间（Lead Time, LT）：这是价值流的平均前置时间。

·　处理时间（Processing Time, PT）：这是实现价值流所需的平均时间。

·　完成度/准确度百分比（%Completeness/Accuracy, %C/A）：这是交付产品中各个中间步骤的完成度和准确度的百分比。它不是指最终产品的质量，而是指价值流内部各个环节的“首次正确”交付情况。

（5）当前状态

当前状态表示业务流程的步骤。这些实际上是稍后将详述的用例。在价值流中可以使用分支，但是，价值流应该保持简洁，最多有20到25个步骤。

（6）边界和限制

每个信息系统都有必须明确定义的边界，这可以通过指示信息系统所受限的输入来完成。此外，还有一些限制，由LT和PT或%C/A表示。这些限制和边界可能会导致需要改进价值流。

（7）改进项

边界和限制可以帮助识别需要改进的点。这些改进点是产品待办事项列表的输入。改进可以作为主题、史诗、特性或故事放入产品待办事项列表中。

（8）未来状态

如果改进导致当前状态发生调整，则需要绘制未来状态，其中包含实现改进所需的价值流变化。实现未来状态中指示的改进对于实现业务目标是必要的。因此，这些必须像平衡计分卡的目标一样持续监控。

5．内部标准框架的模板

内部标准框架源于上述的平衡计分卡，这可以级联到个人层面。平衡计分卡也可以用于起草SLA，即将目标、CSF和SMART目标转化为相关服务或产品的SLA规范。

6．外部标准框架的模板

大多数组织都必须遵守法律法规，例如税法、GDPR、档案法、医疗保健法等。为了满足这些框架的要求，必须提供证据。这些证据必须在价值流中创建。事后为了满足审计师或立法者的信息需求收集证据是一件非常冒险的事情。尽管我们都明白，但为了防止这种情况发生而采取的管理往往不尽如人意。持续审计的目的是完全自动地确定这一点。第一步是对这些框架进行盘点，第二步是确定哪些价值系统或者价值流必须遵守这些框架，最后，应该映射出提供证据所涉及的信息系统，如表1.7.7所示。

相关的标准框架众多，而证据需要来自许多系统。因此，准确地映射出这些所需信息并自动收集证据是很重要的。

三、识别风险

图1.7.1描述了持续审计价值流的第3个用例。

1．目标

此步骤旨在根据组织的目标来识别风险。这些风险必须在先前步骤中确定的TOM范围内。

2．要回答的问题

持续审计价值流中每个步骤的相关问题已在图1.5.3中给出。本节将说明如何回答这些问题，如表1.7.8所示。

目标未达成的风险必须在多个模型的基础上通过持续审计确定，而这些模型的实施需要为TOM确定目标。表1.7.9列出了这些问题并指出了如何获得这些答案。

表1.7.10描述了表1.7.9中的命名模型如何回答问题。

图1.7.8展示了风险的生命周期。风险是从问题、变更、需求和事件中识别出来的。经辨识的风险会与风险控制矩阵（又称CIA矩阵，CIA即Confidentiality, Integrity, Accessibility，也就是保密性、完整性、可用性）进行比对。通过风险评估，对新出现的风险进行细致探查，进而确定其优先级。风险处理会导致控制措施被放置在控制待办事项列表中等待实现。这些控制措施通过CI/CE安全流水线实现和监控。所收集到证据用于确定风险是否已被充分缓解或消除。

（1）风险识别

目标面临的风险可以来自内部和外部因素的识别。这些潜在威胁可能起初没有显露，但在某些情况下会变得严重并构成风险。因此，需要定期评估它们的现状。人员、流程、技术和合作伙伴的变化也是风险来源之一。当然，与业务往来的客户的要求也可能带来风险。最后，发生的事件也表明必须控制的风险。

（2）风险评估

为了制定风险应对措施，必须对风险进行分类，以确定其可能性和影响。基于此来确定如何处理风险。

评估风险的一种有效方法是将其映射到CIA矩阵。CIA矩阵指示了对保密性、完整性和可用性等质量方面所需的控制程度（0、1、2和3）。控制程度也有优先级的区分，可以通过确定可能性和影响来确定优先级。我们可以选择控制（修改）、避免、分担或承担（保留）风险。如果存在被归类为“修改”的风险，则使用CIA矩阵。

CIA矩阵的使用分为三步。第一个CIA矩阵包含已实施控制措施的对象，如表1.7.11所示。如果新风险的对象尚未添加，必须将其添加到矩阵中。如果对象已经存在，则必须将风险添加到第二个CIA矩阵中，该矩阵列出了需要控制的风险，如表1.7.12所示。如果风险尚未列出，则必须将其添加。

（3）风险处理

一旦发现新的风险被添加到CIA矩阵中，就必须检查现有的控制措施是否足以消除或缓解风险。这可以通过定义控制措施并确定其是否已存在来完成。现有的控制措施在第三个CIA矩阵中进行管理，如表1.7.13所示。

四、实现控制

图1.7.1描述了持续审计价值流的第四个用例。

1．目标

识别的风险必须得到妥善管理。这可以通过采取控制措施的形式来完成。前面的用例中已经建立了这些控制措施。在此用例中，我们将识别出在产品待办事项列表已实现的控制措施，并使用CI/CD安全流水线将它们投入生产。

2．要回答的问题

·　相关的“Given – When -Then ”陈述是什么？

·　测量要求是什么？

·　控制措施实现的规划是什么？

·　哪些DevOps团队负责实现哪些控制措施？

持续审计价值流中每个步骤的相关问题已在图1.5.3中给出。本节将说明如何回答这些问题，如表1.7.14所示。

为了消除或减轻风险，我们必须实施控制措施和持续检查控制措施的有效性。有效性不仅在控制措施功能被验收并投入生产时确定，还必须建立监控设施，进行持续监控。表1.7.15列出了这些问题并指出了如何获得这些答案。

表1.7.16描述了表1.7.15中的命名模型如何回答问题。

图1.7.9显示了价值架构模型的路线图，它遵循“产品愿景”“产品路线图”“发布计划”和“迭代计划”的步骤。

（1）产品愿景

该模型表明，敏捷项目的开始应该从构思愿景开始。这是基于企业架构和由其定义的项目组合。产品愿景与持续审计价值流的前两个步骤（“确定TOM范围”和“选择目标”）密切相关。

（2）产品路线图

持续审计的利益相关方是根据利益相关方分析进行选择的。路线图的内容包括将作为概念的持续审计配置以及需要控制的风险，这与持续审计价值流的第三步（“识别风险”）相对应。该路线图包括每个利益相关方每个季度需要实现的风险控制措施。因此，每个史诗都由一个拥有该史诗的利益相关方负责。

（3）发布计划

发布计划来自路线图，包括在史诗和功能级别控制措施实现的规划，它们会在每个迭代中进一步细化。

（4）迭代计划

迭代计划符合敏捷Scrum计划的要求，这也适用于价值路线图的后续步骤。熟悉TMAP中的V模型的人会注意到这并不是V模型。因此，左侧和右侧的步骤之间不存在V模型中所示的对应关系。在这里，控制措施的规划将率先进行，随后在价值路线图的剩余部分中采用敏捷Scrum步骤。

五、监控控制

1．目标

“监控控制”用例的目标是以尽可能统一的方式，使用尽可能少的监控工具来监控已识别的控制措施。

2．要回答的问题

·　哪些对象需要被监控？

·　可以使用哪些监控设施？

·　测量要求是什么？

3．要回答的问题

为了实现这一步骤的目标，必须识别哪些对象需要被监控，基于确定的监控对象选择合适的监控设施。最后确定测量指标。这些问题已经在持续审计金字塔（图1.5.3）中进行了描述。本节将说明如何回答这些问题，如表1.7.17所示。

表1.7.18列出了这些问题并指出了如何获得这些答案。

表1.7.19描述了表1.7.18中的命名模型如何回答问题。

4．监控层模型

图1.7.10展示了监控层模型。每个层级都是一个用于监控控制措施的监控原型。

（1）业务服务监控

价值流监控层是基于精益指标LT、PT和%C/A对价值流进行监控。当然也可以基于其他关键绩效指标（Key Performance Indicator, KPI）进行监控。信息流监控旨在测量信息链或工作流中的信息。例如，可以检查信息链中交易总数是否与发票一致。真实用户监控（Real User Monitoring, RUM）是测量用户实际输入信息系统的交易。

（3）信息系统服务监控

通过使用机器人模拟用户交易的端到端（End to End E2E）监控来监控信息系统也称为“端到端用户体验（End User eXperience, EUX）”。端到端基础设施监控旨在对应用程序运行的基础设施进行端到端的测量，而不需要使用应用程序。通过让机器人执行E2E ping来进行测量，该ping仅遍历基础设施的各个组件，测量时间并传递结果。每个组件上实现一个微应用程序，这样就可以确定监控到的偏差是由应用程序还是基础设施引起的。域基础设施监控用于测量网络中的某个部分，例如广域网（Wide Area Network, WAN）中的局域网（Local Area Network, LAN）。

（3）应用程序服务监控

应用程序服务监控旨在确定信息系统中每个应用程序是否正常运行。通常使用REST API来实现。基础设施服务监控也是如此，但在这种情况下，通常使用SNMP GET协议。

（4）组件服务监控

持续监控层模型的底层是服务监控组件。内部服务监控集中在组件中的服务。例如，这可以是在组件中运行的Windows或Linux服务。Linux运行非网络守护进程服务，如用于调度的cron和提供高级电源管理的apmd。因此，它不是像httpd和inetd那样的基础设施服务监控，而只是本地服务监控。事件监控是通过从日志文件中提取事件或查询组件本身的状态（例如磁盘控制器电池的健康状况）来收集组件中的事件。然后对事件进行关联，以解释和处理事件的一致性。资源监控是监控组件的占用情况，例如内部内存使用情况、外部内存使用情况、网络带宽使用情况等。服务监控组件的最后一种监控原型是内置监控。

这是供应商在所购组件中提供的监控服务。它也可以是组织自己编写的监控服务，作为应用程序的一部分来测量内部性能。

六、证明控制的有效性

1．目标

“证明控制的有效性”用例的目的是确定现有的控制是否充分管理了已识别的风险。

2．要回答的问题

·　证据存放在哪里？

·　如何跟进缺陷？

3．要回答的问题

持续审计价值流中每个步骤的相关问题已在图1.5.3中给出。本节将说明如何回答这些问题，如表1.7.20所示。

证据必须储存，缺陷必须跟进。表1.7.21列出了这些问题并指出了如何获得答案。

表1.7.22描述了表1.7.21中的证据协议如何回答问题。

图1.7.11描述了持续审计的概念。