3.3 持續學習與持續試驗

持續學習與持續試驗是企業不斷成長的動力，通過持續學習，組織能夠在知識技能以及經驗上保持競爭力，通過持續試驗可以保證系統的安全穩定，促進業務的不斷創新。依靠持續學習與持續試驗，團隊具有了快速適應不斷變化的環境的能力，市場是不斷變化的，唯一沒有變化的就是變化自身，這種適應市場快速變化的能力最終會幫助企業贏得一席之地。

3.3.1 通過內部與外部會議促進人員技術成長

舉辦技術會議或者論壇，既是經驗和知識的分享，也是持續學習的重要方式之一。很多企業在這方面都進行了實踐。例如，Nationwide Insurance從2011年開始創建學習型組織，其中包含名為“Teaching Thursday”的活動，每周都會舉辦一次，每次大約兩小時，在這段時間內，可以就感興趣的新技術、流程改善，以及如何更好地管理自己的職業規劃等進行學習和分享。

類似通過組織內部的技術會議促進學習和交流的實例還有：

● Capital One在2015年舉辦了第一屆內部的技術大會，超過1200名內部員工參加。

● Capital One內部的一些技術專家可以允許其他人去咨詢和確認問題。

● Target在2014年先后舉辦了6次內部的DevOps Days的活動，超過975名內部社區成員參與了這些活動。

● Google在2005年推動自動化測試時，舉辦了專門的改善活動，內部的指導者及內部的認證人員可以分享自動化測試的實踐經驗。

當然也可以在外部的技術會議（諸如 DevOps 大會）上分享經驗。在很多以成本為中心的組織中，常常不鼓勵技術人員參加外部技術會議。而要想創建學習型的組織，應該鼓勵技術者去參加內部或者外部的會議從而進行更好的學習。

DevOps Days就是當下一個影響比較大的自組織型會議，在這里，很多組織分享了它們的DevOps實踐經驗或者模式。雖然對于組織外部的分享，目前各種成熟度高的企業都比較冷淡，但是成熟度高的企業在整個組織內部分享經驗的比例更大，這體現了 DevOps 實踐在組織內部不斷復制和借鑒的過程。

創建學習型的企業文化使得每個人不僅能夠進行學習，同時可以分享自己的知識。在這個時代，每個人都應該是終身學習者，不應該為學習新的技術或者知識而感到恐懼、羞愧，這是學習型的組織文化需要保證的氛圍，一個好的方式就是從自己的同伴那里去學習。通過不斷學習內部和外部的知識與經驗，可以保證在技術上跟上業務系統發展的需求。

3.3.2 向生產環境中引入故障來增強彈性

通過在生產環境中嵌入“故障”來產生恢復能力是持續學習和持續試驗常見的手段，在前面我們曾經介紹過，Netflix通過彈性容錯的系統及服務降級的設計方案，保證了在故障發生時業務可以繼續進行。就像汽車的安全氣囊等技術那樣，通過預先設計和思考出現問題時的對策，保證了汽車在出現撞擊等問題時乘客的安全。軟件系統的設計也是如此，應當考慮到其發生故障時的應對方式，如果不進行故障應對設計，結果完全是不可預期的。除此之外，可以通過模擬的方式，在生產環境中引入模擬的故障，增強系統的彈性，以保證真正出現故障的時候不至于手足無措。

2014年，因為突發的Xen安全補丁問題，Amazon 10%左右的EC2服務器重啟。在Netflix的2700個以上的Cassandra節點中，218臺重啟，22臺沒有重啟成功。

而由于事前使用猿猴軍團工具進行了類似故障的模擬，所以基本沒有造成影響，具體的模擬方式是Game Days。

Game Days 實施的目的是幫助團隊模擬故障發生的狀況以便提前發現系統存在的問題，實施步驟如下。

步驟1：規劃一個災難性事件，如模擬整個數據中心的毀壞。

步驟2：給團隊時間用于準備，消除單點故障，創建必需的監控，以及容錯、排錯操作等。

步驟3：實施Game Days演習，盡可能地像發生真實故障那樣進行操作。

步驟4：確認問題，分析原因并應對，再次測試確認。

實施收益：執行Game Days演習可以使服務更具彈性，而且一旦發生問題，能夠為服務的恢復提供更高等級的保障。

除了Game Days，還有很多其他不同的模擬方式，它們大多都是通過直接在生產環境中進行故障插入以增強系統彈性的，比如Google的DiRP（Disaster Recovery Program，災難恢復系統）會模擬演習硅谷發生地震及數據中心停電等情況來確認服務的連續性。

3.3.3 持續學習與持續試驗的建議

本部分將介紹持續學習與持續試驗的建議。

建議1：預留時間用于組織學習和改進。

根據很多公司的實踐經驗，預留出20%的時間用于個人與組織的學習和改進能夠起到很好的作用，很多互聯網公司的創新性主要功能都來源于這段時間的有效利用。

比如Facebook的HipHop編譯器就是在Hack Day活動中產生的，而如果沒有這預留的用于改進的時間，可能就不會有HipHop編譯器。2008年，伴隨著活躍用戶的快速增長，Facebook面臨著一個嚴重的性能問題。在一次 Hack day 活動中，Facebook 的高級工程師趙海平嘗試將PHP代碼轉化為C++代碼以提高效率，并在接下來的兩年內，創建了一個小型的團隊用于開發HipHop編譯器，將PHP代碼轉化為C++，最終的效率比原生的PHP提高了6倍。

后來，有幾個工程師覺得他們可以設計出比 HipHop 編譯器更優秀的工具，而且能夠減少對開發者的影響，于是就創建了一個名為HHVM（HipHop Virtual Machine）的虛擬機項目，之后，HHVM取代了HipHop編譯器。

建議2：鼓勵適當的冒險。

在確保試驗不會帶來災難性的影響的前提下，應鼓勵員工適當冒險，雖然這些操作可能會對生產環境造成一定的影響，但是這會使得系統更好地進化，因此應對其予以鼓勵和支持。

建議3：將償還“技術債務”的行為定期化。

技術債務（因時間、難度、成本等原因而未完成的技術任務）會對系統造成很大的影響，而技術債務也不是一次清除就可以徹底消失的，隨著系統的不斷更新，新的技術債務將不斷增加。定期償還技術債務同償還財務上的債務一樣重要，只有定期審視和償還技術債務，才能保證系統的穩定和可擴展等特性。

建議4：推動快速改善活動。

為了保證開發團隊和運維團隊有時間進行諸如非功能性需求或者自動化的實踐，可以規劃和執行數日或者數周的改善活動，讓團隊自組織地去解決他們所關心的問題，問題可以是代碼、環境、架構、工具等相關的內容。通過這種方式能將開發團隊、運維團隊、信息安全團隊的精力和知識結合起來，對選中的某個特定問題進行改善和演示，從而將積累的改善擴展到整個組織。

將改善集中到日常工作中，其實非常簡單。

步驟1：選擇一個時間段（如一周）讓開發團隊和運維團隊一起對所選擇的目標進行改善。

步驟2：演示所改進的內容并進行進一步的討論。

這種方式會強化跨團隊交流溝通的文化，同時可以發現和消除日常工作中的問題以降低產生技術債務的風險。