操作层体系结构

1）操作层任务

操作层是提供可预测操作的平台和实践集：快速发布，低MTTR，合规性和可管理成本。它为产品和基础设施创建栏杆：标准，自动化，可观察性，变更管理和安全访问。

2）逻辑模型（平面和域）

┌────────────────────────────────────────────────────────┐
│        Interface Plane (UX)          │← ChatOps/Portals/API
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Control Plane: Policy, Orchestration, Identity, CMDB │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Data/Execution Plane: CI/CD, Jobs, IaC, Runtime Ops  │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Telemetry Plane: Logs, Metrics, Traces, SLO Dashboards │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Security & Compliance Plane: Secrets, RBAC, Audit, IR │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Finance/Cost Plane: Usage, Quotas, Budgets, FinOps   │
└────────────────────────────────────────────────────────┘

• 服务目录/CMDB：服务，所有者，SLO，依存关系的统一注册表。
• 编排：piplines，任务，冠，备份，DR。
• 策略（政策即代码）：Alerts, Access, retentions, change-gates。
• 可观察性：度量/跟踪器/logi，SLI/SLO，Alerta和状态页。
• 可用性/秘密：JIT/JEA，令牌，加密，KMS/Vault。
• 事件/更改：ITSM/滴答声，CAB/RFC，后模拟器，模拟。
• DataOps：数据合同,新鲜,线性,质量。
• FinOps：成本核算，限制，配额，优化。

3）参考流

3.1个版本（CI/CD → GitOps）

1.带有代码/清单的公关→测试/扫描→工件签名。
2.带有SLO Gardreils的渐进式涂层（金丝雀/蓝绿色）。
3.降解时的自动后卫；遥测中的发布注释。

3.2个事件（Detect →Respond → Recover）

1.烧伤/症状+法定人数→ Page+战争室。
2.通过轨道/逻辑进行诊断；花花公子。
3.回滚/倒退/限制→ AAR/RCA → CAPA。

3.3更改（RFC/CAB）

1.风险分析+服务窗口+backout计划。
2.非关键性警报的溢出，SLO信号是活跃的。
3.事件和报告，政策修订。

4）服务目录和CMDB

属性：所有者，SLI/SLO，依赖项（内部/外部），dashbords，Alerta，runbook'和，数据类（PII/财务），区域（prod/stage/dev）。
自动填充：来自CI/CD、遥测和存储库。
用途：Alert路由、升级、闪光射线计算、成熟度报告。

5）策略作为代码（Policy-as-Code）

类别：可用性（RBAC/ABAC），安全性（SAST/SCA/DAST），Alerta/SLO，可用性，更改目标，资源/配额。
力学：声明性规则（YAML/Rego/CEL），CI验证，Control Plane执行。

门示例： "如果所有SLO都是绿色的，没有活跃的SEV-1，测试已经通过，签名是有效的，则允许丢弃。"

6）编排和表演

CI/CD: build → scan → sign → promote.

Jobs/CronJobs/DAG：后援/轮换/后卫；截止日期和竞争（Forbid/Replace）。
相似性和回滚：先后检查，步骤标记，巡回休息器。
启动权：JIT帐户，限量版；审计。

7）可观察性和信号质量

按领域划分的SLI/SLO：可用性/潜在性/业务运营成功，数据新鲜度。
Alerts： burn-rate在两个窗口中,定额,dedup/rate-limit, runbook和所有者。
Logi/度量/Traces trace_id相关联；从图形到日志的通道。
状态页面：模板，升级频率，出版物审核。

8）可用性，秘密，加密

保密库（KMS/Vault），轮换，禁止回购中的秘密。
JIT/JEA：在操作/轮班期间授予权利。
服务之间的mTLS/OIDC；映像签名/SBOM。
审核：不变日志,WORM用于关键操作。

9）事件，更改，服务窗口

事件：SEV矩阵，IC/TL/Comms/Scribe，升级模式，AAR→RCA→CAPA。
更改：RFC/CAB，风险评估，金丝雀，背景。
服务窗口：时间选择、通信、规则支持、事件。

10）操作层中的DataOps

数据合同（电路，SLA新鲜/完整）。
每层DQ测试（青铜/银/黄金）。
线性和目录；婚姻隔离。
数据和Alerta的SLO按新鲜/漂移。

11） FinOps和成本

单元经济学：$/1k查询，$/成功交易，$/GiB标志，$/SLO项目。
配额/限额：egress, log卷,任务持续时间。
优化：分期/缓存/实现/归档（热战冷）。
报告：廉价的"昂贵"服务/请求，超支差异。

