3.2 以高度信任為基石的企業文化

創建對失敗友好的架構與環境為企業文化的推行提供了整體保障，在此基礎上進行企業文化建設會更加順暢。

良好的企業文化的最終目標是，能夠促進企業盈利和提升交付能力。在創建適應企業自身的DevOps文化方面，敏捷和精益管理、持續集成和持續交付都是其重要基石。而精益的實踐，我們可以在制造業中獲得很多經驗。

（1）制造業的變革

讓我們把目光投向20世紀80年代制造業的那場變革上。通過踐行精益原則，制造業的生產效率顯著提升，交付時間降低，產品質量及客戶滿意度提高，成功的企業在殘酷的市場競爭中贏得了一席之地。

在這場變革開始之前，制造行業的產品平均交付時間為6周，而且只有少于70%的訂單能夠按時交付。而到了2005年，隨著精益實踐的廣泛推行，制造行業的產品平均交付時間已經少于3周，而且95%的訂單能夠按時交付。

（2）軟件行業的變革

20世紀七八十年代，大多數項目需要一到五年才能完成開發和部署，并且經常伴隨著極其高昂的成本，而失敗則會帶來極其嚴重的影響。

隨著敏捷管理思想的踐行，新功能的開發周期已經縮短為幾個月甚至幾周，但是從部署到生產仍然需要數周甚至數月，而且經常還會伴隨著災難性的后果。隨著軟件和硬件的不斷升級，實施永不停息的服務成為可能，云計算更是提供了彈性擴容、縮容的能力，使得業務和資源的投入能夠更緊密地結合起來。包括云計算在內的諸如物聯網、區塊鏈、人工智能等技術對軟件的開發測試部署和交付提出了更高的要求。

DevOps 的引入更是使得這些需要部署到生產的服務變成了以小時甚至以分鐘計的常規操作，很多企業在這輪變革中已經先行。借助DevOps，這些企業甚至能夠在實際的環境中先行驗證它們的創意，以確認哪些創意能夠帶來最大的效益，并以此來決定所要開發的功能，而這些功能最終將非常安全地被部署到生產環境之中。

互聯網行業的競爭異常激烈，究竟什么樣的企業文化更適合DevOps？以下將結合制造業的經驗及一些企業的實際經驗進行說明。

3.2.1 傳統制造業的懲罰文化

很多企業宣稱，信任是企業文化中的重要組成部分，那么高度信任到底應如何貫徹？這是一個非常難以回答的問題。但反過來看，對于完全不信任員工的企業，執行信任的方式則非常簡單，因為可以相信的只有規章制度，不遵守即嚴懲，這似乎并沒有太多問題。而制造業同樣有很多經驗可供我們借鑒，讓我們再次把目光轉向制造業。

在傳統的制造業中，工作內容被嚴格地定義，作業者必須遵從，他們基本無法從日常工作中學習并成長，更不可能將學到的內容或好的想法集成到現行系統中。對企業來說，個人完全就是工業時代舞動的扳手，個人對企業自然也漠不關心，冷漠是整個文化的主基調。

在這種環境中，除了冷漠，往往還包含另外兩個字：“罰”與“怕”。前者是企業行為，后者是員工心理，兩者共同構成了這種文化的主基調。企業有這種想法也很正常，出了問題的員工被懲罰確實合情合理。拋開容易引起爭論的“應該怎樣做”的話題，在這種情況下，從同理心的角度出發，一般有兩種情形十分常見。

● 第一種情形：因為害怕被懲罰，出了錯的員工可能會做兩件事情，首先是瞞，能瞞多久就瞞多久；其次是推脫，瞞不住的時候開始找各種理由推脫，各種“背鍋俠”紛紛涌現。

● 第二種情形：那些指出問題或者提出好建議的員工容易被孤立，因為他們被視為“麻煩制造者”。能夠提出好建議是因為這些員工發現了目前做得不好的地方，做得不好就要被罰。提建議者被孤立，容易造成其他人的困擾，盡管大家都明白“孤立”的做法并非理性。

不可預測性是復雜系統的重要特點之一。成千上萬種的可能性使得我們無法應對復雜系統可能出現的問題，即使我們在工作中已經謹小慎微，依然不能精確地判斷變更會帶來好處還是帶來災難。

一旦問題發生，我們會立即去尋找原因，而通常的原因是“員工的失誤”，通常的解決辦法也是對員工進行懲罰。做錯事的人被懲罰是合乎情理的，為了防止類似的錯誤繼續發生，一般會增加審批的程序。在項目中還可以增加一種叫作checklist的列表，修改一行代碼可能需要確認1000行的checklist才能確保代碼從設計到編碼規范、測試質量、整體性能、科技人文和企業利潤等不會受到影響。可惜的是，在大部分項目中這種方法似乎不是很奏效。

