以通訊軟體為核心，LINE 持續發展圍繞用戶生活的各種服務，同時也抱持著開放的態度，積極與不同的平台或開發工具串聯。因此，我們鼓勵、更贊助 LINE 的工程師參與各式各樣的外部研討會，激發更多創意或合作的可能性，並於會後撰寫見聞，分享給 LINE Engineering Blog 的讀者們。
《LINE 強力徵才中!》與我們一起 Close the Distance 串聯智慧新世界 >> 詳細職缺訊息
大家好，我是 LINE TW Automation Engineer & DevOps Evangelist - Bryan Liu，除了 docker、Kubernetes，文化 (culture) 與流程 (process) 其實佔了 DevOps 另一大部份。DevOps 的數位變革已經過了十個年頭，但改變的動機從何而來? 我們也需要改變嗎? 這問題正是寫本文想探究的，希望讓大家能樂於擁抱改變、嘗試更有效率的方法。
本文前半段講的是改變的動機、何謂 DevOps，以及它所提倡的團隊文化與組織效率，並藉由故事說明為何這些要素是這場變革中所必須被實踐的。後半段則概述開發團隊中的每個角色可預期的改變有那些，並條列未來在技術方面想更明確講述的主題。
何謂 DevOps
DevOps 有太多的定義比如：Wikipedia、Google Cloud，這些都表達得很好，但我更喜歡從開發（CI/CD）的角度來講這件事，比如：
Continuous Delivery is the ability to get changes of all types ... into production, or into the hands of users, safely and quickly in a sustainable way. ... We achieve all this by ensuring our code is always in a deployable state ... thus completely eliminate the integration, testing and hardening phases ... as well as code freezes. ~ Continuous Delivery
要完成這樣的轉變 (digital transformation)，當中包含了不同類別的各項技能之養成 DevOps capabilities，但在這之前，最難的還是讓團隊了解及接受改變的必要。
為何改變是必須的?
好了，的確有另一些方法可以讓 (軟體) 開發更快、品質更好、更穩定等。但我們現做得不錯，也能固定時間交付客戶所需要的功能，那我還需要改變嗎? 這邊就提到了持續改善的重要性，拿 Uber[1] 來說，它的商業模式並沒有太多改變，但其架構每兩年就大改一次，這改變不外乎是為了架構能容易擴展 (scale out) 及當團隊快速增長時還能維持一樣的開發效率。企業的起起落落，尤其是 IT 產業，當改變是被迫時，往往競爭者已攻城掠地，這時改變是壓力很大的，相反的，隨時都能持續改善，反而可以享受著指標數字隨著改變而不斷改進的成就感，兩者相差甚鉅!
當初 IBM 及微軟內部第一次在推動 DevOps 改造時就是發生在協作軟件的部門 (Lotus Notes and MS Office)，也正是 Google 的 Gmail[2] 等快速地被企業及個人採用後，兩家公司發現當他們還在以每季度在更新軟件時，Google 卻是每天都能更版甚至使用 A/B Testing 的方法在快速反應使用者的回饋。結果是 MS Office 轉型後且上了雲端似乎帶來更好的結果，但 IBM 卻退出了企業協作軟件的市場。
快速變動的行業裡，大家早就應該了解到，沒有改變的風險跟改變本身的風險是一樣高的!
從十年前的第一場 DevOpsDays, Belgium, 2009，到傳統軟體公司想改變時已經是將近五年後的事，但在 DevOps 滿十年後的今天，你，想改變了嗎? 當共享軟體當道，商業模式容易被複製，只要灑錢暫時也能雇用到不錯的工程師，所以長遠來看，企業的差異性與競爭力大概就只剩下企業文化與效率。
企業文化
文化將策略當早餐吃掉了 (指的是一個企業的文化，將左右其營運管理上的策略)，而快速變化的今天，沒人能預測未來將面臨的所有挑戰，而文化就會像一盞燈指引你走出這些黑暗的隧道。就像亞馬遜所說：『在客戶體驗方面，我們已經設置了非常高的門檻，並且有著異乎尋常的不斷改進的緊迫感。』因此，『我們要基於長遠創造更好的客戶體驗』、『持續改善以強化其心血。』。
又如 Netflix 創辦人 Reed Hastings 在 2009 年釋出的 Netflix Culture Deck，它在 SlideShare 點閱率超過 19,000,000 次，被奉為影響矽谷二十世紀以來最重要的文件之一，之後其它公司無不公開其企業文化，以藉此吸引對文化認同之員工，並過濾與本身企業理念不合之應徵者。文件中有太多對於我們這樣的 IT 或創意產業所應有的企業用人留才之策略與認知，也點出了 IT 產業既無土地，也無廠房，有的只有人，既然只有人那文化的重要性就可見一斑了！
文化沒有對錯，但卻是讓一家公司在其認知的價值上深耕並做出差異化的必要手段。
文化的重要性，這邊再說個故事：1982年，美國的 GM (General Motors) 公司把位於加州的弗里蒙特工廠給關閉了，原因是長期的抗爭、罷工，以及所產出車輛質量是所有工廠裡面最差的，車子出了生產線還得另外用車子拖走，經常少了零件或根本無法發動。1984 當時的 Toyata 精實製造正席捲美國汽車業，GM 跟 Toyata 合資一家子公司 NUMMI[3] 然後重啟了工廠，由 GM 負責市場與銷售，Toyata 負責車輛的設計製造及工廠的運維，且 GM 同時派了許多員工至日本工廠學習，以回來改進 NUMMI 的生產線。一直到 1995 年的 JD Power survey 中，美國所販售十輛質量最好的車中，只有兩輛是美國製造，而其中一輛便是 NUMMI 所生產的 Geo Prizm。
上面的故事說的是同一車廠、同一批員工，在不同的文化管理與流程下所表現出來的結果卻是截然不同的! Netflix 也有類似的故事，Netflix 的雲架構師 Adrian Cockcroft 有次被其它 Fortune 500 公司的資深經理人問『 Netflix 到底是從何處招募來這些明星級的工程師？』，而 Cockcroft 也就回答 "I hired them from you!"。
之於開發團隊，這些著名 IT 公司的文化中，不外乎一定有的像是：efficiency, risk taking, high performance, seeking excellence...，而這些不就是整個 DevOps 所一直在強調的事嗎？講到 DevOps 有關組織文化的部份，通常就會提到組織學習和安全文化：
學習型組織 (Learning Organization)：
持續學習應該也用不著我贅述，但很多公司表面上提倡這樣的文化，但實際上並沒有積極地去創造一個有利的環境，或實質上地支持這類的活動。如何實踐跟評估組織的學習文化呢？這邊寫得很棒也夠簡單明瞭 Learning Culture，有興趣就自行參考一下。
另外，如 Spotify 的分會 (Chapter) 及工會 (Guild) 型的架構組織，讓公司內部能更有效率地學習、傳遞知識及實踐工法也蠻值得去嘗試看看。
心理的安全 (Psychological Safety)：
面對日益複雜系統，出現問題是不可避免的，我們要做的是快速發現和解決問題，相反地指責只會導至恐懼文化，如此問題可能被隱藏直到災難發生，所以團隊的免責文化、鼓勵試錯與快速學習才有助於創新。 另外 Google studies[4] 及 The Westrum organizational culture[5] 都提到心理安全的文化，對於建立一個有效率的團隊和創意是至關重要的！
總結一下，對於競爭優勢就如同 Dave West[6] 所提及的：
Peter Senge 在其著作《The Fifth Discipline - The Art & Practice Of The Learning Organization》中描述了組織專注於學習的必要性。
「唯一可持續的競爭優勢是一個組織比競爭者更快速地學習的能力」。
最終，通過專注於敏捷領導力、自組織、以客戶結果為中心、消除浪費以及瞭解組織文化並頻繁交付這 5 項挑戰，組織將變得更加專注於學習並變得更加敏捷。
持續改善 (Continuous Improvement)：
還有持續改善的精神，不得不提的是它貫穿整個 DevOps 的主軸，也是落實文化價值的方法，我猜它源自於企業追求卓越的文化，比如：
- Spotify 的 "Definition of Awesome"
- Amazon 要求的是 "Legendary kind of user experience"
- Netflix culture deck 講的是 "Obsession for performance"
文化上是這樣，唯有不斷精進才能做出差異化的結果，技術方面也一樣，想要有越來越好的團隊效率只有通過持續改善，就如同《從 A 到 A＋》書的結尾說到：
做到卓越不見得比做到優秀困難，反而可以少吃點苦頭，累積的動能會注入更多的能量，持續維持在平庸將不斷耗掉能量，新注入的能量卻很少。
效率
Nokia 在 2013 年將手機業務賣給了 Microsoft，背後的因素除了太慢進入智慧型手機外，開發效率也是其中原因之一。2010 年當其董事會主席 Risto Siilasmaa 視察公司時發現，Symbian 作業系統建製一次需要 48 小時，對於當時的他猶如當頭棒喝，而內部雖然一直有淘汰 Symbian 的建議，卻一直沒被管理層所採納。 建製時間要 48 小時，也就代表開發人員要兩天後才能知道提交的代碼是否有問題，這樣的迭代速度就算再加一倍的人力，可能也改變不了現況，更何況它所面對的是像 Google 這樣有效率的公司。Google 或 Amazon 從 2003 年起的那些 Test automation 及 Continuous integration 的轉變，Nokia 應該也是完全沒跟上。
所以再深再廣的護城河，只要別人的效率是你的兩倍、五倍甚至十倍，那麼護城河也很快就會有被填滿的一天。是的，就像 DevOps Handbooks 所提，『改善日常工作甚至比進行日常工作更重要』，而且要及早做，而非放到最後，層層堆疊，想改也改不動。方法就是用 3~5% 的開發人力，或至少 20% 的時間週期用於持續改善的活動，這當中包含有意識地 (consciously) 償還技術債，以及推動技術與架構的現代化。架構要使團隊能夠獨立開發、测試及向客户部署價值，減少跨團隊的協作與耦合，其中微服務 (Microservices) 間能有各自的軟體交付週期 (release cycle) 便是其中一例！
當然，這邊講到的效率提升是奠基在一樣或更好的品質上，你不會為了讓生產力增加十倍而犧牲了品質！對於效率與品質從來不會只要求做到七十分就好，而是採用持續改善的方式不斷向上提升，永遠都有進步的空間 (Toyota Kata)。 是的，改善工作永遠沒有結束的一天，而在這個快速變動的行業裡，大家早就應該了解到，沒有改變的風險，跟改變本身的風險是一樣高的！
如何開始
實踐方法除了Agile 的 mindset, Scrum process 或是 DevOps Handbooks 中提到的三步工法等，但這些網路上已經有太多好文在講述其中的概念，所以我更想用技術方面的實作來闡述所需相關的能力。這些數位化的改革中，擁抱改變是必要的，因為每個人的工作模式多多少少都需要改變，比如說開發人員除了單元測試外也必需負責 "Acceptance Test" 的自動化創建與維護，以達到快速回饋與避免類似 "Waterfall pipeline" 的反模式產生 (如下圖)，這將會在『持續集成』的章節再詳述。
對 QA 來說， 在非 Continuous Delivery 的交付模式中，一定會有幾天的 code freeze，這段時間就是拿來讓 QA 做整合測試的時間，也唯有 QA sign off 的交付才能被佈署至生產線。 但想想如果要做到每天一次或多次生產線的交付，那麼生產的流水線當中，其實已經沒有 QA 能手動測式的空檔了，所以 QA的角色可能會消失，但有關質量的工作事項卻只會更多且散落在各團隊成員及開發週期 (詳見『測試在 DevOps 中的樣子』章節)，也正是所謂的測試左移或右移，所以 QA 人員反而要回去熟練探索性測試的那些方法，以及如何設計測試案例來驗證跟監控生產線上的狀況。
對運維人員來說，所要熟悉的工具與部署環境，與原本的 system admin 可說是在光譜的兩端，更何況還要懂得去幫助整個功能團隊，合作開發出好運維、可監控的程序，也難怪好的 SRE 這麼難找。
最後，DevOps 轉變帶來的不只是公司效率的提升，個人方面，減少重工及非預期中的工作，可讓員工有時間從事更具創造性的工作，且更滿意工作環境，也更願意推薦自己公司或組織給親友。下面數據來自 DORA 多年來調查資料的分析報告。
接下去的幾個章節中，會對這些實踐做更多的闡述或實作方法 (很多方法其實跟你想的不一樣)，包括：
- 測試在 DevOps中的樣子
- 持續集成 (Continuous Integration)
- 單主幹開發 (Trunk-based Development & Feature Toggles)
- 測試左移 (在開發階段之前定義好測試以及將整合測試提前執行)
- 實例化需求 (Specification by Examples)
- 測試自動化 (Fast Test Automation)
- API 測試? 想想 Consumer Driven Contract Testing
- 想更快? 先做好 Test Isolation
- 自動化測試戰略與工具 (Strategy & Tools)
- 測試右移 (在生產環境中監控，並且實時穫取用户反饋)
- Low Risk Deployment (低風險部署)
- Testing in Production (在生產環境做測試)
- Application Observability (O11y，程式的可觀察性)
待續，持續更新中 ...
Culture is how we think, what habits we create and what we do when we're interacting with each other every day.
Reference
- Stack History: A Timeline of Uber's Tech Stack Evolution
- Developing Gmail’s New Look — Google Blog
- [NUMMI - wikipedia] (https://en.wikipedia.org/wiki/NUMMI)
- Google studies
- Westrum organizational culture
- Dave West. Managing next century agile