許久沒有現(xiàn)場參與業(yè)界DEVOPS大會了。對我來說，參加業(yè)界大會一方面是眼界上的開拓，另一方面是前進方向的校正，也知道天高地厚了。去年參加的很多，感觸很多，今年參加以后發(fā)現(xiàn)業(yè)界整體技術又有一次躍進。
今日參加EE大會，主要關注還是DEVOPS和質(zhì)量。筆記如下。
1. 極簡-DEVOPS云原生轉型之道（曾海劍）
運營商使用SOW松散方式，對外包進行管理（所謂交鑰匙的模式）。在此模式下如何進行轉型？
（1）驅動力
返工多，瀑布模式導致的返工多
質(zhì)量低，通過運維來彌補軟件質(zhì)量的缺陷
統(tǒng)維難，不同部門不同項目，環(huán)境各自部署，維護各自承擔
定位難，出現(xiàn)故障難于定位是研發(fā)問題還是運維問題。溝通成本高
人員流失快，且研發(fā)的核心痛點：浪費、質(zhì)量。
外包型企業(yè)，沒有獲得源代碼會帶來項目綁架的情況。
從物理機到虛擬化到容器化，解決運維的痛點。不需要再去思考如何修理容器。
（2）轉型之痛
放養(yǎng)階段：研發(fā)效能團隊建工具鏈，開發(fā)人員自己配置流水線（開發(fā)人員不懂工具鏈，不懂k8s，組織培訓費時費力不討好）
保姆階段：開發(fā)人員題需求，研發(fā)效能團隊配置流水線（累死研發(fā)效能團隊）
自助階段：把配置變成編排，開發(fā)人員自助編排流水線
核心思想是如何讓開發(fā)人員零知識將代碼發(fā)布到生產(chǎn)環(huán)境。
研發(fā)效能的思考：增效減負。減負指的是降低學習成本，減低溝通成本，降低配置成本。
（3）極簡實踐
一開始是開源方案，發(fā)現(xiàn)開源方案面向的都是專家，比如jenkins，gitlab CI/CD都是通過編程來實現(xiàn)流水線。
設計初衷——極簡
簡化復雜的技術：開發(fā)團隊能力參差不齊，降低接入門檻，減低調(diào)試溝通工作量
簡化復雜的流程：吧復雜的流程原子化，面向結果，隱藏復雜的環(huán)境就緒流程，隱藏復雜的編排發(fā)布流程
簡化復雜的權限：通過統(tǒng)一接口編排能力，簡化權限體系，面向多租戶共用云環(huán)境
實現(xiàn)了動態(tài)編排、多模塊流水線（一個流水線可以支持多個微服務）
一條流水線管理一個微服務，會導致難以對微服務的上線、灰度進行控制的問題。（通過服務網(wǎng)格解決）
服務編排——進化
微服務1.0，使用springcloud。通過開發(fā)方式實現(xiàn)服務治理，誕生背景是虛擬化
微服務2.0，使用Istio，以配置方式實現(xiàn)服務治理，不受語言限制，誕生背景是容器化
Dory從18年開始探索建設，近期將開源
2. 云原生容器化落地實踐（去哪兒-鄒晟）
（1）背景與收益
痛點：環(huán)境不一致、環(huán)境交付慢、服務器多運維成本高、降服務器成本、SDK推動升級難，周期長
1000，5000，8000虛機時出現(xiàn)質(zhì)變（主要是物理設備故障，需要人工確認，KVM進行平移）
我們眼中的云原生：
是什么：云原生是一系列可以為業(yè)務賦能的技術架構準則，遵循它可以使應用具有擴展性、伸縮性、移植性、韌性等特點
為什么：基礎架構需要演進，它可以讓業(yè)務更敏捷
怎么做：DEVOPS、微服務、容器化、可觀測性、反脆弱性（混沌工程）、service mesh、serverless
業(yè)務價值：
PO：敏捷性、彈性伸縮、資源成本
DEV/QA：環(huán)境穩(wěn)定性、環(huán)境一致性
DEV/OPS：節(jié)省人力
去哪兒容器化進程
（2）實踐路線圖
容器化落地策略：盡量少改動業(yè)務性
IaaS層：re-host（評估最小成本）
PaaS層：re-platform
應用層：refactor（通過service-mesh，將熔斷限流平移）
re-host五步：價值認同、制定規(guī)范、工具建設、遷移落地、驗收
（3）關鍵實踐
實踐1 - 價值認同：容器化的ROI是多少，怎么證明？
自證價值-自己的服務先容器化
放大價值-解決業(yè)務線實際問題
技術宣講-價值宣傳，找VIP用戶
實踐2 - 規(guī)范制定
關注幾個點：日志的統(tǒng)一，實時和離線Loki的使用，部署路徑，端口號統(tǒng)一，新應用禁止KVM部署。
實踐3 - 工具建設
通過對工具平臺改造實現(xiàn)全自動化
CD：使用KubeSphere實現(xiàn)多集群管理平臺。發(fā)布系統(tǒng)調(diào)用編譯模塊調(diào)用部署模塊調(diào)用kubesphere。
實踐4 - 遷移落地
- 前置校驗：編譯階段自動檢查配置
- 測試環(huán)境驗證：自動升級SDK
- 線上驗證：灰度發(fā)布，自動化驗證
- 混合部署：kvm和容器混合部署
- 全量部署
- 觀察：7天正常后停止KVM
資源成本：容器化前單機部署的kvm數(shù)：14個；容器化后單機部署的pod數(shù)：20個
（4）總結與規(guī)劃
價值認同：從上而下推進。知之不深，則行之不篤；知之愈明，則行之愈篤。
產(chǎn)品同理心：用戶收益、遷移成本、使用成本
工程化方法：自動化前置檢查、升級SDK、測試、遷移
未來規(guī)劃：穩(wěn)定性治理、資源利用率提升、service mesh落地
3. 工程師文化（華為）
- 對工程師文化的思考
- 企業(yè)在全面云轉型中，如何重塑匹配的工程師文化？
- 工具平臺
對工程師文化的思考
企業(yè)工程師文化，不是脫離具體環(huán)境，獨立存在的
文化不是你要求人家做什么，而且團隊領導做什么，別人跟著做。
影響工程師文化的因素
企業(yè)頂層文化：以客戶為中心，質(zhì)量優(yōu)先……關鍵是，真正在執(zhí)行的是什么？
問題：會不會變成以一線銷售為優(yōu)先？
價值創(chuàng)造過程：商業(yè)模式，產(chǎn)品交付模式，研發(fā)模式，軟件工程實踐，工程師的工作方法，逐步影響
設備供應商和云服務供應商完全不一樣，文化就要轉變。
組織，授權管理體系
- 以流程為中心 vs 以人為中心
- 矩陣組織
-
管控中心 vs 能力中心
企業(yè)在全面云轉型中，如何重塑匹配的工程師文化？
正視差異和差距，窮則變，變則通，通則久。
從why轉變?yōu)閣hy not？
工具平臺不聽匯報，聽使用工具的人的聲音。
最佳實踐不可復制，都是屬于企業(yè)自己的。
PS：華為的思路下，要求開發(fā)變成對ops也了解的全棧，和廣東移動的理念不太一樣。
不能因為管理者的害怕而走回頭路。質(zhì)量的嚴峻挑戰(zhàn)。
代碼分支的維護，質(zhì)量要求嚴格。
平臺支撐
實現(xiàn)在家編碼，這是組織文化變更帶來的。
公司內(nèi)總會有不停造輪子的情況，通過內(nèi)部開源來減少造輪子的情況。
正確的激勵，樹立CleanCode導向。獎勵軟件工匠（編程超過10-15年的人）
信任和不信任的度？
穩(wěn)步才能保證變更不回彈。
