Ownership on Tarragonhttps://tarrragon.github.io/blog/tags/ownership/Recent content in Ownership on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 22 May 2026 00:00:00 +0000Control Owner Patternhttps://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/control-owner-pattern/Thu, 30 Apr 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/control-patterns/control-owner-pattern/<p>Control owner pattern 的責任是把高風險控制面固定到可執行角色。它讓 incident triage、vulnerability response 與 tabletop 演練都能快速判斷誰主責、誰協作、誰做決策。</p> <h2 id="支撐素材">支撐素材</h2> <table> <thead> <tr> <th>素材</th> <th>可支撐論點</th> </tr> </thead> <tbody> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/field-cases/okta-support-token-2023-identity-pressure/" data-link-title="Okta 2023 Support Token：身份支援流程壓力" data-link-desc="把 Okta 2023 support system incident 轉成身份供應鏈與支援流程的藍隊案例素材">Okta support token case</a></td> <td>support owner、identity owner 與 customer communication 需要共同協作</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/field-cases/cisa-geoserver-2024-ir-coordination-pressure/" data-link-title="CISA GeoServer 2024：IR 協調壓力" data-link-desc="把 CISA GeoServer incident response lessons learned 轉成修補、EDR、IR plan 與第三方協調壓力素材">CISA GeoServer IR case</a></td> <td>IR plan 需要包含第三方支援與工具 access procedure</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/professional-sources/nist-sp-800-61r3-incident-response/" data-link-title="NIST SP 800-61r3：事故回應作為風險管理能力" data-link-desc="把 NIST SP 800-61r3 轉成藍隊事故回應與風險治理素材">NIST SP 800-61r3</a></td> <td>incident response 是跨治理、偵測、回應與復原的風險管理能力</td> </tr> </tbody> </table> <h2 id="欄位">欄位</h2> <table> <thead> <tr> <th>欄位</th> <th>責任</th> </tr> </thead> <tbody> <tr> <td>Control owner</td> <td>對控制面結果負責</td> </tr> <tr> <td>Collaborator</td> <td>提供資料、操作或驗證</td> </tr> <tr> <td>Decision maker</td> <td>對風險接受、凍結或升級做決策</td> </tr> <tr> <td>Escalation path</td> <td>定義分級上升與跨團隊接手路徑</td> </tr> <tr> <td>Exit condition</td> <td>定義何時完成處置或轉入復盤</td> </tr> </tbody> </table> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>代表需求</th> </tr> </thead> <tbody> <tr> <td>同一事件在多個團隊間反覆轉手</td> <td>需要明確 owner 與 collaborator</td> </tr> <tr> <td>分級結果有人執行但沒有人決策</td> <td>需要 decision maker 欄位</td> </tr> <tr> <td>第三方支援需要臨時授權</td> <td>需要預先定義 escalation path</td> </tr> </tbody> </table> <h2 id="適用邊界">適用邊界</h2> <p>此模式適合 identity、entrypoint、MFT、artifact 與 vulnerability response 這類跨團隊控制面。單一服務內部的小型修補可以使用較輕量的 owner 欄位。</p> <h2 id="下一步路由">下一步路由</h2> <ul> <li><a href="https://tarrragon.github.io/blog/backend/knowledge-cards/ownership/" data-link-title="Ownership" data-link-desc="說明 ownership 如何把問題、決策與交接責任固定到可執行角色">Ownership</a></li> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/incident-triage-loop/" data-link-title="7.B6 Incident Triage Loop" data-link-desc="把資安訊號轉成 triage、severity、owner、containment 與 evidence 的回應循環">7.B6 Incident Triage Loop</a></li> <li><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/materials/scenarios/identity-support-token-tabletop/" data-link-title="Identity Support Token Tabletop" data-link-desc="以支援流程與 session token 風險設計身份接管 tabletop 情境">Identity support token tabletop</a></li> </ul>Control owner pattern 的責任是把高風險控制面固定到可執行角色。它讓 incident triage、vulnerability response 與 tabletop 演練都能快速判斷誰主責、誰協作、誰做決策。

支撐素材

素材 可支撐論點
Okta support token case support owner、identity owner 與 customer communication 需要共同協作
CISA GeoServer IR case IR plan 需要包含第三方支援與工具 access procedure
NIST SP 800-61r3 incident response 是跨治理、偵測、回應與復原的風險管理能力

欄位

欄位 責任
Control owner 對控制面結果負責
Collaborator 提供資料、操作或驗證
Decision maker 對風險接受、凍結或升級做決策
Escalation path 定義分級上升與跨團隊接手路徑
Exit condition 定義何時完成處置或轉入復盤

