使用團隊拓撲發現並提高敏捷DevOps可靠性質量 - joaorosa

將 DevOps 運動中的團隊拓撲與領域驅動設計社群的上下文對映相結合，可以深入瞭解軟體工程團隊之間的潛在摩擦接觸點。

團隊拓撲是Matthew Skelton和Manuel Pais 的作品，我將它用作我工作的一部分。從社會技術的角度來看，團隊優先的方法對任何組織都至關重要，有助於降低意外的複雜性。因此，我經常被問到“我們如何在 DevOps 中運作？” 或“我怎樣才能擁有可靠的服務來為我的客戶創造價值？”。

將 DevOps 運動中的團隊拓撲與領域驅動設計社群的上下文對映相結合，可以深入瞭解軟體工程團隊之間的潛在摩擦接觸點。您可以在下方找到如何將其組合以及如何產生想法以推動您的組織達到新的績效水平，從而創造一個安全健康的工作環境。

服務可靠性品質

有不同的可靠性質量，我們有關於它的文獻。想想SRE從谷歌或圖書大廈進化架構從尼爾福特，麗貝卡帕森斯和帕特里克挎。它們描述了數字服務的不同質量和不同的方法。但是在將這些概念付諸行動之前，它如何影響團隊？

社會技術思維付諸行動

為了回答這個問題，我在研討會模式下使用上下文對映和團隊拓撲來視覺化 (1) 域、有界上下文及其互動，以及 ( 2）團隊以及他們如何互動。遵循這條路徑，它允許相關人員看到他們所處環境的複雜性以及團隊如何組織以建立問題空間的解決方案。

擁有這些從社會和技術角度來看的見解，它使人們能夠對他們的設計選擇進行推理。通過設計選擇，我指的是團隊和個人的組織（組織設計）和技術設計（解決方案/軟體架構）。因此，在社會技術思維中，團隊的概念不是事後的想法。

首先我想寫另一個重要的概念。複雜性Complex，即在軟體領域。Frederick P. Brooks Jr.早在 1986 年就撰寫了論文No Silver Bullet - Essence and Accident in Software Engineering，在那裡他描述了兩種型別的複雜性：基本複雜性和偶然複雜性。複雜性是分散式系統所固有的（作為一種思考練習，您可以考慮將一個 Web 伺服器連線到一個資料庫伺服器的堆疊），我們從複雜問題構建複雜的解決方案。比我們預期的更多，解決方案有機地增長（使用Kent Beck妙語，我們不知道任何其他型別的增長），但不幸的是它幾乎是偶然的；解決方案的複雜性超過了問題的複雜性。

回到服務可靠性質量：我看到人們要求服務 X具有更高的可用性（或任何其他能力）。同樣，團隊不斷新增元件來嘗試實現它，增加了更多的認知開銷。意識到這一點（我很內疚，因為我過去也有同樣的行為），我開始從另一個角度看待這個問題：如果答案是團隊互動的方式，而不是投入更多的技術呢？

使用來自DDD上下文之間對映和團隊拓撲的見解，我們可以對組織設計進行推理，以實現所需的服務可靠性質量。通常，我有幾個問題，例如：

• 價值流是否跨越多個團隊？如果是這樣，這些團隊型別是什麼？平臺和流對齊的混合？
• 他們屬於同一個部門還是不同的部門？
• 他們有相同的經理嗎？
• 團隊是在同一地點，還是在不同的時區？
• 我們是否在不同的有界上下文中共享模型？
• 我們是否需要修改我們的 SLA/SLO/SLI？
• 我們應該採用實時文件嗎？
• 我們有多少交付？

根據我的經驗，在改變技術方面之前，檢視團隊如何互動以及我們如何佈局我們的解決方案是發現和提高服務可靠性質量的良好開端。隨著組織的發展，複雜性也會增加，因此制定設計決策以應對複雜性非常重要。

讓我們想象一個例子

如您所見，我將 Team Gold 放置在圖表的中間。另外，其餘的團隊都有與其目的相關的名稱，我將讓您的想象力來填充技術細節。現在，在這個虛構的案例中，金牌團隊被要求縮短功能到生產的週期時間，因為他們正在失去與競爭對手的差異化功能。基於團隊拓撲，我們可以看到與不同團隊的不同互動模式可能會影響功能週期時間。

在本練習中，假設團隊 ERP 擁有有界上下文線索資訊，團隊 CRM 擁有有界上下文客戶資訊和客戶分析，而金牌團隊擁有有界上下文合格線索和線索分析。通過快速分析，我們可以發現，雖然 Team Gold 和 Team ERP 之間的關係是 X-as-a-Service，但實際上，Qualified Leads 是符合 Lead Information 的。如果團隊 ERP 決定對其有界上下文進行更改，那麼 Team Gold 將出現級聯故障。在相反的方向上，Lead Analytics 和 Lead Information 之間的關係是Customer/Supplier，其中 Team Gold 可以影響 Team ERP 所做的決策。最後但並非最不重要的是，我們有一個團隊來管理文件；然而，沒有一個有界上下文與之相關。

在這個簡單的例子中，我們可以看到改進團隊與職能需求的一致性的潛力。根據我的經驗，這是發現和提高可靠性質量的第一步。如果團隊的職責與有界上下文保持一致，並且團隊朝著最有利的互動模式努力，則可以提高系統的可靠性。對於採用不同協作模式的組織來說，從產品層面發現邊界是一個很好的起點；所涉及的團隊和有界上下文是什麼，以及可能/應該改變什麼以實現所需的可靠性。考慮到這一點（換句話說，基本的複雜性）設計組織可以在保持團隊自主性的同時促進團隊之間更好的協作。

啟發

可用於生成洞察力的一小部分啟發式方法：

• 團隊互動匹配上下文關係
• 投資於團隊環境，然後投資於技術
• 通過改善團隊互動來提高可靠性

作者背景：

João Rosa主要在複雜的環境中運作，高度監管，有數百個團隊，戰略軟體交付顧問