12）接口： ChatOps/Portals/API

平台门户：服务目录,dploy/回滚按钮, SLO状态,窗口插槽,策略。

ChatOps: `/deploy`, `/handover start`, `/mw create`, `/status update` — с аудитом и evidence.

API：与ITSM/HR/计费/提供商集成。

13）责任模式（RACI）

平台/SRE：控制平面，策略，可观察性，旋转。
产品/Dev：SLO服务，发行版，花花公子。
安全：秘密，漏洞，IR。
Data/Analytics： DataOps, SLA新鲜/质量。

法规遵从性/法律： 法规遵从性,保管性.

支持/Comms：状态页面、客户端消息。

14）操作层成熟度度量

SLO覆盖：具有某些SLI/SLO和burn-rate的服务百分比。

Alert hygiene: actionable ≥80%, FP ≤5%, alerts/on-call-hour (p95).

DORA：降低频率，领先时间，MTTR，更改失败率。
更改管理：RFC更改的百分比,"即时"窗口的百分比,回滚。
安全：保密/证书的平均轮换时间，漏洞关闭。
FinOps：$/单位和QoQ储蓄百分比。
Docs： runbook/SOP覆盖,新鲜度（≤90天）。

15）支票清单"最低可行运营层（MVP）"

• 服务目录/CMDB与所有者，SLO，依存关系和行车记录仪。
• CI/CD+GitOps，工件签名，渐进版本，自动回滚。
• 具有trace_id和SLO Alert的联合遥测（徽标/度量/路径）（双窗口，法定人数）。
• Policy-as-Code：可用性，Alerta，回避，更改游戏。
• 秘密存储，JIT/JEA，mTLS/SSO，不可更改的审计。
• ITSM/事件：SEV矩阵，花花公子，状态页面，升级模式。
• 服务窗口：日历、RFC模板、backout计划、evidence。
• FinOps：成本可见性、配额/限额、报告。
• 文档（Docs-as-Code），SOP/Runbook模板，准备工作清单。

16）反模式

没有控制平面和策略的"平台=脚本集"。
监视"从所有"→雪崩的警报fatigue。
没有GitOps/审核的手动 Prod更改。
没有存储和旋转的环境变量的秘密。
缺乏SLO：我们争论感官而不是质量目标。
分散的目录/所有者表→丢失的升级。
High-risk没有反向计划。
没有结构/相关性的日志→冗长的调查。

17）迷你模板

17.1个服务卡（目录）

Service: checkout-api
Owner: @team-checkout
SLO: availability 99. 9% (28d), p95 latency ≤ 250 ms
Dependencies: payments-api, auth, redis, psp-a
Dashboards: SLO, errors, latency, capacity
Runbooks: rb://checkout/5xx, rb://checkout/rollout
Data: PII masked; retention 30d logs, 365d audit
Change gates: canary 1/5/25%, auto-rollback on burn-rate breach

17.2 Alert政治（想法）

yaml id: checkout-latency-burn type: burn_rate sli: http_latency_p99 windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
quorum: [ "synthetic:eu,us", "rum:checkout" ]
owner: team-checkout runbook: rb://checkout/latency routing: page:oncall-checkout controls: {dedup_key: "svc=checkout,region={{region}}", rate_limit: "1/15m"}

17.3 Gate deploy（伪）

yaml allow_deploy_when:
tests: passed signatures: valid active_sev: none_of [SEV-0, SEV-1]
slo_guardrails: green_last_30m rollback_plan: present

18）实施路线图（8至12周）

1.奈德。1-2：服务清单→ 目录/CMDB；基本的SLI/SLO和dashbords。
2.奈德。3-4：GitOps+渐进版本；Policy-as-Code（Alerta/Retentions）。
3.奈德。5-6：单一遥测和状态页面；具有法定人数的burn-rate；runbook覆盖。
4.奈德。7-8：秘密/JIT，不变审计；RFC/服务窗口。
5.奈德。9-10：FinOps报告，配额/限制；优化日志和存储。
6.奈德。11-12：事件模拟/DR；成熟度量标准；持续改进计划。

19）结果

操作层体系结构是一个控制平面以及标准化实践，可将操作转变为可重复，可测量和安全的过程。服务目录，GitOps，遥测，策略，安全访问和管理的更改可提供可持续的发布，快速恢复和透明的成本-即业务的可预测性。