判讀訊號

訊號 代表需求
同一事件在多個團隊間反覆轉手 需要明確 owner 與 collaborator
分級結果有人執行但沒有人決策 需要 decision maker 欄位
第三方支援需要臨時授權 需要預先定義 escalation path

適用邊界

此模式適合 identity、entrypoint、MFT、artifact 與 vulnerability response 這類跨團隊控制面。單一服務內部的小型修補可以使用較輕量的 owner 欄位。

下一步路由

]]>PostgreSQL Developer / DBA Responsibility Splithttps://tarrragon.github.io/blog/backend/01-database/vendors/postgresql/developer-dba-responsibility-split/Fri, 22 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/01-database/vendors/postgresql/developer-dba-responsibility-split/<p>PostgreSQL developer / DBA responsibility split 的核心責任是把資料庫決策拆成 application ownership、database operation 與 platform governance。PostgreSQL 功能深，事故常跨 query、schema、connection、backup、replication 與 capacity；若責任分工模糊，問題會在 release 與 incident 時放大。</p> <p>本文的判讀錨點是：developer 和 DBA 分工要讓每個決策有清楚 owner、evidence、review gate 與 rollback，而非把資料庫丟給某一方。</p> <h2 id="ownership-map">Ownership Map</h2> <p>Ownership map 的核心責任是定義誰能改什麼、誰要驗證什麼。</p> <table> <thead> <tr> <th>面向</th> <th>Developer owner</th> <th>DBA / platform owner</th> <th>Shared gate</th> </tr> </thead> <tbody> <tr> <td>Schema design</td> <td>domain model、constraint、query</td> <td>naming、storage、partition、extension</td> <td>migration review</td> </tr> <tr> <td>Query performance</td> <td>repository SQL、query shape</td> <td>index、planner、statistics、capacity</td> <td>explain evidence</td> </tr> <tr> <td>Migration</td> <td>app compatibility、rollback</td> <td>lock impact、DDL strategy、PITR</td> <td>release gate</td> </tr> <tr> <td>Connection</td> <td>pool usage、transaction length</td> <td>pooler、max connection、proxy</td> <td>load test</td> </tr> <tr> <td>Backup / DR</td> <td>restore smoke test</td> <td>WAL archive、PITR、replica</td> <td>restore drill</td> </tr> <tr> <td>Security</td> <td>tenant / workflow intent</td> <td>role、RLS、audit、grant</td> <td>access review</td> </tr> </tbody> </table> <p>這張表的重點是 shared gate。Developer 最懂產品語意，DBA / platform 最懂資料庫風險；正式變更需要兩邊的 evidence 合併。</p> <h2 id="schema-and-migration">Schema and Migration</h2> <p>Schema and migration 的核心責任是讓 application release 與 database change 同步。Developer 應提供 business invariant、compatibility window、read/write path；DBA / platform 應審查 lock、index build、table rewrite、replica lag 與 rollback。</p> <table> <thead> <tr> <th>Migration 類型</th> <th>Developer evidence</th> <th>DBA / platform evidence</th> </tr> </thead> <tbody> <tr> <td>Add nullable column</td> <td>app read/write compatibility</td> <td>DDL lock time、replica impact</td> </tr> <tr> <td>Add NOT NULL</td> <td>backfill plan、default behavior</td> <td>table rewrite / validation strategy</td> </tr> <tr> <td>Index build</td> <td>query contract、expected selectivity</td> <td>concurrent build、disk、bloat</td> </tr> <tr> <td>Partition change</td> <td>routing logic、retention behavior</td> <td>detach / attach、maintenance window</td> </tr> <tr> <td>Type change</td> <td>serialization、API compatibility</td> <td>cast risk、rewrite duration</td> </tr> </tbody> </table> <p>Migration review 要從 failure mode 開始。若 migration 卡住，誰停止 rollout；若 backfill 造成 lag，誰降速；若 app 新舊版本同時存在，哪個 schema 能兼容兩者。</p> <h2 id="query-and-capacity">Query and Capacity</h2> <p>Query and capacity 的核心責任是把 query shape 和 database resource 對齊。Developer 負責避免 N+1、長交易、無界查詢與錯誤 pagination；DBA / platform 負責 index、statistics、vacuum、work_mem、connection 與 storage。</p>PostgreSQL developer / DBA responsibility split 的核心責任是把資料庫決策拆成 application ownership、database operation 與 platform governance。PostgreSQL 功能深，事故常跨 query、schema、connection、backup、replication 與 capacity；若責任分工模糊，問題會在 release 與 incident 時放大。

