忘記單體與微服務，重要的是團隊的認知能力和範圍！ | TechBeacon

banq發表於2019-09-27
微服務

“單體與微服務”的爭論通常集中在技術方面，而忽略了戰略和團隊動力。但是，思維敏捷的組織不是從技術入手，而是以團隊的認知負擔作為有效交付和執行現代軟體系統的指導原則。 過多的認知負擔不利於有效的團隊所有權和軟體的可支援性。(banq注：人的能力有限，過多支援太多太廣的系統就會力不從心)

微服務粒度很難確定？當您根據擁有單個服務的團隊他們可以處理的認知負擔來重新考慮問題時，圍繞服務大小如何確定等大多數混淆都將消失。

如何定義認知負荷

心理學家約翰·斯威勒（John Sweller）將認知負荷定義為“ 在工作記憶中使用的精神努力總量 ”，然後繼續描述三種不同的認知負荷：

  1. 內在的認知負荷，與問題空間基本任務的各個方面有關。示例：如何用Java定義類？
  2. 無關的認知負荷，與完成任務的環境有關。示例：如何再次部署此元件？
  3. 相關認知負荷， 這 涉及需要學習或高效能特別注意任務的各個方面。示例：此服務應如何與ABC服務互動？

廣義上講，您應該嘗試最小化內在的認知負擔（透過培訓，對技術的良好選擇，聘用，結對程式設計等），並消除無關的認知負擔（無聊或多餘的任務或命令，它們幾乎沒有保留在工作記憶中的價值） ）。這將為人的認知負擔（“增值”思維所在）留出更多空間。
有關認知負載如何應用於軟體開發的概述，請參閱Jo Pearce的文章“ 管理團隊學習的認知負載 ” 。

團隊的認知負荷
當將認知負荷的概念應用於整個團隊時，您需要限制期望團隊工作的軟體系統的大小。也就是說，不要讓軟體子系統超出負責它的團隊的認知符合。這對軟體系統的形式和架構具有強烈而徹底的影響：當您將認知符合明確視為可支援性和可操作性的指標時，軟體架構將變得更加具有“團隊形”。
儘量減少不必要的認知負擔的驅動力還導致需要關注開發人員的經驗和運維人員員的經驗。透過使用明確定義的平臺和元件，您的團隊將能夠減少不必要的認知負擔。
一些組織甚至開始使用認知符合作為對軟體體系結構和系統邊界決策的明確輸入。

為什麼您應該使用團隊認知能力來合理選擇微服務
在“ 您構建，執行 ”的世界中，整個團隊負責軟體服務的成功運營，必須消除對團隊軟體所有權的不必要障礙。模糊的命令或神秘的配置選項增加了團隊成員的（外部）認知負擔，有效地降低了他們獲取或改善面向業務方面的能力（認知負荷）。
另一個典型的示例是等待另一個團隊為基礎結構提供驗證或更新配置。這打斷了依賴團隊的流動，再次導致認知能力的有效利用減少。
團隊認知能力的下降使團隊完全擁有軟體服務的能力受到壓力。團隊花費大量時間來處理複雜的配置，容易出錯的過程和/或等待新的環境或基礎結構更改，以致於無法對可測試性或執行時邊緣案例的重要方面給予足夠的重視。
正如軟體開發人員Julia Evans所說，減少團隊的認知負擔意味著設定介面邊界。 您組織中的每個技術人員都不必是Kubernetes專家。
換句話說，透過確保團隊的認知負擔不太高，您將有更好的機會來增強團隊所使用的軟體的可支援性和可操作性。它可以更好地擁有自己的服務，因為團隊更好地瞭解它們。

減少團隊認知負荷並改善流程的三種方法
沒有降低團隊認知負擔的神奇方法，但是我們與全球許多大型組織（包括中國，歐洲和美國）合作，建議使用三種有用的方法：定義明確的團隊互動模式，獨立的流程，統一的團隊，以及最薄的可行平臺。

1.建立明確的團隊互動模式
在組織中，團隊之間的關係經常沒有很好地定義或理解。正如羅素·阿科夫（Russell Ackoff）所說，組織中出現的問題“ 幾乎總是零件相互作用的產物，而不是單個零件作用的產物。 ”
您可能已經聽到諸如“為什麼我們必須與其他團隊合作？”之類的抱怨。或“為什麼那個團隊不提供我們所需的東西？” 這些跡象表明組織內部的團隊互動是模稜兩可的。在《團隊拓撲》一書中，我們確定了三種核心的團隊互動模式，以幫助闡明和定義團隊之間的互動方式：

  1. 協作：在定義的時間段內與另一個團隊合作，以發現新的工作方式，新工具或新解決方案。
  2. X即服務：使用或提供“服務即服務”，並具有清晰的API和對服務級別的明確期望。
  3. 促進：幫助團隊（或得到團隊幫助）獲得新技能或新領域意識，或採用新技術。

