開發人員與 DevOps 不斷增加的認知負擔被認為是軟體工程中最大的問題之一。隨著越來越多的工具、框架和方法可以選擇，以及「You build it, you run it」的 DevOps 思想的發展，我們可以看到為了提供面向客戶的產品和服務，認知負擔也隨之大幅增加。
在今天的文章中，我們將初步瞭解認知負擔的基本概念，一起探討對於開發人員與 DevOps 工程師來說，他們的認知負擔來自哪裡，平臺工程將如何減輕認知負擔並改進相應工作流程。
通常來說人在任何給定時間內可以處理的複雜性是有限的，同時存在於我們腦海裡的想法數量也是有限的，通常是在三到七個之間。而一些不必要但又不得不處理的資訊或分散手頭任務的注意力也增加了我們所處理的複雜性。複雜性還來自於我們整合想法及概念以幫助理解的過程。這些都構成了我們在嘗試執行任務時所需要承受的認知負擔。在心理學中，每種型別的負擔都有對應的名稱：
內部認知負擔-由於任務內在難度而產生的負擔
外部認知負擔-處理分散注意力或不必要的元素產生的負擔
附加認知負擔-由於建立對任務的理解而產生的負擔
隨著對任務的熟悉程度越來越高，當我們開始整合理解並建立一個關於任務的更高階心智模型，內部認知負擔將隨之減少。例如，當我們第一次嘗試駕駛時可能感到力不從心，即使在路況良好的情況下我們也需要高度集中，這時駕駛給新手司機產生的內部認知負擔是極高的。隨著對車況更加熟悉且駕駛技術有所提高，開車這項任務所帶來的認知負擔逐漸減少。當然，我們的駕駛技能依然會受到外部認知負擔影響，比如在開車時手機突然響了等因素。
開發人員往往喜歡談論架構、抽象和實施細節方面的事情。架構通常是整體想法或創意，也就是系統如何在宏觀層面上組合在一起。抽象則是概括，也就是如何在架構中重用程式碼或元件。實施細節就是如何實現抽象的具體版本。
這種層次結構允許開發者們在忽略各種細節的情況下仍然能夠理解他們正在工作的系統。通常來說，參與軟體開發專案的每個人都應該熟悉總體體系結構。在實際情況中，如果開發人員需要了解軟體系統的所有細節可能不是啥好事，比如軟體中某個地方有 bug 或者更糟心的，架構某處存在缺陷。
開發現代軟體是一項高度複雜、涉及多職能及高度共同作業的過程。例如，專注於構建 web 端相應式 UI 的開發人員可能不一定知道如何設定為應用程式提供服務的 K8s 叢集。理想情況下，該開發人員會專注於構建 UI 並保持較低的外部認知負擔，而設定 K8s 機群會分散對核心任務的注意力。對於該開發人員來說，K8s 是一個隱藏在抽象層下的實施細節，與構建 UI 並沒有直接關聯。所以當每個人可以專注於自己的專業領域時，開發團隊的價值就能發揮的最大。團隊中的每個人都可以忽略與手頭任務不相關的事情時，相應的外部認知負擔就會很低。
儘管 DevOps 旨在提高軟體開發效率，但 DevOps 工程師經常面臨大量艱鉅的任務，這些任務增加了他們的認知工作量。讓我們來看一些常見的例子。
首先，DevOps 工程師經常需要為新的軟體專案設計新的流程，例如持續整合和持續交付（CI/CD）流程。DevOps 工程師可能還需要啟動開發環境的基礎設施，同時確保與生產環境的相容性。這涉及管理 Docker 檔案、Helm 圖表和 Terraform 程式碼，隨著專案的發展，這些檔案需要定期維護和支援。CI/CD 管道也需要構建，儘管工程師可以從以前的專案中獲取某些部分，但新專案的新測試或構建要求會增加額外的複雜性。
現有流程必須擴大或縮小以滿足當前需求。這些流程包括擴充套件基礎設施以滿足新的處理或儲存要求，以及修改為不斷壯大的小型工程師團隊設計的現有工作流程。
DevOps 工程師還管理軟體工程生命週期許多方面的所有權。這包括在內部程式碼庫和基礎設施之上管理第三方工具和產品。其他開發人員還需要進行程式碼審查和會議來討論需要專業 DevOps 知識的潛在解決方案選項。此外，DevOps 工程師必須確保系統正確記錄紀錄檔，並且可以收集和分析指標。掌握不同軟體應用程式的效能對於確保它們順利執行至關重要。它還可以幫助工程師瞭解需要擴充套件的潛在領域。
除了滿足服務級別協定 (SLA) 和其他內部業務目標之外，所有這些都給 DevOps 從業者帶來了巨大的認知壓力。每個任務和流程都會產生 DevOps 從業者必須處理的額外開銷，通常會從他們的創新和優化的主要目標中消除資源。
隨著認知負擔的增加，相關的複雜性和壓力也會增加，導致倦怠、錯誤的增加。這會顯著降低團隊生產力，並最終抑制創新。
平臺工程的存在就是為了提供多職能團隊共同處理同一軟體專案所需的抽象。平臺將軟體執行在實施細節上的基礎架構提供給開發人員，而在此基礎架構上執行的軟體也能同時成為運營團隊的實施細節。平臺工程有效減少了日常工作的認知負荷，開發人員在平臺中可以以自助服務的方式使用資源，消除了由於必須處理的流程（例如工單系統）而導致的額外認知負荷。
平臺工程的核心之一就是有效劃分複雜性。企業組織中每個團隊都有自己的職能領域，該團隊中的成員擅長處理該領域中的複雜問題，於此同時其他人可以安全地忽略這些領域。每個人都根據共同的抽象和對資訊組合在一起的理解來處理實施細節。
舉個例子，對於開發團隊和運營團隊來說，架構是一個共用協定，整個系統需要執行才能使客戶滿意。這兩個團隊都使用抽象：容器是在各種系統上執行的單元，資料庫等資源可用於根據需要儲存資料。而實施細節根據職責有所區分，對於運營團隊的成員來說，實施細節包括網路、叢集中的 Pod 策略和管理資料庫範例。開發人員對實施細節就是要解決的業務問題。在整個專案中，平臺工程是每個人實現其實施細節而進行溝通的途徑和方式。
在這一部分，我們將結合一個用例來說明平臺工程如何降低 DevOps 和開發人員的認知負擔並改進工作流程。
想象一下一家企業設計的 Web 應用程式都遵循類似的架構模式。有一個資料庫、一個 API 和一個基於 Web 的前端，有預構建的 Docker 映象和 CI/CD 模板。但是這一切都是手動完成的。DevOps 工程師必須為每個專案建立 Docker 檔案、實施 Terraform 指令碼並構建 Git 管道。然後，他們將與開發人員合作，確保環境滿足他們的需求，並向生產基礎設施新增監控和警報。這些任務與響應現有基礎設施的 SLA 和執行定期維護一起發生。
這給 DevOps 工程師帶來了巨大的壓力。主要問題是無論複雜程度是怎樣，所有任務都直接交給 DevOps 團隊。因此，工作堆疊最終會延長希望推進專案的開發人員的交付時間。這時平臺工程師可以通過將其構建到內部開發者平臺（IDP）中來自動化這些工作。例如，開發人員可以從 IDP 請求儲存庫，然後由 IDP 進行建立，而不是手動設定 Git 儲存庫。然後，IDP 將分配正確的使用者組並自動整合正確的 CI/CD 模板。同樣的模式適用於建立開發環境和部署核心基礎設施。IDP 充當開發人員請求服務和應用設定的自助服務平臺，瞭解預設內建的安全最佳實踐和監控。IDP 還可以在專案跟蹤軟體和檔案模板中自動設定專案。
可見，平臺工程師通過將一套標準化模式構建成自助式內部開發平臺來增強工作流程。這樣以來消除了專案初始化的負擔，團隊也可以立即開始提供業務價值，而不用花費專案設定的前幾周時間來解決初期問題。同時，由於開發人員將更加自主，平臺工程師可以專注於解決更大的架構挑戰並將其反饋給 IDP。通過這種方式，他們可以改善現有服務並加強未來的新系統。
參考連結：