ISPE 文章提出 GxP 环境中 PaaS 持续运营控制方法

GxP 环境中 PaaS 的持续控制

作者：

Robin Wennemuth, Sebastian Koch, Florian Kekule, Robert McDowall

（博士）

来源：

ISPE

《

Pharmaceutical Engineering

》杂志

2026

年

7/8

月刊（

Technical

栏目）

西门先吐个槽：现如今，上云是大趋势，无论是中短期投入产出比，还是应用自身选择，就拿SAP举例，目前几乎已经没有OP版本可以选择，所以提前学习好三个aaS的管控，是制药领域最近几年的大课题。

对于云，真正的难点从来不在于初始验证工作，而在于：尽管平台是根据服务商的计划进行变更，但合规责任主体始终是受监管的用户。针对特定时间点所做的验证，无法跟上每周都在发生变更的服务节奏。（变化太快，比如VEEVA saas一年三到四次强制更新？但好在它还能提前告知，并且自己写风评估，非医药行业专供的saas paas iaas呢？更新可能会漏通知，强制更新繁多）

一种更具可持续性的做法是：明确各项服务的预期行为，利用自有探针及服务提供商的遥测数据进行持续监控，并将发现的偏差纳入现有的事件管理流程中处理。 如此一来，各类证据和依据便能在日常运行中不断积累，而不至于在验证报告签署之日即刻面临过时的风险。

摘要

从本地部署（on-premise）向云端系统的迁移，要求受监管环境中的 IT 基础设施管理方式发生转变。与其采用传统的静态确认（qualification），对支持 GxP 应用的平台即服务（PaaS）基础设施实施持续运营控制，可使生命科学企业既保持合规性，又加速创新。

本文提出一种实用的、基于风险的方法，通过持续监控、自动化测试与实时证据生成，建立并维持关键 PaaS 服务持续适用于预期用途的信心，从而在满足法规合规性的同时带来可观的业务价值。

背景

从传统本地部署 IT 基础设施向云端解决方案的迁移，标志着生命科学行业的一次重要演进。随着企业推进数字化转型，云计算提供了无与伦比的可扩展性、创新潜力与运营效率。然而，在这些动态环境中确保符合 GxP 指南的要求，带来了独特的挑战。行业对云基础设施确认的需求已得到充分确立；然而，现行的方法与解决方案在应对 PaaS 高度复杂与动态的本质方面仍有不足。

我们探索对支持 GxP 受监管工作负载的 PaaS 实施持续运营控制的概念，以应对这一挑战。持续保证同样适用于本地部署基础设施，而在云环境中这一需求尤为突出，原因在于云服务变更频率高，且云服务提供商（CSP）与生命科学企业之间责任共担。超大规模 CSP 向其服务部署代码变更的速率高于传统本地部署 IT，主要提供商公开宣称的年部署量达数百万次。生命科学企业无法控制这些变更何时以及如何部署，但最终需对其负责。

本文提出一种实施持续运营控制的实用方法论，既能满足法规要求，同时带来显著的商业收益。

从本地部署到云计算的迁移

历史上，生命科学企业自行管理 IT 基础设施，对系统保持完全控制。随着时间推移，企业转向利用基础设施即服务（IaaS），将部分责任转移给 IaaS 提供商，但仍保留较强的控制力。向 PaaS 的迁移代表着下一个演进步骤。

美国国家标准与技术研究院（NIST）将 PaaS 定义为："提供给消费者的能力，是将消费者创建或获取的应用部署到云基础设施上——这些应用使用提供商支持的编程语言、库、服务与工具创建。消费者不管理或控制底层云基础设施（包括网络、服务器、操作系统或存储），但控制所部署的应用，并可能控制应用托管环境的配置设置。"

PaaS 提供预构建、业务就绪的服务，进一步增强创新与敏捷性，包括但不限于：