而這種懲罰的方式所帶來的后果則是，它會使得那些容易出錯的員工更加恐懼而不是更加仔細，整個組織也會變得更加官僚化，“自我保護”現象也會變得更加常見。

“懲罰文化”大行其道給員工帶來了恐懼情緒，當問題出現或者出現征兆的時候，甚至到災難發生的那一刻，員工的做法常常是視而不見。而這一點也得到了2018年DORA調查報告的支持：企業最高管理層比團隊成員對 DevOps 進展更加樂觀。而這份樂觀很大程度上來源于我們討論的“懲罰”與“害怕”文化所導致的信息無法自下而上完整傳遞，信息傳遞過程中可能存在“過濾”和“消毒”，導致阻礙進程的問題及瓶頸都無法被真實地看到。企業最高管理層對現狀的認識是不完整的，所以在某些數據上顯示出了和團隊成員之間的較大不同。例如，在關于安全團隊是否介入了設計和部署過程的問題上，管理層中有64%持肯定看法，而團隊成員中則只有39%持肯定看法，這是需要認真對待的。

科技是第一生產力，而技術的提升需要不斷地學習、需要試錯。企業文化的作用就是創建一種高度信任的寬松環境，使得員工敢于也甘于通過持續學習來促進自身成長，而這個過程就在日常瑣碎的工作之中進行，因為要進行試驗，自然會有風險，如果沒有高度的信任，是難以做到的。通過試驗，會知道哪些流程或者知識能夠在實際的生產環境中奏效，哪些沒有效果。有想法的員工將自己的想法付諸實施之后，自然也會判斷哪些可能有用哪些不正確。而且，經驗的分享和全局利用也是文化的重要組成部分，如何將較好的實踐經驗推廣到整個組織，也是企業文化需要考慮的事情。

3.2.2 聚焦改善的免責事后分析

在一個高度信任的組織中，除個別員工自身確實存在誠信問題外，很多管理人員都認為員工所犯錯誤的真正根源在于所使用的工具。相對比地，傳統的企業文化是揪出“害群之馬”對其進行懲罰。而更好的處理方法則是將其視作學習的機會。

一旦員工在所犯的錯誤上感到安全，他們就會有意愿改正錯誤，甚至還會熱情幫助公司的其他成員，以避免他人再犯同類錯誤。這樣可以將免責的事后分析流程作為持續學習探索的開始，從而不再聚焦于“懲罰”，而聚焦于如何進行改善。

這里使用Netflix的一個案例來進行說明，一位在18個月內使Netflix宕機了兩次的工程師，未受懲罰并仍被企業重用。因為這個工程師使得系統能夠安全地部署，并完成了極大數量的生產環境部署，他為公司帶來的價值非常之高。

2014 年 DORA 的 DevOps 研究報告同樣給出了數據上的支持。該報告指出，高績效的DevOps組織犯錯和失敗的次數更多。這是可接受的，也是組織所需要的，比如高績效組織的效率是低績效組織效率的30倍時，即使失敗率只有低績效組織的一半，他們失敗的次數仍然遠遠大于低績效組織。

對失敗友好的架構與環境，因為具有彈性，因此可以包容一定程度的失敗，這就給予了DevOps實踐在基礎架構上的保障。而允許適當風險和失敗的企業文化則將失敗視作持續學習的機會，不會過度聚焦于對犯錯員工的懲罰，這種氛圍會使員工更能坦言自己的行為，甚至過失，因為這是一次組織改進的機會。在這樣的基礎之上進行聚焦并改善問題的事后分析會事半功倍。

為了做好問題的事后分析，在問題解決之后要召開事后“免責分析會議”，最好在大家的相關記憶還沒有消失的時候進行。這樣的事后免責分析會議一般有以下主要原則。

● 設定時間限制，從不同角度獲取相關的詳細信息，確保不會因犯錯而懲罰員工。

● 鼓勵犯錯的員工成為相關專家，以幫助和教育組織其他成員不犯同樣錯誤。

● 提出預防同類問題再次發生的應對措施，確保問題有負責人，并將應對措施在目標日期內記錄下來。

為了達到更好的效果，參加會議者可以包括如圖3-4所示的成員。

從圖 3-4 中可以看到，參加會議的包括發現問題者、響應問題者、故障診斷者、問題影響人、可能對問題解決有幫助的人及有興趣參加會議的其他任何人，這就保證了問題分析的全面性，進行事后免責分析的要點如下。

（1）做記錄，包括問題發生的時間、采取了什么舉措（最好能在諸如IRC或者Slack等工具的聊天記錄中進行管理）、觀察到了什么樣的結果（最好能夠在生產環境的監控指標中進行確認）、進行了什么樣的調查、考慮到了哪些應對方法。

