開發(fā)人員與 DevOps 不斷增加的認知負擔被認為是軟件工程中最大的問題之一。隨著越來越多的工具、框架和方法可以選擇，以及“You build it, you run it”的 DevOps 思想的發(fā)展，我們可以看到為了提供面向客戶的產(chǎn)品和服務，認知負擔也隨之大幅增加。
?

在今天的文章中，我們將初步了解認知負擔的基本概念，一起探討對于開發(fā)人員與 DevOps 工程師來說，他們的認知負擔來自哪里，平臺工程將如何減輕認知負擔并改進相應工作流程。
?

了解認知負擔

通常來說人在任何給定時間內(nèi)可以處理的復雜性是有限的，同時存在于我們腦海里的想法數(shù)量也是有限的，通常是在三到七個之間。而一些不必要但又不得不處理的信息或分散手頭任務的注意力也增加了我們所處理的復雜性。復雜性還來自于我們整合想法及概念以幫助理解的過程。這些都構成了我們在嘗試執(zhí)行任務時所需要承受的認知負擔。在心理學中，每種類型的負擔都有對應的名稱：
?

• 內(nèi)部認知負擔-由于任務內(nèi)在難度而產(chǎn)生的負擔

• 外部認知負擔-處理分散注意力或不必要的元素產(chǎn)生的負擔

• 附加認知負擔-由于建立對任務的理解而產(chǎn)生的負擔

?
隨著對任務的熟悉程度越來越高，當我們開始整合理解并建立一個關于任務的更高階心智模型，內(nèi)部認知負擔將隨之減少。例如，當我們第一次嘗試駕駛時可能感到力不從心，即使在路況良好的情況下我們也需要高度集中，這時駕駛給新手司機產(chǎn)生的內(nèi)部認知負擔是極高的。隨著對車況更加熟悉且駕駛技術有所提高，開車這項任務所帶來的認知負擔逐漸減少。當然，我們的駕駛技能依然會受到外部認知負擔影響，比如在開車時手機突然響了等因素。
?

開發(fā)人員的認知負擔

開發(fā)人員往往喜歡談論架構、抽象和實施細節(jié)方面的事情。架構通常是整體想法或創(chuàng)意，也就是系統(tǒng)如何在宏觀層面上組合在一起。抽象則是概括，也就是如何在架構中重用代碼或組件。實施細節(jié)就是如何實現(xiàn)抽象的具體版本。
?

這種層次結構允許開發(fā)者們在忽略各種細節(jié)的情況下仍然能夠理解他們正在工作的系統(tǒng)。通常來說，參與軟件開發(fā)項目的每個人都應該熟悉總體體系結構。在實際情況中，如果開發(fā)人員需要了解軟件系統(tǒng)的所有細節(jié)可能不是啥好事，比如軟件中某個地方有 bug 或者更糟心的，架構某處存在缺陷。
?

開發(fā)現(xiàn)代軟件是一項高度復雜、涉及多職能及高度協(xié)作的過程。例如，專注于構建 web 端相應式 UI 的開發(fā)人員可能不一定知道如何配置為應用程序提供服務的 K8s 集群。理想情況下，該開發(fā)人員會專注于構建 UI 并保持較低的外部認知負擔，而配置 K8s 機群會分散對核心任務的注意力。對于該開發(fā)人員來說，K8s 是一個隱藏在抽象層下的實施細節(jié)，與構建 UI 并沒有直接關聯(lián)。所以當每個人可以專注于自己的專業(yè)領域時，開發(fā)團隊的價值就能發(fā)揮的最大。團隊中的每個人都可以忽略與手頭任務不相關的事情時，相應的外部認知負擔就會很低。
?

DevOps 的認知負擔

盡管 DevOps 旨在提高軟件開發(fā)效率，但 DevOps 工程師經(jīng)常面臨大量艱巨的任務，這些任務增加了他們的認知工作量。讓我們來看一些常見的例子。
?

首先，DevOps 工程師經(jīng)常需要為新的軟件項目設計新的流程，例如持續(xù)集成和持續(xù)交付（CI/CD）流程。DevOps 工程師可能還需要啟動開發(fā)環(huán)境的基礎設施，同時確保與生產(chǎn)環(huán)境的兼容性。這涉及管理 Docker 文件、Helm 圖表和 Terraform 代碼，隨著項目的發(fā)展，這些文件需要定期維護和支持。CI/CD 管道也需要構建，盡管工程師可以從以前的項目中獲取某些部分，但新項目的新測試或構建要求會增加額外的復雜性。
?

現(xiàn)有流程必須擴大或縮小以滿足當前需求。這些流程包括擴展基礎設施以滿足新的處理或存儲要求，以及修改為不斷壯大的小型工程師團隊設計的現(xiàn)有工作流程。
?

DevOps 工程師還管理軟件工程生命周期許多方面的所有權。這包括在內(nèi)部代碼庫和基礎設施之上管理第三方工具和產(chǎn)品。其他開發(fā)人員還需要進行代碼審查和會議來討論需要專業(yè) DevOps 知識的潛在解決方案選項。此外，DevOps 工程師必須確保系統(tǒng)正確記錄日志，并且可以收集和分析指標。掌握不同軟件應用程序的性能對于確保它們順利運行至關重要。它還可以幫助工程師了解需要擴展的潛在領域。
?