有了這些定義明確的團隊互動模式，您就可以開始在組織級別上聽取訊號，以瞭解效果良好的團隊互動和不良好的團隊互動，包括認知負擔問題。
例如，如果協作互動持續太長時間，則可能表明該技術的某些方面最好由平臺作為服務提供。
同樣，如果一個團隊希望使用“作為服務”的監視工具，但經常需要與提供團隊合作來診斷問題，則這可能表明使用團隊的認知負荷過多，您需要簡化API。

2.使用獨立的，按流程分組的團隊
在大型和小型組織中，越來越多的小型跨職能團隊（具有多種技能）擁有整個問題領域的“切片”，從創意到實時服務。這樣的團隊通常稱為產品或功能團隊。
但是隨著物聯網和無處不在的連線服務的發展，我們稱它們為“流對齊”，因為當您談論物理裝置，線上服務和網路之間的多對多互動時，“產品”失去了其含義。
與流程保持一致的團隊與組織部門所要求的變更流保持一致，無論是業務線，市場部門，特定的地理位置還是政府服務。
確保流對齊的團隊可以獨立於其他團隊進行絕大部分工作來分析，測試，構建，釋出和監視更改，這一點極為重要。依賴關係會引入大量的認知負擔（例如，等待其他微服務或環境能夠進行測試，或者沒有以微服務為中心的監視）。
確保按流程排列的團隊在日常工作流程中基本獨立，可以消除無用的外部認知負擔，使團隊可以專注於工作的內在和緊密聯絡（與領域相關）。這種獨立性的部分原因在於能夠使用有效的平臺。
在大型組織中，交付大型，複雜的系統時，將兩個或三個團隊緊密地聯絡在一起很有用。這種密切的關係有助於避免一個團隊等待另一團隊。
顯然，團隊確實依賴其他服務和相關的團隊來提供基礎結構，執行時API，工具等。但是，這些依賴關係不會阻止流向一致的團隊的工作流程。能夠自助服務新測試環境，部署管道或服務監視都是無阻塞依賴關係的所有示例。與團隊保持一致的團隊可以根據需要獨立使用它們。

3.建立最薄的可行平臺
與流保持一致的團隊應該期望從定義明確的平臺使用服務，但避免使用過去龐大，不友好的平臺。相反，構建最薄的可行平臺（TVP）：加速團隊開發現代軟體服務和系統所需的最小的API，文件和工具集。
這樣的TVP可能只有一個Wiki頁面，該頁面定義了其他團隊應該使用哪種公共雲提供商服務以及如何使用。較大的組織可能會決定在底層雲或IoT平臺上構建其他服務，但是這些額外服務應始終“足夠稠密”，以加速以流為單位的團隊中的變更流程，而不是更稠密。
當內部平臺腫，緩慢且有故障時，避免過去的頻繁錯誤；有糟糕的使用者體驗；而且-更糟的是-必須使用。
一個好的平臺可以作為流對齊團隊的力量倍增器，透過關注開發人員的經驗，易用性，工具的簡單性和文件的豐富性，幫助他們專注於核心領域的功能。簡而言之，使用平臺本身內的標準敏捷性和DevOps做法，將與流對齊的團隊作為內部客戶來構建和執行平臺，作為產品或服務本身。
雲通訊公司Twilio的工程師在內部對其交付團隊採用了這種方法。在2018年QCon的一次演講中，工程高階總監賈斯汀·北川  （Justin Kitagawa）描述了Twilio的內部平臺如何透過提供統一的自助式宣告性平臺來構建，交付和執行數千個全球微服務，從而減輕了工程師的認知負擔。
此外，該平臺的開發者經驗會定期根據內部客戶的反饋（使用淨髮起人得分）進行評估。
Twilio的內部平臺明確遵循以下關鍵原則：
  • API優先：授權開發團隊透過自動化在平臺功能方面進行創新。
  • 透過網守自助服務：幫助開發團隊確定自己的工作流程。
  • 宣告式勝於命令式：“什麼”優先於“如何”。
  • 善解人意地構建：瞭解使用該平臺的人們的需求和挫敗感。

這種方法使Twilio能夠擴充套件到全球40,000多家組織的客戶群。
透過減少認知負擔，一個好的平臺可以幫助開發團隊專注於問題的不同方面，增加個人和團隊級別的流程，並使整個團隊更加有效。

減輕負荷
在考慮軟體系統邊界的大小和形狀時，團隊的認知負荷是一個重要的方面。透過確保團隊的認知負擔不會太高，您可以增加團隊成員能夠有效地構建和運營服務的機會，因為他們會正確地理解他們正在構建的系統。我們建議使用三種核心的團隊互動模式來闡明團隊之間的互動，並最終幫助減輕認知負擔。當與獨立的按流分組的團隊和最薄的可行平臺一起使用時，這些團隊互動模式將幫助您的組織檢測系統中不同部分的認知負擔何時過高。

相關文章