開篇小故事

　　下面的故事都是真實(shí)的，猶如雷同純屬同類，請(qǐng)仔細(xì)反思。

　　故事1：升級(jí)硬件

　　客戶后臺(tái)數(shù)據(jù)庫存在性能問題，查詢特別慢，長(zhǎng)時(shí)間語句很多。客戶因此而苦惱，咨詢了軟件廠商我該怎么辦？軟件廠商給出的答案：升級(jí)硬件吧，現(xiàn)在的資源不能滿足了！

　　那么客戶是什么硬件配置呢？數(shù)據(jù)庫什么體量呢？

　　答：128的CPU、512的內(nèi)存、高端的存儲(chǔ)，跑了一個(gè)200G數(shù)據(jù)量的庫，好像硬件滿滿的夠用呀！

　　問題的根源就是最基本的大量少索引而已！

　　

　　故事2：負(fù)載均衡

　　客戶想做數(shù)據(jù)庫的負(fù)載均衡，于是找到我們，各種方案各種高大上的說，我深深的被客戶的前衛(wèi)思想洗禮了一下，畢竟傳統(tǒng)行業(yè)很多對(duì)數(shù)據(jù)庫性能，安全方面的一些保障不是很完善。

　　前期談的很愉快，然后我去檢查客戶的現(xiàn)有環(huán)境，更驚奇的事情發(fā)生了，2臺(tái)跑在同一個(gè)物理機(jī)上的虛擬機(jī)要做負(fù)載均衡？

　　合久必分，分久必合的節(jié)奏？

 

　　故事3：高配更慢？

　　客戶在原有64CPU、128內(nèi)存的服務(wù)器進(jìn)行升級(jí)變成128CPU、512內(nèi)存，升級(jí)硬件也是軟件廠商建議提高服務(wù)器配置，升級(jí)完成以后客戶發(fā)現(xiàn)系統(tǒng)更慢了！這也可以？

　　正常的情況添加硬件資源不會(huì)出現(xiàn)這樣的情況，那么這個(gè)客戶是為什么呢？找了服務(wù)器的廠商各種檢測(cè)，各種報(bào)告分析，無法得知原因，最終換回原配置的服務(wù)器。

　　這是為什么: 該軟件廠商的程序基本是使用定制化模板，根據(jù)業(yè)務(wù)拼接，開發(fā)方便，但是后臺(tái)語句條件復(fù)雜，語句龐大在數(shù)據(jù)量增大以后語句的執(zhí)行變得很耗資源，也更依賴與CPU的并行，在沒有設(shè)置并行度的情況下升級(jí)硬件（添加CPU），導(dǎo)致并行度過高，語句執(zhí)行更慢。說白了就是簡(jiǎn)單的一個(gè)參數(shù)配置問題！

這些問題你是否有？

photoshop培訓(xùn),電腦培訓(xùn),電腦維修培訓(xùn),移動(dòng)軟件開發(fā)培訓(xùn),網(wǎng)站設(shè)計(jì)培訓(xùn),網(wǎng)站建設(shè)培訓(xùn)

　　這樣那樣的問題到底是什么原因呢？誰又該來改善這樣的現(xiàn)狀呢？

 

用戶的問題

　　在很多傳統(tǒng)行業(yè)里，IT部門沒有專門的DBA，或者所謂的DBA是這樣一種角色：往往身兼數(shù)職（網(wǎng)管、項(xiàng)目管理、協(xié)調(diào)廠商、DBA、開發(fā)、應(yīng)用、寫報(bào)告），既有很多協(xié)調(diào)性的管理工作，又有一些專業(yè)技術(shù)工作。這其實(shí)和網(wǎng)上產(chǎn)品經(jīng)理的段子很類似。

　　其實(shí)也就是說用戶沒有管理好自己的數(shù)據(jù)庫，很多時(shí)候數(shù)據(jù)庫的一些運(yùn)維配置都停留在軟件廠商部署時(shí)候的配置，經(jīng)過幾年的業(yè)務(wù)和數(shù)據(jù)的積累這些配置可能早就不適用了。再說日常的體檢，隨著業(yè)務(wù)增長(zhǎng)的長(zhǎng)期規(guī)劃....好吧，那就更是沒有了！

　　而且更糟的是，在日常的使用過程中對(duì)數(shù)據(jù)庫還存在一些改造，比如毫無規(guī)劃的添加數(shù)據(jù)表，一些周邊功能的開發(fā)，其他方案的拼接。

　　所以問題慢慢的積累慢慢的爆發(fā)。

　　看到這有些看官自然會(huì)想，我們購買的軟件，數(shù)據(jù)庫不應(yīng)該是軟件廠商管的東西么？為什么我們要請(qǐng)DBA呢？

 

軟件廠商的問題

