1.1.運維平臺之規劃路線

整個平臺劃分為用戶中心、資源中心、監控中心、運營中心、控制中心.
用戶中心(ucenter): 

        涉及用戶日常工作內容, 劃分為工作流系統(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歲

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

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