上兩周在上海出差，工作比較忙，沒有及時更新文章，對自己提出批評。之前看到Dr.Fish寫的《2017- 我的敏捷學習之年》將scrum用于自己的學習，深深的佩服魚心博士的自制力，感慨學霸的帽子不是白扣的。受此啟發，或許自己可以寫一些關于devops的心得，自己不是資深Devops專家，僅僅了解些Devops的思想，全當總結。

Devops

image.png

關于Devops，從字面意思上說就是開發運維一體化，而帶來的組織變化如下圖所示。

組織結構變化.png

在我看來，關于IT工作可以分為四類：業務項目、內部項目、變更以及計劃外活動。無論devops或者scrum都是站在更高的維度來看IT運維以及開發那點事。二者并不是什么新技術，都只是在傳統制造業管理理論中衍生出的優化IT工作流的管理方式而已。旨在統籌全局(開發、測試、運維)確保計劃內工作流的吞吐量最大，從而向業務部門交付工作價值，同時盡可能的降低計劃外工作的影響，減少返工。

提到Devops, 不得不提三步工作法：

• 工作從開發部門移向運維部門再到客戶時，如何建立快速工作流，因為開發、測試、運維部門是業務部門與客戶之間的銜接。必要的做法包括持續構建、集成以及部署，按需創建環境，嚴控半成品，以及構建起順利變更的安全系統和組織。
• 如何縮短并放大業務部門與客戶之間，開發與運維之間的反饋回路，避免返工（浪費）
• 如何建立一種工作文化，既能鼓勵探索，從失敗中吸取教訓，又能讓大家理解反復實踐是精通的先決條件。

Devops是把雙刃劍.jpg

而實際工作中Devops是把雙刃劍。其實風險本身并不可怕，可怕的是拒絕風險，或者放任風險。大家可能已經看過很多DevOps宣傳，覺得實行DevOps之后可以做到萬無一失，從開發到交付是分分鐘搞定的事情。其實這里有個陷阱。那就是工具可以幫助生產到交付快速進行，但是從另一個角度講，如果一旦出現問題，錯誤也可能會很快傳遞到生產環境中。所以如何快速捕捉問題，解決問題，而不是讓問題傳遞，這才是DevOps要處理的問題。另外盡早的在持續交付的初期發現問題，比如說有價值的缺陷，然后把它作為單元測試的目標去防范，這對于團隊來說是一個不斷成長的過程。
“精益的側面是控制風險，所以要小心風險和DevOps流程一起傳遞。”

怎么實現一個scrum

Scrum也有自己的四步法：

• Sprint(沖刺)計劃。 列舉總的任務清單并進行估算，根據優先級與難易程度，明確近期Sprint中需要完成的任務。
• Sprint執行。 按照將要執行的Sprint計劃，完成Sprint。每日以站會的形式，在15mins左右的時間回答：昨天做了什么，今天要做什么，遇到了什么困難。
• Sprint評審。評審在每個sprint結束時召開，由開發團隊展示sprint完成的功能，不需要PPT，一般展示已完成的demo，需要由客戶、經理、開發人員、product owner參加。
• Sprint回顧。由scrum團隊、產品責任人等進行復盤，回顧經驗并吸取教訓，宗旨是scrum團隊如何在下一個sprint中做的更好。

Devops和Scrum的關系

image.png

很多人好奇敏捷和DevOps是什么關系。敏捷是一種軟件開發過程，最初只是在軟件開發中推廣，很多人提出由開發敏捷轉型到運維敏捷，從而到業務敏捷。這個提議毋庸置疑，不管從文化，流程以及工具層面都是很好的延伸。可以說敏捷方法，敏捷工具為DevOps理念提供了很好的理論指導和工具支持。近些年來很多公司逐漸開始進行敏捷實踐，比如說項目經理變成了Scrum主管，用戶故事替代了以前的需求，開發計劃變成了更短的沖刺計劃。以前每周一次的組會變成了每天的站會。一開始大家都精神滿滿，久而久之覺得每天的站會太麻煩。而Scrum主管還是以前那個逼著大家干活兒的項目經理。沖刺使得開發周期變短了，能做的功能也變少了。頻繁上線給運維人員帶來更大的壓力，生產環境的Bug似乎比以前還要多。
“如果不了解團隊自治，責任共擔，面向交付，那就不了解DevOps文化。”

