[[389109]]

大家好，我是史丹利「Stanley」，今天聊聊運維提效。

最近CTO在梳理公司提效方案，老板希望我能多提點建議看法。因為，剛巧在梳理本周的 k8s 技術分享，所以臨時寫了點，大家也多提自己的想法看法，我一并提交，如果屆時落地有好的效果，我一并回饋給社區。在此先謝過。

提效工具

我的回復如下：

這個話題其實挺大，應該是管理層看到了一些問題也真的是想去解決，所以才發起這么個腦爆。

首先，我個人很肯定這種方式，公司終于有意識在真正的向下求解，雖然沒有360度閉環考核，但也終于不再一味向外尋求解決方案。這種方式可以定期多組織，因為，憑一時收集，不一定能想起來容易漏，問題也是逐步變化的。

回到提效這處話題，我的理解提效有幾個維度：

• 流程提效
• 工具提效
• 質量提效
• 工程提效

流程提效

最短路徑

流程是雙刃劍，大家都知道。流程的本質，我的理解是通過建議規章約束把最初的用戶愿景以最短的路徑且高品質的傳遞給工程端，并由工程端高品質無差別的高品質交付。重要的是交付鏈條足夠短，交付品質足夠高。

但流程提效，正確的角色是輔助，不應該是ADC。咱們諾亞前面遇到了很多問題，迫于壓力，只能把流程提效和工具提效的角色互換，通過抑制需求，解決故障多的問題。在當時的場景下，是必然也是最優解，這毫無疑問。短時間行，長時間不行。如果要做互聯網產品化的金融，要改的地方很多。雖然公司在oa改造發力很多，但要努力的地方還有很多。諸如oa這些的，咱們CICD流程相對完善，但要做的還有很多。比如，發布日的art項目已經推送到平臺，代表已經過審，但仍要逐項目舉手，意義真的很重要？項目提測的關閉窗口總在變，更沒人嚴格執行，原由很簡單，人員變動太，文化沒有被傳承。但這是各公司都會存在的問題，所以有很多偉大的技術產品出現，解決了很多工程學中人為因素的難題。比如git解決了版本控制，比如springcloud解決了java開發的架構拓撲能力。k8s解決了運維的高可用，高并發，擴縮容的架構能力。

回歸到本質，還是要用技術手段去解決人的因素。

工具提效

[[389111]]

工具提效，在傳統公司越來越被重視，但重視度有待商榷。真正偉大的公司在技術和文化的投入是很舍得花錢花時間。

工具提效講究兩點：做的人要懂，更要執著。

從問題中來，最終回歸到問題中去。做的人在問題中深受煎熬，最后受不了，跳出來，做了一套工具，甚至一套解決方案，解決了公司痛點，甚至行業痛點。像 Ansible，slatstack，jumpserver，k8s 等工具都是一樣的，他們提供的解決方案被行業接受，所以也能得到社會的回饋。

我們現在使用的成熟流行工具都有一個特點：好用。但公司級的產品不一樣，cicd，art等還在路上，功能都有，好用和精品有待商榷，但這不能怪我們的團隊不行。公司要舍得投入錢和時間，為啥餓了么送外賣的公司，都能在前端變化萬千的產品線中做出element 和 ant、vue抗衡，那也是有原因的，值得花大價錢從行業招專家。當然，各家公司有自己的定位，要視自家特色解決問題。個人覺得，我們還是缺懂運維產品的人。

質量提效

質量管理不在我們的管理范疇，我們不做過多討論，問題大家都看的到，不做無意義討論

工程提效

工程提效很關鍵，是所有事情的源頭。公司也付出了很多，比如多技術棧合并，統一架構推廣，全面擁抱容器。大的戰略層面是夠了，但中層的腰部力量明顯薄弱。

• 各部門的 KPI 割裂

同樣的容器化項目，還要分2個。容器化是一個部門的，上線成功是另一個部門的。為了 KPI 而 KPI，為了 OKR 而 OKR，這個鍋建議高層自我反思。

• 閉環不夠

看似事故總體匯總到 PM，完整閉環，但實際效果和老板關注度有很大關系。

• 業務分級定位

這么多業務，到現在還沒有星級打標，什么星級匹配對應的資源和支持。一直沒有，誰先來誰優先。誰占坑時間長，誰優先。誰會喊誰優先。

其它的想到我再補充

個人對提效的理解，最終都回歸到一個詞吧：共同價值。價值是認知定義，共同是全體認同。