• 高度抽象的服务，接近使用具有较高可配置性的应用；例如托管数据库、工作流管理、文档管理或门户服务；

• 用于身份验证与授权的支持性和基础性服务、应用日志记录或事件自动化。

这种向 PaaS 的迁移不仅加速了开发、简化了运营，还要求在复杂环境中采用新的合规管理与责任共担方式。

云提供商每一层新的抽象都将责任转移给云提供商，但受监管用户仍然负有最终责任。亚马逊云服务（AWS）——最知名的云提供商之一——指出："对于受监管的企业客户，当如此多的责任已与供应商共担时，如何确认并证明对系统的控制，成为关注焦点之一。确认策略（Qualification Strategy）的目的正是回答这一问题。"

PaaS 的法规框架

欧盟（EU）与药品检查合作计划（PIC/S）GMP 附录 11、美国食品药品监督管理局（FDA）21 CFR 第 11 部分与第 211 部分等法规框架，适用于运营用于 GxP 相关流程的计算机化系统的受监管企业。义务落在受监管用户而非 CSP 身上。附录 11 指出"应用应当经过验证（validated）；IT 基础设施应当经过确认（qualified）"。在此背景下，支持 GxP 应用的 IT 基础设施——包括云平台——必须由受监管企业证明其处于受控状态并适用于预期用途。

ISPE GAMP® 5 指南（第二版）附录 M11（IT 基础设施）将 PaaS 归类为 IT 基础设施而非 GxP 受监管应用。PaaS 组件按第 1 类基础设施软件或软件工具处理（附录 D9）。这一分类明确了 PaaS 本身不适用传统的应用验证，但仍需作为底层基础设施的一部分进行确认。ISPE GAMP® 5（第二版）建议采用"良好 IT 实践"（如基于 ITIL 的服务管理、配置管理、运营监控、事件管理与持续改进），而非经典的 IQ/OQ/PQ 协议——后者并不适合动态云环境。目标在于实现并维持基础设施的受控状态，从而使运行于其上的 GxP 应用保持已验证状态。

监管期望强化了这种方法。EU GMP 附录 11 要求在整个系统生命周期内管理风险（第 1 条）、控制变更（第 10 条），并定期评估系统以确认其保持有效状态（第 11 条）。美国 FDA 的指南文件《生产和质量体系软件的计算机软件保证》（FDA Computer Software Assurance for Production and Quality System Software）认可云部署模式，并建立了基于风险的框架，制造商应在其中"基于风险分析选择执行保证活动的适当频率"。

该指南还指出，持续性能监控有助于确保软件保持与质量体系义务一致的已验证状态。FDA 21 CFR 第 11 部分进一步将这些期望延伸到托管电子记录的基础设施，要求确保审计追踪、安全性与数据完整性。与此同时，国际人用药品注册技术要求协调会（ICH）Q10《药品质量体系》要求组织建立并维持工艺达到预期结果并持续改进的条件，合适的 IT 基础设施是该能力不可或缺的组成部分。

ISPE GAMP® 良好实践指南《IT 基础设施控制与合规》（第二版）为满足 PaaS 环境的这些期望提供了实践指导。"平台确认——积木块（Building Block）"概念通过将平台分解为可管理的组件，支持结构化的确认方法。附录 11"平台即服务"为确认 PaaS 提供了具体指南，后续章节则强调在运营期间通过持续监控、变更控制与事件管理维持已验证状态的重要性。对运营环境的持续保证对于基于云的基础设施尤为关键——频繁更新与配置变更是常态。因此，通过基于风险的、有文件记录的、受监控的控制措施在运营期间维持已确认状态，是向监管检查与质量保证审计证明控制与合规的核心。

挑战：云基础设施的现实

云提供商每年部署数百万次更新。这些更新发生在受监管企业控制范围之外。传统的单时间点基础设施确认在此类环境中并不可行。公有云是高度分布式、持续演进的系统。基于微服务架构构建，它们继承了分布式计算的复杂性——网络分区、级联重试、部分故障与涌现行为——这些都需要超越传统服务级检查的测试方法。

