資訊專欄INFORMATION COLUMN
摘要：當云平臺出現網絡故障系統故障等問題，這對云租戶用戶有時甚至是致命的，所以不少是由高級別開發人員轉型而來。目前國內各大云廠商也基本都提供了應用運維平臺，包括騰訊藍鯨阿里華為等。
DevOps 全鏈路
下圖是我們熟知的軟件研發環節，在迭代頻率高的研發組織里，一天可能要經歷多次如下循環。對于用戶群體龐大或者正在經歷大幅業務擴張的企業研發組織，除了重點關注應用的快速上線之外，如何保障應用的高可靠、高可用也成為焦點，即服務上線要快，運行要好。
如何讓開發更簡單，運行更高效，接下來我們從兩個角度來探討這個問題：
組織方式
研發工具
關于運維人員的組織方式一種方式是組建專門的運維團隊，一個運維團隊往往會承接多個開發團隊的協作。除了 DBA 這類針對某個中間件的運維之外，這種模式的弊端在于不少運維工程師深陷于環境配置、日志收集、業務恢復、現象記錄等瑣碎事情當中，沒有時間閱讀項目源碼以及提升能力，對較為深入的業務問題分析困難，開發團隊又往往無暇分身，運維容易陷入被動的境地。
另一種方式，開發人同時負責各自模塊的開發與運維。好處自然是由于開發人員熟悉本模塊源碼，定位問題的效率要高出不少。同時開發者可以直接得到下游用戶使用反饋，將其融入到研發當中去。壞處在于，讓開發人員陷入到頻繁的用戶問題定位之后，難以保證代碼開發的時間。
近年來，國內也興起了 SRE 這種高級運維職業，特別是在云計算行業，SRE 的職業要求非常高，需要精通諸如網絡、編程、算法、數據結構、操作系統、安全等知識與技能。當云平臺出現網絡故障、系統故障等問題，這對云租戶/用戶有時甚至是致命的，所以不少 SRE 是由高級別開發人員轉型而來。
在 Google SRE 的服務可靠性層級當中，SRE 通過產品、開發、容量規劃、測試、根因分析、事件響應、監控七個層次的實踐來確保應用服務的健康狀態。從這個層級當中我們可以看出 Google 提倡運維要積極控制服務發展的方向，而不僅僅在事故發生后反應性地滅火。目前來看，SRE 這種精英式的運維在國內還有待探索與實踐。
粗暴地將開發運維拆開，或者將開發運維簡單合并，都不是特別合適的一種方式。從筆者的研發經驗看，一種方式可供大家思考與討論——根據業務實際情況做分工：比如由團隊內的開發者輪流負責整個項目運維。由于各個開發者對項目公共代碼都需要熟悉，在理解其它模塊代碼也相對快速，這種方式基本能消滅大部分的問題，剩下的一小部分可以和指定模塊的負責人結對定位。除此之外，為“每個服務團隊分派運維聯絡人”，“邀請運維工程師參加開發團隊的會議”都是能夠加強運維與開發之間協作的措施。
關于工具的使用除了恰當的人員組織方式之外，合適的工具也能給研發團隊注入能力。
在配置研發環境時，研發組織可以選擇通過開源工具自建代碼管理和持續構建環境。這種方式的缺點在于需要有專門的 CI 團隊來維護持續構建環境，一旦環境被破壞，開發的腳步就會停滯。并且由于各個開源工具數據未打通，開發人員要在多個工具之間切換使用。另外一種方式就可以通過現有的軟件研發管理系統，例如 CODING 研發管理系統，來實現一站式的研發流程管理，無需自建、維護眾多的研發工具與研發環境，支持在瀏覽器中完成全套軟件開發流程，真正做到了 Coding Anytime Anywhere。
當開發人員通過 CODING 研發管理系統快速開發并部署好應用后，下一步就要讓應用在運維工具的輔助監控下可靠運行（并不是所有應用都需要運維工具，需對癥下藥）。研發組織可以選擇自己開發運維工具，也可以選擇現有的運維工具。
目前的運維工具逐漸地朝以應用為中心發展，因為應用是直接向用戶提供業務能力的，無論是開發還是運維，都是被業務價值驅動的。主流的運維工具主要涵蓋基礎設施層監控、應用層面監控、業務層面的分析與監控。
接下來我們看看現有的運維工具一般會提供哪些具體能力：
基礎設施環境的監控：對服務器整體的 CPU、內存、磁盤、文件系統、網絡等資源占用情況進行上報。
應用性能監控：針對應用使用的中間件，例如持久化數據庫、緩存數據庫、消息中間件等訪問效率進行監控；以及對應用本身請求響應速度進行監控，包括延遲、吞吐量等等。
應用調用鏈路追蹤：在分布式系統下，一個請求往往需要經過多個進程處理完畢。當出現用戶請求調用失敗或者出錯時，運維平臺支持整個調用鏈路的分析與故障環節定位。
日志數據采集與分析：日志的采集主要是為了輔助應用調用鏈路分析以及性能監控，運維人員無需進入后臺去大量翻找日志。
故障自動恢復
靈活的告警
可視化面板展示監控與告警信息
國外熱度較高的運維工具包括 ZIPKIN（分布式追蹤），pinpoint（分布式追蹤），logstash（數據收集）等等。目前國內各大云廠商也基本都提供了應用運維平臺，包括騰訊藍鯨、阿里 ARMS、華為 APM 等。以下是這幾個運維平臺能力的簡要對比：
目前大部分的運維平臺主要通過 Agent 和探針的方式去采集應用的指標信息，匯總處理后反應在可視化界面上。除上述的工具和平臺之外，AIOps 也逐漸成為未來的一個趨勢，AIOps 通過 AI 技術的運用來進行智能業務故障診斷，同時自動恢復應用故障，企圖讓研發組織徹底告別人肉運維時代，筆者也萬分期待這天的到來。運維人員不用擔心因 AIOps 失業，工具和平臺只是提升運維效率，不會取代運維。
在運維階段發現缺陷后，開發人員可在 CODING 中處理對應的缺陷，記錄下每個缺陷的類型、優先級、模塊、描述、處理人等信息。軟件缺陷是不可避免的，但只有通過對缺陷進行管理和復盤才能知道缺陷產生的原因（人為因素 / 環境因素 / 工具問題等），從而改進，避免類似缺陷的重復。對缺陷的管理也有助于管理人員對軟件質量的正確評估。缺陷處理人通過 CODING 實現缺陷的快速修復和部署，可大大縮短故障恢復時間，減少因缺陷產生的業務損失。
在 DevOps 理念的指導下，筆者建議開發人員在開發業務代碼時，除了功能之外，也應當思考如何開發可運維的代碼，通過適當的日志、錯誤碼、異常等措施來提升運維效率；運維人員也需逐步提升能力，從傳統的繁雜運維當中轉型，走上敏捷自動化的運維之路。
寫在最后我們可以看到隨著 DevOps 工具鏈自動化顯著提升，DevOps 的門檻變得更加地低。擁抱自動化的結果是研發過程會變得越來越安靜，頂尖的開源項目里的 committers 在日常僅僅是通過郵件和 issue 將事情說清楚，沒有熱火朝天、冗長拖沓的會議；也沒有花花綠綠，色彩斑斕的工作表格。但這些都是建立在 DevOps 良好實踐的基礎之上。我們相信在踐行 DevOps 的道路上，未來軟件的開發會更簡單，運行也會更加高效。
參考：
https://www.collab.net
https://landing.google.com/sr...
吉恩·金（Gene Kim）；耶斯·亨布爾（Jez Humble）；帕特里克·德布瓦（Patrick Debois）；約翰·威爾斯（John Willis）.《DevOps 實踐指南》
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/8109.html
摘要：對于商業市場來說，特別是中國這樣一個云計算才剛剛起步的市場。反觀云計算售賣的一些商品，目前主要還是以服務器為主。云計算的本質是將計算能力轉化為標準化，可售賣的服務。可以說是云計算實踐的一個經典案例。有的人會問，云計算廠商需要提供哪些服務。 2015年伊始，國內云計算市場可謂風起云涌。各路群豪紛紛涌入這個市場。其中最活躍的領域當屬IAAS。阿里騰訊硝煙未盡，百度重新檢討了自己的PAAS戰略后，...
摘要：北京時間月日月日，由和中國國際人才交流基金會聯合主辦的第七屆全球軟件案例研究峰會簡稱在北京國家會議中心圓滿落幕。本屆峰會，來自阿里美團百度平安銀行等企業的講師分別從企業轉型及研發效能方面分享敏捷和的實踐細節和操作經驗。 北京時間11月30日-12月3日，由msup和中國國際人才交流基金會聯合主辦的第七屆全球軟件案例研究峰會（簡稱：TOP100summit）在北京國家會議中心圓滿落幕。T...
摘要：雖然已經成為了云領域的容器技術之王，但一個新的挑戰者已經出現了。擁有一套集群來連接其他的集群服務，例如以及亞馬遜的容器服務等。也對有著同樣的關注，后者是谷歌的開源容器管理器。微軟公司于近期實施了，這是企業應用容器技術的一個共同選擇。 雖然Docker已經成為了云領域的容器技術之王，但一個新的挑戰者已經出現了。專家David Linthicum針對這一競爭進行了分析。隨著新的一輪競爭開始，容器...
亞馬遜賣家專用vps有沒有?亞馬遜賣家最害怕的是什么，那就是被檢測到使用同一個IP地址運營多個店鋪，導致店鋪被封禁的情況，而云服務器可以完美解決這種問題，至于原因為何，且聽我滿滿道來!哪家亞馬遜云主機好用呢?只要IP純凈，服務器穩定，用于亞馬遜是很安全的，你可以百度搜索易探云，這家是專業的海外運營云服務器商家，同時推出美國電商云，保證IP純凈～搞亞馬遜運營店鋪，云服務器是絕佳選擇，而易探云優惠力度...
閱讀 1399·2021-09-02 09:53
閱讀 2667·2021-07-29 13:50
閱讀 1714·2019-08-30 11:07
閱讀 1570·2019-08-30 11:00
閱讀 1449·2019-08-29 14:00
閱讀 1843·2019-08-29 12:52
閱讀 2559·2019-08-29 11:11
閱讀 3415·2019-08-26 12:23
