OpsKeeper
团队协作

Harness 指南

验证 Harness 是 OpsKeeper 证明“某次改动没有让闭环退化”的机制。它会跑三个场景，对接真实的 Postgres + Qdrant + 控制平面：alert_storm、rca_loop、recovery_verify。

运行 Harness

harness
# 拉起 Harness 环境
make harness-up

# 跑全部场景
make harness

# 跑单个场景
make harness SCENARIO=rca_loop

# 收摊
make harness-down

场景

alert_storm

60 秒内向 alerter 灌 10,000 条合成告警，断言：

  • 去重熔断器跳闸次数不超过 2。
  • 创建的事件数不超过 50。
  • critic 在正确的严重度档位被调用。

rca_loop

端到端重放 pg-connection-pool-exhaustion，断言：

  • 闭环在 90 秒内走到 verified。
  • investigator 返回的证据来自至少 3 个数据源。
  • 提案携带合法的 payload 哈希与爆炸半径。

recovery_verify

通过已审批的提案对一个合成目标做变更，断言：

  • verifier 返回的 VerifiedDelta 与白名单一致。
  • payload 哈希被篡改的提案会被以 proposal_hash_mismatch 拒绝。
  • 运行结束后审计账本 HMAC 仍可验证。

写一条新断言

断言放在 tests/harness/assert/ 下。每个是一个 Go test，接收实时控制平面句柄和一份录制的运行结果。

assertion_test.go
package assert

import (
  "testing"
  "github.com/vincent-wuhan/opskeeper/harness"
)

func TestRecoveryAppliesOnlyApprovedPayloadHash(t *testing.T) {
  run := harness.LoadRun("recovery_verify")
  for _, evt := range run.Audit {
    if evt.Action == "recovery.dispatch" {
      if evt.PayloadHash != run.Proposal.PayloadHash {
        t.Fatalf("dispatch payload hash %s != approved %s",
          evt.PayloadHash, run.Proposal.PayloadHash)
      }
    }
  }
}

CI

Harness 在每个 PR 的 CI 里跑。Harness 红 = 发版阻塞。