《DevOps實踐指南》前言

• 2019 年 12 月 10 日
• 筆記

《DevOps實踐指南》前言

介紹

• 在訪談了『DevOps之父』Patrick Debois之後，我深刻地理解了『DevOps is the Human Factor』這句話的真諦
• DevOps更多的是實踐而不是角色
• 通過「三步工作法」鋪平流程，選擇合適的切入點，根據康威定律調整組織、持續交付、自動化、運維改善等
• 「基礎設施即代碼」（infrastructure as code）理念
• 運維人員的工作模式可能會變得像開發人員一樣，他們必須在源代碼控制系統里維護系統的配置，並在工作中使用持續集成/持續交付（CI/CD）的模式

常見誤區

• 誤區1：DevOps只適用於創業公司。他們所遇到的問題和傳統企業相比並無二致：軟件的高風險代碼容易導致災難性故障，無法快速發佈新功能來擊敗競爭對手，存在安全合規性問題，服務無法擴容，開發和運維彼此高度不信任等
• 誤區2：DevOps將取代敏捷
• 誤區3：DevOps與ITIL不兼容。許多人認為，DevOps與1989年發佈的ITIL（Information Technology Infrastructure Library，IT基礎架構庫）。DevOps實踐可以與ITIL流程兼容。然而，為了支持DevOps所追求的更短的發佈周期和更頻繁的部署，ITIL流程的許多方面需要完全自動化
• 誤區4：DevOps與信息安全及合規活動不兼容。集成到了軟件開發生命周期的每一項日常工作中，因此會得到更好的質量、安全性和合規性
• 誤區5：DevOps意味着消除IT運維，即「NoOps」。許多人錯誤地將DevOps解釋為完全消除IT運維的職能，然而，這種情況是很少見的。通過這種方式，IT運維人員變得更像是開發人員（或者QA和信息安全人員），融入到了產品開發過程中，而該產品則是開發人員在生產中用來安全快速地測試、部署和運行IT服務的平台
• 誤區6：DevOps只是「基礎設施即代碼」或自動化。但是DevOps還需要文化規範和架構，以便在IT價值流中實現共同的目標
• 誤區7：DevOps僅適用於開源軟件。但實現DevOps與所使用的技術無關

導言：展望DevOps新世界

• 產品經理、開發人員、QA人員、IT運維人員和信息安全人員互相幫助，齊心協力，整個公司的業績蒸蒸日上
• 「技術債務」這個術語是Ward Cunningham首次提出的。類似於金融債務，技術債務是指我們當前所做出的決定會導致一些問題，而這些問題隨着時間的推移會越來越難解決，未來可採取的措施也越來越少。即使我們審慎地承擔技術債務，也依然會產生利息
• 開發部門通常負責對市場變化做出響應，以最快的速度將新功能或者變更上線。而IT運維部門則要以為客戶提供穩定、可靠和安全的IT服務為已任，讓任何人都很難甚至無法引入可能會危害生產環境的變更。這種配置方式讓開發部門和IT運維部門的目標和動因之間存在巨大的衝突
• 公司對不同部門的考核和激勵不同，阻礙了公司全局目標的實現
• 這些長期衝突常常導致技術工作者交付出質量低劣的軟件和服務，打造出糟糕的客戶體驗，每天都要採用臨時解決方案、應對緊急情況

惡性循環三部曲

• 第一部曲：我們日常工作中的很多問題源於應用程序和基礎設施過於複雜、異常脆弱、文檔不完備。更令人擔憂的是，我們最脆弱的組件正支撐着最重要的業務系統或者最關鍵的項目
• 第二部曲：某個產品經理承諾了一個更大規模、更大膽的吸引客戶的功能，或者是業務主管設置了一個更高的收益目標。又導致了技術債務的增加
• 最後一部曲：所有事情都變得更加困難——所有人都越來越忙，工作所消耗的時間越來越多，溝通變得更加緩慢，工作積壓得越來越多

為什麼惡性循環無處不在

• 企業領導者想要實現業務目標，對有效IT管理的依賴程度遠遠超出了他們的預想

成本：人和經濟

• 對於我們的員工而言，這意味着長時間工作、周末加班、生活質量下降，而且影響的不僅僅是員工，還有所有依賴他們的人，包括他們的家人和朋友。當這種情況發生時，我們失去最好的員工（除了那些因為責任感和義務而覺得不能離開的人）也就不足為奇了
• 2011年，約5%的全球GDP（即3.1萬億美元）用於IT（含硬件、服務和電信）。如果我們估計這3.1萬億美元中的50%用於運營成本和維護現有系統，而且這50%的三分之一用於緊急和計劃外工作或返工

DevOps的準則：總有更好的方法

• 通過在流程中的每一個步驟創建快速反饋迴路，每個人都可以立即看到工作效果
• 自動化測試可以幫助開發人員快速發現錯誤（通常在幾分鐘之內），實現更快速的修復以及真正的學習。如果錯誤是在6個月後的集成測試中發現的，那時相關的記憶和因果關係早已消退
• 想要讓新功能生效，我們只需要改變一個功能開關或者配置項即可，而不再需要經曆數天或者數周的辛苦工作。這個小變更使新功能對更大規模的客戶群可見，一旦出現錯誤，就會自動地回滾。因此，發佈新功能變得可控、可預測、可逆，且壓力也小了
• 在出現問題時，我們進行不指責的事後分析，這並不是要懲罰某人，而是為了更好地理解導致事故的原因，以及如何防止事故再次發生。因為注重質量，所以我們甚至會故意在生產環境中注入故障，從而了解系統是怎樣以預期方式發生故障的

DevOps的業務價值

• 應用了DevOps的高績效公司在以下方面的表現遠超低績效同行
  • 吞吐量指標；
  • 代碼和變更部署次數（頻繁30倍）
  • 代碼和變更部署前置時間（快200倍）
  • 可靠性指標
  • 生產環境部署（變更成功率高60倍）
  • 平均服務恢復時間（快168倍）
  • 組織性能指標
  • 生產力、市場份額以及營業目標（大約2倍以上）
  • 市值增長（3年內高出50%）
• 換句話說，高績效者要更加敏捷和可靠

DevOps有助於提高開發人員的生產力

• Frederick Brooks在其著名的《人月神話》一書中強調過這一點。他解釋說，當項目延遲時，增加更多的開發人員不僅降低了單個開發人員的生產力，而且也降低了整體的生產力
• 另一方面，DevOps證明了在擁有正確的架構、技術實踐和文化規範的情況下，小型開發團隊能夠快速、安全、獨立地開發、集成、測試和部署變更到生產環境

• 圖展示了在團隊人數增加時，低績效公司每個開發人員每天的部署次數在降低，中等績效公司維持不變，而高績效公司則線性增加
• 在應用了DevOps的企業中，在開發人員數量增加時，每天的部署次數呈線性增加趨勢；谷歌、亞馬遜以及Netflix已經做到了
• 另一個更加極端的例子是亞馬遜。2011年，亞馬遜每天部署近7000次；到2015年，他們每天要部署130 000次

書籍

• 《持續交付：發佈可靠軟件的系統方法》
• 《目標：簡單而有效的常識管理》——精益製造運動中最有影響力的圖書之一
• 《鳳凰項目：一個IT運維的傳奇故事》