IT運維的痛點是什么？
2020-06-08 19:46 作者：艾銻無限 瀏覽量：
伴隨著IT在企業中的作用日益明顯，IT建設和IT運維同時成為了企業效率的加速器。同時，計算機硬件系統和軟件系統的運維已成為了各行各業單位，尤其是大型綜合服務系統普遍頭痛的事情。
人工不是傳統運維的當下過失，是過去的延續。在早期，運維的很多能力建立在少量的高可用硬件對象之上，平臺化的需求很弱。另外，閉源的軟件生態，給平臺化的建設增加難度，而這些歷史債務，并不是一下就能丟下的。留給傳統企業的時間并不是那么充足，開放平臺和業務的互聯網化帶來的沖擊是非常大的，時間非常的短。這是一個多維沖擊能力，從思維、技術、能力等多個維度。不過很開心的是，傳統企業運維人對運維監控平臺擁抱非常強烈，從運維自身能力自動化到全流程的持續交付自動化。我也經過和傳統企業的IT部門深入廣泛接觸，大家對運維自動化作為突破口非常認可，更愿意以此為原點，單點突破，再全面覆蓋。
IT運維之痛2：流程 vs 創新
很多人會告訴我，在傳統企業中沒辦法，我們必須通過流程來驅動各個組織角色，確保協同工作。真的如此么？那么在BAT維護那么多產品線，沒有流程怎么做到的？然后真的會混亂不堪么？我和我之前的運維團隊來說，如果你不能保持一個對外的簡單清晰運維界面，那就是我們工作的失職。流程是我們找不到解決方案的時候，添加的累贅！而現在各式各樣的一體化的運維監控平臺正式扮演了這樣一個監控流程的角色，維持監控的有序進行。
IT運維之痛3：責任分離 vs 持續改進
沒有比責任分離更糟糕的事情了。在一個問題產生的時候，大家首先不是想著如何尋求更好的解決方案，而是在找這個問題應該由哪個團隊的責任，責任分離。可以說是過度流程化的結果，流程設計者們很多都在精心設計責任應該由誰來背。當責任被清晰的界定之后，而后的解決方案也只能落到該團隊上了，自然而然，思維就局限了。其實應該換個視角，當業務的質量出問題了，持續交付這個鏈條上的所有人都有責任，而基于責任的分析范圍應該更廣泛一些，需要思維上的突破。我們總是怪測試不夠充分，你給到足夠的時間給測試了么？你讓測試早期參與了么？你建立了穩定的技術框架，讓自動化測試更好的覆蓋了么？怪運維的環境部署有問題，你有降低運維部署的復雜度么？怪運維定位問題慢，你有把運維定位故障的復雜度降低么，消除了菜鳥和專家的區別么？反之亦然~ 系統的IT運維監控平臺更好的把出現在問題降低到最少，相應的責任也會分擔的最少。改進責任分離與持續改進之間的矛盾問題。
IT運維之痛4：組織設計
設計系統的組織，最終產生的設計等同于組織之內、之間的溝通結構。不得不說，傳統的職能式的IT組織架構越來越不能滿足互聯網化的業務需要了。基于持續交付打造的全鏈條整合鏈條打破的就是職能邊界，提供的就是面向產品化的服務能力。如果組織不能給新產品上線和老產品快速迭代提供足夠的能力支撐，那么這個組織一定是冗余設計的。架構組提供的架構能力只能是一個意向參考，沒有真正的落地實現，這個架構組就是冗余的；流程組提供的流程能力是減慢了交付速度，這個流程組就應該去思考是否把流程讓位于更優的技術實現。很容易觀察到的一個效果，復雜的組織設計，最終讓設計出來的軟件復雜，導致問題重重，隨后便不斷的增加附加角色，讓軟件的交付過程主次不分。其實附加角色增加的檢查點并不能起到服務改善的作用，“越早發現缺陷，越早修復成本越低”這個準則需要深刻體會，check機制都是事后的機制，是人肉機制，而自動化的機制必須早期介入。糟糕的情況，組織設計完全面向問題，而非面向用戶。誰能代替用戶來對IT組織的考核？沒有。但我們的方式恰恰相反，認為考核組就可以，針對每個小組，設計了一些指標。說實話考核組離一線現場太遠了，數據的是非判斷準則都很難建立。
IT運維之痛5：架構設計
架構設計的問題是一直是核心的技術問題所在。架構設計問題體現在很多方面：
1、不能建立統一的架構標準
架構師在傳統企業中是普遍的存在，而架構規范恰恰不是普遍的存在。很多時候都讓位于業務的復雜需求，認為技術架構標準可以放低。技術架構標準絕不是架構師的呼聲，應該是產品線的統一技術要求。合理的技術架構，會大大提升后續的產品推出速度和演進速度。
2、從代碼依賴到二進制依賴到服務依賴
很多傳統企業的大型軟件之間采用的還是代碼依賴，當一個組件發生變化的時候，這個時候需要整個系統的全量更新。久而久之，更新的代碼影響哪些外部系統，都不知道。這是深度耦合，給后續的測試和運維都帶來了很大的難度。到服務依賴，才能真正的實現架構自治。
3、沒有統一的開發框架
開發框架其實是統一技術標準的最佳手段，是真正的把架構規范落到了可執行層面。傳統企業的架構組應該在這個點上多思考，統一的開發框架到底包含哪些？
以上內容由北京艾銻無限科技發展有限公司整理
相關文章
IT電腦維護外包
關閉