第三章 知己知彼
- 2022 年 10 月 6 日
- 筆記
- DevOps 流水環
知彼知己，百戰不殆；不知彼而知己，一勝一負；不知彼，不知己，每戰必殆。《謀攻篇》
前面兩章其實重點是在掰扯數智化，IT研發本身的數字化其實除了DevOps這一種手段之外還有很多，比如Low Code、RPA等等，AI都可以自動寫程式碼了，還有啥是不可能的呢！不過本人能力有限，這點斤兩也就敢玩玩DevOps，其他的碰都就不敢碰，接下來聚焦到DevOps的一些見解上。
3.1 劍鋒所指
作為雲原生重要組成部分的DevOps，跟雲原生一樣沒有標準定義，不同的大廠都會結合自己的實際給出不同維度的註解。綜合各家所言，我們可以重點提煉出DevOps的目標到底是什麼呢？
|
|
|
|
|
Atlassian |
DevOps 團隊包含了開發和 IT 運維，大家一起協作，共同參與產品的整個生命周期，一起為提升軟體品質和加速軟體開發過程而努力。 |
|
|
微軟 |
DevOps 是人、過程和產品的結合，使能持續地向終端用戶交付價值。 |
|
|
AWS |
DevOps 是文化理念、實踐和工具等的組合，能夠提升一個組織快速交付應用和服務的能力。 |
|
|
|
|
|
DevOps劍鋒所指何處？想必真正要玩DevOps的你心裡肯定有自己的小九九了，就不再贅述總結了，每個人都可以有自己的見地。
3.2 最佳實踐
多數情況下，開發的目標是快速發布更多的新特性，而運維的目標是保證更高的系統可用性。DevOps 通過切實可行的最佳實踐體系來拉齊這兩個目標，在提升系統穩定性的同時加速產品交付到市場的速度。
這個最佳實踐是什麼呢？顯而易見，就是形形色色的「無窮環」。
|
|
|
|
|
Atlassian |
|
計劃（Plan） 構建（Build） 持續集成和部署 監控和告警 運維（Operate） 持續回饋 |
|
微軟 |
|
計劃（Plan） 構建（Build） 持續集成 部署（Deploy） 運維（Operate） 持續回饋 |
|
AWS |
|
構建（Build） 測試（Test） 發布（Release） 監控（Monitor） 計劃（Plan） |
|
|
|
|
知彼部分是對《什麼是 DevOps？看這一篇就夠了！》（//www.danielhu.cn/what-is-devops/）的解讀，叫抄襲也行，還請原文作者多多海涵。
總結來講，最佳實踐都基本上指向了重要的三件套：(技術)工具、流程和文化。
文化轉變
結合「開發」和「運營」，「DevOps」一詞強調整合兩個團隊的活動以交付有效軟體。 也就是說，範圍不僅限於這些部門。所有參與軟體開發和交付的人員都需要一致推進向用戶交付有效軟體的共同目標。
DevOps 的核心是創造一種共擔責任、相互信任和開放溝通的文化。 對於開發團隊來說，在本地構建能夠運行不足以表明工作已經完成。 為了交付可用於生產的程式碼，開發者需要程式碼和發布間步驟的可見性。 這意味著打破孤島並與品質保證、安全和基礎架構團隊合作，以了解其在流程中的作用。
工具和自動化
雖然手動流程可以讓團隊間的合作更加緊密，但使用工具將儘可能多的工作自動化可以帶來更高效率。 構建、測試和部署步驟自動化可使工作得以更快完成，這也意味著可以更快得出這些階段的結果。 自動化是 DevOps 方法的核心，能夠實現緊密的回饋循環，這對於提高品質和消除浪費至關重要。
高效的流程
DevOps 出現在精益製造原則開始應用於軟體開發的時候。 精益的重點是通過優化流程中的每個階段、提高品質並營造尊重的氛圍來消除浪費。DevOps 融合了大部分這種思想，並優化端到端流程，通過緊密回饋循環對正在構建的內容儘早提供回饋，提高軟體開發效率。
這涉及更早地進行下游開發活動，並在發現問題後立即解決。無論是失敗的測試、安全漏洞還是構建問題。
由於每個人都要分擔向用戶交付軟體的責任，「在我的機器上能用」的陳舊回應已經不再適用。 使用 DevOps 方法，開發者可以更清楚地了解軟體的使用方式和出現的挑戰，從而更好地修正這些問題。
採用 DevOps 將敏捷的好處擴展到開發團隊之外。 適應開發者的節奏並以較小的規模工作，可以更容易地發現和隔離問題，因為只有較少的變數在發揮作用。 同樣，及時生成回饋可以避免在後續將棄置的測試和暫存構建上浪費精力。 反過來，這也將確保整個組織獲得以較小增量工作的全部效益
3.3 查缺補漏
當我們在說DevOps建設時，到底要建設什麼？說法千千萬，選擇自己偏信的信一信就行了，重點是結合自己所在境況，能夠落地的，才是有價值的。
梳理已有的能力，比起跟其他大廠或競品所標榜的能力來個開發常掛在嘴邊的「拉齊」，來個知己知彼，至少各種半年、年度總結啥的有點存貨可以拿出來講講。
以微軟定義的 DevOps 8大能力為例，做了個簡單的對照表，主要從工具、流程和文化三個角度進行。
持續計劃 Continuous Planning
|
開宗明義 |
從簡單雲以及雲效項目協作的功能來看，持續計劃其實更側重於於項目管理工具，基本上都是參考敏捷開發的主體思想，將IT研發迭代的工作流程、各工種協作、狀態流轉等整合進系統里。 類似功能的產品其實有很多，比如TAPD、Tower等。這些單純只是研發工作流程的資訊流轉，不能鏈接作用到最終運行在Linux的「程式碼服務」跟著流轉。比如，提測的時候把迭代分支程式碼，合併到測試分支，並且在測試環境發布本次變更。 持續計劃是DevOps的源頭，也是收尾處，這樣才能成環。 |
|
已有能力 |
Jira+Wiki,這應該是很多公司的標配了。 |
|
欠缺能力 |
工具其實沒啥好壞，真正有價值的是使用工具的人如何使用。工具夠用就行，最多就是使用不方便、操作不友好這一大堆。要是問題在使用的人不懂做做計劃、協調資源和控制進度，刀劍太鋒利只會誤傷人的手指。個人不是深度 持續計劃使用者，所以感覺不出來欠缺啥。之前主要使用過TAPD、Tower。 |
|
備選能力 |
沒調研，總之要私有化部署。公司的核心秘密不能放到別人機房。 |
|
個人理解 |
CP能力工具和文化的佔比都不大，重要的是流程。制定執行流程的人，才是核心。 |
持續集成 Continuous Integration
|
理解與說明 |
持續集成，簡稱CI，是軟體開發周期的一種實踐，把程式碼倉庫（Gitlab或者Github）、構建工具（如Jenkins）和測試工具（SonarQube）集成在一起，頻繁的將程式碼合併到主幹然後自動進行構建和測試。簡單來說持續集成就是向源程式碼/版本控制系統定期提交變更，以便每位成員都在同一基礎上構建。 每次提交都會觸發一個構建和一系列自動化測試，以驗證行為並確保所做變更沒有破壞任何已有內容。 最關鍵的是自動化測試，也是最難的。是後續「持續品質」重點解決的問題範疇。 |
|
已有能力 |
但就CI的工具來地主家的餘糧綽綽有餘，在容器化建設之前Jenkins、Sonar等等工具早都有的。流程層面本來就不是問題，將這些工具通過各種Action串聯起來。 自動化測試，也建設了專門的平台，而且還不止一個兩個，外採的、自研的各式各樣。 |
|
欠缺能力 |
看上去似乎是不缺什麼能力的，但是實際中也並不是那麼樂觀。這種「不科學」的時刻，得要往「文化」上想一想了。 |
|
備選能力 |
|
|
個人理解 |
CI能力，工具和流程都很容易信手拈來，極致體驗的使用的。重點在於得有這麼一個文化，讓研發和測試信服或者強制遵循。 |
持續交付 Continuous Delivery
|
開宗明義 |
鑒於CD既可以是Continuous Delivery又可以是Continuous Deployment，各種觀點和分歧最後可能就分不清楚了。所以個人建議不加以區分了，籠統的來講CD的能力，持續交付以由持續集成建立的構建和測試自動化為基礎，將持續計劃中的某個需求（泛指不僅僅是需求），從開發者到測試人員，再從測試人員到發布經理的交接，並最終把形成的「能力」發布到生產環境，交付給目標用戶。 不論是手動還是自動，也不管有多少個環境，CD的最終目標就是向終端用戶交付了價值。 |
|
已有能力 |
從18年開始的容器化建設，一開始就主攻的CD能力。部署自動化 |
|
欠缺能力 |
|
|
備選能力 |
|
|
個人理解 |
對於持續交付，資料太多、各家之言太雜亂反倒把最重要的部分給蒙蔽了。回歸到碼農的工作的本質，寫好程式碼，最終要給用戶「交付」一個東西（.exe///127.0.0.1:1024）。持續不斷的，能夠自動化的把寫好的程式碼，變成終端用戶可接受的那個「東西」，我覺得這就是CD了。 |
持續運維 Continuous Operations
|
開宗明義 |
監控、告警、日誌、鏈路追蹤；監控自動化、配置自動化、作業自動化、日誌分析自動化。 持續運維可減少或消除計劃性故障時間或中斷，例如計劃性維護。 如果可能，應將基礎結構、應用程式和服務的持續監視與自動化修正相關聯。 用戶應該永遠不會知道何時發生更新或增量發布。 |
|
已有能力 |
不論是人工手動，還是各種工具自動，公司再運維的投入比容器化是要大的。 |
|
欠缺能力 |
|
|
備選能力 |
|
|
個人理解 |
|
持續品質 Continuous Quality
|
開宗明義 |
構建可靠的自動化測試套件並在軟體交付生命周期中執行各種掃描、測試，從而提高軟體品質。 |
|
已有能力 |
程式碼品質掃描、測試覆蓋率、單元測試覆蓋率、Java項目標準化、靜態分析等等 |
|
欠缺能力 |
|
|
備選能力 |
|
|
個人理解 |
交付品質，單純的只有工具、流程建設肯定是不夠的；單純的只有測試人員也是不夠的。 |
持續安全 Continuous Security
|
開宗明義 |
DevSecOps 強調了將安全性納入軟體開發生命周期 (SDLC) 的重要性。 將安全性融入團隊的文化、流程和工具，可以避免孤島並確保快速交付不會以犧牲安全為代價。 |
|
已有能力 |
主要是6種安全掃描工具 GitLeaks\AWVS\Nuclei\IAST\Twistlock\奇安信安全掃描 |
|
欠缺能力 |
|
|
備選能力 |
|
|
個人理解 |
|
持續協作 Continuous Collaboration
|
開宗明義 |
持續協作是支援對任何 DevOps 之旅至關重要的文化轉變的做法。 持續協作使團隊能夠在計劃的會議範圍之外進行創新，並通過創建集成體驗來促進團隊內部的創新。可以使用技術和實踐分解孤島，即使沒有理想的共同位置，團隊也能一起工作。 從持續協作的角度回顧敏捷宣言，你將意識到，這實際上是關於進行協作和個人交互以實現真正的創新的價值。持續協作鼓勵你重視：①個人與交互勝過進程與工具；②有效用的軟體勝過全面的文檔；③客戶協作勝過合約協商；④響應變化勝過遵循計劃 |
|
已有能力 |
|
|
欠缺能力 |
|
|
備選能力 |
|
|
個人理解 |
|
持續改進 Continuous Improvement
|
開宗明義 |
連續且坦誠地觀察你的 DevOps 流程可使團隊能夠確定可能的改進點。所有的改進都需要改變，但並非所有的改變都是改進。 這就是為什麼度量對於使用 DevOps 的組織來說是成功的關鍵因素。 正如 Peter Drucker 所說，「如果無法度量，就無法改善。」 缺乏有效的回饋機制使得難以提高應用對業務的影響。 這就是為什麼有必要創建一個環境來促進以學習為中心的 DevOps 改進方法，並著重於基於數據進行調整。
|
|
已有能力 |
|
|
欠缺能力 |
|
|
備選能力 |
|
|
個人理解 |
|
3.4 結語
工具和能力都是散落的點，真正能體現水平的是如何形成良性的「無窮環」，如果覺得無窮太大了，那至少得是能夠「閉環」。
經過4年多的容器化建設，以及相關研發能力的完備，DevOps的8大能力基本上是具備的，現在重中之重是如何進行「包裝上架」。利用已有的平台，成體系的整合完備。