近期事件印证了这一点：单个服务的硬件异常、网络中断与看似无害的配置变更，可能蔓延为多服务宕机。这些连锁效应凸显了隐藏依赖与持续平台变更如何侵蚀对系统可靠性的信心。

因此，仅靠单时间点的投产前测试，无法为云服务持续适用于预期用途、且风险水平为生命科学应用所接受提供持续保证。现代分布式系统表现出因持续变更组件之间交互而产生的涌现性故障模式，无法事先穷举列举；近期行业事件中观察到的部分故障、网络分区与配置传播问题直接证明了这一点。因此，可辩护的保证方法将严格的投产前确认与运营期间对平台进行的持续、生产安全的测试与监控相结合。

生命科学应用嵌入云环境之中。应用变更通常不频繁、受控，并在每次发布时经过明确验证；而底层云平台持续变更，且受监管用户在很大程度上未察觉。因此，平台变更频率比应用变更频率高出数个数量级。整个系统的已验证状态是两层共同作用的结果：应用验证可以保持事件驱动（在发布时触发），而平台保证则必须持续进行，以发现可能侵蚀应用所依赖基础设施已确认状态的变更。系统由生命科学企业控制的组件与其控制范围之外的云组件共同组成，如图 1 所示。

图 1：PaaS 基础设施的不同层级与责任（改编自 ISPE GAMP® 5（第二版））

向平台确认方法的转变

这在 PaaS 场景中尤为明显。PaaS 持续演进，例如通过交付安全补丁或改进服务质量。此类平台更新的发布周期与使用它们的生命科学应用通常不一致。由于交付周期短、内部变更透明度有限以及影响分析所需的工作量，逐一审查每项变更实际上不可行。此外，PaaS 提供商提供租户级隔离（例如子账户、订阅或项目），允许客户隔离其开发、质量保证（QA）/验证与生产环境。然而，底层托管服务实现——控制平面与多租户运行时——在所有客户环境之间共享。因此，服务级变更与缺陷会同时传播到每个环境，无论客户如何构建其租户结构。处于不同生命周期阶段的客户应用使用相同的服务版本，并继承相同的平台侧变更。

确认策略需要转向平台确认方法，专注于在受控状态下管理平台并保持适用性，而非针对特定应用。这涉及确认平台提供商，并使用 ISPE GAMP® 良好实践指南《IT 基础设施控制与合规》（第二版）中的"积木块"概念确认标准化服务。不同的积木块（例如托管数据库等组件）具有天然不同的风险特征。利用确认数据可以为这些风险提供有价值的洞察，定期风险再评估应嵌入持续质量改进流程之中。

鉴于平台侧的持续变更，需要一套敏捷的、基于风险的、电子化记录的变更管理程序，以评估云服务更新对 GxP 应用的影响并确定再确认需求（见图 2）。此外，建立公司范围内云服务使用标准至关重要。目标是制定内部"云服务目录"，定义公司内获批准的服务集合，从而创建"受监管着陆区"。在该受控环境中，生命科学企业可以以风险可控的方式在公有云平台上运营 GxP 相关应用。

图 2：云服务变更与中断的持续基于风险的监控

为何平台级持续控制符合 GAMP 要求

ISPE GAMP® 5（第二版）将 PaaS 组件视为第 1 类基础设施或软件工具（附录 D9），并建议采用 ITIL 式良好 IT 实践，而非应用式 IQ/OQ/PQ。下文方法详述了该建议：交付物为 IT 服务管理（ITSM）工件与监控证据，活动是对平台的运营控制，而非对受监管应用的验证。问题在于，三项常规控制措施——应用验证、CSP 供应商确认与基础设施级事件管理——是否足以单独支撑 PaaS 上的 GxP 工作负载。它们覆盖了大部分风险包络，但遗漏了一组特定的故障，而这组故障是它们均不擅于捕获的。平台级持续控制正是对 GAMP 框架中严重度 × 概率 × 可检测性这一缺口作出的直接回应。

