除了規(guī)模最小的IT部門外,所有IT部門都往往劃分各管理員所需的一套技能。畢竟,要聘請到高素質(zhì)的網(wǎng)絡(luò)管理員、服務(wù)器管理員和存儲(chǔ)管理員本身夠難的了,更不用說要物色到面對多項(xiàng)IT任務(wù)時(shí)都表現(xiàn)得游刃有余的候選者。
作為一條組織原則,劃分“技能”確實(shí)可行:它不但明確了團(tuán)隊(duì)不同成員之間的職責(zé),還確保了數(shù)據(jù)中心基礎(chǔ)架構(gòu)的每一個(gè)部分都得到應(yīng)有的關(guān)注。
遺憾的是,技術(shù)卻在往一個(gè)完全不同的方向發(fā)展。數(shù)據(jù)中心的技術(shù)變得日益融合、虛擬化。正如我在之前指出的那樣,對存儲(chǔ)方面一竅不通的網(wǎng)絡(luò)管理員來說,日子越來越難過;對網(wǎng)絡(luò)方面一竅不通的存儲(chǔ)管理員來說,也是如此。
而且,這不是劃分技能的方法存在的唯一缺點(diǎn)。劃分技能的另一個(gè)副作用是,基礎(chǔ)架構(gòu)團(tuán)隊(duì)極少花心思去了解,從技術(shù)的角度來看,到底是什么讓應(yīng)用程序順利運(yùn)行。
在大多數(shù)IT部門,每個(gè)關(guān)鍵任務(wù)應(yīng)用程序都有各自專門的管理員。然而,這些成天圍繞應(yīng)用程序的管理員很少深入了解底層運(yùn)行的基礎(chǔ)架構(gòu),在設(shè)計(jì)、實(shí)施和支持方面需要依賴基礎(chǔ)架構(gòu)團(tuán)隊(duì)。反過來,基礎(chǔ)架構(gòu)團(tuán)隊(duì)也一般不大關(guān)注應(yīng)用程序,需要依賴軟件開發(fā)商才能弄清楚如何合理部署應(yīng)用程序,以便該應(yīng)用程序獲得所需要的資源。
這條應(yīng)用程序交付鏈從最終用戶的工作站開始,經(jīng)由網(wǎng)絡(luò),到達(dá)應(yīng)用程序堆棧和服務(wù)器,再一路到達(dá)存儲(chǔ)基礎(chǔ)架構(gòu);這條交付鏈有多可靠多健壯,完全取決于最薄弱的那個(gè)環(huán)節(jié)。最薄弱的那個(gè)環(huán)節(jié)十有八九出現(xiàn)在應(yīng)用程序團(tuán)隊(duì)與基礎(chǔ)架構(gòu)團(tuán)隊(duì)之間(要是沒有一位技能嫻熟的DBA,更是如此)。
真實(shí)教訓(xùn)
要明白這個(gè)問題,不妨考慮本人多年來發(fā)現(xiàn)屢屢應(yīng)驗(yàn)的一種情況:
現(xiàn)在是星期一下午2點(diǎn)15分。用戶們開始反映某個(gè)關(guān)鍵任務(wù)應(yīng)用程序遇到了嚴(yán)重的性能問題。除了性能不盡如人意外,應(yīng)用程序管理員并沒有發(fā)現(xiàn)這個(gè)應(yīng)用程序有什么問題,于是這個(gè)問題轉(zhuǎn)交給了基礎(chǔ)架構(gòu)團(tuán)隊(duì)。服務(wù)器管理員欣然加入進(jìn)來,確定應(yīng)用服務(wù)器在正常范圍內(nèi)運(yùn)行,但數(shù)據(jù)庫服務(wù)器出現(xiàn)了存儲(chǔ)延遲嚴(yán)重的問題。
隨后存儲(chǔ)管理員證實(shí):與該數(shù)據(jù)庫服務(wù)器相連接的存儲(chǔ)區(qū)域網(wǎng)(SAN)卷的確容量即將告罄,但它們本身其實(shí)沒什么問題。到這時(shí),問題已極其糟糕,好幾個(gè)管理層都注意到了這個(gè)問題,于是一群高級管理人員突然來到存儲(chǔ)管理員的辦公室,想看看到底是怎么回事。當(dāng)然,正所謂“錘子在手,滿眼釘子”;于是那名存儲(chǔ)管理員提議添加更多的磁盤;或者恐慌之余,提議將數(shù)據(jù)庫卷升級到固態(tài)硬盤。
這種情況下,整條鏈上就是沒有人真正關(guān)注該應(yīng)用程序在做什么,或者它為什么突然加大了磁盤負(fù)載。真正的問題,也是我親眼目睹的問題是,兩個(gè)頻繁存儲(chǔ)到數(shù)據(jù)庫的程序前后排得太密集了。只要其中一個(gè)程序的運(yùn)行時(shí)間比應(yīng)用程序開發(fā)商預(yù)計(jì)的長一點(diǎn),兩者就相互重疊,導(dǎo)致數(shù)據(jù)庫卷面臨頻繁的輸入/輸出操作。這兩個(gè)程序一起完成所需的時(shí)間更長,進(jìn)而與其他程序相互重疊,結(jié)果引發(fā)了雪球效應(yīng),最終導(dǎo)致了這個(gè)明顯的問題。
應(yīng)用程序團(tuán)隊(duì)對應(yīng)用程序面向用戶的那部分非常熟悉,服務(wù)器管理員對操作系統(tǒng)和硬件很了解,但就是沒有人實(shí)際負(fù)責(zé)兩者之間脫節(jié)的那個(gè)極小部分。這種情況下,勢必會(huì)導(dǎo)致性能突然大幅降低(如本文中的這個(gè)問題)。管理員條件反射般地配置過多的基礎(chǔ)架構(gòu)資源,試圖“解決”問題。
問題的反省
在當(dāng)今“少花錢多辦事”的IT環(huán)境下,這種結(jié)局司空見慣。你可能會(huì)問,“DBA到底在哪里?”問得好!以前,許多公司設(shè)有一名DBA;但如今由于預(yù)算吃緊,加上新的應(yīng)用程序大批涌入,這個(gè)人的職責(zé)轉(zhuǎn)變成了負(fù)責(zé)部署另一個(gè)新的應(yīng)用程序。誰也沒想到“少花錢多辦事”的口號到頭來成了“多花錢少辦事”:那個(gè)新增存儲(chǔ)設(shè)備的成本原本可以用來支付知道沒有必要購買更多設(shè)備的某個(gè)人的薪水。
要避免這種問題,唯一的辦法就是確保應(yīng)用程序支持鏈銜接無縫。在理想情況下,這意味著恢復(fù)DBA的職位;但在眼下這年頭,另外增加一名專職員工很少被看作是解決問題的法子。
所以到頭來,這個(gè)職責(zé)被轉(zhuǎn)移到存儲(chǔ)管理員、服務(wù)器管理員和網(wǎng)絡(luò)管理員的身上。他們完全需要自力更生,不斷充電,學(xué)習(xí)自己支持的應(yīng)用程序的基本要點(diǎn)。畢竟,一旦哪里出了錯(cuò),受責(zé)備的往往是管理員。性能圖表上不會(huì)平白無故地出現(xiàn)性能驟降,它們往往與功能失常的硬件沒有多大的關(guān)系。連高層管理人員沒有注意的稍縱即逝的異常現(xiàn)象也值得仔細(xì)分析,以查明根源。這些異??赡苁窍滦瞧谝唤o你當(dāng)頭一棒的問題體現(xiàn)出來的征兆。
【推薦閱讀】
◆IT運(yùn)維管理專區(qū)
◆系統(tǒng)管理員如何面對角色裂變?
◆系統(tǒng)管理員需要掌握哪些軟技能?
◆強(qiáng)迫癥會(huì)害死系統(tǒng)管理員
◆網(wǎng)管軟件專區(qū)
本文來自互聯(lián)網(wǎng),僅供參考