Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,54 +1,54 @@
|
||||
---
|
||||
title: "IntegrationGovernance"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
# IntegrationGovernance（集成治理）
|
||||
|
||||
## Definition
|
||||
对每个接入系统的角色、权限、数据流向和失败模式进行明确定义的治理规范，确保多系统协作的清晰性和可审计性。
|
||||
|
||||
## Core Principle
|
||||
> **"No integration is approved without source-of-truth clarity."**
|
||||
> （未经明确数据权威来源，不得批准任何集成。）
|
||||
|
||||
## Required Definitions Per Connected System
|
||||
|
||||
| 维度 | 描述 |
|
||||
|------|------|
|
||||
| **System Role & Source of Truth** | 该系统在整个数据流中的角色，以及谁是数据的权威来源 |
|
||||
| **Auth Method & Token Lifecycle** | 认证方式（API Key / OAuth / JWT 等）和令牌刷新策略 |
|
||||
| **Trigger Model** | 触发方式（WebHook / Polling / Event Bus / Scheduled） |
|
||||
| **Field Mappings & Transformations** | 输入/输出字段映射及数据转换规则 |
|
||||
| **Write-back Permissions & Read-only Fields** | 写回权限范围和只读字段清单 |
|
||||
| **Rate Limits & Failure Modes** | API 速率限制及常见失败场景处理 |
|
||||
| **Owner & Escalation Path** | 系统负责人及问题升级路径 |
|
||||
|
||||
## Integration Approval Checklist
|
||||
- [ ] 数据权威来源已明确定义
|
||||
- [ ] 认证方式已配置且令牌刷新机制已实现
|
||||
- [ ] 触发模型已选定并实现
|
||||
- [ ] 字段映射已文档化
|
||||
- [ ] 写回权限已获授权方批准
|
||||
- [ ] 速率限制和失败模式已评估
|
||||
- [ ] 负责人已指定并知晓升级路径
|
||||
- [ ] 集成已通过 [[ReliabilityBaseline]] 中的外部依赖失败测试
|
||||
|
||||
## Re-Audit Triggers（重审计触发条件）
|
||||
以下任一情况发生时，需重新评估现有集成：
|
||||
- API 或 Schema 发生变更
|
||||
- 错误率显著上升
|
||||
- 业务容量大幅增长
|
||||
- 合规要求发生变化
|
||||
- 反复出现人工修复的情况
|
||||
|
||||
## Related Concepts
|
||||
- [[AutomationGovernance]]：集成治理是自动化治理的核心组成部分
|
||||
- [[ReliabilityBaseline]]：通过集成治理确保整个系统链路的可靠性
|
||||
- [[N8nWorkflowStandard]]：n8n 工作流中的"External Actions"步骤需遵循集成治理规范
|
||||
- [[ReAuditTriggers]]：重审计触发条件
|
||||
|
||||
## Sources
|
||||
- [[automation-governance-architect]]（primary）
|
||||
---
|
||||
title: "IntegrationGovernance"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
# IntegrationGovernance（集成治理）
|
||||
|
||||
## Definition
|
||||
对每个接入系统的角色、权限、数据流向和失败模式进行明确定义的治理规范，确保多系统协作的清晰性和可审计性。
|
||||
|
||||
## Core Principle
|
||||
> **"No integration is approved without source-of-truth clarity."**
|
||||
> （未经明确数据权威来源，不得批准任何集成。）
|
||||
|
||||
## Required Definitions Per Connected System
|
||||
|
||||
| 维度 | 描述 |
|
||||
|------|------|
|
||||
| **System Role & Source of Truth** | 该系统在整个数据流中的角色，以及谁是数据的权威来源 |
|
||||
| **Auth Method & Token Lifecycle** | 认证方式（API Key / OAuth / JWT 等）和令牌刷新策略 |
|
||||
| **Trigger Model** | 触发方式（WebHook / Polling / Event Bus / Scheduled） |
|
||||
| **Field Mappings & Transformations** | 输入/输出字段映射及数据转换规则 |
|
||||
| **Write-back Permissions & Read-only Fields** | 写回权限范围和只读字段清单 |
|
||||
| **Rate Limits & Failure Modes** | API 速率限制及常见失败场景处理 |
|
||||
| **Owner & Escalation Path** | 系统负责人及问题升级路径 |
|
||||
|
||||
## Integration Approval Checklist
|
||||
- [ ] 数据权威来源已明确定义
|
||||
- [ ] 认证方式已配置且令牌刷新机制已实现
|
||||
- [ ] 触发模型已选定并实现
|
||||
- [ ] 字段映射已文档化
|
||||
- [ ] 写回权限已获授权方批准
|
||||
- [ ] 速率限制和失败模式已评估
|
||||
- [ ] 负责人已指定并知晓升级路径
|
||||
- [ ] 集成已通过 [[ReliabilityBaseline]] 中的外部依赖失败测试
|
||||
|
||||
## Re-Audit Triggers（重审计触发条件）
|
||||
以下任一情况发生时，需重新评估现有集成：
|
||||
- API 或 Schema 发生变更
|
||||
- 错误率显著上升
|
||||
- 业务容量大幅增长
|
||||
- 合规要求发生变化
|
||||
- 反复出现人工修复的情况
|
||||
|
||||
## Related Concepts
|
||||
- [[AutomationGovernance]]：集成治理是自动化治理的核心组成部分
|
||||
- [[ReliabilityBaseline]]：通过集成治理确保整个系统链路的可靠性
|
||||
- [[N8nWorkflowStandard]]：n8n 工作流中的"External Actions"步骤需遵循集成治理规范
|
||||
- [[ReAuditTriggers]]：重审计触发条件
|
||||
|
||||
## Sources
|
||||
- [[automation-governance-architect]]（primary）
|
||||
|
||||
Reference in New Issue
Block a user