工作回顧、一圖勝千言
一圖勝千言：
回顧過去2年，參加/負責了2個項目，《技術平臺開發》、《IT基礎設施項目》。涉及到的技術術語很多，日常工作也繁雜；
如有人問，在XX公司做什麼，做出了什麼成績？工作確實有些“雜”，回答這個問題，很有必要覆盤工作、系統思考、體系總結一下；
總結就是，在DevOps領域，主要是 CICD、容器平臺、網絡互聯、工具鏈、應用容器環境設計 5個技術方面，做出了一點成果，支持公司車聯網業務發展；
業務、行業的一點思考
用confluence畫了一張圖，公司的業務、技術都可以從這張圖找到根源：
車聯網業務
車聯網，即把車、車主、車廠、數字服務商互聯，如圖所示，再此之上，承載各種業務場景。
典型的一個車企例子–特斯拉；而國內各大車企，或多或少，都想成爲“特斯拉”。面臨特斯拉這類互聯網型車企的巨大挑戰，網聯化、數字化、智能化，車企的轉型升級任務必要且緊迫；
三大ToB業務
公司的業務就是緊緊圍繞車聯網，圍繞國內各大車企在，網聯化、數字化、智能化、電動化，的轉型需求。
公司業務圍繞這張圖開展的，客戶是車企，提供技術服務。
根據公司定位；可總結爲車企提供三大類技術服務：
- 平臺建設，圍繞 TSP平臺建設，解決車、車主、車企連接問題；
- 生態聚合，打通 車主-TSP系統-數字服務提供商 鏈路；
- 數據增值，用大數據等技術助力車企拓展爲數據企業；
圖中當然還有其他業務，目前公司沒有涉及，比如，
- 車機、Tbox車載硬件；
- 導航、支付等用車服務；
- 買車等營銷服務；
- 保養、4S等養車服務；
- …等
困難、挑戰
2018年，公司的技術棧爲：
應用層，使用 Java/SpringCloud、Springboot/Nodejs、使用了微服務。
容器層，使用docker、docker-compose方式，沒有使用kubernetes，沒有容器平臺。
網絡層，沒有明確規劃，辦公網絡、雲VPC網絡、項目環境網絡比較亂。
雲平臺層，共用一個阿里雲，使用、權限比較混亂。
困難一：三低，效率低、士氣低、質量低
- 效率低
舉些例子，這些例子是2018年初，我們遇到的效率問題。
| 活動 | 效率問題舉例 |
|---|---|
| 構建 | 1. Jenkinsfile 維護工作量大、易出錯。微服務化後，多個項目都幾十上百個Git代碼，每個Git一個Jenkinsfile，改一個環境地址要改幾十上百個 |
| 部署 | 1. 微服務應用部署名稱問題。不統一，易混亂；應用。 |
| 配置 | 1. 應用配置文件多問題。每次發佈哪些配置更改過？ |
| 日誌 | 1. 看應用日誌問題。開發問，去哪裏看日誌，我不會用k8s，kubectl |
| 監控 | 1. 看應用資源監控問題。開發問，我的應用CPU/MEM佔用情況哪裏能看？ |
| 調試 | 1. 應用調試問題。我怎麼重啓一下的服務，怎麼查看監聽的端口？2. 本地調試問題。我的應用要依賴XXX才能調試，我本地怎麼訪問XXX？ |
| 訪問 | 1. 應用域名問題。我的服務部署上去，域名、IP是什麼？2. NodePort端口衝突問題。應用這麼多，多個Namespace，NodePort衝突！3. 域名混亂問題。微服務幾十個應用，這麼多域名，哪個域名是哪個服務的,？ |
| 權限 | 1. 運行環境權限問題。誰把我的應用重啓了？ |
| 文檔 | 1. 設計文檔畫圖問題。2. 1. 設計文件拷來拷去，好麻煩，有沒有在線編輯在線協作的，還能畫圖的 |
| 沉澱 | 1. 配置構建，手動部署 工作量大，易出錯，重複工作，下個項目還得搞一遍；個人技術沒法提高，問題一直重現，也沒辦法沉澱成公司成果，好煩； |
| xxxxxxxxxx |
- 質量低
一些舉例
| 活動 | 質量問題舉例 |
|---|---|
| 代碼分支 | 1. 分支管理問題。誰又把沒經過測試驗證的代碼合併進master分支？！ |
| 測試環境 | 1. 代碼管理問題。Test環境的鏡像版本能不能和Prod環境保持一致？ |
| beta部署 | 1. 生產能不能有一種部署新版本，但是對線上影響小的方式。 |
| 生產權限 | 1. 生產環境在哪，怎麼訪問，我需要看生產環境的實時日誌 |
| xxxxxxxx |
歸納起來就是，分支管理問題，環境部署問題，環境設計問題。
- 士氣低
加班多效率不高、產出還質量不高；上生產沒有信心；上班心情不好啊。
困難二：多業務部門，項目支持問題
這個困難，是公司增長到200+人後，領導層進行內部組織架構改革。分五大業務部門。各個業務部門負責獨立的年度API。也將 售前、產品經理、BA、前端開發、後端開發、QA等劃歸到業務部門。
問題來了，分還是合。建平臺還是建煙囪？
DevOps建設的系統，之前都是平臺化支持全公司的方向來建設的。同時DevOps 工作範圍，從底層 雲平臺、網絡、系統、容器、中間件、工具鏈系統，哪些應該平臺化，哪些部門化？
技術、工具的一點思考
技術爲業務而生。技術爲效率、質量而生。技術也要緊跟新技術浪潮。
針對困難一，回顧來看，主要是通過：技術升級，來解決。
針對困難二，回顧來看，主要是通過：調整團隊人員架構、明確職責、技術上改造適配多業務部門制，來解決。
我的工作 - 落地
目前升級到的技術棧，用一張技術圖譜（上圖）展示。
考慮困難與問題，結合業務背景作爲需求，針對性的從多個技術層次解決。
圍繞服務端技術棧升級改造，落地 應用容器環境設計、容器平臺、CICD、網絡互聯、DevOps工具鏈、雲平臺。圍繞解決困難一。
落地：一段時間，某個技術方向上，進行預研、選型、規劃、設計、部署、二次開發，投產、維護 ，持續循環。
當前情況，大數據PaaS還處於初步階段，應用安全未成型。其餘技術已成型，等下一輪技術才需要大幅更新。
容器平臺落地–雲計算、混合雲、容器技術、微服務背景
目前已落地成型。私有云爲 RKE/rancher/AD/網絡互聯。公有云爲 容器服務採購/rancher/AD/網絡互聯。
回顧過程，這部分是最難落地的。
容器化、微服務化的應用架構，量上來了，系統和應用加了一層容器。
故，一定會遇到部署難，調試難，訪問難，配置難的問題。難就難在，任何一個沒有解決，都沒法完全落地。
而解決這些困難，涉及個各技術面。上要跟應用框架（業務開發、架構師）一起解決，下要跟網絡、基礎設施一起解決。
我們的解決辦法是
| 困難 | 辦法 |
|---|---|
| 部署難 | CICD二次開發，非常強調自動化、簡單性 |
| 調試難 | 引入K8S UI（rancher），打通容器網絡，支持本地調試 |
| 訪問難 | overlay、underlay網絡統一IP規劃，打通容器網絡、辦公網絡；CD自動生成ingress 內網、公網域名 |
| 配置難 | 引入 spring config，nacos 配置中心 |
研發工具鏈落地 – DevOps 背景
目前DevOps工具鏈已落地近2年，沒有大的變化。
該部分主要工作是，部署，相互集成，體驗調優（速度、易用性）、多部門租戶規範。
比較有體會的是，
- confluence有畫圖插件後，大家都非常喜歡用了（注：我畫的這些圖都是confluence裏畫的）。
- 圍繞 用戶體驗爲中心，持續優化。工具最好是好用才用，而不是強行推廣。
網絡互聯落地 – 混合雲、容器網絡背景
ToB企業的典型企業網絡：
雲計算、容器技術下的ToB企業的典型混合雲網絡：
容器技術下，容器平臺某Kubernetes(K8S)集羣的容器網絡：
網絡互聯落地，經過近一年多實踐，取得很好的效果。
我們在網絡互聯方面做了些創造性、巧妙性的工作，取得了事半功倍的效果。
在雲計算，公有云背景下，引入了Kubernetes 容器，應用容器的訪問是一大效率問題。
解決這個問題，有幾個心得：
- 從業務、應用的角度提需求去設計企業網絡。
- 容器網絡考慮在內的統一IP地址規劃。即Kubernetes的CIDR。
- 容器網絡考慮在內的網絡互通。開發人員在辦公網絡裏，快速訪問容器應用，支持本地調試，業務流量打到辦公網絡，大幅提高了開發效率。
- 客戶網絡的互聯技術vyos/openV|P|N。客戶網絡使用的設備千差萬別，安全策略千差萬別，一種適應性很強的網絡技術給大幅提高了我們效率。滿足異地協同研發。
應用容器環境設計
CICD 落地 – Kubernetes、微服務背景
我們CICD核心實現設計如下，我們部分開源出來 https://github.com/chimeh/cicd-s2e-runner
創新點：
- runner也容器化，docker-compose方式。非常強調新項目啓動、到客戶環境快速建立CICD。
- 強調使用簡單化。無論什麼語言，CICD只需要一條命令
s2i /path/to/src，完成源碼檢測、artifact構建、docker構建入庫、部署K8S。 - 及其方便集成。我們採用CLI、API方式集成，易於與多種多版本倉庫工具鏈、Kubernetes集成。
- runner抽象四大部分，快速定製CICD邏輯。runner由 client/cmd、secrets、templates、cicd-logic四大部分組成。
困難的解決
通過上個章節，各個層次的技術落地。工作彙總如下
| 技術層次 | 落地工作 |
|---|---|
| 業務層 | |
| 應用層 | nacos 容器化，CICD二次開發，自動化，域名自動化，非常強調自動；化、簡單性；取好名稱 |
| PaaS-容器層 | 容器網絡規劃、rancher部署、私有云RKE，公有云TKE。引入K8S UI（rancher），打通容器網絡，支持本地調試 |
| PaaS-數據庫、中間件層 | 買，庫名規範， |
| PaaS大數據層 | 目前相關經驗少 |
| 網絡互聯層 | IP地址規劃、overlay、underlay網絡統一IP規劃，打通容器網絡、辦公網絡；CD自動生成ingress 內網、公網域名 |
| 雲平臺層 | 買、賬號集成，採購流程，權限設計 |
| xxxxxxxxxxxxxx |
落地工作：一段時間，某個技術方向上，進行預研、選型、規劃、設計、部署、二次開發，投產、維護 ，持續循環。
業務的技術、員工的技術
技術爲業務而生，也要緊跟新技術浪潮。
技術承載業務，也助力員工技術成長。
現在回頭看，雲計算、容器技術、微服務背景下的技術棧升級改造，確實很有必要，具體體現在：
-
好招人；
近一年面試過程中，候選人還是很認可公司技術棧的。所謂跳槽，看薪資、看平臺、看行業、看技術、看薪資。看技術方面取得良好效果。 -
助力售前項目；
公司積累的 容器、微服務、敏捷開發、CICD、DevOps等技術經驗彙總成材料，在去競標等方面，還是有不少助力； -
有效提高了效率、質量，大體降低了成本；
-
有利崗位忠誠度、崗位滿意度；
“技術是不是過時了，積累的經驗，跳槽是否有幫助？”多數技術崗會有這個問題，直接影響崗位忠誠度與滿意度。雖然待遇、薪資無法跟大廠，但是技術棧對員工的技術成長方向是匹配的。
個人回顧，雖然容易感覺“雜”，體系化總結後，我覺得自己還是技術方面成長也是不少；
務實與務虛：項目實施、方法論、團隊組織的一點思考
背景、問題、 目標、任務、成果
TODO
拿來主義與輪子
TODO
理論指導、最佳實踐、套路、模板
TODO
成果與經驗教訓
TODO
總結
TODO