除了滿足服務級別協(xié)議 (SLA) 和其他內(nèi)部業(yè)務目標之外，所有這些都給 DevOps 從業(yè)者帶來了巨大的認知壓力。每個任務和流程都會產(chǎn)生 DevOps 從業(yè)者必須處理的額外開銷，通常會從他們的創(chuàng)新和優(yōu)化的主要目標中消除資源。
?

隨著認知負擔的增加，相關的復雜性和壓力也會增加，導致倦怠、錯誤的增加。這會顯著降低團隊生產(chǎn)力，并最終抑制創(chuàng)新。
?

平臺工程有效劃分復雜性

平臺工程的存在就是為了提供多職能團隊共同處理同一軟件項目所需的抽象。平臺將軟件運行在實施細節(jié)上的基礎架構提供給開發(fā)人員，而在此基礎架構上運行的軟件也能同時成為運營團隊的實施細節(jié)。平臺工程有效減少了日常工作的認知負荷，開發(fā)人員在平臺中可以以自助服務的方式使用資源，消除了由于必須處理的流程（例如工單系統(tǒng)）而導致的額外認知負荷。
?

平臺工程的核心之一就是有效劃分復雜性。企業(yè)組織中每個團隊都有自己的職能領域，該團隊中的成員擅長處理該領域中的復雜問題，于此同時其他人可以安全地忽略這些領域。每個人都根據(jù)共同的抽象和對信息組合在一起的理解來處理實施細節(jié)。
?

舉個例子，對于開發(fā)團隊和運營團隊來說，架構是一個共享協(xié)議，整個系統(tǒng)需要運行才能使客戶滿意。這兩個團隊都使用抽象：容器是在各種系統(tǒng)上運行的單元，數(shù)據(jù)庫等資源可用于根據(jù)需要存儲數(shù)據(jù)。而實施細節(jié)根據(jù)職責有所區(qū)分，對于運營團隊的成員來說，實施細節(jié)包括網(wǎng)絡、集群中的 Pod 策略和管理數(shù)據(jù)庫實例。開發(fā)人員對實施細節(jié)就是要解決的業(yè)務問題。在整個項目中，平臺工程是每個人實現(xiàn)其實施細節(jié)而進行溝通的途徑和方式。
?

將平臺工程納入開發(fā)與 DevOps 中

在這一部分，我們將結合一個用例來說明平臺工程如何降低 DevOps 和開發(fā)人員的認知負擔并改進工作流程。
?

想象一下一家企業(yè)設計的 Web 應用程序都遵循類似的架構模式。有一個數(shù)據(jù)庫、一個 API 和一個基于 Web 的前端，有預構建的 Docker 鏡像和 CI/CD 模板。但是這一切都是手動完成的。DevOps 工程師必須為每個項目創(chuàng)建 Docker 文件、實施 Terraform 腳本并構建 Git 管道。然后，他們將與開發(fā)人員合作，確保環(huán)境滿足他們的需求，并向生產(chǎn)基礎設施添加監(jiān)控和警報。這些任務與響應現(xiàn)有基礎設施的 SLA 和執(zhí)行定期維護一起發(fā)生。
?

這給 DevOps 工程師帶來了巨大的壓力。主要問題是無論復雜程度是怎樣，所有任務都直接交給 DevOps 團隊。因此，工作堆棧最終會延長希望推進項目的開發(fā)人員的交付時間。這時平臺工程師可以通過將其構建到內(nèi)部開發(fā)者平臺（IDP）中來自動化這些工作。例如，開發(fā)人員可以從 IDP 請求存儲庫，然后由 IDP 進行創(chuàng)建，而不是手動設置 Git 存儲庫。然后，IDP 將分配正確的用戶組并自動集成正確的 CI/CD 模板。同樣的模式適用于創(chuàng)建開發(fā)環(huán)境和部署核心基礎設施。IDP 充當開發(fā)人員請求服務和應用配置的自助服務平臺，了解默認內(nèi)置的安全最佳實踐和監(jiān)控。IDP 還可以在項目跟蹤軟件和文檔模板中自動設置項目。
?

可見，平臺工程師通過將一套標準化模式構建成自助式內(nèi)部開發(fā)平臺來增強工作流程。這樣以來消除了項目初始化的負擔，團隊也可以立即開始提供業(yè)務價值，而不用花費項目設置的前幾周時間來解決初期問題。同時，由于開發(fā)人員將更加自主，平臺工程師可以專注于解決更大的架構挑戰(zhàn)并將其反饋給 IDP。通過這種方式，他們可以改善現(xiàn)有服務并加強未來的新系統(tǒng)。
?

參考鏈接：

1. https://mp.weixin.qq.com/s/4yvvRIL1uo5uTtIRUwxU5w

2. https://circleci.com/blog/platform-engineering-devops-at-scale/