從電子遊戲到DevOps

cornerstone發表於2019-07-01
遊戲dev

從電子遊戲到DevOps

在一個專案團隊中，開發與運維之間的關係像極了知名大型遊戲《刺客信條》裡的故事：開發就是追求自由的刺客聯盟——我喜歡用各種新穎技術手段去滿足使用者爸爸那些花裡胡哨的需求，你別管那技術好不好用，總之它實現了需求；運維就是那支援秩序的聖殿騎士——我要的是穩定執行！穩定執行！穩定執行啊！
從電子遊戲到DevOps
於是，產品與運維之間形成了一道牆。
開發部門夜以繼日地打造出自己的“傑作”，並懷著今晚就能開慶功會的心情把自己的“傑作”交給了運維部門，殊不知牆那面的運維們對開發的抱怨才剛剛開始：
l  這款優秀的產品在目前的底層平臺上無法執行，因為這個平臺太古老了，因為這個平臺空間不足，因為這個平臺不支援某某版本……
l  這款產品的體系結構跟我們的{儲存，網路，部署，安全}模型不匹配。
l  這款產品的報告、安全、監視、備份balabalabala 我們搞不懂 ，所以沒法把它做成實際可用的產品。
當運維將問題源源不斷地反饋給開發後，開發的回覆一定是：
l  這不是我們的錯，我們的程式碼非常完美，是（運維部門的）部署做的太差勁了。
l  運維部門比較笨，他們不懂新技術，為什麼他們沒法實現最新的技術呢？為什麼他們這麼落伍呢？
l  在我的機器上執行的沒問題啊……
刺客聯盟與聖殿騎士互掐了幾百年，但事實上他倆都不過是想維護人類文明；開發與運維互看不順眼，但他們的初心都是想這個專案能順利驗收。
雖然開發和運維這樣相愛相殺的關係看上去和遊戲很像，但其對專案的危害性可不是遊戲，開發與運維陷入一場暴風驟雨，客戶則成了蒙受損失的一方，最終團隊失去了客戶，失去了金錢，失去了專案。
DevOps就是為了讓開發和運維告別這樣的悲劇而被提出的。它是一種框架，包含了很多優秀想法和原則，它重視開發部門和運維部門打破隔牆，通力合作。
DevOps希望做到的是軟體產品交付過程中IT工具鏈的打通，使得各個團隊減少時間損耗，更加高效地協同工作。專家們總結出了下面這個DevOps能力圖，良好的閉環可以大大增加整體的產出。
從電子遊戲到DevOps
在DevOps環境中，開發人員和系統管理員會構建一些關係、流程和工具，從而更好的與客戶互動，最終提供更好的服務。
DevOps的三大原則
基礎設施即程式碼
DeveOps的基礎是將重複的事情使用自動化指令碼或軟體來實現，例如Docker（容器化）、Jenkins（持續整合）、Puppet（基礎架構構建）、Vagrant（虛擬化平臺）等；
持續交付
持續交付是在生產環境釋出可靠的軟體並交付給使用者使用。而持續部署則不一定交付給使用者使用。涉及到2個時間，TTR（Time to Repair）修復時間，TTM（Time To Marketing）產品上線時間。要做到高效交付可靠的軟體，需要儘可能的減少這2個時間。部署可以有多種方式，比如藍綠部署、金絲雀部署等；
協同工作
開發者和運維人員必須定期進行密切的合作。開發應該把運維角色理解成軟體的另一個使用者群體。協作有幾個的建議：a、自動化（減少不必要的協作）；b、小範圍（每次修改的內容不宜過多，減少釋出的風險）；c、統一資訊集散地（如wiki，讓雙方能夠共享資訊）；d、標準化協作工具（比如jenkins）。
DevOps的影響
交付
使用DevOps有多爽？有調查報告發現，在2016年，根據全球4600位各IT公司的技術工作者的提交資料統計，得出使用DevOps的公司團隊平均每年可以完成1460次部署。與傳統組織相比，DevOps組織的部署頻繁200倍，產品投入使用速度快2555倍，服務恢復速度快24倍。
協調合作
強有力的釋出協調人彌合了開發與運營之間的技能鴻溝和溝通鴻溝，採用電子資料表、電話會議、即時訊息、企業門戶（wiki、sharepoint）等協作工具來確保所有相關人員理解變更的內容並全力合作。
自動化
強大的部署自動化手段確保部署任務的可重複性、減少部署出錯的可能性。
如今，IT行業已經越來越與市場的經濟發展緊密掛鉤，能否讓公司的IT配套方案及時跟上市場需求的步伐，在今天顯得至關重要，DevOps或許就是給與公司和團隊的一劑良方。
最後推薦幾個在實現DevOps上已很成熟的專案管理工具：CORNERSTONE、Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker。
要說這些工具各有什麼特色，改天我們再聊吧。話說不知道刺客信條故事的最後結局會不會也和運維與開發一樣，最終兩個派系握手言和共同進退呢……


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69933591/viewspace-2649235/，如需轉載，請註明出處，否則將追究法律責任。

相關文章