本文的判讀錨點是：developer 和 DBA 分工要讓每個決策有清楚 owner、evidence、review gate 與 rollback，而非把資料庫丟給某一方。

Ownership Map

Ownership map 的核心責任是定義誰能改什麼、誰要驗證什麼。

面向 Developer owner DBA / platform owner Shared gate
Schema design domain model、constraint、query naming、storage、partition、extension migration review
Query performance repository SQL、query shape index、planner、statistics、capacity explain evidence
Migration app compatibility、rollback lock impact、DDL strategy、PITR release gate
Connection pool usage、transaction length pooler、max connection、proxy load test
Backup / DR restore smoke test WAL archive、PITR、replica restore drill
Security tenant / workflow intent role、RLS、audit、grant access review

這張表的重點是 shared gate。Developer 最懂產品語意，DBA / platform 最懂資料庫風險；正式變更需要兩邊的 evidence 合併。

Schema and Migration

Schema and migration 的核心責任是讓 application release 與 database change 同步。Developer 應提供 business invariant、compatibility window、read/write path；DBA / platform 應審查 lock、index build、table rewrite、replica lag 與 rollback。

Migration 類型 Developer evidence DBA / platform evidence
Add nullable column app read/write compatibility DDL lock time、replica impact
Add NOT NULL backfill plan、default behavior table rewrite / validation strategy
Index build query contract、expected selectivity concurrent build、disk、bloat
Partition change routing logic、retention behavior detach / attach、maintenance window
Type change serialization、API compatibility cast risk、rewrite duration

Migration review 要從 failure mode 開始。若 migration 卡住，誰停止 rollout；若 backfill 造成 lag，誰降速；若 app 新舊版本同時存在，哪個 schema 能兼容兩者。

Query and Capacity

Query and capacity 的核心責任是把 query shape 和 database resource 對齊。Developer 負責避免 N+1、長交易、無界查詢與錯誤 pagination；DBA / platform 負責 index、statistics、vacuum、work_mem、connection 與 storage。

Query review 的最小 evidence：

  1. SQL text 或 repository method。
  2. Expected cardinality 與資料量。
  3. EXPLAIN / EXPLAIN ANALYZE 結果。
  4. Index 依賴與 fallback plan。
  5. Timeout、pagination、transaction boundary。

Capacity review 要把 query 放進 workload。單一 query 快不代表整體穩定；高頻 query、batch job、migration backfill、CDC consumer 都會共享 I/O、CPU、lock 與 WAL。

Incident Roles

Incident roles 的核心責任是讓資料庫事故有分工。Incident 發生時，developer 看 workflow、feature flag、traffic 與 recent deploy；DBA / platform 看 lock、replica、WAL、disk、pooler 與 backup。

Incident Developer 第一反應 DBA / platform 第一反應
Lock storm 暫停相關 workflow、停 rollout 查 blocking PID、DDL、transaction
Connection exhaustion 降低 app concurrency、停 retry storm pooler queue、max connection、admin access
Replica lag 暫停 heavy write / backfill WAL sender、slot、standby apply
Bad migration block release、保留 failed state restore point、rollback / PITR
Slow query spike feature flag、query owner plan regression、statistics、index

Incident command 要保留決策紀錄。資料庫事故常有高壓操作，例如 kill session、promote replica、drop slot、restore backup；每個操作都要記錄原因與回復路線。

Review Cadence

Review cadence 的核心責任是把資料庫品質納入日常。建議節奏如下：

節奏 Review 內容
每個 release migration diff、new query、role / grant
每週 slow query、lock wait、replica lag、pool
每月 backup restore drill、index bloat、vacuum
每季 DR drill、major version plan、extension review

Review cadence 要跟服務風險對齊。高交易量或合規服務需要更短週期；內部工具可以更輕量，但仍要保留 backup / restore evidence。

Handoff Artifact

Handoff artifact 的核心責任是讓下一位維護者能接手。

最小內容：

  1. Database owner、application owner、platform owner。
  2. Schema migration process 與 rollback route。
  3. Query review checklist。
  4. Connection / pooler policy。
  5. Backup / PITR / DR evidence。
  6. Security / role / audit owner。
  7. Incident escalation route。

這份 artifact 應連回 PostgreSQL overview、Schema Migration Evidence Lab 與 PITR Restore Drill。

下一步路由

責任分工建立後，migration gate 讀 Online Schema Change；連線責任讀 Connection Pooler Comparison；安全責任讀 Security / RLS / Audit Logging。

]]>