作者簡介
於洪奎 中國銀行軟件中心高級經理， 系統分析師、CCEP、CSM、DevOps Master 14年軟件開發相關經驗，其中9年開發管理經驗
以下爲於洪奎老師在 DOIS 2018 · 北京站的分享整理而成。
我來自中國銀行軟件中心的一個開發部門，中國銀行軟件中心從 2013年開始試點敏捷軟件開發以及相關CI、CD等實踐，而我們內部真正的提 DevOps 比這個要更晚些。
中國銀行的 DevOps 涉及的產品線和技術棧衆多，下面的分享並不能完整的給家介紹中國銀行整個 DevOps 的做法，只會包括與 X86 相關的部分產品的 DevOps 實踐情況。
我的分享主要包含以下四方面內容：
第一，和大家一起了解一下，這個題目中所謂的“器用”和DevOps，“器用”到底是什麼？
第二，和大家一起分享一下我們的 DevOps，什麼叫做我們的 DevOps 呢？就是我們在踐行 DevOps 的時候的工具選擇和一些整體上的思考，這裏並不是說我們的做法就是最好的，只是和大家分享一下我們的做法，所謂，它山之石可以攻玉，拋點“小石子”供大家參考。
第三，分享一些我們認爲自己做的比較成功的東西，一方面給大家Show一下，另一方面，也增加一下同業在踐行 DevOps 時的信心，有些東西不僅僅是互聯網公司可以做到，其實，我們金融企業、大型銀行，也是可以做到的。
第四，分享幾個我們“失敗的教訓”，我們常說“來，說點不開心的，讓大家開心一下”，這個也是讓大家一起開心一下，反思一下。所謂“失敗是成功之母”，但是，僅僅有“失敗”是不夠的，最重要的是失敗之後的學習和反思。
一. 器用與 DevOps
首先，跟大家分享的就是這張圖，這張圖是開發著名敏捷管理工具 Jira 的Atlassian 公司的 DevOps 成熟度調研網站的入口，網址是：https://www.atlassian.com/devops/maturity-model。
爲什麼和大家分享這張圖呢？我認爲這張圖裏面的關於 DevOps 描述，比較好的表達出了：我們去看 DevOps 這個詞的時候，你到底希望得到什麼？
我們大家現在都在做DevOps，前段時間都在搞敏捷，我相信我們很多人必定思考過，我們做這些到底是爲了什麼？而從這張圖裏面，有兩個詞非常的吸引我，比較清晰的表達出了，我們到底希望從DevOps中獲得的內容，就是：“frequent” 和 “reliable” 。我們做DevOps歸根結底，就是希望更“高頻”、更“穩定”的來發布我們的軟件應用產品，這個地方給大家講兩個小故事。
第一個小故事，我在去年的時候給我們總行的某業務門部發了一個匿名的調查問卷，這個問卷裏面的內容很簡單，您認爲我們作爲中行的軟件開發部門，我們在哪些方面最應該得到提升？
第一個是我們的交付不夠快，我們應該更快的交付；第二個是我們交付的不夠多，我們應該做更多的交付；第三個是說我們交付的質量差，我們應該提升交付的軟件的質量；第四個是我們開發成本高，同樣的開發內容我們報價貴，我們應該降低自己的開發成本；第五個是我們交付的軟件安全性差，我們應該提升交付的軟件的安全性。我把這五點簡稱爲：多、快、好、省、安。我把這五項給我們的業務同事們讓他們選一選，最多讓選兩項。最後得到的結果是什麼呢？得到的結果是90%以上業務同事的都認爲我們現在慢，我們應該更快的交付。
我們經常有人說，我們金融行業與其他行業有很大的不同，我們不是互聯網，所以，我們的敏捷和 DevOps 也應有自己的特色，這一點我完全同意。但是，有特色，不是說脫離本質。
我們金融行業做 DevOps 不能僅僅學互聯網、照搬互聯網公司的做法，但是“你首先學互聯網，學會互聯網的快”。
我一直一來有一個觀點：所有不能讓企業變快的敏捷和 DevOps 都是耍流氓，你去做 DevOps 和敏捷，首先你要能夠快起來。當然，這個快要是可持續的快，是穩健的快。
第二個小故事，就在前幾天，我們和質量部門、測試部門同事一起做了一個敏捷測試沙龍，大家都說我們敏捷之下質量得到了“提升”。我就問大家，我們踐行敏捷之後質量真的提升了嗎？那麼和傳統的開發比，我們到底有了哪些方面的提升？大家都會心的笑。
其實和採用傳統開發方法的部門和產品團隊相比，採用敏捷方法的開發部門和產品團隊的軟件交付質量並沒有提升，最起碼從我們內部的數據來看是這樣的。
敏捷並沒有提升我們軟件產品的交付質量，甚至，你們發現，當我們一開始做敏捷的時候，我們的交付的確開始變快了，但是，我們的交付質量變差了，這不是感覺，是有數據支撐的。
但是，隨着時間的推移，敏捷產品的交付質量在逐漸的，明顯的提升，有的已經接近了傳統開發方法下的交付質量水平，這個也是有數據支撐的。這其實並沒有什麼大驚小怪的，早就有變革曲線模型對此進行解釋，管理大師彼得·聖吉也說：先變差，再變好。
通過這兩個小故事，我認爲這個非常好的詮釋了我們對敏捷和 DevOps 的訴求，無論是從我們的業務方，還是我們自身，我們都希望更高頻、更快的交付我們的軟件產品，但是，這種交付也要是高質量的、穩健的。
經常有人說：敏捷和 DevOps 不是快。我認真這句話不準確，我比較贊同的一個準確的說法是：敏捷和DevOps不僅僅是快，但是，首先要快。
說到 DevOps 的時候有幾個概念，大家可能也都比較瞭解，比如敏捷、精益。我這裏想分享一下，從狹義上講，這幾個概念之間的關係是什麼樣的。首先，從廣義上說，敏捷也好，精益也好，DevOps也好，從來都不承認它只關注一段，都說自己是端到端貫通的，典型的 DevOps 有無窮環，精益也沒有說它不管後面，敏捷也沒有說它不管前面。我這裏是從狹義上說，我第一次聽這個觀點是來自光環的李健昊老師，從狹義上說，這幾個概念在我們的開發過程中就是下圖這個樣子的。
我這個圖總結爲：精益更聚焦於把事情做對，敏捷更聚焦於把事情做快，而DevOps 更聚焦於把事情做暢。說到精益給大家推薦兩本書，一本是《精益創業》，還有一本是《精益數據分析》，從精益的角度上來說，通過學習、構建和反饋過程來不斷地探索商業價值和尋找商業價值，就是在不斷的探索和尋找那個“對”的價值點。這裏的“精益”其實與當初“精益生產”中的精益，已經有所不同了。
敏捷大家都知道，它從源頭上是一幫開發的大師發起的，他們本質上更關注的是“探尋更好的軟件開發方法”，他們一開始也說我們要交付客戶價值、交付可工作的軟件、響應變化，他們沒有說我對其他的不關注。
只是從本源和狹義上看，敏捷更多的關注於軟件開發方法，而對於前面的價值探尋與後面的順暢交付，的確提的少一些。
DevOps 我就不多說了，前面已經說得很多了。後面還會說到。我們再來說說“器用”，器用這個詞是個很古老的詞，一開始的時候所謂的器是指武器，用是指農具，後來變成了工具使用，我們中華文明博大精深，每個詞都有很多種解釋，在這裏我引用這個“器用”就是指工具使用，沒有什麼其他高深的含義。
這個就涉及到我們在理解工具的時候是怎麼樣的看法？
文化和行爲，我們都知道文化會影響行爲，行爲也會反過來影響文化，但是當我們引入工具的時候，其實也是一樣的，你以爲自己在通過自己的行爲使用工具，影響工具的功能變化，同時，反過來工具也會影響和規範，甚至引導你的行爲。
二. 我們的 DevOps
上面簡單的說了一下 DevOps 和工具這兩個概念，下面就是我們中國銀行的 DevOps，大家都非常關心，或者非常希望能夠了解中行的 DevOps 到底是什麼樣子的，這裏和大家一起去做一些分享，當然這裏僅僅涉及我們X86相關的部分。
2.1 工具的選擇
我一直都在說工具的如琢如磨，我們來看一看我們在說工具的時候到底在說些什麼？
DevOps 的工具鏈很多，這只是其中的一些，也並沒有多全，現在有很多地鐵式、蜘蛛網式，甚至元素週期表式的工具鏈地圖，大家可以參考許峯老師的《一文收錄16張DevOps“拍照審圖”》一文。
其中這張圖，大家很多人肯定都認識，這是經常被應用的一張圖，來自James Bowman。這張圖非常推薦大家去了解，從前面到後面每一個環節上有各種各樣的領域，每一個領域下有一些它推薦的，或者覺得大家應該使用的開源工具。在這些開源工具裏面，我們中行用了其中不少的工具。
所有標註的開源、非開源工具我們基本都多多少少用到了，我想告訴大家的是，其實用哪個工具並不重要，重要的是你在這個過程中怎麼選、怎麼用，以及是不是真的用工具解決了自己的問題!
2.2 Devops 工具鏈
上面這張圖很複雜，從使用者的視角我們的過程是這樣的，從前面的需求到後面的監控整個過程中我們大概使用了這些工具。這裏需要反覆和大家提一下的是，這個只是涉及我們X86相關的部分。
三. 成功之經驗分享
3.1 源代碼
我們大家都知道業界關於 SVN 和 Git 之間有爭論，有的說 SVN 好，有的說 Git好，你認爲 SVN 和 Git 之間的區別是什麼？或者你擁護的是什麼？
畫外音：其實此處的互動，見仁見智，並沒有標準答案！
在實際開發中，我所在的部門使用的是 SVN，我們有些部門使用的是 Git。哪個工具更好，我的答案是：“主線開發更好！”。
完全答非所問嘛！這就是我希望分享的我們自認爲的成功的實踐的第一點：主線開發。我們都知道，提高工作效率，很重要的一點就是：消除浪費。
那麼，軟件開發中的浪費是什麼？我們都知道：工作切換、無效溝通、還有給開發人員配備爛機器和小屏幕。這裏，我要提到是一個很多人不以爲然的，但是很明顯的浪費，就是分支合併，在敏捷、精益裏面都會說我們要產生價值，大家想想軟件開發過程中的分支合併，產生了什麼用戶價值？完全沒有產生任何用戶價值。
我一直有一個觀點：所謂，分支合併，在當今的 IT 技術環境下，只是軟件開發過程中的一個不產生任何價值的多餘的動作。你消除不了它只有兩個原因，一、你不願，被自己的想象力束縛了手腳，覺得自己不得不這樣做；二、你無能，技術水平差，就只有所謂“管理”手段補。
3.2 分支管理
上圖就是我們曾經的分支，大家能想象嗎？這個就是我們一個批次一個批次的投產，這個就是我們曾經的分支狀況，我們爲了這個分支狀況有一個特別牛的項目經理畫了一張表專門進行管理。厲害吧！？
這個是我們認識到了這個問題以後，經過了半年多的努力以後得到的清爽結構，我想告訴大家的是，它是可以做到的，它真的是可以做到。但是，它真的很難。
我們看到主幹開發的時候，業界很多人知道這個，但是到底什麼是主幹開發？所謂理想的主幹開發，首先所有的代碼都是提交到主幹分支上的，然後你的發佈隨時可以從主幹發佈，這個能夠做到非常困難，需要讓你的主幹一直保持非常的穩定，這需要你的團隊足夠的自律，每一個提交代碼的人都足夠的自律，你的持續集成都足夠的健壯，並且維護的特別好。
我們做的是一種現實的主幹開發，就是你的提交依然提交到主幹，但是你要發佈，你要發佈的時候會從這個地方拉出一個分支做release，release的時候會在分支不超過一個迭代的時候就投，投完之後這個分支就凍結了，我舉了一個非常形象的模型，它像一棵樹一樣，它一直在長，這個就是我們現在做的主幹開發的情況。但是，主幹開發其實真的很困難。
上面這個圖是業界經常用到的版本管理分支，我們以前也是這樣的。這兩種方法是決然不同的，它對於你帶來的價值和效率的提升其實也是決然不同的。
都說主幹開發好，但是，硬幣總是有兩面的，它有什麼副作用？它的困難是什麼？大家要想一想。
我們經常會做同業的交流，大家一聽我介紹主幹開發都會說這個東西好！好，你爲什麼不做？大家都會很會心一笑，我們做不到嘛！我們比較特殊，我們有這原因，那理由，巴拉巴拉……..
這個時候，我們要是自己問一下自己，我們爲什麼做不到？我怎麼樣可以做到？我們如果真的要想做到，最開始的一步、最小的一步切實的改變會是什麼？
我和很多的同業交流的時候，特別是我們金融的同業，我們養成了一種狀態，在《DevOps實踐指南》中提到的一個詞，叫做習得性無助，見《DevOps實踐指南》第xxii頁。對於像我一樣在金融IT領域工作了十多年的“老油條”，我還聽說過一個更貼切的詞，叫做老練的無能。這種狀態的養成，這一方面是環境造成的，另一方面也是自己造成的。我們要做 DevOps 的時候，首先要意識到這個的問題。
有的時候你忙忙叨叨，做的很多工作其實都只是你能做的，然而並不見得是你應該做的。因爲，我們常常覺得“應該做的事情”太難了，就主動的、在想法還只是一個想法的的時候就放棄了。
主幹開發，想說愛你不容易
- 足夠短的迭代週期(兩週，可投產版本)
- 足夠短的投產前置週期(三個工作日)
- 不顧一切保證需求串行
主幹開發，就是這樣一件絕對應該做，但是，也是絕對艱難的事情，特別是在金融同業裏。要做到主幹開發，需要足夠短的迭代週期，足夠短的投產前置週期，就這兩點，已經足以讓很多金融同業望而卻步了，再加上一個保證需求串行。好了，基本上就徹底放棄了。
我想告訴大家的是，這是可以做到的，也應該做到。
3.3 持續集成
持續集成是什麼？
- 開發人員每天至少提交一次代碼
- 代碼提交後立即觸發構建和測試
- 構建和測試失敗後應儘快處理
持續集成不是什麼新鮮詞彙了，每個人都在說持續集成，這是我定義中的持續集成，這三條，清晰的定義了在做到“持續集成”之後，應該達到的效果。連這幾點最起碼要求都做不到，我一般不稱它爲持續集成。我見到的更多的所謂持續集成，其實只能做到第二條，這種的持續集成更應該被稱爲：自動化構建。
這裏我重點說的一點是，“構建和測試失敗後應儘快處理”，“儘快處理”是什麼意思？在我們的定義裏，儘快處理就是：儀表盤變紅不下班。我們部門的每一個產品開發團隊的附近都放着一塊顯示屏幕，我們稱其爲：物理儀表盤。經過幾年的努力，我們現在終於可以做到：儀表盤變紅不下班。
大家想想這一條規則或者叫做紀律會有什麼副作用？
對，爲了下班，大家會提前提交代碼。你可以下午四點的時候把代碼提交了，這個我們是允許的，我們並不介意開發人員下午四點就提交代碼。
“儘快處理”雖然聽起來是一句模模糊糊的話，但是，我們是有清晰的定義和規則以及紀律來支撐的。
只有你把上面這每一條都做到了，持續集成才變得有意義。
我們會有持續集成的紀律，聽起來很簡單，但是，真的要讓紀律切實的被大家所遵守，成爲大家的習慣，真的沒有想象的那麼簡單。它並不是哪個管理者說一說，宣講一下，拉個宣傳橫幅，就能夠做到，它需要切切實實的採取行動。
怎麼做到？我給大家說一下我們的做法，不一定適合大家，但是大家可以聽一聽。
我們有一個物理儀表盤就像下邊這張圖，這個物理儀表盤搭建很簡單，我相信你們只要有人研究個一天半天就能搞的，這個物理儀表盤就放在開發團隊的附近。物理的東西有天然的信息輻射作用，就是你想看、不想看它都在那兒。這是第一步，也是最簡單的一步。
第二步是給大家培訓，我們先後進行了很多次的培訓，告訴大家怎麼寫單元測試，怎樣的單元測試纔不會因爲數據、環境等其他烏七八糟的問題導致儀表盤變紅。
第三步是作爲管理者和文化的推動者，要和團隊共度第一個艱難的時刻。
給大家講個小故事，2017年8我們有一個四個Scrum團隊大產品在西安做異地封閉開發，七八十人，每週工作六天，每天晚上到10點，我被要求作爲內部教練去輔導團隊，我去的時候，儀表盤就一直紅着，用了將近兩週的時間，我們經歷了三次培訓，經歷了修復各種烏七八糟的導致儀表盤變紅的問題的階段。8月24日中午，我至今依然清晰的記得這個日期，一切就緒，我決定啓動“儀表盤變紅不下班”的工作紀律，就和大家宣告了一下。
其實，我心裏還是很虛的，本來就工作到晚上十點，變紅了真的修不好，真的讓大家通宵啊？如果真的這樣的話，我都覺得自己有點不講道理。墨菲定律啊！大家到了9點半的時候，都開始提交代碼，突然儀表盤紅了，然後，大家都驚呆了，我也是心裏一陣緊張。
我告訴所有人，停止所有的工作，我們還有半個小時下班，儘快修復，修復完了我們就可以下班了。一陣忙碌，各種查找晚上10點20分，儀表盤修好了，大家自發的給自己鼓掌。從此，這個產品團隊一直都保持着“儀表盤變紅不下班”的工作紀律，已經一年了。
我想告訴大家的是，在推行持續集成的程中，最重要的是持續集成的工作規則和工作紀律的建立，工具和平臺是最好搭建的。
而你想要引入一條規則，建立一個紀律的時候，你一定要定義出這件事情到底想怎麼做，過程中要給大家培訓，給大家和大家一起趟路，怎麼樣儘快的定位和修復可能的問題，接着做一些事情強化這個行爲，你要真的作爲參與者參與到這個過程中，陪着大家一起度過第一、第二個艱難時刻，然後，自然而然的，就成就了團隊新的習慣和紀律，也就是所謂的建立了新的“文化”。
很多時候，教練或者管理者“沒文化”，卻天天的喊着要建立文化，轉變文化。具體到這件事情上，對教練或者管理者的文化啓示就是：教練或者管理者要學會把手弄“髒”，簡單來說，就是要和大家一起幹！文化是幹出來的，不是喊出來的、宣傳橫幅報貼出來的。
說到這裏，你認爲那些上面的持續集過程中，我們用到的工具還像之前你認爲的那麼重要嗎？
3.4 自動化部署
自動化部署是大家的老大難：
- 生產環境權限管理融合難
- 生產環境配置參數收集難
- 生產環境資源變更聯動難
- 增量、全量的支持統一難
- 自動組包標準貫徹落實難
飯要一口一口的吃，我們在2016年的時候在部門年度質量目標裏面寫到一條：所有產品實現自動化組包，嚴禁手工組包。從一定意義上說，手工組包就是在浪費組織資源，所以我們在內部強烈的推了自動化組包。然後，纔有我們的自動化部署。
整個軟件中心，現在已經有20多個產品上了自動化部署，我們今年提的目標是100+，不知道能不能達到，但是已經有20多個產品已經實現了自動化部署，有X86等等各種各樣的平臺都有實現了自動化部署。
相對於手工部署的時間，自動化部署會變得很快，其實，變快只是收益中的一點點，最主要的是自動化部署的時候你在喝咖啡，而且一般不會出錯，想想手工部署的情況下，運維的同學在幹什麼？手指如飛，眉頭緊鎖。對比一下兩種情況，這個幸福感和平穩度決然不同。
自動化部署是我們做DevOps的時候應該努力去做的事情，但是我們在做自動化部署的時候，自動化組包，環境管理、參數管理、權限管理，如果你的數據中心和開發中心還是分開的時候，這些全都是你需要克服的點，而且每一個都不簡單。這個太複雜了，我不細說了，我想告訴大家的是自動化部署是克服各種困難都要去做的事情，是應該做的事情。
四. 失敗之回顧反思
下面說一點，我們的失敗與反思。
自動化功能測試的苦難：
- 2016年多個產品集中編寫了將1000多個面向UI的自動化功能測試案例(Robot Framework)，半年後，全部廢棄，沒有再被運行過。
- 某產品編寫的大量面向UI的自動化功能測試案例，全部運行一次 一般需要一到兩週才能完成，有2-3名測試開發人員專職負責運行和編寫，以及更新這些案例。
看到大家會心的笑容，我就知道我們的現狀並不特殊，我們和大家一樣都經歷着同樣的苦難，互聯網公司給我們做了很好的榜樣，但是很不幸的是它救不了我們，我們環境不一樣。
通過我的分享就知道，你的排期任務所有的這些流程和互聯網公司截然不同，有的互聯網公司產品經理弄個PPT，給高層秀一下，拍個板就開幹了，該抓人抓人，該要錢要錢，我們金融同業，搞個需求，從評估到立項成功，沒有個一年半載是下不來的，能下來的都是快的。
回到自動化測試，上面是我們在自動化測試上的一個“苦難”，苦難之後，我們有反思的。還是那句話：幹該乾的，別光幹那些容易乾的。
因爲，很多情況下，你覺得該乾的並且不容易幹不成的那些事，就是系統改進的關鍵點，否則，爲什麼你幹了那麼多能幹的事情，系統仍然沒有什麼改善呢?
該幹什麼呢？我們發現在已經發布了一個高績效組織和低績效組織的對比過渡圖裏面找到那個點。
我們每10天到100天發佈一次，這是我們現在的現狀，你會發現，在圖中處於這個階段的組織，開發和測試人員是共同去維護自動化測試案例的，而我們上面提到的自動化功能測試案例，第一個開發是自己寫的，第二個是專門的搞自動化測試的測試人員寫的，唯一沒有一起寫，共同維護的。
看到這個點的時候，當時對我的啓發很大，我想找到了那件該做的事情，我天天聽到有人說要測試遷移、要開發與測試融合，可是，何爲融合？如何融合？
用自動化測試這個話題，讓開發和測試融合。共同維護自動化測試案例了，開發和測試就融合了。
什麼叫共同維護自動化測試案例？“共同維護”到底是什麼？
再直觀點：開發和測試共享自動化測試的代碼，共同修改自動化測試的代碼。我們有的時候特別喜歡說一些模糊的、抽象的話，因爲，這些話讓大家覺得有一種朦朧的安全感。
從開發、測試融合，到共同維護自動化測試案例，到共享自動化測試代碼，大家好好的體會一下這之間的區別。找到那個關鍵點，其實沒有那麼容易，可是，其實也沒有多難。
找到只是第一步，做到，才重要。這又是一個艱難的旅程，有多少開發和測試是一個部門的？有多少測試是具備編碼能力的？我相信自己問了這兩個問題，很多人就默默的在心裏放棄了。
我們的開發和測試分屬於兩個不同的部門，我們的測試人員基本沒有編碼能力。可是，我們正在做這件事：通過共享自動化測試代碼，開發和測試共同維護自動化接口和功能測試案例，形成開發與測試的融合。因爲，這是應該做的事。
說到編寫自動化測試案例，就有一個增加案例和案例多少的話題。
在這裏面，我們正在執行一個紀律，就是：在增加自動化測試的時候，你要保證你的自動化測試案例持續的有效和可用。怎麼樣叫持續的有效和可用？ 就是增加的自動化功能測試案例，必須可以
- 每天至少運行一次
- 運行預期應該是100%成功的
- 如果沒有成功，一定是由於應用問題，而不是因爲環境、數據等非應用問題
我把這稱爲：有紀律的增加自動化測試案例，
增加的自動化功能（接口也算）測試案例，每天至少跑一次。一天都跑不了一次的自動化測試案例，基本上就是擺設，除了讓其管理者每次看案例數的時候感覺爽一下，沒有什麼實際用處。
每一次的運行都應該預期是100%成功的，如果沒有成功，一定要是你的應用出問題了，而不是因爲什麼數據問題，或者什麼環境又不穩定了，其它的系統宕了所以我們有宕了等等。
只有第一個案例滿足這個條件了，才允許寫第二個，兩個案例都滿足這個條件了，才允許寫第三個。如果第一個案例就滿足不了上面的三個條件，就好好的想辦法先讓你的第一個案例可以滿足上面的三個條件。
這叫做有紀律，這叫做剋制。我們現在非常謹慎的增加我們的自動化測試案例，而且我們要求我們的測試融進我們的團隊裏面和我們一起去寫自動化的測試案例。
我們的接口測試案例，基本上都是在迭代中，在開發人員的支持下，由測試人員編寫的。一開始不會寫怎麼辦？培訓啊！學習啊！
說到在這個地方，單元測試有個原則叫做FIRST原則，功能測試的時候有的地方叫AIR原則，我覺的加個A有點多餘，我認爲自動化的功能測試應該滿足SIR原則，什麼叫SIR原則？你會發現其實就是沒有單元測試的FIRST原則的F和T了。
F是什麼？F是Fast，你會發現你的單元測試是會Fast，但是，無論如何你的自動化接口測試、自動化功能測試都很難像單元測試那麼快。
T是Timely，就是能夠及時的編寫，你的單元測試是開發自己寫的，甚至有的時候可以用TDD，所有足夠的Timly，但是你的功能類的自動化測試、接口類的自動化測試就不一定可以那麼Timely的編寫了。
所有，我認爲自動化的功能測試應該滿足SIR原則。
這個就是我們經過一系列的失敗之後，自己的反思和行動，現在還不能算有什麼成績，過程也很艱難，不過我們會繼續做下去。
說到這裏，不知道大家對於DevOps中的“器用之道”是否有了不同的看法。模仿敏捷宣言的Over體，最後給大家一個寄語：
工具很重要，什麼更重要？
這個問題留給大家去思考和總結。
注：本文僅代表個人觀點。