　　我?guī)啄甑拈_發(fā)經(jīng)歷中就有過在軟件廠商做運(yùn)維的經(jīng)歷，那個(gè)時(shí)候真的是頭大，天天電話不斷今天這問題明天那問題：業(yè)務(wù)問題，數(shù)據(jù)不一致問題，功能修改，新功能上線，無聊的會(huì)議，客戶突發(fā)奇想我還得跟著聽聽吹牛。我可以夸大點(diǎn)說當(dāng)時(shí)在做開發(fā)沒有轉(zhuǎn)到DBA的時(shí)候，我的數(shù)據(jù)庫技能可能是整個(gè)運(yùn)維團(tuán)隊(duì)里最好的：基本的調(diào)優(yōu)，索引的應(yīng)用，一些系統(tǒng)視圖的應(yīng)用，指標(biāo)的檢測(cè)，聽起來挺厲害了吧！

　　所以我就是運(yùn)維中的DBA了？

　　現(xiàn)在回想起來，其實(shí)那個(gè)時(shí)候?qū)?shù)據(jù)庫的了解根本沒有成體系，對(duì)問題的分析也是比較片面的。解決問題也是東一錘子西一棒子，加個(gè)索引CPU指標(biāo)降下來了，語句也快起來了，認(rèn)為問題解決了，其實(shí)可能并沒有。

　　呵呵，但是！在運(yùn)維的時(shí)候我一天天忙的狗一樣，客戶不反應(yīng)問題，我肯定不會(huì)主動(dòng)做優(yōu)化做體檢，客戶反映問題了，簡(jiǎn)單看一看能推就推，客戶急眼了，能安撫就安撫，迫不得以出手解決一下，長(zhǎng)期積累的問題花了很長(zhǎng)的時(shí)間，還很可能解決不了[苦笑][苦笑]。

　　看到幾個(gè)指標(biāo)高，又解決不了，那么第一反應(yīng)基本就是加硬件吧。

矛盾點(diǎn)

　　用戶不會(huì)配置專門的人干這樣的事情，感覺都是廠商的問題，而廠商的人手技能也有限，很多軟件廠商沒有專業(yè)的數(shù)據(jù)庫人員，又不一定能做這樣的事情，最酷（苦）的就是運(yùn)維人員、開發(fā)人員整天從早忙到晚連口水都喝不上，卻被打上差評(píng)的標(biāo)簽。廠商在客戶面前慢慢的失去了信服力，客戶對(duì)于遲遲不能解決的問題更是很氣憤，還想繼續(xù)收運(yùn)維費(fèi)用？廠商有時(shí)也很無奈，很多時(shí)候又并不是軟件的問題。

　　矛盾　　矛盾　　矛盾

　　扯皮　　扯皮　　扯皮

說說企業(yè)運(yùn)維

　　也許是崇洋媚外，接觸過幾家國外的軟件公司他們的運(yùn)維保障服務(wù)做的確實(shí)好，但價(jià)錢也確實(shí)高，反觀國內(nèi)的一些軟件公司很多公司在開發(fā)階段基本是賠錢賺吆喝，而運(yùn)維保障費(fèi)用才是收入的開始，但是運(yùn)維保障的效果確實(shí)不怎么理想，當(dāng)然如果你是大客戶給得起錢，那自然駐場(chǎng)工程師多多，服務(wù)周到，解決不了的問題也要死磕到天亮。

　　慢慢的國內(nèi)協(xié)作運(yùn)維服務(wù)已經(jīng)熱起來，專業(yè)的人干專業(yè)的事兒~也許這樣的第三方運(yùn)維引入可以解決上面的問題，一部分企業(yè)已經(jīng)先行嘗到了這種你好，我好，他也好的甜頭。

　　企業(yè)運(yùn)維服務(wù)已經(jīng)是這個(gè)樣子了：

　　企業(yè)服務(wù)市場(chǎng)，橫向按客戶規(guī)模分為大客戶市場(chǎng)和中小客戶市場(chǎng)，縱向目前最火的三大領(lǐng)域分別是大數(shù)據(jù)、云計(jì)算和運(yùn)維服務(wù)市場(chǎng)，云再細(xì)分為SaaS、PaaS和IaaS，這樣就構(gòu)成了如下市場(chǎng)布局：

　　

　　從運(yùn)維服務(wù)產(chǎn)品角度來說，至少分為三層不同的能力，每一層都有各自不同的特點(diǎn)和要求：

  • 可視化統(tǒng)一管理能力：從統(tǒng)一信息采集、監(jiān)控告警到可視化運(yùn)維管理能力，這個(gè)是ITOM的基礎(chǔ)能力，做到運(yùn)維服務(wù)的統(tǒng)一管理和可視化；

  • 自動(dòng)化運(yùn)維服務(wù)能力：從運(yùn)維自動(dòng)化的統(tǒng)一控制、任務(wù)編排、網(wǎng)絡(luò)業(yè)務(wù)開通和執(zhí)行到自動(dòng)化運(yùn)維服務(wù)場(chǎng)景迭代，這是ITOM升級(jí)進(jìn)化的必然之路，做到工具解放人力。

  • 場(chǎng)景化驅(qū)動(dòng)業(yè)務(wù)能力：運(yùn)維產(chǎn)品最終要為運(yùn)維服務(wù)、要為業(yè)務(wù)服務(wù)，從敏捷開發(fā)到敏捷運(yùn)維，實(shí)現(xiàn)工具優(yōu)化業(yè)務(wù)，讓運(yùn)維更敏捷。