01 原始约束
六个约束同时作用在一张架构图上
| 类型 | 具体表现 |
|---|---|
| 技术 | 设备与平台来自多家厂商，协议与数据模型不统一；专网隔离，跨网调用受限 |
| 合规 | 权限分级、操作留痕与审计追溯要求叠加；谁能看什么、什么时候看的记录必须可回溯 |
| 业务 | 一线已形成固定处置流程，系统必须贴合既有习惯，不能要求全员重新学习 |
| 既有系统 | 在运系统不可长时间停机，无法采用「停机替换」式方案 |
| 工期 | 受年度建设计划与验收节点约束，无法按理想排期分三年完成 |
| 组织 | 跨部门协同，数据责任边界需要在流程上写清，而不是在系统里默认放开 |
02 被排除的路径
三条看起来更快的路，为什么不能走
没有一条路径是被「技术上做不到」排除的。它们都是被约束排除的。
排除 01
全量汇聚成一个大库，再统一分析
数据责任边界无法逐条追溯，审计回答不了「谁在什么时候、凭什么看了哪条数据」。一旦发生争议，系统无法自证合规。
技术上最省事，合规上最危险 → 第一个被排除
排除 02
推倒重建统一平台
既有业务不能长时间停机；一次性替换的预算与培训成本超出年度计划；一线操作习惯的隐性阻力会在上线后集中爆发。
成本与停机窗口双重不允许
排除 03
只交付可视化大屏
大屏不改变处置闭环，交付后仍要靠人手工串联各系统。看起来完成了，实际问题被推给了运维。
验收容易通过，问题不会消失
03 实际切口
先把一条处置任务跑通，再谈汇聚
顺序很重要：汇聚能力服从授权模型，而不是先汇聚再补权限。
切口
- 最小业务闭环：把「一条处置任务从发起到归档」跑通，只接这条链路上必需的字段
- 架构取舍：先建数据服务层，做「授权可见 + 可审计调用」，其余数据按需申请、留痕
- 权限取舍：权限按字段级配置，不做角色级粗放授权；越权请求留痕可回溯
代价
- 初期可见范围比「全量可见」小，一线需要习惯按需申请
- 额外做了一个授权配置与审批的管理界面，这部分工作在原始需求之外
- 上线节奏被授权模型倒逼，前期比「先做界面」的方案慢
04 可验证结果
能公开的结果，只写能公开的
除下列公开结论外，其余运行指标未经客户授权，不在此页展示，也不以行业均值替代。
| 项目 | 结论 | 证据状态 |
|---|---|---|
| 项目验收 | 通过验收，并在全省推广 | 公开信息 |
| 处置闭环时效 | 含上线前后对比数据 | 未公开 |
| 授权审批耗时 | 含审批流日志统计 | 未公开 |
| 审计日志完整率 | 含抽样审计结论 | 未公开 |
「未公开」不等于「没有」：这些指标在项目内部有基线，只是未取得对外披露授权。需要核验可在保密协议下提供。
05 能力移交
移交包清单作为合同附件
移交不是交账号。是让客户的人能独立完成日常授权配置、一线支持与新增系统接入。
移交包
- 授权配置手册：字段级权限怎么配、审批流怎么改
- 审计字段规范：留痕要记哪些字段、怎么抽查
- 接口对接说明：新增厂商设备如何接入
- 故障处置 SOP 与值班交接表
时间线
- P3 结束时完成培训与文档交付
- 组织一次「无伊索在场」的自治演练，由客户方独立操作
- 自治节点到期，双方共同确认是否转入二线支持
具体节点日期以合同附件为准
06 复用资产
这个项目留下的东西，下一个项目还在用
多厂商接入适配器
视频、卡口、业务系统三类薄适配器；不做统一抽象层，因为抽象会吃掉厂商的异常语义。
字段级授权组件
权限按字段配置，审批流可配置，越权请求留痕。
审计日志字段规范
留痕字段与抽查清单，可直接用于新项目的合规评审。
判断规则
当审计无法自证时，汇聚深度必须让位于授权可追溯性。
07 退出条件
客户什么时候不再需要我们
这个问题必须在项目开始时就回答，而不是在合同到期时才讨论。
三条同时成立即退出日常在场
- 客户方能独立完成授权配置与审批流转，连续若干周无伊索介入
- 审计检查由客户方独立完成并出具结论
- 新增业务系统的接入由客户方按既有适配器规范自行完成
此后伊索只保留二线支持与版本升级评审，按合同约定的方式计价。达到条件时我们主动出具《撤场评估》。
你的项目里，哪条约束最难绕开？
打给我们说说。我们会先告诉你：类似的约束下，哪些做法我们已经验证走不通。