Devops實踐

自治型的小型化團隊

自治型組織.jpg

這點對于很多公司，特別是目前國內的諸多公司來講也許很難做到。組織的自治意味著控制力的減弱。控制力的減弱加上人類天生的惰性將導致項目的失敗。這可能是團隊轉型中存在的共同問題。實際上自治并不是說缺乏管理，而是說對目標做出正確的期望，對結果做出合理評價。中間的過程通過一系列的檢查點做出指導和糾正。其余的工作交給團隊去協調完成。

Image_20170601100812.jpg

首先敏捷實踐中將用戶故事，任務等明確責任人，這是非常好的做法。明確了責任，大家才能向目標邁進。而另一個責任共擔的好辦法是讓每個人參與團隊計劃的制定，大家幫助任務的負責人共同估算出故事點。這樣不僅會培養團隊成員的責任感，并且最終估算的結果會比項目經理自己做出的決策更加準確。在項目執行的時候，看板等工具的運用使團隊中每個參與者的工作都具有相同的可見性。以看板中待辦項以及任務狀態確定每天站會的內容。而不是架構師匯報技術難點，項目經理匯報開發狀態，大多數人被忽略的情況。

Image_20170601101332.jpg

不超過10人的小團隊被很多企業證明是一個良好的實踐。可以讓對的人去做擅長的事，如果團隊過大很多人無法承擔合適自己的角色也是一種浪費。另外隨著持續交付的演進，產品總有新的需求，也有舊的問題。如何合理分配人員從而做到一石二鳥？一些組織開始將團隊分為若干個特性團隊和維護團隊。這樣能帶來以下好處：

• 每個特性團隊都有一個架構師，同時也是Scrum主管。由于人數小所以很容易做到工作進度與工作量的管理。
• 特性團隊和維護團隊，互相輪崗。在維護團隊中，成員可以接觸客戶，新成員可以通過修復Bug熟悉產品，對產品足夠成熟后再輪崗到特性團隊。
• 不同的小團隊甚至可以不用在一個地方。
• 從DevOps的角度，一個大的產品團隊就可以完成項目開發到上線的整個交付工作。

全程可控的追溯工具

核心的概念其實就是讓我們在工具上所做的事情在不同的生命周期時可以做到全鏈路的可追溯，因此我們給出以下實踐：

• 從需求出發，驅動任務執行。
• 任務和代碼生產相結合，進行追溯。
• 以任務為單位進行持續集成。
• 以需求為單位進行持續交付。
• 以質量為綱，進行系統驗收。
• 運維規范化。
• 隨時隨地的溝通。
• 持續監控，持續改進。

基于以上的思維，越來越多的公司都會在原有開源工具之上，構建devops環境。 核心工具如下（網上的圖片和我自己用的不一樣）：

image.png

這種集成方式給運維帶來的改變可能要多于傳統的研發，因為傳統的運維在方法論，工具，規范程度等方面還遠不及開發，比如說：

• 與很多成熟的開發流程脫節，以及生產環境的相對隔離造成了運維的黑賬本（碎片化的腳本）。
• 環境部署后，使用者和管理者的信息不同步造成了很多僵尸系統。

實時的度量驅動

軟件開發過程中充滿了各種各樣不確定的因素，有時一個小情況的出現就會成大程度影響軟件產品的按時交付。對于中高層管理者來講，只能通過重復的人工周報月報來獲取信息。然而不及時，且摻雜人工數據的報告講給決策支持帶來很大的誤導。DevOps就是要將數據鏈路打通，為管理者提供實時，準確的生命周期數據。使管理者在風險到來之前有效的對其管控。

image.png

