DevOps時代下工作整合問題
什麼樣的工作需要整合，什麼樣的工作不應該整合？
在軟件交付領域，分角色的精細分工是不利於整體交付效率的，那爲什麼在DevOps倡導下的全棧工程師、開發運維一體化又會產生新的問題呢？如何解決這些新問題呢？
也許，我們需要認真思考，在整個軟件交付過程中，什麼樣的工作需要整合，什麼樣的工作不應該整合。
在前DevOps時代，分角色分工的思路其實是來源於工業時代的。做過手工的都知道，如果要手工做100只燈籠，一開始會做得很慢，做了幾隻後，會越做越快，所謂熟能生巧。
再進一步，把做燈籠的過程拆解一下，比如拆解成搭骨架、糊紙、上色等工序，然後多找幾個人來，每人負責其中一道工序，經過幾番磨合，由於每個人要做的事情比較單一，很容易上手和熟練，效率將會大大提升。燈籠的成品和質量也會越來穩定。
把這個過程放大，就是一個工廠的模式。
所有工廠都是通過拆解和精細分工獲得極高的效率的，而且，分工越精細，效率越高。而生產最大的特點是在不斷地做重複的事情，產出是同樣的產品，而且產品間的差異越小越好，最好趨近於零。對於重複的事情，就應該通過拆解、精細分工、標準化和自動化來提升效率。
但是軟件交付過程則完全不一樣，和生產最大的區別就是“不重樣”。
每一個軟件需求都是不一樣的，用戶想要的結果也是不一樣的，這導致需求分析、開發、測試面對每個需求，或者運維面對每個故障的具體工作是不一樣的。
而且軟件交付是一個知識工作，是信息流動和轉換的過程，而交接會帶來信息的衰減和變異，因此在軟件交付過程中，按角色分工非但不會帶來像生產那樣的效率提升，反而會因爲信息在不同角色間的交接和傳遞而產生不必要的摩擦和誤解，甚至交付出錯誤的軟件產品。
因此，我們更希望軟件交付團隊成員可以具備從需求到運維的端到端的交付能力，每個團隊針對一個特定的業務領域能夠獨立完成交付，減少交接，減少對外依賴。
而且這個團隊應該足夠小（最好不多於7人），以確保團隊內目標一致、高效溝通和高度靈活。
然而，對於業務或用戶來說，IT系統和服務是一個整體，除了軟件，還有硬件。而每個人的帶寬和能力都是有限的，術業有專攻，不可能每個人都是全能的，特別是有些細分領域專業度非常高。
如果把所有的職責都歸到業務線交付團隊，那麼交付團隊必然需要擁有具備各類所需技能的專家，從而形成新的龐大實體，除了造成不必要的資源浪費外，組織一旦變大，勢必又會變得官僚和低效，原本想避免的問題又會重新出現。
三、解決工作整合問題的關鍵
要找出哪些工作是重複的，哪些是非重複的。
那麼問題的癥結在哪裏呢？通過前面的分析，我們知道，重複的工作，可以通過拆分、精細分工、標準化和自動化來提升效率，非重複的工作，可以通過減少交接和依賴來提升效率。
要解決如何分、如何合的問題，最關鍵的就是找出哪些工作是重複的，哪些是非重複的。重複的，解決方案是整合資源、角色分工和自動化；非重複的，解決方案是一體化。
那麼在軟件交付過程中，哪些工作是重複性的呢？我想到的有以下這些：
1、網絡、硬件等基礎設施
這些IT基礎設施不會因爲不同的項目和需求有太多的差異，而且專業性強，不太適合一人分飾多角，這些角色整合在一個獨立團隊中，使他們保持專注，也有利於這些專業領域的技術交流和知識傳遞。
2、部署
應該儘量自動化，最低要求也應該標準化，有標準的具體作業流程，誰都可以遵照流程做好。
我們把應用部署過程整理成含具體操作步驟的標準化手冊，這樣這項工作團隊內誰都能做，把他從部署這項具體工作釋放出來，在此基礎上，讓他把這個過程自動化，從而讓他學習流水線和自動化部署的技術，接觸技術性工作。
他也可以把故障處理流程整理成操作手冊，賦能其他團隊成員在合規的環境下承擔運維工作，把他自己釋放出來；
3、DBA、操作系統等專家團隊
應該通過腳本、自助服務等形式賦能交付團隊在受控的環境下滿足交付需要，減少對他們的依賴。
我們可以收集各交付團隊對於DBA的具體需求，把具有共性的需求提煉出來，做成可以通過DBA權限執行的腳本，既滿足交付的需求，又確保了DBA權限不會被濫用；
4、標準流程
所有項目都必須要走的標準流程，如採購等，由專業的團隊提供服務的形式來執行，大大降低各項目團隊由於需要熟悉繁瑣流程的過程所導致的不必要浪費；
需求分析、開發、測試、業務支援等非重複性工作則應該保持在一個自滿足小團隊中，爲特定的業務領域提供軟件交付和維護服務。
四、總結
DevOps的目標是實現持續交付，提升整體的交付效率。要實現這個目標，簡單地把開發、應用維護，甚至IT運維整合在一起，有點過於粗暴。
我們還是應該認真分析哪些具體工作是重複的、可標準化的和哪些是非重複的、不能標準化的來分開處置。重複的，解決方案是整合資源、角色分工、標準化和自動化；非重複的，解決方案是一體化。
說說DevOps“像” 什麼：
1. DevOps起源於敏捷方法論，或者我們說的精益原則，目的是爲了產品發佈更加快捷、頻繁和可靠。
2. IT價值流在DevOps的帶動下將快速貫穿開發至生產全過程，雖然字面上我們只看到一個“Dev”和一個“Ops”，感覺像是“一帶一路”似的，其實包括了從開發到測試，再到發佈生產各個環節，下圖被經常用到解釋DevOps和已有的研發部門角色之間的關係。（其實還應該包括企業的架構師）
“DevOps是在整個IT價值流中實施精益原則的結果。IT價值流將開發延伸至生產，將由程序員這個遙遠的祖宗所繁衍的所有子孫給聯合在一起。”
以上是Gene Kim對DevOps的解釋，供大家參考。
DevOps Check List
這裏簡單粗暴的列出一些Check List，大家可以對號入座，但不要過分糾結：
1. 開發團隊，測試團隊和運維團隊之間應該沒有障礙。三者皆是DevOps統一流程的一部分。
2. 每個團隊的輸出都是經過自驗證的，這樣才能保證DevOps的閉環順利運轉。分享一個DevOps 閉環圖：
3. 開發、測試和發佈環境標準化，可以很容易將之擴展並進行部署。
4. 每個團隊之間的通信線路都很明確，保證溝通效率。
5. 所有的團隊成員都有時間去爲改善系統進行試驗和實踐。
6. 每次學習到的經驗都應該文檔化下來並分享給相關人員。事故處理成爲日常工作的一部分，且處理方式是已知的。
運維的 “革命”
運維可以說是DevOps這場“IT運動”中受到影響最大的角色，從傳統運維到DevOps，就是一場“革命”。
Google的SRE（Site Reliability Engineer），從前一段時間開始，被人們熱捧，有的公司馬上把自己的運維崗位換名爲SRE，確實顯得B格高了一點點。甚至有人把SRE和DevOps劃了等號，這樣做真讓人覺得槽點滿滿。我認爲SRE其實是運維“革自己命”的產物，客觀講，這樣的轉型是很高明的，一定是經驗積累，加思考，再加探索得出的。
SRE是Google的運維團隊從實踐中總結出來的一套方法論，將工程研發、日常運維和應急響應等任務較好的結合並落地，當Google的運維團隊開始在做SRE的時候，DevOps的概念可能還不爲人所知。
所以我們是否應該首先想到是，如何學習Google的運維團隊走出適合自己的轉型之路，我們的運維團隊未來是什麼？
運維的未來是什麼？
—一切皆自動化
“運維的未來是，讓研發人員能夠藉助工具、自動化和流程，並且讓他們能夠在運維干預極少的情況下部署和運營服務，從而實現自助服務。每個角色都應該努力使工作實現自動化。”——《運維的未來》
說到自動化，感覺又是槽點滿滿，也許有人和我一樣都經歷過爲了自動化而自動化的尷尬，在大公司裏，不乏專門做自動化工具的團隊，每年出一套工具，“緊跟時代潮流”，然後被迫使用這些自動化工具的團隊怨聲載道；但是有經驗的開發、測試或者運維工程師一定能體會到，“自動化”對於DevOps來說，是剛需。
—工具的合理選擇
同樣對於DevOps來說，工具是必要條件，但工具不是充要條件，如果沉迷於各種工具的堆砌，那麼可能跑偏，下面是我們經常會提到的一些工具：
代碼管理（SCM）：GitHub、GitLab、BitBucket、SubVersion
構建工具：Ant、Gradle、maven
自動部署：Capistrano、CodeDeploy
持續集成（CI）：Travis、Jenkins
配置管理：Ansible、Chef、Puppet、SaltStack
容器：Docker、LXC、第三方廠商如AWS
編排：Kubernetes、Core、Apache Mesos
服務註冊與發現：Zookeeper、etcd、Consul
腳本語言：python、ruby、shell
日誌管理：ELK、Logentries
系統監控：Datadog、Graphite、Ganglia、Nagios
性能監控：AppDynamics、New Relic、Splunk
壓力測試：JMeter、Blaze Meter、loader.io
應用服務器：Tomcat、JBoss、IIS
Web服務器：Apache、Nginx
數據庫：MySQL、Oracle、PostgreSQL等關係型數據庫；mongoDB、redis等NoSQL數據庫
項目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker
面對茫茫“工具海”，傳統運維團隊在日漸式微，而構建工具的團隊日益壯大起來，這些工具包括持續集成環境和持續交付等等。運維能力應該逐漸延伸到構建和維護基礎設施服務、配置管理、日誌管理、容器管理以及監控等多方面（深以爲然）。我的建議是，不選別人認爲對的，只選最適合自己的。
—熟悉業務
在實踐中我們發現，熟悉業務是團隊最難實現，顆粒度最難把握的一部分。
傳統運維會有很詳細的分工，包括團隊之間和團隊內部。有的團隊之間會做隔離，舉個小例子，“今天上線的內容，我需要你每一步都寫的清清楚楚，我只負責執行，不問爲什麼，出了問題我不負責”，聽上去是否耳熟？其實問題不在於要求上線申請寫的多清楚，問題是對業務相關“我不負責”。在傳統運維團隊內部，一般有專門負責部署上線，跑腳本的同事；有DBA，數據庫所有操作就是“我”來；有做監控的同事等等。當然各個公司情況或許有所不同，但如果你曾經試着說服運維團隊去靠近業務層，你碰到的問題應該類似，那就是或多或少的抵觸。
DevOps中的運維團隊需要對業務負責，這點毫無疑問，我想大家都沒有必要再“害羞”了。事要知其然，且知其所以然。當然循序漸進的過程是有必要的，所以在GeneDock我們選擇了一條自己的運維之路。
GeneDock的運維之路
GeneDock的運維團隊開始踐行DevOps，努力的方向有兩個：一是推進自動化落地；二是在原有的“知其然”基礎上，要求團隊成員“知其所以然”。
自動化的切入點是持續集成和部署，一步一腳印的向DevOps方向前進。目前主要圍繞GitHub和jenkins，構建了線上（公有云）和線下（私有云）混合模式的持續集成和部署框架。如下圖所示。
業務層面，運維團隊在開發團隊的大力幫助下，從上線後故障排查，以及配置管理問題的覆盤開始，不斷在實際問題中總結，並形成文檔。同時也通過優化部署流程幫助整個研發團隊提高發布效率。團隊間相互促進，形成良性循環。
在很多企業中，應用程序發佈是一項涉及多個團隊、壓力很大、風險很高的活動。然而在具備DevOps能力的組織中，應用程序發佈的風險很低，原因如下 ：
（1）減少變更範圍
與傳統的瀑布模式模型相比，採用敏捷或迭代式開發意味着更頻繁的發佈、每次發佈包含的變化更少。由於部署經常進行，因此每次部署不會對生產系統造成巨大影響，應用程序會以平滑的速率逐漸生長。
（個人體會：我覺得這是敏捷和DevOps最大的優勢，對比之前老的開發模式，週期很慢，適用於硬件和傳統嵌入式開發，而現在前端技術和中臺技術的發展，造就了必須有快速部署、全棧開發的出現）；
（2）加強發佈協調
靠強有力的發佈協調人來彌合開發與運營之間的技能鴻溝和溝通鴻溝；採用電子數據表、電子數據表、電話會議和企業門戶（wiki、sharepoint）等協作工具來確保所有相關人員理解變更的內容並全力合作。
（個人體會：軟件交付，需要每天每時每刻進行溝通，所以不能採用一週一溝通的方式）
（3）自動化
強大的部署自動化手段確保部署任務的可重複性、減少部署出錯的可能性。
與傳統開發方法那種大規模的、不頻繁的發佈（通常以“季度”或“年”爲單位）相比，敏捷方法大大提升了發佈頻率（通常以“天”或“周”爲單位）。
（這點，只有大公司有這個能力，我之前的公司維持了一個龐大的團隊，專門用於自動化測試，運維…減少後期很多bug和開發時間 ；然而成本也是巨大的，但是比起出bug花費的資源和隱形成本，總之是很值得的）
