# OPS02-BP07 團隊之間的責任是預先定義或經過協商的
<a name="ops_ops_model_def_neg_team_agreements"></a>

團隊間已定義或協商說明如何相互配合及支援的協議 (例如，回應時間、服務水準目標或服務水準協議)。團隊間的溝通管道記錄於文件中。透過了解團隊工作對於業務成果和其他團隊及組織成果的影響，可得知其任務的優先順序，並協助他們適當地回應。

 如果責任和擁有權未定義或未知，則您會面臨風險，不僅無法及時處理必要的活動，在解決這些需求時還會出現冗餘和可能相互衝突的工作。 

 **預期成果：** 
+  團隊間的工作或支援協議經過議定並記錄於文件中。 
+  相互支援或合作的團隊定義了溝通管道和回應預期。 

 **常見的反模式：** 
+  生產過程發生問題，兩個不同的團隊各自起始了疑難排解。其各自為政的工作使中斷更為嚴重。 
+  營運團隊需要開發團隊的協助，但雙方並未就回應時間達成協議。要求卡在積存中。 

 **建立此最佳實務的優勢：** 
+  團隊知道如何彼此互動與支援。 
+  眾人對回應能力有相同的預期。 
+  溝通管道明確定義。 

 **未建立此最佳實務時的風險暴露等級：**低 

## 實作指引
<a name="implementation-guidance"></a>

 實作此最佳實務意味著，團隊間對於彼此的合作方式不會有歧義。正式協議明訂了團隊相互合作或支援的方式。團隊間的溝通管道記錄於文件中。 

 **客戶範例** 

 AnyCompany Retail 的 SRE 團隊與其開發團隊間有一份服務水準協議。無論開發團隊是否是在其票證系統提出要求的，應該都能在十五分鐘內獲得回應。如果發生站點中斷，SRE 團隊將主導調查，並由開發團隊提供支援。 

 **實作步驟** 

1.  與組織中的利害關係人合作，根據流程和程序制定團隊之間的協議。 

   1.  如果兩個團隊之間共用流程或程序，請制定關於團隊應如何共事的執行手冊。 

   1.  如果團隊之間相互依賴，請協議要求的回應 SLA。 

1.  在您的知識管理系統中記錄責任。 

 **實作計劃的工作量：**中。如果團隊之間目前沒有任何協議，與組織中的利害關係人達成協議可能會頗費周章。 

## 資源
<a name="resources"></a>

 **相關的最佳實務：** 
+  [OPS02-BP02 已為流程和程序識別擁有者](ops_ops_model_def_proc_owners.md) - 必須在設定團隊之間的協議之前識別程序擁有權。 
+  [OPS02-BP03 已為營運活動識別負責其效能的擁有者](ops_ops_model_def_activity_owners.md) - 必須在設定團隊之間的協議之前識別營運活動擁有權。 

 **相關文件：** 
+ [AWS Executive Insights - 透過雙披薩團隊增添創新動能](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [DevOps on AWS 簡介 - 雙披薩團隊](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)