有鑑於越來越多的組織開始利用 DevOps 支援數位轉型，本文帶領你洞察此團隊。
文／Peter Wayner 譯／Iris.Liu 校／曹乙帆
在一開始，只有程式碼及編寫程式碼的程式設計師。開發人員則負責承擔一切。他們精心設計邏輯，接著點擊按鈕使其在伺服器上執行。隨著團隊的擴大及組員們的差異性，讓這種慣例產生了變化。某些組員負責設計程式（devs開發人員），其他組員則負責維護機器（ops維運人員）。
近年來由於雲端及微服務的興起，軟體的運作轉變為被切割成數十個、甚至數千個相關的元件，並部署在不同的電腦中。每一台機器在技術上都是獨立的，但所有的機器必須協同合作，以確保各自的執行都遵循著自動化腳本執行。歡迎加入DevOps 家族。
DevOps團隊的主要任務是提供多面向應用程式的進階編排流程。它們可能無法處理軟體結構的深層次問題，卻能讓元件執行流暢。
此外，DevOps人員這一角色相對較新，職責也尚未明確界定或分配，其技能仍在持續發展中。DevOps人員的工作是跨職責的，可能必須同時負責程式設計與營運，不過也有不少團隊認為維持伺服器的穩定執行即可。在程式設計團隊更新程式碼以及調整執行方式的過程，進行配置需要針對細節進行精心規劃。
隨著越來越多的組織轉向利用DevOps以支援其數位轉型，而運用的重點之一是得到洞察力。故下文將說明關於DevOps此一新興領域中，一些被隱藏的真相及普遍的錯誤觀念。
DevOps不是撰寫程式
不少主管層級都認為DevOps不是撰寫程式，這樣的想法是正確的。不過DevOps人員的工作職責已經產生變化，像是處理位元組及資料結構等可能讓其產生困惑或覺得困難的繁瑣工作，都指派給沈浸於抽象世界的程式設計師。就策略面而言，讓程式設計師從維持所有程式正常運行的責任中釋放出來是合理的，因為他們可能迷失在當代錯綜複雜的堆疊(stack)叢林中。
不過DevOps團隊成員仍必須撰寫少量的程式碼。他們仍需要進行資料結構的抽象化。利用不中斷的指令列(command line)引動過程以維持所有程式的執行，而這些引動過程方法通常利用收集並簡化為shell script。儘管某些堅持絕對遵守傳統撰寫程式規則或結構的程式碼純粹主義者，可能不會將這類的高層級的工作歸類為撰寫程式，即使它包含函式呼叫、參數及變數等元素。而真實的情況是，DevOps人員其實擁有許多跟程式設計師相同的技能。
集結管理程式設計師會是主要職責
即使DevOps人員不需要撰寫程式碼，但最終也要管理程式人員，但這通常意味有著很多的工作。每一位開發人員都在進行創造新穎且完美的成品，而程式碼是一種藝術。每個人都希望立即將他/她完成的容器(container)投入生產，以更新自己的任務清單。而他們通常會衡量程式碼的執行會順利嗎？有哪一個關節的問題可能導致系統整體的崩潰？故確保程式設計師們不會把事情搞砸是DevOps人員的重任之一。
DevOps人員正在慢慢接管
當軟體是個別單一的時候，程式設計師能擁有絕對的控制權。現在的應用程式通常被劃分成數十個甚至是數百個微服務，DevOps人員負責它們的執行狀態，且另外有架構師及程式設計師們共同決定如何將不同的服務連接在一起，而DevOps人員在身負連接整體服務的職責上，將會是一個越來越不可忽視的難題。
不再關注價格而是審查人
當雲端服務供應商以每小時數美分計價收費方式為其機器定價時，他們顯得相當精明的。畢竟誰身上沒有零錢呢？但隨著雲端實例(cloud instance)數量的不斷上升和使用時間的流逝，這些費用就會累計增加。在30天中有720個小時裡，原本每小時僅花費1美元的複雜型機器，一年的費用就會高達8,760美元。突然之間購買自己的設備開始變得便宜了。
但在收到令人咋舌的帳單後，有些團隊開始設立DevOp稽核人員，其唯一的職責是在目不暇給的機器中找出最節省資金的方式。他們開始對立場模擬兩可人員的決定展開仔細的審查，然後做出結論：「不」。這種錙銖必較的緣故是因為他們很清楚如何節省預算。
只有少數手段可以提升效能
管理雲端服務的難度增加了，主因是DevOps人員通常只有幾個工具和方法可以利用。一旦程式設計師提交程式碼並建構容器後，DevOps團隊的工作就是讓它們能夠正確執行。如果執行的效率不佳，可以試著新增更多的虛擬CPU或RAM。如果效率仍然沒有改善，就可以在機房中增加更多的機器以分擔負載量。
難以避免的錯誤百出
最深層的問題之一是電腦總是在掩飾錯誤。我曾經遭遇某些容器每隔數小時就會崩潰。這可能是連接資料庫失敗、或是參數配置錯誤所導致的。發生問題的原因可能藏在日誌檔中，但是我從未發現過。Kubernetes可以啟動另一個實例，並回應查詢要求，同時完成其作業。這是故障保護(Fail-Safe)架構的一個完善的案例，即使其內部的情況是混亂且難以處理的。
從外部到內部，容器和實例可能在任一個地方產生損壞的情況。只要用戶及顧客都能完成工作，通常每個人都可能以更輕鬆的方式從不同角度看問題，進而忽略掉所有的虛擬毀壞
資料庫主宰一切！
多數人可能會因過於關注所有的專屬程式碼，進而操弄 AJAX 或 CSS，不過所有的資料最終都會被儲存在資料庫中。資料庫就像是程式碼圍繞著軌道運行的太陽，也就是系統的核心，真實性的唯一來源。如果團隊能維持系統的運行並回應查詢要求，這幾乎就包含了所有的作業。用戶可以容許DIV標籤的位置或對齊方式有誤，或不熟悉的新設計，但無法接受資料庫的走樣。我曾經為一個使用最新的、最出色的 Node.js 套件的團隊審查過程式碼，他們持續地更新堆疊以保持最先進的地位。但其採用的資料庫已經有 10 多年的歷史，所以沒有人會想招惹那套軟體。
對程式的執行方式了解有限
目前儀器的層級可能已經達到足以令人驚喜的程度了。我們可以透過各種軟體的應用來體驗資料的遽增，就像水手感知風浪般。隨著機房負載的流量波動，我們會抓出系統何時運行正常以及何時不堪重負，進而調整出應對負載問題的措施。若負責電子商務的網路應用程式，我們將是第一個知道優惠何時生效的人，因為應用程式的流量負載將會遽增。
但是儀器能揭露的資訊有限。輸出的數字彙整了元件的平均應變和回應時間，卻無法呈現出導致輸出結果的原因。而程式設計師可以理解元件內部的狀態，他們可以透過隔離錯誤並找到解決方案。
有些企業管理者可能會希望轄區中擁有全能全知的技術人員，且最好還熟知整體的堆疊。某些企業或許不乏全才，但對不少企業而言，其所肩負的工作量太大，必須維護的程式碼量也過多。因此最好為 DevOps 人員和程式設計師找到最適的協同合作方式
一切都有點神秘
電腦或許是種徹底的邏輯機器，程式碼則以可預測的確定性方式進行演化。而出現的每一個錯誤都可以追溯出原因。我們可以利用除錯工具(debugger)、檢視日誌檔 (log file)、審查程式碼，但誰有時間呢？
就像針對有問題的裝置重新開機，可以解決掉 90% 的技術問題般，DevOps 人員也需要做同樣的處理。可以肯定的是，在運用「容器」和「實例」這類的名詞，並利用大量的儀表板以追蹤所發生的事，且最終繼續前進反而會更快速、更簡單，就如Iris Dement所唱的那首歌《讓神秘歸於神秘》(Let the mystery be)一樣。