以下列出的故障具备两个共同特征：它们可能产生真实的 GxP 影响，且三项常规控制措施难以发现它们。这一局限源于观察视角与时机，而非努力程度。

■ 稳定 API 中的漂移：

API 版本未变，但缺陷修复或实现变更改变了响应含义、错误代码、延迟或顺序。发布时的应用测试不会重跑，供应商审计覆盖流程而非逐服务行为。

■ 尾部延迟或尾部错误回归：

均值未变，但 p99 或 p999 发生变化；对尾部敏感的批处理作业错过其时间窗口。提供商服务水平协议（SLA）报告的是粗粒度可用性，而非工作负载特定的尾部指标。

■ 仅在故障转移时显现的故障：

故障转移区域已悄然漂移到不同的版本、配置或复制拓扑。这种不匹配只有在实际故障转移时——当响应时间最短时——才会显现。

■ 后台平台工作的副作用：

计划内的备份、复制、密钥轮换、证书续期或打补丁会在特定时间改变服务质量（QoS）。应用测试由应用驱动，从不演练平台发起的后台工作。

■ 其他租户的干扰：

来自共租户的资源争用会在 SLA 边界内降低 QoS；这种效应呈突发性、与负载相关，无法按需复现，且大多数提供商 SLA 不覆盖。

■ 弃用超期：

已弃用功能在宣告的移除日期之后仍然可用，且应用仍依赖它。应用测试检查的是当前行为，而非弃用日历。

■ 服务组合中的故障：

应用使用的每个托管服务在隔离状态下均正常工作，但它们的组合方式已发生变化。应用直接调用式测试不演练传递依赖图。

■ 提供商发出应用看不到的信号：

平台发出新的错误类别或遥测信号，应用未订阅，但该信号表明其适用性正在下降。

以上列表并非穷尽，但足以表明：残余风险集合是真实存在的，可能产生重大影响，且不被三项常规控制覆盖。严重度取决于工作负载且往往重大；每次变更的概率为低到中等，但在运营生命期内累积；常规控制下的可检测性较差。其结果是一种残余风险，按照 GAMP® 原则，需要补充检测控制。

该控制措施即对平台行为的持续监控，由受监管用户或受委托供应商运行，而非平台提供商。它将针对提供商公开发布的应用编程接口进行的独立探测、对提供商自身健康、弃用与变更通知信息流的接收，以及这些信号随时间相对于基线的统计分析相结合。其与应用级测试的区别不在于由谁运行，而在于能看到什么——包括来自平台内部的信号，以及应用自身不会演练的探测面。提供商只需维持其已为自己的站点可靠性工作运行的可见性面即可。

该控制是附加性的。它不取代应用验证、供应商确认或 ITIL 事件与问题管理；它覆盖这三者遗留的可检测性缺口。交付物是 ITSM 工件：逐服务行为基线、与之绑定的探测与信息流、将异常路由至现有事件流程的报警策略，以及运营证据日志。下一节的方法论以 ITSM 对齐的术语应用这些原则。

持续云服务运营控制与合规

实现并维持受控状态需要缓解或在可能的情况下消除风险。然而，在 PaaS 中，除非完全停止使用平台服务，否则风险永远无法完全消除。受监管企业与 PaaS 提供商应通过实施运营控制来实现受控环境，通过持续确认增强问题的可检测性，从而降低患者安全、产品质量与数据完整性风险。

只有 CSP 本身作为供应商获得确认，平台层的运营控制才可信。由于受监管用户无法直接洞察企业服务提供商内部的变更、发布与质量流程，供应商确认必须依赖文件证据与合同工具。实践中，这包括：

