IT運維的痛點
2020-06-02 15:32 作者：艾銻無限 瀏覽量：
IT運維工作，以服務(wù)為中心，以穩(wěn)定、安全、高效為三個基本點，確保公司的互聯(lián)網(wǎng)業(yè)務(wù)能夠 7×24 小時為您提供高質(zhì)量的服務(wù)。
人工不是傳統(tǒng)IT運維的當下過失，是過去的延續(xù)。在早期，運維的很多能力建立在少量的高可用硬件對象之上，平臺化的需求很弱。另外，閉源的軟件生態(tài)，給平臺化的建設(shè) 增加難度，而這些歷史債務(wù)，并不是一下就能丟下的。留給傳統(tǒng)企業(yè)的時間并不是那么充足，開放平臺和業(yè)務(wù)的互聯(lián)網(wǎng)化帶來的沖擊是非常大的，時間 非常的短。這是一個多維沖擊能力，從思維、技術(shù)、能力等多個維度。不過很開心的是，傳統(tǒng)企業(yè)IT運維人對運維平臺擁抱非常強烈，從運維自身能力自動化到全流程的持續(xù)交付自動化。我們也經(jīng)過和傳統(tǒng)企業(yè)的IT部門深入廣泛接觸，大家對運維自動化作為突破口非常認可，更愿意以此為原點，單點突破，再全面覆蓋。
IT運維之痛2：流程 vs 創(chuàng)新
很多人會告訴我，在傳統(tǒng)企業(yè)中沒辦法，我們必須通過流程來驅(qū)動各個組織角色，確保協(xié)同工作。真的如此么？我們在維護那么多產(chǎn)品線，沒有流程怎么 做到的？然后真的會混亂不堪么？我和我之前的運維團隊來說，如果你不能保持一個對外的簡單清晰運維界面，那就是我們工作的失職。流程是我們找不到解決方案的時候，添加的累贅！很榮幸，我了解的傳統(tǒng)企業(yè)中，給我們上了一趟生動的流程課，此處和大家分享一下。
IT運維之痛3：責任分離 vs 持續(xù)改進
沒有比責任分離更糟糕的事情了。在一個問題產(chǎn)生的時候，大家首先不是想著如何尋求更好的解決方案，而是在找這個問題應(yīng)該由哪個團隊的責任。責任分離可以說是過度流程化的結(jié)果，流程設(shè)計者們很多都在精心設(shè)計責任應(yīng)該由誰來背。當責任被清晰的界定之后，而后的解決方案也只能落到該團隊上了，自然而然，思維就局限了。其實應(yīng)該換個視角，當業(yè)務(wù)的質(zhì)量出問題了，持續(xù)交付這個鏈條上的所有人都有責任，而基于責任的分析范圍應(yīng)該更廣泛一些，需要思維上的突破。我們總是怪測試不夠充分，你給到足夠的時間給測試了么？你讓測試早期參與了么？你建立了穩(wěn)定的技術(shù)框架，讓自動化測試更好的覆蓋了么？怪運維的環(huán)境部署有問題，你有降低運維部署的復(fù)雜度么？怪運維定位問題慢，你有把運維定位故障的復(fù)雜度降低么，消除了菜鳥和專家的區(qū)別么？反之亦然。更糟糕的是，當問題變得越來越嚴重的時候，還在想著流程設(shè)計得不夠完美。
IT運維之痛4：組織設(shè)計
"設(shè)計系統(tǒng)的組織，最終產(chǎn)生的設(shè)計等同于組織之內(nèi)、之間的溝通結(jié)構(gòu)。"--Conway's Law.
不得不說，傳統(tǒng)的職能式的IT組織架構(gòu)越來越不能滿足互聯(lián)網(wǎng)化的業(yè)務(wù)需要了。基于持續(xù)交付打造的全鏈條整合鏈條打破的就是職能邊界，提供的就是面向 產(chǎn)品化的服務(wù)能力。如果組織不能給新產(chǎn)品上線和老產(chǎn)品快速迭代提供足夠的能力支撐，那么這個組織一定是冗余設(shè)計的。架構(gòu)組提供的架構(gòu)能力只能是一個意向參考，沒有真正的落地實現(xiàn)，這個架構(gòu)組就是冗余的；流程組提供的流程能力是減慢了交付速度，這個流程組就應(yīng)該去思考是否把流程讓位于更優(yōu)的技術(shù)實現(xiàn)。很容易觀察到的一個效果，復(fù)雜的組織設(shè)計，最終讓設(shè)計出來的軟件復(fù)雜，導(dǎo)致問題重重，隨后便不斷的增加附加角色，讓軟件的交付過程主次不分。其實附加角色增加的檢查點并不能起到服務(wù)改善的作用，“越早發(fā)現(xiàn)缺陷，越早修復(fù)成本越低”這個準則需要深刻體會，check機制都是事后的機制，是人肉機制，而自動化的機制必須早期介入。糟糕的情況，組織設(shè)計完全面向問題，而非面向用戶。誰能代替用戶來對IT組織的考核？沒有。但我們的方式恰恰相反，認為考核組就可以，針對每個小組，設(shè)計了一些指標。說實話考核組離一線現(xiàn)場太遠了，數(shù)據(jù)的是非判斷準則都很難建立。
IT運維之痛5：架構(gòu)設(shè)計
架構(gòu)設(shè)計的問題是一直是核心的技術(shù)問題所在。架構(gòu)設(shè)計問題體現(xiàn)在很多方面：
1、不能建立統(tǒng)一的架構(gòu)標準
架構(gòu)師在傳統(tǒng)企業(yè)中是普遍的存在，而架構(gòu)規(guī)范恰恰不是普遍的存在。很多時候都讓位于業(yè)務(wù)的復(fù)雜需求，認為技術(shù)架構(gòu)標準可以放低。技術(shù)架構(gòu)標準絕不是架構(gòu)師的呼聲，應(yīng)該是產(chǎn)品線的統(tǒng)一技術(shù)要求。合理的技術(shù)架構(gòu)，會大大提升后續(xù)的產(chǎn)品推出速度和演進速度。
2、從代碼依賴到二進制依賴到服務(wù)依賴
很多傳統(tǒng)企業(yè)的大型軟件之間采用的還是代碼依賴，當一個組件發(fā)生變化的時候，這個時候需要整個系統(tǒng)的全量更新。久而久之，更新的代碼影響哪些外部系統(tǒng)，都不知道。這是深度耦合，給后續(xù)的測試和運維都帶來了很大的難度。到服務(wù)依賴，才能真正的實現(xiàn)架構(gòu)自治。
3、沒有統(tǒng)一的開發(fā)框架
開發(fā)框架其實是統(tǒng)一技術(shù)標準的最佳手段，是真正的把架構(gòu)規(guī)范落到了可執(zhí)行層面。傳統(tǒng)企業(yè)的架構(gòu)組應(yīng)該在這個點上多思考，統(tǒng)一的開發(fā)框架到底包含哪些？
4、業(yè)務(wù)需求優(yōu)先，非功能性需求次之
要命的是，評估一個研發(fā)團隊的績效是從實現(xiàn)業(yè)務(wù)的功能需求角度去考核的。
以上內(nèi)容由北京艾銻無限科技發(fā)展有限公司整理
相關(guān)文章
- [網(wǎng)絡(luò)服務(wù)]保護無線網(wǎng)絡(luò)安全的十大
- [網(wǎng)絡(luò)服務(wù)]無線覆蓋 | 無線天線對信
- [網(wǎng)絡(luò)服務(wù)]綜合布線 | 綜合布線發(fā)展
- [數(shù)據(jù)恢復(fù)服務(wù)]電腦運維技術(shù)文章：win1
- [服務(wù)器服務(wù)]串口服務(wù)器工作模式-服務(wù)
- [服務(wù)器服務(wù)]串口服務(wù)器的作用-服務(wù)維
- [服務(wù)器服務(wù)]moxa串口服務(wù)器通訊設(shè)置參
- [網(wǎng)絡(luò)服務(wù)]網(wǎng)絡(luò)運維|如何臨時關(guān)閉
- [網(wǎng)絡(luò)服務(wù)]網(wǎng)絡(luò)運維|如何重置IE瀏覽
- [網(wǎng)絡(luò)服務(wù)]網(wǎng)絡(luò)運維|win10系統(tǒng)升級后
- [辦公設(shè)備服務(wù)]辦公設(shè)備:VPN簡介
- [辦公設(shè)備服務(wù)]辦公設(shè)備:VPN技術(shù)的要求
IT電腦維護外包
關(guān)閉