原文https://www.zhihu.com/question/24413538?sort=created
鏈接：https://www.zhihu.com/question/24413538/answer/116474416
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
我是做DevOps這個領域的創業者，跟一些中小互聯網和傳統IT公司都有過這方面的一些探討。
現在對實施DevOps有想法的公司，多半都是業務發展還不錯，在研發和運維上都比較大的壓力的公司，希望通過引入DevOps來提升公司IT部門的總體運作效率，來支撐業務的發展速度。
關於DevOps對效率的提升，Puppet出過一份調研報告，算是比較成體系的。
中文版的報告鏈接在此：http://www.idcos.com/download/devops-report
工欲善其事，必先利其器，現在大家在DevOps領域最關注的還是在工具層面。
下面是我跟這麼多公司接觸下來，大家使用比較多的工具：
1、監控工具
比較老牌的就是Zabbix,Nagios，用Zabbix的感覺是最多的。
國內的有小米開源的OpenFalcon。
這類監控工具一般是對服務器、服務（中間件，數據庫）做一些常用指標的監控。
2、性能分析/APM工具
APM很多時候被認爲是監控的一個細分領域。
但在現代複雜分佈式系統架構下，APM工具往往更能準確、直接的幫助用戶定位到性能瓶頸，比如哪一個URL訪問慢、哪一個方法執行慢、哪一個SQL執行慢。
在以往要想拿到這些數據，往往得需要比較資深的架構師、DBA一起合作才能拿到這些數據，而定位瓶頸的效率往往還不太高。
現在通過APM工具能讓普通技能的運維人員，也很高效的定位到這些深層的問題。
現在商用的APM工具不少，國外的有Newrelic，國內知名的就有聽雲、Oneapm、透視寶這些。
開源的也有Pinpoint（naver開源）、Zipkin（twitter開源）、CAT（大衆點評開源）.
3、批量+自動化運維工具
這裏就比較多了，知名的有Puppet、Ansible、Chef、Saltstack這些。
這些在網上的資料也比較多，找比較新版本的官方文檔看就行了。
Puppet和chef是比較早期的工具，受衆面也很大，不過這兩個工具基於ruby實現，現在要找到熟悉ruby的人來做這塊的二次開發可不容易。
而ansible和saltstack則相對新生代一些，目前用戶基數增長很快，基於python實現，要找做二次開發的人也相對容易的多。
4、集中日誌分析工具
在一個服務器比較多的環境下，如何集中的管理和分析、查詢日誌，已經變成一個比較強的需求了。
想象一下，如果發生了某個錯誤，你還得一臺臺機器去翻日誌文件，是不是很蛋疼。
在這個需求驅動下，就誕生了一些集中日誌分析工具。
在開源領域，比較知名的就是ELK這一套工具了，涵蓋了日誌採集、上報、搜索、展現這一類基本需求，現在比較多的上規模的企業都用這個，網上資料也大把。
核心實現機制都是通過一些日誌採集代理（類似Filebeat）去爬日誌文件，將最新的部分提交到採集服務端，後端再對接搜索引擎，能支持很快速、準確的搜索即可。
有一個國內不怎麼知名的Sentry日誌收集服務，比較輕量級，本身是Python做的，與各種語言的日誌框架做了非常好的集成，可以很方便的集中收集異常日誌，並分配給對應的開發人員。
它在github上有10000多個star了，這在DevOps相關的軟件裏，都是排名非常靠前的了。
git的地址：GitHub - getsentry/sentry: Sentry is cross-platform crash reporting built with love
5、持續集成/發佈工具
我接觸的人都是用Jenkins的，沒有用其他的，可能跟我所在的技術圈子有關。
集成打包的過程其實一般都比較簡單，配好版本庫和打包腳本就行。
但發佈的過程就比較複雜，有些是全量發佈，但也有非常多的IT團隊採用增量發佈。
這個方面如果想用工具，還是得先分析清楚現有的發佈流程，手工情況下怎麼做，哪些能通過自動化工具來完成。
最近兩年的公有云推廣比較迅速，很多新的服務器採購都被導入到雲上去了。
現在主流的公有云都提供了比較完備的API，基於這些API也可以做一些針對基礎資源的自動化操作，比如遊戲行業的快速開服。
鏈接：https://www.zhihu.com/question/24413538/answer/145048082
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
DevOps在移動應用開發中的應用，以 iOS 開發爲例
DevOps 是什麼呢？
我們先來看一張圖
<img src="https://pic4.zhimg.com/50/v2-766b9dd173926ac13d7449bcce5c3f87_hd.jpg" data-rawwidth="1300" data-rawheight="1268" class="origin_image zh-lightbox-thumb" width="1300" data-original="https://pic4.zhimg.com/v2-766b9dd173926ac13d7449bcce5c3f87_r.jpg">
Dev, QA, Ops 的交匯處我們認爲就是 DevOps。 實際上說白了，DevOps 就是把產品開發過程中各部門交匯處的活給幹了，讓各部門都專注於幹他們自己的活兒。
依稀記得，剛進公司的時候，每天工作的大頭就是給 QA， TA， PM, Boss編譯各種版本的包，真正寫代碼的時間寥寥無幾 :(
<img src="https://pic2.zhimg.com/50/v2-82efc5c06509b986951889f86fcd6479_hd.jpg" data-rawwidth="252" data-rawheight="220" class="content_image" width="252">
實際上，做過移動應用開發的都知道，iOS 需要很多版本，inHouse, Adhoc, AppStore, 以及QA還需要各種不同的環境來測試相對應的功能，TA（自動化測試）也要各種版本，每個開發還需要自己獨立的分支版本交付QA測試等。
尤其是我們團隊採用的是 scrum 開發模式，基本每兩星期就是一個迭代，上述的工作非常繁瑣，重複性又大，Dev基本上每天都在被逼着給build，QA，TA，PM又在着急的等着build，每個人都怨氣滿滿。
<img src="https://pic1.zhimg.com/50/v2-2379d2496e7bef8a07ace647710f57c4_hd.jpg" data-rawwidth="264" data-rawheight="220" class="content_image" width="264">
爲了防止各方互相扔屎 ：）， 我們很快購買了一臺 Mac Pro 作爲編譯服務器，在上面部署了Jenkins2.0。
V1.0 Jenkins Job只有幾種類型，Inhouse，Adhoc，AppStore等幾種最基本的Job
因爲iOS不同的編譯類型需要不同的證書，爲了方便，我們把不同的證書打包成 diff 文件，
下圖中這些不同後綴的Job 的配置中，會apply相對應的diff文件
<img src="https://pic4.zhimg.com/50/v2-61829457d5fa49b12bd50f51a6b71a47_hd.png" data-rawwidth="690" data-rawheight="396" class="origin_image zh-lightbox-thumb" width="690" data-original="https://pic4.zhimg.com/v2-61829457d5fa49b12bd50f51a6b71a47_r.png">
此時雖然各方已經不互相扔 shit 了，但還在互噴，主要問題在於Jenkins經常掛掉，而開發又沒有及時去fixed。原因是在於我們的 App 集成了crash監控服務crittercism，它可以做到實時監控crash數據，彙報新的crash。但是開發每次都需要手動上傳DSYM文件，很是麻煩。雖然我們用了Jenkins插件自動集成，不過Jenkins插件的支持很不好，經常在上傳DSYM的時候GG。到了後面我們自己也忍不了了，就自己寫了上傳DSYM的腳本。
考慮到TA還需要自定義產品環境，App動態的版本號和 git commit 號等，我們就直接將所有的配置都用 python,shell 腳本實現，實現了基於Jenkins Job名字的自動化配置。
App編譯結束後，我們會自動將生成的 IPA 包發佈到所需要的渠道，我們使用HockeyApp自動發佈和自動推送，而針對國內的網速，則是使用了http://fir.im .
還有針對Adhoc/App Store的上傳TestFlight的神器，叫fastlane，其中Gym和Deliver兩大神器結合使用最牛逼。可以全自動上傳App Store，不僅傻瓜化好用，而且還帶push notification功能。(該功能慎用，至於爲什麼自己去搜咯 ：)
放出小部分腳本代碼
#jenkins environment variable
jenkinsJOB_NAME = os.environ.get('JOB_NAME', '') ## MEANS This is running in jenkins ,not local
if jenkinsJOB_NAME:
#os.system("git reset --hard HEAD") #need run this in jenkins shell, otherwise will discard user's committed code
isInhouse = jenkinsJOB_NAME.lower().find("inhouse")
isHockeyApp = jenkinsJOB_NAME.lower().find("hockeyapp")
isAdhoc = jenkinsJOB_NAME.lower().find("adhoc")
isDevelopment = jenkinsJOB_NAME.lower().find("development")
isAppStore = jenkinsJOB_NAME.lower().find("appstore")
isTaXMN = jenkinsJOB_NAME.lower().find("ta-xmnlab")
經過好幾次的升級之後，現在Jenkins Job基本都比較穩定了，如果某個開發需要提供自己所開發功能的build， 只需要 copy一份相對應的Job 配置， 改掉代碼指向，就可以了，前後花費時間不超過 30s，甚至QA在需要的時候也可以自己手動觸發Job編譯自己需要的Build。從那以後，我明顯能夠感覺到漂亮的 QA妹子花在 Dev 單身狗身上的時間更少了，說好的天天喊我給Build的呢。
<img src="https://pic1.zhimg.com/50/v2-2121ecccb910e2e470de12b32bb82b8c_hd.jpg" data-rawwidth="297" data-rawheight="220" class="content_image" width="297">
最後放一個小彩蛋，
<img src="https://pic1.zhimg.com/50/v2-e383c25578c80ae95ae37a759194dcc8_hd.jpg" data-rawwidth="210" data-rawheight="193" class="content_image" width="210">
不好意思，放錯圖了，
<img src="https://pic4.zhimg.com/50/v2-77e81d3b83da50442b8b99d4c05c03b7_hd.jpg" data-rawwidth="216" data-rawheight="220" class="content_image" width="216">
我們在Job的name 中加了一個 LED 的關鍵字，如果Job 編譯成功了，綠燈，啥事也沒有，但是，要是Job掛了，這個就會滴滴滴地響，你可以想象一下，在Jenkins上建幾十個Job，然後讓每個Job都掛掉，那真是蛙聲一片。
不過這個還是得看個人需要吧，我們目前只有兩個Job配置了這種高端貨，並且只有失敗的第一次會響三聲。
來，贊一下：）
鏈接：https://www.zhihu.com/question/24413538/answer/139454464
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
DevOps一種概念、一種思想，很難界定說DevOps該做什麼，不該做什麼。
在工作的過程中，我從來沒有向團隊同事提起過“DevOps”這個單詞。這個新型英語單詞的發音/devɒps/，就算髮音準確了，你還得跟別人再拼讀一次D.E.V.O.P.S ；拼讀完了，還得介紹它是Development Operations的簡稱；接下來還要跟他們介紹什麼含義。這不但顯得自己裝逼，還賣概念賣理論搞得別人暈頭轉向，讓別人不知道怎麼回事。
日常中，一般溝通時，更多是用“自動化”這個詞，自動化編譯、自動化部署、自動化發佈等等。對普通非技術類人員來說（比如遊戲項目裏的策劃和美術），雖然還沒聽過DevOps這個概念，但其實已經應用在自己的日常工作中了。
實施
我對效率工具熱愛，在開發的工具中處處追求自動化來提高生產力，這是前Unity遊戲項目（2014-2015年）的一個DevOps工具鏈的嘗試：
<img src="https://pic1.zhimg.com/50/v2-3670fc84c0a1c3215c7f8a1540c308cc_hd.png" class="content_image">
查看大圖：https://pic1.zhimg.com/v2-3670fc84c0a1c3215c7f8a1540c308cc.png
簡單說下日常自動化流水線，
Redmine：任務的管理，工作的分配；由項目經歷、遊戲策劃進行工作調度，在工作完成後，爲任務標記上“待測試”，進入測試狀態；在測試完成後，標記“已測試”，以維持基本的日常任務進度。
Subversion(SVN)：作爲團隊開發的基礎，各人的工作按照規範往上進行提交；包括程序、策劃和美術工作成果，都往SVN版本庫上傳。
Jenkins：當SVN提交完成後，觸發鉤子，進行編譯工作；（另有每晚凌晨定時）除編譯工作以外，Jenkins還會承擔各種有自動化需求的工作，如測試環境的部署。 它是開發、運維連接的核心橋樑。
私有云虛擬機：當Jenkins完成編譯工作後，立刻在內網部署服務器並啓動；
軟件倉庫：到這裏已經驗證提交的結果能正常運行了，將產物放到軟件倉庫歸檔；本質上它其實就是一個簡單的http文件服務器，可以通過瀏覽器（如h5ai等插件）來查看和管理文件。
Supervisord：啓動的服務器的進程管理；它有監控功能，能監視進程的健康狀況。
ELK：ElasticSearch+LogStack+Kibana，日誌的收集和查詢；所有的遊戲客戶端日誌，都會通過UDP的方式，上傳到ELK日誌系統。在日常第三方出現問題是，能通過該日誌系統快速定位問題。
測試驗收：回到Redmine，根據任務的內容，把它當做測試用例來測試；
Ansible：自動化配置、運維，從軟件倉庫獲取軟件，對多臺機器進行批量部署；
FIR.im：部署外網，外網也可以體驗到最新Demo；
至此一次成功的發佈完成了，這種發佈，每天都會進行無數次。任意環節失敗了，會發送郵件進行預警，看是誰的鍋。
老實說，其實最初使用Jenkins+Redmine+Ansible等工具鏈的時候，我們還不知道“DevOps”這個名堂，是後來才瞭解這個概念的。可以說，當時推行“自動化”這個出發點開始使用各種自動化工具的時候，已經逐漸的走上DevOps的路了。
改變
DevOps帶給開發團隊怎樣的改變？ 舉一些剛入行的經歷：
一個遊戲項目裏，有程序、策劃、美術的分工。那時候，一個美術完成他們的場景編輯後，會用Unity打包一個Package，發給某一個策劃；策劃同學，收到這個Package，導入到Unity，然後整理場景格式，之後進行Asset Bundle導出，並進行SVN的提交。這時候程序同學，更新到SVN下來，發現Asset Bundle資源是錯的，跟策劃同學說；策劃同學跑去跟美術同學說，美術同學修復；美術修復完了，再打Package，又給策劃同學........（循環，一天過去了）。
經過一個月的開發，我們要發佈新版本的IPA程序了，已經有一個月的時間，沒有編譯過最終產品了，不知道編譯是否順利。這時候，老大一聲下令，把SVN鎖了，然後打開Unity，手工編譯Xcode工程； 但是發現有一個依賴庫問題，修復，再手工編譯，又發現一個BUG，再重新來...........（循環，一天過去了）
要發佈一個DEMO給外網的合作，一個熟悉Linux負責測試的同學，開始在Linux上手工進行編譯，然後SSH上去服務器，上傳服務器文件，執行各種命令，進行服務器的啓動、停止。 哦，發現一個BUG，要馬上改，改完了，重複之前說的步驟..........（循環，一天過去了）
如今看起來啼笑皆非的重複勞動力，當時是確確實實的存在的。入行之初我就對這些現象非常的震驚，我萬萬沒想到做程序員的人居然是這個樣子的。 這也是後來在主導的項目中引入了這些工具鏈，也算是DevOps的實施嘗試吧。
是否引入DevOps思想或DevOps相關工具鏈，這對一個開發團隊的影響是十分的深的，這不光體現在編譯、運維，甚至還會影響開發人員的編程風格 —— DevOps思想強調自動化，而編程的過程中，一些重複累贅的代碼也是應該通過自動化來解決的。
未來
在我看來，引入DevOps工具鏈可以節省成噸的成本：包括時間成本，人力成本。 實施DevOps前，從上面的案例中可以看到，其實每個工具，都可能需要一個特定的人來完成的，工作量分佈下去，可不是一件小事情了，很容易就讓人在坑中度過漫長歲月。
跟之前相比，現階段所整合實施工具就更多了，比如：
Docker、Zabbix、Sentry、Rundeck等等等。
在我看來，這個領域還有一個殺手級的應用程序可以發展，可以把這一切整合一起的，它應該是一個類似Jenkins這種任務流的產品，並比它更好用，更完善的GUI。個人之力無法實現，只能期待未來有這樣的產品出現——也許，這個產品，就是人工智能的催化產物。
DevOps企業
與以前相比，這些工具鏈，也不一定事必躬親，已經有很多的雲計算企業有這方便的幫助了：
華爲開發雲
這類產品本身是非常好的，但要讓這種思想讓普通人都容易理解，才能讓它們真正的普及、整合起來。 傳播、佈道是關鍵。