可能在傳統的印象中度量不就是一堆報表嗎？其實這里有個很大的誤區，那就是度量的方法更多的是通過數據看趨勢，事先為管理決策作出支持，而不是事后分析。比如說項目經理在看到缺陷不斷呈現上升趨勢就應該去尋找問題，進行干預。Scrum主管在看到任務周轉時間要長于原先的預估時間，那就要評估原先的沖刺計劃是否能達成。實施度量正是切合敏捷的擁抱變化的理念，幫助項目的參與者盡早的發現問題，在需要的時刻做出干預。

將以上三者結合起來

image.png

用什么方法能將三者融合起來呢？我們發現使用Kanban（看板）Baseline(基線)和Pipeline(管道)這三種方法可以將任務管理，版本控制，過程管理緊密的聯系在一起。
看板：以任務的狀態為核心，管理在制品的生產情況。任務是自組織團隊的工作契約。
基線：以工件的版本為核心，選取合格的交付物。比如說開發團隊決定哪個代碼提交版本，或者編譯的構建版本為最終交付的版本。度量指導基線的產生。
管道：以生命周期階段為核心，控制基線交付物的投產。比如說一個合格的代碼基線目前處于編譯態，還是部署態。自動化工具圍繞管道互相集成。

image.png

那什么又是將這三者融合在一起的方法呢？答案就是工作項（WorkItem）。它涵蓋了需求（長篇故事，特性，用戶故事），開發（任務，缺陷）,測試（測試用例，測試計劃）等。
工作項是看板展示的最小單元，看板的泳道就是工作項的狀態。
基線是通過需求工作項規劃，任務工作項生產，測試工作項驗收的最終產物。
工作項是生命周期不同交付物的容器，交付物的最終投產通過管道體現。

image.png

最近這幾年可以說IT行業發生了一個質的改變。不論從方法論，還是軟件工具以及基礎設施都讓軟件開發這件事與業務結合的越來越緊密。可以說DevOps就是云平臺開發運營的指導思想。在人員角色方面，推崇全棧工程師，讓開發者更貼近業務。在開發方法方面，而在這個平臺之上從開發到運營流轉的交付物就是以微服務方法開發的應用。在物理形態方面，以容器的方式交付到生產部門運營。對于使用者來講，這種業務的最終交付形態可能就是一系列的API接口，或者直接可用的應用。一切都變得平滑起來。

基于以上內容，我將如下的內容應用到日常的工作當中（目前想到的不分先后）：

• 重新定義完成的含義。之前開發部認為代碼開發完就算完成，并沒有給測試以及運維部預留時間，而今被認可的完成是開發、測試、運維整套流程走完并被認可才叫完成。
• 重新定義了變更的定義。之前膚淺的認為做重大配置改變時才叫變更，比如修改數據庫的配置文件。現在所謂的變更即對應用程序、數據庫、操作系統、網絡或硬件進行的物理、邏輯或者虛擬操作、以及其他可能對相關的服務產生影響的操作都叫變更，只不過嚴重等級不同。看似簡單，但是對于日常運維等，思維的改變很重要，會改變許多流程的定義。
• 將變更的流程通過日常訓練，讓工程師形成了一種習慣。高危險變更必須提交申請并量化，必須杜絕未經授權的高危險變更。
• 建立了可視化的工作管理工具，并在整個系統中應用起來。比如看板：在辦、待辦、已辦。比如重大變更：變更內容、開始時間等。
• 應該重視員工的加班狀況。員工加班除了自身原因之外，應該思考是否是任務分配的時候出現了問題，是否是計劃外任務導致的。有個理論，等待時間=忙碌百分比/空閑百分比，比如忙碌時間占到了日常工作的90%，空閑時間占到了10%，則等待時間就是9個單位時間。而日常的運維工作普遍存在計劃外任務的情況，所以盡力減少排隊等待的時間。
• 識別項目或者流程中的約束點并且加以保護，比如設立三級工程師。對于約束點外的改進都是徒勞的，換言之，不要讓約束點浪費任何時間，不要讓約束點為了前就別的資源而處于等待的狀態，應該專注于工作中優先級最高的那一項。
• 應該想盡辦法消除計劃外工作，它直接影響了開展計劃內工作的能力。
• 應盡量為工程師剔除無用的工作。在外企中很多強制但無用的工作直接影響了員工的時間，應對其加以控制。
• 注重例會、周報、月報的狀態更新。
• 適當的讓團隊成員展現缺陷或者脆弱面。
• 應該整體把控項目是朝著正確的方向發展，這點scrum做的很好，模塊化的工作，船小好調頭。對于IT部門，目標是提高整體的系統生產力而不是提高任務完成的數量。
• 管理好工作交接。
• 規范了第一封郵件回復格式。對于技術支持團隊，要求其中含有計劃完成時間這個強制選項。
• 在部署管道中構建和測試失敗時，采取安燈拉繩的方式，停止整條流水線的作業。看似浪費時間，實則返工造成的消耗更大。
• 必須跳出IT領域，識別由于IT引起的業務風險才能看清IT部門的任務和績效問題。比如何業務部門溝通，明確公司的愿景->細化到公司的績效->細化到業務依賴IT的方面->細化到由于IT可能會導致的業務風險等，由上而下的細化，由下而上的保證。
• 持續對IT系統實施監控并設立預警值。
• 保證開發、QA和生產環境相一致。在弄清楚所有環境保持同步之前，暫停部署。Docker和openstack很好的幫助了這一點。
• 跟上客戶需求。社會越來越多的產品是快速上線、快速消費、快速淘汰。
• 建立可同時創建開發、QA、生產環境的構建規則以及自動化機制。
  -盡量讓業務部門和IT部門作出同向的決定。
