【編者的話】DevOps這個話題已經鋪天蓋地了，從方法論到流程再到工具，可謂前人之述備矣。今天再談DevOps，我想分享下DevOps實施過程中的痛點和思考。
DevOps 究竟是什麼
敏捷方法論在數年前被奉為金科玉律，以至於出現了敏捷教練這個角色，使命是幫助企業改善產品研發流程，提升效率和質量。網際網路的快速發展，各類產品迭代速度驚人，使得企業意識到必須有一套新的方法論、流程和工具來提升企業競爭力。競爭力的差距不再是活的好不好的問題，而是能不能活下去的問題。生死存亡之際，於是紛紛希望通過DevOps這一個全新的理念實現快速迭代，更快地實現管理者的意圖，畢竟效率決定生死。
所以，DevOps是一種改善產品生產流程，提升競爭力的手段。本質上來說，軟體研發也是生產活動，只是有一些特殊而已。DevOps能做的是將各自擅長的領域劃分開，設計、開發、測試、運維關注在自己的核心領域，本質上與微服務架構的核心思想一致，都是分而治之，實現精細化操作與管理。責任明確、守土有責，那麼人就成為了關鍵因素，人的積極性調動了，很多事情就很好解決了。
DevOps 如何實施
企業內部的研發流程往往存在很久，從內部開始是最好的做法，從內部突破、發掘痛點才能真正實現產品的“歸零”。這裡有兩個誤區要避免：
按照既有的內部流程和工具設計一套DevOps系統；
希望打造一個大而全的東西覆蓋所有需求；
從內部需求出發沒有問題，關鍵是需要甄別哪些是合理的，哪些是需要改造甚至重新來做的。怎樣的流程才合理，哪些工具才合適當然跟設計人員的視野有關，但參考業內一些比較好的案例，基本上也能找到較好的解決方案。
DevOps系統也必須遵循在核心需求的基礎上迭代的原則，往往蒐集DevOps需求的時候，從BA到設計、開發、測試、運維到專案管理者各種需求層出不窮，他們都希望DevOps能幫助他們解決目前遇到的痛點或者不爽點，但是往往讓DevOps設計人員難以抓住核心需求。
記得在一個大中型公司的DevOps啟動會上，負責人面對著眾多相關人員的眼睛，在臺上說的第一句話是DevOps專案80%都失敗了。他說出這句話的時候，其實已經說明這不是一個容易的事情。對既定流程的更改、對現用工具的更新換代都會給各個相關崗位的人員帶來一定的工作量。
那麼DevOps如何實施呢？
- 工具鏈
- 管理平臺
- KPI
- Pipeline
DevOps相關的工具非常多，全部都可以採用開源工具，比如GitLab + Jenkins + Sonar + Robot + Kubenetes等等，當然最新開源的Spinnaker對於多雲環境的部署有著非常好的支援，這方面也非常值得引入。對於傳統專案中，通常會使用Jenkins配合諸多外掛實現一鍵打包和部署。
對於管理平臺而言，就需要一個統一的門戶來管理各個工具。與各個工具的互動均以API形式進行，使用者也不必管理在各個工具裡面的使用者和許可權資訊。最關鍵的是，通過一個統一的管理平臺，可以很方便地將這些資訊與專案管理資訊對接起來，從專案維度看整個DevOps流程。
能夠從相關管理角度看DevOps，那麼很自然就可以想到使用KPI Dashboard的形式提供一個專案監控功能，方便檢視整個的程式。比如，專案進行到哪個Sprint，每個微服務的開發進度，構建情況、部署情況，運維相關情況等等。
Pipeline是規範化的操作流程，結合視覺化的設計，方便設計人員對流程進行管理，固化某些最佳實踐實現複用。將Pipeline與產品的版本及專案關聯能夠很方便地追蹤產品的整個生命週期情況，方便進行評估。
痛點在何處
既有專案的複雜依賴
通常一個專案的開發是基於一些已有的基礎性內容，經年累月就會出現一個專案的依賴來自於另外兩三個專案的Nexus倉庫。只有具體負責專案的人才瞭解這些依賴，甚至經過專案人員流轉，專案組成員也很難說清楚具體的依賴關係。
在做微服務改造的時候，很大部分時間就是在梳理這些依賴關係，然後一點點剝離，最終才能實現獨立分發部署。然而整個過程中需要大量的專案相關人員的配合與參與，具體推進速度如何就取決於專案人員的配合程度了。
Jenkins 構建
部署環境相關資訊多通過GitLab進行管理，由於Jenkins Job中CI和CD捆綁在一起，直接使用程式碼中的環境資訊進行釋出，自然簡單快捷。這是基於開發人員對部署環境非常熟悉的情況，但是對於DevOps平臺來說，問題就很嚴重了。往往版本的構建和釋出是兩個階段，中間需要稽核操作，其次開發和環境資訊是隔離的，環境資訊必須在部署前通過系統注入進去，而不是在程式碼中寫成HardCode。
Job 改造
另外一個問題是Jenkins Job的定義方式，通常都採用直接定義，而不是採用DSL Pipe的形式進行定義。對於DevOps平臺來說，程式碼構建和部署的Pipeline是跟產品的階段、版本繫結的。必須可以在一個統一的管理平臺上進行定義，DSL這種Pipeline描述語言就是為這種需求而生。設施DevOps意味著這類的Job的定義必須進行改造。
版本控制
實際專案開發過程涉及到專案與構建、部署資訊需要打通的問題，即能夠方便清晰地看到專案的版本有哪些微服務、每個微服務經歷了哪些版本迭代、每個迭代經歷了哪些構建等等。需要將原來的線下版本控制流程搬到線上，並且關聯到具體的每一個構建和部署。
對程式碼的要求
很多專案由於非核心部分，在單元測試、程式碼的規範等要求不太夠。當使用SonarQube等程式碼質量控制工具進行檢查後，就會出現程式碼的測試覆蓋率、規範等等影響開發行為的事情，這時候對於程式碼簽入、PR合入的原則都有了新的要求。
總結
每個企業對與DevOps專案都有不同的期許，對於打造DevOps平臺的企業來說，也是必須逐個擊破痛點。DevOps涉及到的方面多、影響比較大，但不得不否認，其帶來的影響力也是巨大的，推進DevOps的過程也是很艱辛的，但總體來說，還是很值得各個型別的企業在這個上面進行一番探索的。