• 审查第三方鉴证报告，如 SOC 2 Type II 与 ISO/IEC 27001/27017/27018 报告，并对照受监管用户的 GxP 控制要求进行映射；

• 审查提供商发布的 GxP 白皮书与责任共担矩阵，同时认识到这些是供应商陈述，不能替代用户自身的风险评估；

• 涵盖变更通知义务、事件沟通、审计权、数据驻留与子处理方管理的质量（或技术）协议；

• 记录在重大事件（认证失效、司法管辖区变更、安全事件或责任共担边界发生实质性变化）时触发供应商再评估的书面程序。

下文所述的持续运营控制是对该供应商确认活动的补充，而非替代。

表 1 中的方法论概述了建立与维持持续确认的流程，如图 3 所示——云应用生命周期中的云服务确认评估。该框架以 GxP 要求为设计出发点，但足够灵活，可同时适用于 GxP 与非 GxP 应用。虽然框架建立在 GxP 特定指南之上（如附录 11、FDA CSA、ISPE GAMP® 5、ICH Q10），其基于风险的范围界定、持续证据生成与平台级控制等基本原则，也可移植到其他在托管云服务上运行工作负载的受监管行业。

利用历史服务故障数据对于评估服务风险与潜在故障空间至关重要。除了通过提高可检测性来缓解变更影响外，有关故障空间（例如虚拟机错误）的更多信息有助于确定纠正措施与作为应用设计一部分的故障陷阱。在检测并分类已知故障场景后，可自动采取纠正措施，例如调配更多计算资源或建立自校正能力。此外，外部监控信息（如 CSP 官方可用性）有助于快速识别、分类与缓解变更。主动变更影响分析也可作为利用历史信息以及 CSP 关于计划内变更（如功能弃用）信息的有效控制机制。

表 1：PaaS 基础设施持续确认的阶段与活动

阶段 (Phase)

活动 (Activities)

阶段 1：评估所用云服务

• 识别关键解决方案组件：识别软件应用中的关键解决方案组件，并记录所用云服务

• 影响分析：分析云服务对应用的影响

• 预期用途定义：明确定义每个云服务将在 GxP 应用中的使用方式

• 评估基本要求：访问控制、审计追踪、监控、数据保密性（接口层[数据传输]与存储库层[数据存储]的数据加密）、备份与恢复、灾难恢复、业务连续性，以及适当时的归档与检索

• 功能服务评估：评估每个云服务中使用的具体特性与功能，并基于预期用途定义具体要求

• 危害识别：识别与每个服务使用相关的潜在危害，重点关注服务功能、数据完整性、安全性与可用性方面

• 风险分析：评估潜在故障的严重度、概率与可检测性

• 风险评价：基于风险对 GxP 合规性与整体业务运营的影响进行优先级排序

阶段 2：执行风险评估

• （同阶段 1 中的识别与分析方法：在识别关键组件与危害的基础上，对所用云服务执行系统化风险评估，确定风险等级与需重点控制的服务）

阶段 3：制定持续监控计划

• 定义测试策略：制定全面的测试策略，包括范围、服务测试程度与测试频率

• 自动化测试实施：实施持续验证云服务合规性的自动化测试

• 缓解策略：定义缓解已识别风险的策略，包括出现偏差时立即调查的报警触发、回退程序与纠正措施

• 持续监控计划：概述自动化与持续基础设施确认的计划，实现从云服务到测试用例的可追溯性；确保在变更管理流程中经过审查与批准

阶段 4：发布门与运行阶段：初始确认、持续测试与偏差管理

• 服务准入基线：建立预期服务行为、监控探测、遥测订阅与报警规则的文档化基线，并提交质量审查与批准。发布服务准入基线即将服务纳入云服务目录，并标志着向运营监控的过渡

• 测试执行：按照持续监控计划定期执行探测并摄取遥测信息流；对照服务准入基线记录结果