（2）注意事項：確保成員不會擔心被懲罰，要在免責的方式下進行，避免使用“本來可以”“本來能夠”等表述方式；避免員工過度自責，要將問題聚焦到“當時為什么覺得采取那個舉動是自然而然的”上；避免“認真一點”“聰明一點”等不具可操作性的應對措施；避免從“明天的我們一如今天一樣愚蠢”這樣的角度去考慮應對舉措。

（3）公開事后分析結論，為了使整個組織都能從中學習獲益，在事后免責分析會議結束之后需將結論在組織內部進行公開。

3.2.3 多角度的知識與經驗分享

對于企業來說，知識和經驗是重要的組織資產。當下，知識和經驗的共享已經變得非常重要，而且共享的過程也可以通過各種方式來實現，如圖3-5所示。

1.盡可能地進行內部信息的共享

包括事后免責分析會議的記錄與結論在內，盡可能地進行內部信息的共享能夠快速地分享知識和經驗。例如，Google的員工對公司內所有的事后分析文檔都可以搜索查看，當同類問題發生時，這些文檔會最早被研究和比較。

當然，當共享的內容非常多的時候，在整個企業內部一定會積累大量的記錄信息，堆積在Wiki或者相關的知識共享平臺上。我們需要意識到共享信息的獲取和操作的便捷化也會直接帶來良好的效應，使用新的工具或者自行開發相關的、適應自己企業的平臺都是值得的。例如，Esty公司就遇到了進行大量信息共享時效率低下的問題，于是開發了一款名為Morgue的工具，用它來記錄每一個事件的重要因素，如平均修復時間和嚴重程度等。使用 Morgue 可以使相關信息更容易被記錄，比如：

● 問題發生的原因（定期操作或非定期操作引起的）；

● 事后分析的負責人；

● 相關IRC（Internet Relay Chat）工具保存的聊天記錄；

● 相關Jira（Atlassian公司的項目管理工具）的任務單；

● 相關客戶的事件報告信息。

Morgue的開發和使用使得對嚴重等級稍低的問題（P2、P3、P4）的事后免責分析記錄越來越多。這證明了如果有類似 Morgue 這樣方便的工具用于管理事后免責分析結果，員工會更多地記錄結果，能更好地促進組織的學習。盡可能地進行內部信息的共享，同時使用適合自己企業的工具，在知識和經驗的積累方面能起到很好的作用。

2.結合工具進行進一步的集成（ChatOps）

DevOps有一個分支被稱為ChatOps，可以通過即時聊天工具（如聊天機器人）集成自動化操作工具，在保證了工作透明性的同時，又能記錄實際的文檔（聊天記錄）。

ChatOps 還能間接起到分享的作用。比如，即使是團隊的新成員，也可以通過查看聊天記錄來了解一些事情是怎么完成的，就好像一直在和聊天記錄里的人員進行結對編程一樣。通過這種方式，可以獲得多種收益，相關收益羅列如下。

● 透明性：每個人都能看到所有發生的事情。

● 培訓：第一天上班的工程師能看到日常工作是怎樣的，以及是如何實施的。

● 協作：當人們看到其他人在相互幫助時會傾向于同樣發出求助，這有助于團隊間的協作。

● 文檔化：相較于郵件，信息更容易被記錄和共享。

● 虛擬團隊的知識分享：如果很多工程師都在不同的城市，使用聊天室能更好地推動知識的分享。

● 快速地幫助：通過快速問答和信息全體可見進行知識的分享。

GitHub曾聲稱，Hubot是自己企業最忙碌的員工，而Hubot正是這樣一個強大的聊天機器人。GitHub可以利用Hubot進行自動化集成和信息分享，如圖3-6所示。

Hubot用于集成自動化操作工具，這些工具包括Puppet、Capistrano、Jenkins、Resque、Graphme等。通過集成這些工具，Hubot不僅可以實現信息的共享和團隊的協作，還可以實現更多操作，比如：

● 檢查服務的健康狀況；

● 進行Puppet操作；

● 部署代碼到生產環境；

● 系統進入維護模式后進行警告通知；

● 當部署失敗后取得“冒煙測試”的日志；

● 源代碼提交信息的顯示；

● 觸發生產環境部署信息的顯示；

● 部署流水線執行導致的狀態變化的顯示。

3.進行技術棧的標準化

復雜的系統往往使用了很多的技術，對那些被維護了較長時間的大型項目來說，這是十分常見的事情。多種操作系統、多種編程語言、多種框架、多種中間件、多種硬件設備共存的情況使得整體的應用架構非常復雜。而這往往會極大拖慢 DevOps 實踐的進度，僅自動化推動方面也會遇到非常大的阻礙，降低整體復雜度對這種系統來說已是當務之急。