• 開發團隊不再是孤立的點而要將20%的時間用于幫助確保工作順利通過下游部門（比如QA，運維部），加快自動化測試，改進部署基礎架構。
• 在保證功能性要求的前提下，重視非功能性要求（比如可擴展性、質量操作性、安全性等）
• 建立同事評議制度確保每個人對代碼和運維工作有信心。
• 通過第二條使開發人員在工作中不斷的獲得迅速反饋：在代碼編寫時，自動單元、驗收和集成測試一直在類生產環境中，使環境也一直處于可部署的狀態。
• 對于新功能，開發部可以很早就發布但通過配置的方式對用戶不可見，在內部測試，之后以極小的，可控的狀態逐步開放。

最后我想說的是，IT像是毛細血管深入到公司的各個角落，我認為一個好的IT團隊不代表他們擁有最聰明的人，使團隊變好的因素是每個人都相互信任，同時挑戰也在于如何讓員工同心協力想著同一目標邁進。于我，盡管我所在公司以及大部門的離職率很高，但我自己的團隊在過去的兩年中至今沒有一個成員離職，這是對我個人最大的肯定。在帶領團隊的過程中，我一直遵循以下兩點：

• 我一直在工作中試著做到公平，即使沒有做到完全的公平也會讓團隊成員知道我是在盡力在做到這一點。
• 盡力為員工爭取福利，畢竟我們都是打工仔。馬老板不是說過離職就兩個原因一是不開心二是錢沒給夠。我真是在自己的職責范圍內，盡量為大家爭取福利。

另外，我也將scrum思想應用到了個人任務的日常管理中，用了teambition的看板工具將個人家庭任務列成backlog，每日更新狀態。teambition手機和電腦同步，免費版已經夠用。

最后，
感謝DrFish給予的寫作靈感；
感謝過去很多年中和自己并肩作戰的小伙伴們。
感謝壓寨夫人每日辛苦的帶小核桃給予我最寶貴的時間。

下面是devops工具的一些摘抄, 僅供自己后續學習時參考
版本控制&協作開發：GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar

自動化構建和測試:Apache Ant、Maven 、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit

持續集成&交付:Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go

容器平臺: Docker、Rocket、Ubuntu（LXC）、第三方廠商如（AWS/阿里云）

配置管理：Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible

微服務平臺：OpenShift、Cloud Foundry、Kubernetes、Mesosphere

服務開通：Puppet、Docker Swarm、Vagrant、Powershell、OpenStack Heat

日志管理：Logstash、CollectD、StatsD

監控，警告&分析：Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana