# OPS02-BP06 團隊之間的責任是預先定義或經過協商的
<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)