在2018年的DORA的研究報告中也明確指出了構建標準化技術棧的重要性，很多人認為自動化應該是最初的切入點。而實際上如果事前的準備工作沒有做好，直接切入自動化，很多時候這種急功近利的期望并不一定能夠得到滿足。因為在一個技術棧非常復雜的情況下，自動化本身將會變成一個不可控的需求，而如果不對這種復雜技術棧進行控制，后續的投入很有可能會大幅增加。所以規范化整體的技術棧更多的是為了簡化系統，降低依賴，正所謂磨刀不誤砍柴工。

在很多 DevOps 實踐的項目中也是如此，雖然會將自動化作為一個很重要的目標，但還是要對整體的流程、可改善的環節、改善的計劃和重點、技術架構進行討論，明確并降低系統整體的復雜性，以期能夠持續穩定地投入并獲得持續穩定的回報。

構建規范的技術棧，不應局限于某一個應用或者某種服務，而應著眼全局，從整體角度進行考慮。對技術棧進行規范化和標準化，從長遠來看會取得很好的效果。但是對于擁有復雜度很高的老舊系統，確定如何實施才是關鍵所在。影響太大、改動成本過高往往是對老舊系統技術棧進行標準化的阻礙。構建標準化的技術棧勢在必行，但是如何實施，以什么樣的規劃實施才是首先需要考慮的。

之所以把標準化技術棧作為知識和經驗分享的一個重要方式，是因為它不但對構建整體架構具有指導作用，而且由于復雜度的降低可使壁壘大幅度減少，溝通的效果會明顯改善。隨著技術棧的簡化，往往在成本方面諸如各種授權費用或版權費用也會有所降低。例如，對于整體的技術棧來說，Google 提倡使用一種官方編譯語言，一種官方腳本語言，一種官方 UI 語言，緊跟這“大三樣”，既能保證得到庫和工具的支持，也能更容易地找到協作者。

4.單體共享源代碼倉庫

當企業規模很大的時候，其擁有的系統往往也很多，而這些系統有可能使用了相同的框架，比如Java的Web開發框架Spring Boot。如果不同的系統能統一使用相同的版本，同時框架有專人負責，那么一旦出現安全問題，或者需要升級版本，整體使用單一的共享源代碼倉庫來進行管理可以使知識和經驗的積累更加有效。但是在實際的企業中，很難做到統一共享源代碼倉庫，這些企業往往有多個源代碼倉庫，以及不同的框架和版本，升級和安全問題也難以統一管理。由組織級別創建單一的共享源代碼倉庫，能夠很好地推動知識的分享。

雖然這看起來很難做到，但以Google為例，在2015年，Google用單一的共享源代碼倉庫管理著超過10億個文件和20億行代碼，超過2.5萬名工程師在使用這一倉庫。

Google的眾多核心功能在此倉庫中被管理著，包括：

● Google搜索；

● Google地圖；

● Google文檔；

● Google+;

● Google日歷；

● Gmail;

● YouTube.

共享源代碼倉庫中不僅保存源代碼，同時還管理著其他內容，比如：

● Chef recipe或者Puppet manifest這樣的有關基礎框架和環境的配置標準；

● 部署工具；

● 包含安全在內的測試標準；

● 部署流水線工具；

● 監控和分析工具；

● 教程文檔。

Google所有的庫，諸如OpenSSL或者Java線程都有專門的負責人，可以保證此庫不僅能通過編譯，還能通過所有的相關測試。同時，當版本升級也由該負責人負責。Google正是通過這樣的方式，保證了知識和經驗分享的順暢進行。

5.結合自動化測試和社區活動擴展知識

為了將知識和經驗擴展至整個組織，還可以采用自動化測試和社區實踐的方式。這聽起來會有點奇怪：自動化測試為何能夠作為知識擴展的方式？在組織級別往往有一些共享的庫文件，若想使用這些共享的庫文件則需要進行信息的共享。而使用共享的庫文件的前提是確保這些庫都有大量的自動化測試。如果結合一些工具或者在測試的時候考慮到分享的因素，就可以將這些測試用例直接做成可供用戶學習的文檔。例如，工程師可以通過確認測試用例去探索如何使用REST API，這時結合Swagger等工具往往更為方便。往往這種情況都伴隨著TDD（Test Driven Development，測試驅動開發）實踐的發生，在理想情況下，每個庫都有一個負責人或者負責的團隊，另外在生產環境中只允許一個版本被使用，這樣能確保組織級別中共享知識和經驗，基于TDD的自動化測試也能在組織內擴展知識。

關于社區實踐，可以對每一個庫或者服務創建討論組或者聊天室，在這樣的環境下，提問者得到的回答往往來自其他使用者而不是該庫的負責人或者開發者，通過社區實踐，使用者能夠相互幫助，從而更好地在組織內進行知識的擴展。