如今很多人認為devops將徹底取代傳統運維，我不這麼認為，在我看來devops只是很大程度上的代替了傳統運維的手工操作，運維人員只需寫好自動化運維指令碼，利用自動化工具（zabbix，elk，ansible等）就可以實現自動發布和監控，省去了很多人力。因此devops能否順利落地，運維平台的建設將會很重要。本文主要簡單介紹下我司的三大運維平台。
運維職責運維平台當前我司運維平台主要有3個：持續整合和交付
①基於jenkins持續構建
②支援容器化打包和部署
③發布平台，支援灰度發布，異常快速回滾
監控告警平台
①完善的監控體系：覆蓋機器、網路、服務和客戶裝置維度
②快速的異常發現和告警
問題定位平台
①基於elk實現日誌採集、上報、告警
②採集軟體平台所有元件的執行日誌
③通過呼叫鏈分析和定位裝置問題
平台運營情況
持續整合和交付持續整合(ci)，微服務元件全部改造成容器化部署，並通過k8s實現編排。
持續交付(cd)，做乙個版本發布平台：支援灰度、藍綠發布、版本回滾。
監控平台公司之前一直使用的是zabbix+grafana的監控方式，隨著我們的微服務推行容器化後，k8s應用的監控需求增加，prometheus會更適合容器的監控。另外，prometheus用的就是自研的 tsdb，zabbix 則用的是 mysql 或 postgresql，在高併發的情況下，時序型資料庫讀寫效能是遠高於關係型資料庫的，同時還提供了很多內建的基於時間的處理函式，簡化資料聚合的難度。因此我們現在也逐步將zabbix遷移到prometheus。目前監控平台採集覆蓋基礎資源38項，102個元件、9項業務監控。問題定位平台背景：線上使用者反饋裝置使用異常，研發或qa介入排查，經常出現問題定位時間太長，問題反饋不及時，客戶體驗較差。因此需要開發乙個問題定位平台，聚合一些裝置日誌和監控資料進行分析，縮短研發定位時間。模組涉及到主要概念
•flow：表示處理問題的流程
•action：表示flow中需要執行的操作，是有序的，是在程式中封裝好的對資料來源的小粒度操作
•situation：使用者定義的問題場景，用於描述該問題場景下日誌的分析規則
situation由使用者建立，在查詢時需要指定該引數，會根據situation中的規則分析出請求日誌之間的順序。
平台演示後記這三大運維平台用的都是開源系統，總共有12個系統，sonar、jenkins、ranche、consul、elk、admin-service、zabbix、prometheus、smokeping、grafana、skywalking、jumpserver。後續會基於jenkins開發乙個devops整合平台，將這些系統進行整合，以便更好地支援前端業務交付。如何構建智慧型運維平台？
隨著技術的發展，運維支撐必須逐漸擺脫對人力的單純依賴，走向平台化。如何才能構建具有一定智慧型的運維平台？軟體即服務 software as a service 需要以軟體服務為基礎，實現運維的it能力和業務能力的對接。生活中，幾乎我們每一天都在接觸saas雲服務，比如 我們平時使用的蘋果手機雲服務，...
運維平台系列 關於DevOps平台架構思考
現在很多公司都在推行devops平台。為了能夠提公升研發運維效率。這一章節主要寫點關於偏ops層面的東西，dev層面的東西主要涉及到研發域的內容包括 管理 編譯與發布管理 研發流程專案管理及bug管理等。乙個大的產品與技術架構圖 後續會將各個子產品域的設計大圖整理出來.1.關於決策層的思考 基於運維...
實戰 阿里巴巴 DevOps 轉型後的運維平台建設
摘要 阿里巴巴devops轉型之後，運維平台是如何建設的？阿里巴巴高階技術專家陳喻結合運維自身的理解，業務場景的分析和業界方 的一些思考，得出來一些最佳實踐分享給大家。前言 我是這個應用的 owner 是阿里巴巴devops轉型的重要策略，運維有了這個策略以後，pe大量的日常工作就可以釋放出來，會有...