平臺工程 | 內(nèi)部開發(fā)者門戶權(quán)威指南
本系列文章譯自?https://www.getport.io/blog/guide-to-internal-developer-portals??，全文共7個小節(jié)，首發(fā)于公眾號“數(shù)理話”。
內(nèi)部開發(fā)者門戶權(quán)威指南
平臺工程概述
內(nèi)部開發(fā)者門戶驅(qū)動平臺工程
內(nèi)部開發(fā)者門戶是什么？誰需要它？
優(yōu)秀平臺工程實踐的5大原則
打造內(nèi)部開發(fā)者門戶
內(nèi)部開發(fā)者門戶的價值
開發(fā)者門戶的未來
平臺工程逐步成為一個核心的關(guān)注點，其任務(wù)是確保良好的開發(fā)者體驗，以提高生產(chǎn)力并持續(xù)維持。要做到這一點，內(nèi)部開發(fā)者門戶已經(jīng)成為一項基本要求。本文介紹了建設(shè)內(nèi)部開發(fā)者門戶的理由和具體方式，以及它們?nèi)绾斡绊戦_發(fā)者體驗和生產(chǎn)力。
01. 平臺工程概述
現(xiàn)代應(yīng)用程序開發(fā)的速度越來越快，但同時復(fù)雜性也越來越高，包括微服務(wù)、容器和不同的DevOps工具及云服務(wù)供應(yīng)商。今天，即使是DevOps領(lǐng)導(dǎo)者，在管理工程化運維方面也面臨諸多挑戰(zhàn)。
“我們有GitHub、Jenkins、Jfrog Artifactory和DataDog作為基礎(chǔ)工具，還有各種構(gòu)建和安全工具，如blackduck或snyk，以及多個云服務(wù)供應(yīng)商等等。你可以通過一個購物車服務(wù)就貫通我們的整個流程并體驗DevOps工具。開發(fā)人員不可能掌握所有這些工具，沒有人可以做到?！保⊿hlomi Benita，CyberArk）。
這就導(dǎo)致人們越來越關(guān)注開發(fā)者體驗和平臺工程。
Gartner表示，“平臺工程通過自動化基礎(chǔ)設(shè)施運維實現(xiàn)了可重用工具和自服務(wù)能力，提高了開發(fā)者體驗和生產(chǎn)力”。它使用可重用可配置的應(yīng)用程序組件和服務(wù)，對用戶的好處在于標準化的工具、組件和自動化流程。
這就意識到，糟糕的開發(fā)者體驗和基于“工單運維”的開發(fā)者DevOps交互是不可持續(xù)的。在某種程度上，部署代碼的能力下降、生產(chǎn)力下降以及開發(fā)人員的沮喪情緒的代價變得太高了。
“能讓正式管理層能夠在內(nèi)部開發(fā)平臺上工作的最大賣點之一是，用圖表呈現(xiàn)變更耗時走勢。我們展示了沒有IDP的變更耗時以及有IDP的變更耗時。隨著時間的推移，我們預(yù)估出：沒有IDP，變更耗時會變得更糟。這使得管理層信服?！保⊿hlomi Benita，CyberArk）。
或者，正如Gartner副總裁兼分析師Paul Delory所說：“平臺工程的出現(xiàn)是為了應(yīng)對現(xiàn)代軟件架構(gòu)日益復(fù)雜的情況。如今，非專業(yè)的最終用戶經(jīng)常被要求操作一組復(fù)雜玄妙的服務(wù)。為了幫助最終用戶，減少他們做有價值工作過程中的摩擦，具有前瞻性的公司已經(jīng)開始構(gòu)建運維平臺，這類平臺介于最終用戶和他們所依賴的后端服務(wù)之間”。
02. 內(nèi)部開發(fā)者門戶驅(qū)動平臺工程
平臺工程實踐的第一步是內(nèi)部開發(fā)者門戶。正如Gartner所解釋的：“IDP 提供了一套精心設(shè)計的工具、功能和流程。它們由主題專家選擇并打包，以供開發(fā)團隊輕松使用。其目標是一種無摩擦、自服務(wù)的開發(fā)者體驗提供了正確的功能給開發(fā)者和其他人，使其能夠以盡可能少的開銷生產(chǎn)有價值的軟件。該平臺應(yīng)在提升開發(fā)者生產(chǎn)力的同時減少認知負荷；也應(yīng)當包括開發(fā)團隊所需的一切，并以最適合團隊首選工作流的方式呈現(xiàn)”。
平臺工程的另一個問題是，一些開發(fā)者也缺乏在“誰創(chuàng)建，誰擁有”的世界中茁壯成長所需的基本知識。例如，當從單體或企業(yè)定制產(chǎn)品演進時，就是這種情況，這對開發(fā)人員來說并非易事。在這種情況下，內(nèi)部開發(fā)者門戶允許開發(fā)者以自服務(wù)模式使用DevOps資源，并提供產(chǎn)品級的使用體驗，還為他們提供所需的基礎(chǔ)防護。
IDP還通過提供可以減少開發(fā)人員認知負載的抽象層，大大減少了DevOps和開發(fā)團隊的日常負載。當一切都被抽象掉時，所有開發(fā)者需要關(guān)心的就是編碼、Git和使用IDP中的自服務(wù)功能（然后它將與DevOps正在使用的任何工具通過接口集成，從K8S到Git、Terraform、Jenkins等）。?
03.?內(nèi)部開發(fā)者門戶是什么？誰需要它？
根據(jù) Puppet 的 DevOps 現(xiàn)狀報告（譯注：現(xiàn)已升級為 DevOps 現(xiàn)狀報告平臺工程版），內(nèi)部開發(fā)者平臺是讓成熟的工程組織與眾不同的三大舉措之一（另外兩個是集成安全和自動化變更管理）。
什么是成熟的工程組織呢？這取決于你所在的組織，可能是一個棘手的問題。不過，讓我們從工程團隊的規(guī)?？紤]，看看組織的規(guī)模如何影響開發(fā)者體驗、開發(fā)者生產(chǎn)力以及開發(fā)者和DevOps密切合作的能力。根據(jù)下述圖示，該圖描繪了工程組織規(guī)模和使用開發(fā)者自服務(wù)工具的需求之間的關(guān)系：
組織越大，就越可能需要一個內(nèi)部開發(fā)者門戶（盡管成熟度不一定等于組織大小…）：
有1~30名員工時，一切正常。如果開發(fā)人員懂運維，他們可以自運維；如果他們不太懂，DevOps可以很容易地為他們服務(wù)。無論如何，大部分需求都可以通過與同事在喝杯水的功夫交流或者獲取內(nèi)部知識庫的幫助來得到解決。
擁有超過100名員工的組織通?？梢圆捎?GitOps、直接使用開發(fā)工具等，也可以采用健康適度的工單運維。這不是最優(yōu)但仍然可以工作。你可以在這里閱讀這方面的內(nèi)容。
在某些時候組織使用諸如 Jenkins 之類的 CI 工具來實現(xiàn)開發(fā)者自服務(wù)，但這些解決方案在規(guī)模化使用時往往容易崩潰。
超過1500名開發(fā)人員？除了內(nèi)部開發(fā)者平臺之外的任何解決方案都不起作用，無論是自建還是采購。
?合規(guī)也是復(fù)雜性的重要驅(qū)動因素，因為比如 SOC2 需要對基礎(chǔ)設(shè)施進行適當?shù)臋?quán)限管理。這可能會導(dǎo)致更多的工單。
但建設(shè)內(nèi)部開發(fā)者門戶的原因不止是組織規(guī)模。內(nèi)部開發(fā)者門戶網(wǎng)站在質(zhì)量和數(shù)量上都有其價值。
要想成功，你需要有一個 IDP。我們是一家大公司，并非所有的開發(fā)人員都“懂”云。如果我們告訴他們“這是云，以及所有相關(guān)配置，使用云 SDK，使用這些 API 吧”，他們將不知道該怎么辦。所以這不僅僅是教育培訓(xùn)問題，它還涉及到擁有一個平臺及其內(nèi)部的防護措施。（Guy Brodny，CyberArk）
04. 優(yōu)秀平臺工程實踐的5大原則
內(nèi)部開發(fā)者門戶應(yīng)當通過消耗DevOps資產(chǎn)，為開發(fā)人員提供滿足其基礎(chǔ)設(shè)施需求的自服務(wù)能力；還應(yīng)該能夠搭建、部署、瀏覽、操作及訪問所有應(yīng)該提供給他們的服務(wù)。
以下是要遵循的五個原則：
#1 產(chǎn)品級體驗與解耦
?在 IDP 中，開發(fā)人員應(yīng)該獲得基于 UI 且易于使用的類似產(chǎn)品級的體驗，表單也應(yīng)該清晰易用。IDP 中的工具應(yīng)該與基礎(chǔ)設(shè)施解耦，以便在不改變開發(fā)者體驗的情況下更改基礎(chǔ)設(shè)施。
#2 合規(guī)與安全設(shè)計
使用平臺工程工具應(yīng)當確保并支持合規(guī)、測試、質(zhì)量和安全性。這包括基于角色的訪問控制，以及在必要時添加手動審批的能力。
#3 中心化
?開發(fā)人員應(yīng)當訪問一個中心化的入口，包含文檔、工具、標準、模板、基礎(chǔ)設(shè)施和云資源。視圖應(yīng)反映組織內(nèi)管理的不同DevOps資產(chǎn)的實時狀態(tài)，并可由團隊/開發(fā)人員自定義。所有開發(fā)人員都應(yīng)該根據(jù)自己的角色訪問該系統(tǒng)，因為它包含了整個工程領(lǐng)域的 DevOps 狀態(tài)。
#4 支持最廣泛的自服務(wù)
自服務(wù)應(yīng)該不局限于微服務(wù)腳手架，并提供開發(fā)人員需要做的任何事情：在你所設(shè)置的策略和防護范圍內(nèi)，對軟件目錄中暴露出來的任何資產(chǎn)（無論是否為微服務(wù)）進行供應(yīng)、終止和執(zhí)行 Day-2 操作。
#5 API 優(yōu)先
機器人也應(yīng)該擁有類似于呈現(xiàn)給人類用戶的 IDP 接口的訪問權(quán)，以便可以觸發(fā) DevOps 流并能夠訪問 DevOps 自動化流程及流水線的相關(guān)軟件目錄數(shù)據(jù)。
05. 打造開發(fā)者門戶
內(nèi)部開發(fā)者門戶在工程組織中各不相同 —— 這取決于開發(fā)人員需要抽象的領(lǐng)域、代碼庫、DevOps團隊的需求、開發(fā)人員背景（他們是否習(xí)慣于基于云的微服務(wù)，或者他們是否在內(nèi)部單體架構(gòu)上工作），以及工程文化、流程以及使用的工具。不過它們也有許多共同點。
初始的定義是，平臺就是提供一個抽象層（通常稱為軟件目錄），并具備開發(fā)人員對目錄中呈現(xiàn)的資產(chǎn)執(zhí)行自助操作的能力。
軟件目錄旨在為復(fù)雜的 DevOps 相關(guān)問題提供簡單的答案，這些問題通常需要開發(fā)人員在數(shù)十種不同的工具中穿梭，并需要有深度的內(nèi)部知識庫。
自服務(wù)是為了減輕 DevOps 和開發(fā)團隊的負擔(dān)。內(nèi)部開發(fā)者平臺使所有人都可以使用工具、服務(wù)和知識，從而將它們釋放到代碼中。IDP 應(yīng)具有基于角色的訪問控制能力，以根據(jù)工程師的角色提供對數(shù)據(jù)的合法訪問。
以下是三個主要部分：
5.1 軟件產(chǎn)品目錄?
軟件目錄應(yīng)該遠不止是微服務(wù)目錄，其復(fù)雜性在于基礎(chǔ)設(shè)施中會有多個實體。
軟件目錄是基礎(chǔ)設(shè)施及其上部署的軟件的可視化呈現(xiàn)。理想的軟件目錄應(yīng)該顯示 SDLC 相關(guān)的整個生態(tài)系統(tǒng)：CI/CD 流、開發(fā)環(huán)境、流水線、部署和所有云資源。
軟件目錄需要回答的主要問題是“在哪里部署了什么”，而目錄的結(jié)構(gòu)取決于回答這個問題所需的內(nèi)容，該問題因組織而異，甚至可能隨著時間的推移而改變。
軟件目錄應(yīng)幫助工程團隊快速回答以下問題：
給定服務(wù)在生產(chǎn)環(huán)境當前運行的是什么版本？
誰負責(zé)這個微服務(wù)，它公開了哪些 API 路由？
哪些Kubernetes集群存在于哪個云環(huán)境中？
為什么這次部署失敗了？
誰在值班？
這個版本準備好發(fā)布到生產(chǎn)環(huán)境了嗎？
給定團隊、服務(wù)或開發(fā)人員的 DORA 指標
?
?由于回答這些問題也是“在哪里部署了什么”以及“什么”和“哪里”的相對復(fù)雜性的函數(shù)，因此軟件目錄并沒有理想態(tài)的結(jié)構(gòu)。
讓我們來看一個常見的案例，比如需要（1）服務(wù)、（2）環(huán)境、（3）部署的服務(wù)和（4）部署的統(tǒng)一視圖。在這個案例中，有了這4個元素，就能清楚地了解每個服務(wù)的成熟度和就緒情況，并能詳細了解每個服務(wù)從第一次提交到跨不同環(huán)境運行的多個部署的完整生命周期。我們看看這個案例中的相關(guān)定義。
服務(wù)
服務(wù)可以是微服務(wù)、單體架構(gòu)軟件或者任何其他架構(gòu)的軟件。
環(huán)境
環(huán)境包括任何生產(chǎn)、預(yù)發(fā)布、測試、開發(fā)、按需定制或任何其他環(huán)境類型。
部署的服務(wù)
部署的服務(wù)是指一個運行在特定環(huán)境中的服務(wù)的當前“存活”版本的表示。它將包括對服務(wù)、環(huán)境和部署的引用，以及狀態(tài)、正常運行時間和任何其他相關(guān)元數(shù)據(jù)等實時信息。
部署
部署可以被描述為表示一個 CD 作業(yè)的對象。它包括已部署服務(wù)的版本和指向作業(yè)本身的鏈接。與其他對象不同，部署是軟件目錄中不可變的一項。保持不可變性至關(guān)重要，旨在確保目錄可以保持一致的真實來源。
然而，在某些情況下，根據(jù)環(huán)境的不同，回答“在哪里部署了什么”的問題可能要復(fù)雜得多。讓我們看看這個需要映射的環(huán)境，除了（1）服務(wù)、（2）環(huán)境、（3）部署的服務(wù)和（4）部署這4個元素之外，還有以下元素：（5）命名空間（6）集群（7）云服務(wù)帳戶，以及（8）系統(tǒng)和（9）產(chǎn)品單元。在這種情況下，回答問題需要基于所有9個元素的映射。
軟件目錄應(yīng)該是實時動態(tài)的。一旦你定義好了基礎(chǔ)，軟件目錄就會與你的開發(fā)生命周期集成，即時提供你需要的數(shù)據(jù)（K8S 導(dǎo)出組件、Terraform、GitHub應(yīng)用、Jenkins 等）。它還應(yīng)該具有最小的基礎(chǔ)設(shè)施消耗，并在自服務(wù)UI界面和底層基礎(chǔ)設(shè)施之間實現(xiàn)完全解耦；另外還需要一個顯示依賴關(guān)系的視圖。
5.2 基于構(gòu)建者模式的方法
不同的組織有不同的需求和架構(gòu)，因此，他們需要不同的軟件目錄來可視化呈現(xiàn)他們的 SDLC 。
建議從軟件目錄資產(chǎn)的模式定義開始，這樣可以很容易地構(gòu)建目錄。模式是基本的構(gòu)建單元 —— 藍圖，它表示可以在內(nèi)部開發(fā)者門戶中管理的資產(chǎn)：
微服務(wù)
環(huán)境
包
集群
數(shù)據(jù)庫及其他
藍圖支持任意數(shù)量的屬性，并且通常包含你想要管理和跟蹤的基礎(chǔ)設(shè)施的組件和屬性。如上圖所示，它們是映射“在哪里部署了什么”視圖中需要映射的內(nèi)容的唯一方法。在下一步中，將創(chuàng)建映射到藍圖模式的實體。
想象一下，將 Kubernetes 數(shù)據(jù)映射到實體，以形成軟件目錄，并將數(shù)據(jù)放入相關(guān)實體中。你可以管理運行中集群的表示，查看包含所有命名空間的表，并查看在每個命名空間中部署了哪些服務(wù)。另一個案例是跟蹤身份驗證和授權(quán)資源。你將能夠看到服務(wù)帳戶（Pod 中運行的進程的標識），以及使用它的 Pod 以及相關(guān)規(guī)則和策略。
?
5.3 自服務(wù)的重要性
Gartner 在其“軟件工程領(lǐng)導(dǎo)者改進開發(fā)者體驗指南”報告（需要訂閱）中強調(diào)了開發(fā)者自服務(wù)的重要性：“開發(fā)者自服務(wù)有一個天生的好處，那就是為原本不同的流程和容易出錯的手動切換帶來一致性和可重復(fù)性。自服務(wù)的目標是，確保開發(fā)者擁有‘做正確的事情、直觀的事情’的體驗。例如，通過自服務(wù)預(yù)審來自受信任的組件目錄中的開源庫的能力，就提升了治理能力以及開發(fā)者體驗。”
成功的關(guān)鍵是使用產(chǎn)品思維?—— 內(nèi)部開發(fā)者門戶應(yīng)該同樣易于使用，并考慮到任何軟件產(chǎn)品的“普通”用戶的用戶旅程。這意味著開發(fā)人員應(yīng)該很容易自助服務(wù)，但應(yīng)該以更有用的方式進行抽象，幫助開發(fā)人員做出正確的決策。
在這方面，很重要的是確保自服務(wù)擴展到微服務(wù)腳手架之外，并允許開發(fā)人員在組織內(nèi)的政策、手動批準和防護（包括預(yù)定義模板）之內(nèi)，對軟件目錄中暴露的任何資產(chǎn)進行供應(yīng)、終止和執(zhí)行 Day-2 操作。讓他們提供一個開發(fā)環(huán)境，申請 S3 桶的權(quán)限，或者向微服務(wù)添加一個秘鑰。
5.4 不僅僅是一個 K8S 的抽象層
平臺工程的挑戰(zhàn)之一是為你的開發(fā)者客戶找到正確的抽象。所謂正確的抽象對于不同組織來說也是不同的，甚至在同一組織中的開發(fā)者之間也是不同的。
每個組織都是一片獨一無二的雪花，都有自己的流程和工作流。一些組織開發(fā)生產(chǎn)關(guān)鍵型產(chǎn)品，而另一些組織則開發(fā)“值得擁有”的開發(fā)工具產(chǎn)品。一些組織里的開發(fā)人員熟悉 Kubernetes 的比特和字節(jié)級細節(jié)，而有些開發(fā)人員根本就不想聽到它。有些組織更專注于大數(shù)據(jù)技術(shù)，而另一些組織則專注于前端技術(shù)，等等。這就是為什么在 Kubernetes 之上創(chuàng)建抽象層是徒勞的，這些抽象層不能在不同的組織和角色之間進行定制。
你很可能找不到一個現(xiàn)成的抽象層來滿足組織的特定需求。一個開發(fā)者門戶對一家公司來說可能是很了起的，但對另一家公司則是災(zāi)難。
開發(fā)者門戶必須可定制，以滿足組織中不同開發(fā)人員的確切需求。如果沒有這些定制功能，組織中的開發(fā)者門戶對開發(fā)人員來說將過于復(fù)雜，對 DevOps 團隊來說也不安全，或者它會將開發(fā)人員置于“黃金籠子”中，并降低研發(fā)團隊的速度。
此外，DevOps 生態(tài)并不僅僅由 Kubernetes 組成，還有 Git 倉庫、runbook、云服務(wù)和身份認證服務(wù)、CI/CD 流水線、工單、值班、可觀測性工具等等。
開發(fā)者門戶必須封裝組織的 DevOps 生態(tài)中的所有活動部分，僅僅使用 Kubernetes 是遠遠不夠的。
?
5.5 對比 GitOps
GitOps 允許開發(fā)人員使用 Git 中的代碼變更來完成任務(wù)。開發(fā)人員可以部署微服務(wù)、提供云資源、管理環(huán)境、配置等。雖然這確實提供了良好的開發(fā)者體驗，但它并不能取代對開發(fā)者門戶的需求。
原因如下：
GitOps 相關(guān)的文件分布在整個代碼庫中，這使得很難確定需要變更的內(nèi)容，且產(chǎn)生了嚴重中斷的風(fēng)險。
DevOps 和開發(fā)人員資產(chǎn)存在于同一個文件中，這使得開發(fā)人員很難知道需要變更什么。
工具創(chuàng)建大量工單的請求激增。
Git 不能反映真實世界的實際情況，這可能會導(dǎo)致開發(fā)人員做出錯誤的決定。
當有許多的代碼倉庫和配置文件時，缺乏清晰度。
內(nèi)部開發(fā)者門戶是 GitOps 之上的一個解耦接口，確保開發(fā)人員的輸入得到驗證，并確保開發(fā)人員走上黃金路經(jīng)。開發(fā)人員不需要理解 GitOps 文件。通常，基本操作和重復(fù)操作將通過開發(fā)者門戶執(zhí)行。預(yù)定義的自服務(wù)操作將減少拉取請求的數(shù)量。如果你合并了自服務(wù)操作，那么這是最好的，這樣以來，如果在 GitOps 中需要更改多個文件，請嘗試通過在內(nèi)部開發(fā)者門戶中只設(shè)置一個自助服務(wù)操作來實現(xiàn)。
?
5.6 對比 CI 工具
啟用?Jenkins自服務(wù)可以很好地用于開發(fā)者自服務(wù)，但由于 Jenkins 天生的開放性，存在許多已知的可見性、合規(guī)性和其他問題。在某些時候，速度和靈活性也可能會變得一團糟。
Jenkins 并不是為自服務(wù)而生的，原因有很多：
它是無狀態(tài)的，因此很難跟蹤變更和擴展操作。
它有一組有限的UI組件，因此表單不支持輸入驗證（包括正則表達式和針對第三方的驗證）、第三方數(shù)據(jù)輸入（例如，有一個包含用戶所有S3 桶的下拉列表），以及 if-then-that 特性。
Jenkins 也是高耦合的，這使得變更更加困難。
所有這些都會給開發(fā)人員帶來糟糕的體驗，極有可能出現(xiàn)錯誤、合規(guī)和安全問題。
06. 內(nèi)部開發(fā)者門戶的價值
“我們的KPI是，過去一周內(nèi)至少進入開發(fā)者門戶一次的開發(fā)者的百分比。目前，這一比例約為 40%。我們開放的操作越多……使用的人就越多?！保↙ior Rabin，monday.com）。
如何知道內(nèi)部開發(fā)者門戶已經(jīng)達成了目標？一個好的內(nèi)部開發(fā)者門戶應(yīng)該可以減輕開發(fā)人員在處理現(xiàn)代軟件復(fù)雜性方面的負擔(dān)。結(jié)果應(yīng)該是開發(fā)人員只在一個地方尋找與環(huán)境、部署、軟件、ETL、數(shù)據(jù)庫相關(guān)的任何東西，以及他們執(zhí)行所需自服務(wù)操作的簡單方法。當復(fù)雜性的負擔(dān)減輕時，軟件的質(zhì)量、成熟度、安全性和穩(wěn)定性都應(yīng)該得到提高，開發(fā)人員的生產(chǎn)力和滿意度都會很高。它還會使DevOps能夠?qū)Ｗ⒂跇?gòu)建基礎(chǔ)設(shè)施和自動化，這可能也會讓他們更快樂。
?不要讓通過開發(fā)者門戶開啟的“黃金路徑”變成“黃金籠子”。不能強迫開發(fā)人員始終使用開發(fā)者門戶。一個好的 IDP 應(yīng)該為 98% 的用例提供一條黃金路徑，因此它確實實現(xiàn)了與之相關(guān)的好處。但總會有 2% 的用例需要在開發(fā)者門戶之外進行工作—— IDP 應(yīng)該接受這一點，而不是阻止它，并小心創(chuàng)建“黃金籠子”。重要的是，即使工程師沒有使用黃金路徑進行自服務(wù)操作，但其所做的任何操作都將通過從工程基礎(chǔ)設(shè)施中獲取數(shù)據(jù)而出現(xiàn)在IDP 中。這會通過一個導(dǎo)出工具完成，該導(dǎo)出工具將使用來自其他系統(tǒng)（例如K8S）的數(shù)據(jù)填充服務(wù)目錄，即使這些更改不是通過內(nèi)部開發(fā)者門戶完成的。
6.1 定量收益
?Twitter通過其開發(fā)速度來定義其平臺工程團隊的成功。通過使用內(nèi)部開發(fā)者門戶，它預(yù)計會將其翻一番。
今天，“我們從尋找速度開始，”推特平臺負責(zé)人 Nick Tornow 說。“我們將其定義為工程師在一個時間單位內(nèi)可以提供的功能數(shù)量，我們希望到 2023 年底將其翻一番?！??出處
許多行業(yè)專家估計，使用內(nèi)部開發(fā)者門戶可以將 DevOps 收到的工單數(shù)量減少 80%，從而釋放寶貴的 DevOps 時間。
除了開發(fā)人員的速度，還可以衡量開發(fā)人員的生產(chǎn)力、DevOps的生產(chǎn)力、云成本的降低，以及更大的目標，如減少技術(shù)債務(wù)或減少停機時間。DORA?指標也可以改進，MTTR 和新開發(fā)人員上手所需的時間也可以改進。
開發(fā)者門戶的一個經(jīng)常被忽視的好處是，它可以為開發(fā)人員提供部署權(quán)限的防護和開發(fā)者生產(chǎn)力的標準，從而為服務(wù)成熟度制定標準。這些相同的元素也可以按服務(wù)、開發(fā)人員或團隊進行度量。服務(wù)成熟度可以是很多東西，但你可以使用內(nèi)部開發(fā)者門戶將其定義為生產(chǎn)準備、質(zhì)量、安全性和合規(guī)性的混合體。然后，你可以立即通過團隊、開發(fā)人員等對所有服務(wù)進行評分，了解哪些服務(wù)或資源符合標準，哪些不符合標準。
“我們未來考慮的一個功能是對服務(wù)的準備程度進行評分。如果一項服務(wù)沒有使用我們定義為核心的包進行更新，如果在 GitHub 上沒有所需的配置，如果該服務(wù)不存在于我們所有的地理區(qū)域，我們可以計算分數(shù)。分數(shù)會讓我們警告服務(wù)所有者，他們的服務(wù)低于標準。如果服務(wù)下降到某個閾值以下，我們可能希望采取阻止部署到生產(chǎn)或類似的手段”（Lior Rabin，Monday.com）。
6.2 定性收益
?在文化上做出轉(zhuǎn)變，提倡左移，使開發(fā)人員更加輕松，讓 DevOps 能夠在更多的戰(zhàn)略項目中發(fā)揮價值，所有這些對工程團隊而言，都使公司變得更好。所有這些都可以通過采用內(nèi)部開發(fā)者門戶來實現(xiàn)。
07.?開發(fā)者門戶的未來
整本電子書主要關(guān)注的是人類用戶如何與內(nèi)部開發(fā)者門戶進行交互。除此之外還有一個未來趨勢：機器也將與內(nèi)部開發(fā)者門戶進行交互。讓我們設(shè)想這樣一個例子：今天是黑色星期五，我們不希望電商網(wǎng)站有任何變更。在 IDP，可通過 CI/CD流水線查詢并檢查部署到生產(chǎn)環(huán)境服務(wù)的“鎖定狀態(tài)”。這個例子告訴我們，IDP 將發(fā)展成為反映整個軟件架構(gòu)和實際狀態(tài)（權(quán)限、秘密、所有者等）的中樞，所有應(yīng)當和不應(yīng)當進行的操作都會在此強制記錄在案。在未來，IDP 還將為機器提供與人類用戶相似的接口，以觸發(fā) DevOps 流。
歡迎來到 DevOps 的未來 ——?平臺工程。
NOTE
如果你對平臺工程、內(nèi)部開發(fā)者門戶等話題感興趣，歡迎添加微信好友 nodexy，備注“平臺工程交流”獲邀加入我們的平臺工程技術(shù)討論群組。
也可以在GitHub查看平臺工程主題的資源列表??https://github.com/toptechevangelist/awesome-platform-engineering?
關(guān)注并加入平臺工程社區(qū) https://github.com/pecommunity ?
