涉及用戶日常工作內容, 劃分為工作流系統(workflow)和賬戶系統(accounts).
資源中心(resource):

復合CMDB系統, 硬件網絡層CMDB, 服務應用層CMDB, 容器微服務化CMDB等三大類, 劃分為硬件資產(device)、應用及服務(appservice)、網絡資源(network)、基本盤(base)、成本統計(summary).

監控中心(monitor):

綜合告警展示處理、告警配置、合並壓縮平臺. 劃分為告警動態(alarm)、監控控制器(controller)、告警統一平臺(uaplatform).

運營中心(analysis):

數據報表展示,類似Grafana監控報表數據、hichart圖表展示(grafana無法表達)、ELK日誌分析日誌.(需要花更多時間開發.)

控制中心(control):

代碼發布、配置管理、任務調度, 暫時還使用ansible進行配置控制, jenkins控制代碼發布, 無法做到頁面自動化操作.(待開發) .

自問自答:

1.1 為什麽寫一系列文檔?

其一, 現在網上有很多成品平臺介紹，功能齊全格調很高, 贊贊贊. 可是我也想做一個, 可是不知道怎麽下手，分享一下吧. 其二, 原稿是2017年初運維平臺規則稿, 這批文檔會起到承前啟後作用, 用以指導後期平臺開發. 其三, 職業生涯工作總結, 一系列有道雲筆記和平臺記錄, 算是留下一些足跡, 像我們這麽專業的,當然要讓別人也知道(哈哈,這很重要).

2.1 在夾縫中求生存

起初以為開發慘, 沒想到運維雜工更慘(時刻背鍋,時常待命), IT行業實在太激烈, 行業要求不斷上漲,.

其一, 來自培訓機構的壓力, 看到他們的全面教程內容讓我汗顏, 批量化產出高中級架構師, 哪裏還能坐得住.

其二, 傳統IDC CDN到現在阿裏雲、騰訊雲、ucloud等雲廠商升級, 它們已經開始售賣解決方案, 只要花錢就可以幫我解決很多問題, 作為被替代產品, 不能坐以待斃.

其三, 要做一個具備開發能力的運維, 這是一些大廠頭目的血淚控訴, 前輩的語錄我永記在心. 隨著工作深入,維護的業務復雜度和數量越來越多, 具備開發能力寫些工具方便我們維護, 不用這麽累. 哎.

3.1 往事不堪回首

於15年維護七八個郵件服務項目,需要分析郵件日誌, 進行郵件日誌切割和收集,最後再通過頁面進行查詢和作圖顯示. 花了不少時間處理bootsrap、jquery、ajax等前端頁面知識.
於16年重寫用戶控制、一期workflow, 一期CMDB, 一期監控告警(對接zabbix) 兩者關聯. CMDB例如硬件服務器表單 機架圖 服務器(os層)kvm vmware 華為雲等機器對接, 大約300臺左右. 應用項目和服務管理. zabbix api數據抽取rrd寫入落地及自定義判斷. 過濾報警.
於17年 二級CMDB(微服務和容器管理), 二期監控告警(改用openfalcon),定義立體化監控樹. docker容器大量出現,微服務項目等管理,如何對接之前應用項目和服務管理. 改改改.... 棄用zabbix,改用openfalcon+grafana作圖,重寫數據收集腳本. 改改改.....

4.1 本質是希望有用.

日常運維工作內容一般有CMDB、代碼發布、監控、故障定位和性能優化, 人類發展的歷程其實也是工具升級的過程，此運維平臺其實是管理工具的集合, 提高工作效率. 本質是追求運維平臺的實用性，幫助解決和提升運維工作.

5.1 青春不在, 我的28歲

當你認定某一件事的時候, 全心全意的付出, 灌溉青春的心血, 掃清一個個障礙, 未來的路還很長呢.

回首向來蕭瑟處 也無風雨也無晴.

1.運維平臺之規劃路線