網絡時代來臨讓很多相關崗位人員的工作越來越繁復枯燥，當然也越來越具有挑戰(zhàn)性。運維工作人員也避不開這個問題。如何提高效率成了大家經常探討的問題，許多公司的管理層都在運維提效方面有所考量，其實運維工作提效的問題可以從這幾個方面來說說。比如：流程提效、工具提效、質量提效、工程提效等等。下面分享一下具體想法，希望對從事運維工作的您有所幫助。

提效工具：這個話題其實挺大，應該是管理層看到了一些問題也真的是想去解決，所以才發(fā)起這么個腦爆。首先，我個人很肯定這種方式，公司終于有意識在真正的向下求解，雖然沒有360度閉環(huán)考核，但也終于不再一味向外尋求解決方案。這種方式可以定期多組織，因為，憑一時收集，不一定能想起來容易漏，問題也是逐步變化的。

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

工具提效，在傳統公司越來越被重視，但重視度有待商榷。真正偉大的公司在技術和文化的投入是很舍得花錢花時間。工具提效講究兩點：做的人要懂，更要執(zhí)著。從問題中來，最終回歸到問題中去。做的人在問題中深受煎熬，最后受不了，跳出來，做了一套工具，甚至一套解決方案，解決了公司痛點，甚至行業(yè)痛點。像 Ansible，slatstack，jumpserver，k8s 等工具都是一樣的，他們提供的解決方案被行業(yè)接受，所以也能得到社會的回饋。

質量提效：質量管理不在我們的管理范疇，我們不做過多討論，問題大家都看的到，不做無意義討論。工程提效：工程提效很關鍵，是所有事情的源頭。公司也付出了很多，比如多技術棧合并，統一架構推廣，全面擁抱容器。大的戰(zhàn)略層面是夠了，但中層的腰部力量明顯薄弱。各部門的 KPI 割裂，同樣的容器化項目，還要分2個。容器化是一個部門的，上線成功是另一個部門的。為了 KPI 而 KPI，為了 OKR 而 OKR，這個鍋建議高層自我反思。

閉環(huán)不夠看似事故總體匯總到 PM，完整閉環(huán)，但實際效果和老板關注度有很大關系。業(yè)務分級定位，這么多業(yè)務，到現在還沒有星級打標，什么星級匹配對應的資源和支持。一直沒有，誰先來誰優(yōu)先。誰占坑時間長，誰優(yōu)先。誰會喊誰優(yōu)先。

以上是我們對提效的方面給您的建議，當我們擁有共同價值的時候，都會朝著共同的目標而努力。價值是認知定義，共同是全體認同。如果您想了解更多關于運維的信息，請您及時關注中培偉業(yè)。