• 事件与问题管理：将监控异常与检测到的基线偏差路由至受监管用户现有的 ITIL 事件管理流程，进行分类、根因分析与纠正措施（包括适当时的应用级缓解措施，如最终用户通知）；通过变更通知与支持渠道与 PaaS 提供商处理并管理可归因于提供商的事件，并将文档、解决与沟通记录在原始事件记录中

• 实时监控：提供带有实时报告的监控仪表盘，提供对云服务合规状态的洞察

• 持续监控证据日志：维护证据日志，证明从监控探测与遥测信号到检测到的异常、事件记录与纠正措施的端到端可追溯性；该日志构成文件证据，证明运营控制在报告期内按设计运行

• 持续测试改进/调整：监控云服务的公告变更，并基于更新调整自动化测试用例实施

• 审查流程：定期审查持续基础设施确认流程

阶段 5：报告

• 基于持续监控证据日志出具报告，汇总报告期内的监控结果、偏差处理与纠正措施，作为运营控制有效性的文件证据（见图 4、图 5）

图 3：云应用生命周期中的云服务确认评估（改编自 GAMP® 5（第二版））

案例研究：SAP 业务技术平台（BTP）

SAP 业务技术平台（BTP）是一个综合性 PaaS 环境，提供用于开发、集成与管理企业应用的工具与服务。生命科学企业利用 SAP BTP 服务为 GxP 流程构建与维护软件。实际用例示例包括：

• 批放行驾驶舱：利用云端解决方案简化、优化并支持批放行流程，同时保持对法规标准的合规性；

• 细胞与基因治疗流程编排：使用 SAP BTP 编排复杂的细胞与基因治疗流程，帮助确保正确的患者获得正确的治疗而不出错；

• 温度管理解决方案：部署用于在供应链全过程中监控与管理药品温度的解决方案。

生命科学企业在 SAP BTP 上利用持续确认来证明对所用云服务的控制。为此开发了集成式基础设施监控工具，多家企业正在使用该工具。它涵盖了上一节所述的云服务确认全过程，包括运行预定义云服务目录中交付的自动化测试。持续确认与 SAP BTP 上 GxP 应用的运营生命周期集成，生命科学企业可获得持续监控、变更影响可见性与偏差管理。

实践中，这使"计划-报告"方法在平台持续变更的情况下仍然可行。每个服务的监控计划一次性建立，此后在变更控制下维护。仅当应用对 BTP 服务的使用方式发生变化时，经人工审查与批准后才进行调整；平台自身的持续变更由监控本身捕捉，而非通过修订计划。支撑证据由工具持续生成，而非人工汇编，因此维护工作量跟随应用的受控发布周期，而非平台快得多的变更节奏。其结果是结构化、自动化驱动的方式来管理确认与合规，在运营上可持续，并作为监控的副产品产生检查就绪的证据。

对云服务的持续控制与可视化

为维持并可视化对云服务的控制，系统配备了全面的仪表盘与随时间变化的报告功能。仪表盘提供对服务性能与合规状态的实时洞察，支持对任何问题进行主动管理（见图 4）。

随时间变化的报告使企业能够跟踪趋势、识别重复出现的问题，并评估纠正措施的有效性。图 5 展示了随时间变化的服务确认报告的系统摘录，包含单份文档中的完整端到端可追溯性。

图 4：展示对云服务实时控制的仪表盘示例

图 5：记录云服务确认的确认报告示例

结论

PaaS 基础设施的持续运营控制，是云环境中基础设施确认监管要求的实际落地。通过结合基于风险的评估、持续测试、自动化监控与实时证据生成，生命科学企业可以保持合规、加速创新并降低运营成本。该方法根植于基础监管原则（附录 11、FDA CSA、ISPE GAMP® 5（第二版）、ICH Q10）。GxP 环境中基础设施控制的未来是持续、自动化与智能的。