開篇小故事 下麵的故事都是真實的,猶如雷同純屬同類,請仔細反思。 故事1:升級硬體 客戶後臺資料庫存在性能問題,查詢特別慢,長時間語句很多。客戶因此而苦惱,咨詢了軟體廠商我該怎麼辦?軟體廠商給出的答案:升級硬體吧,現在的資源不能滿足了! 那麼客戶是什麼硬體配置呢?資料庫什麼體量呢? 答:128的CP ...
開篇小故事
下麵的故事都是真實的,猶如雷同純屬同類,請仔細反思。
故事1:升級硬體
客戶後臺資料庫存在性能問題,查詢特別慢,長時間語句很多。客戶因此而苦惱,咨詢了軟體廠商我該怎麼辦?軟體廠商給出的答案:升級硬體吧,現在的資源不能滿足了!
那麼客戶是什麼硬體配置呢?資料庫什麼體量呢?
答:128的CPU、512的記憶體、高端的存儲,跑了一個200G數據量的庫,好像硬體滿滿的夠用呀!
問題的根源就是最基本的大量少索引而已!
故事2:負載均衡
客戶想做資料庫的負載均衡,於是找到我們,各種方案各種高大上的說,我深深的被客戶的前衛思想洗禮了一下,畢竟傳統行業很多對資料庫性能,安全方面的一些保障不是很完善。
前期談的很愉快,然後我去檢查客戶的現有環境,更驚奇的事情發生了,2台跑在同一個物理機上的虛擬機要做負載均衡?
合久必分,分久必合的節奏?
故事3:高配更慢?
客戶在原有64CPU、128記憶體的伺服器進行升級變成128CPU、512記憶體,升級硬體也是軟體廠商建議提高伺服器配置,升級完成以後客戶發現系統更慢了!這也可以?
正常的情況添加硬體資源不會出現這樣的情況,那麼這個客戶是為什麼呢?找了伺服器的廠商各種檢測,各種報告分析,無法得知原因,最終換回原配置的伺服器。
這是為什麼: 該軟體廠商的程式基本是使用定製化模板,根據業務拼接,開發方便,但是後臺語句條件複雜,語句龐大在數據量增大以後語句的執行變得很耗資源,也更依賴與CPU的並行,在沒有設置並行度的情況下升級硬體(添加CPU),導致並行度過高,語句執行更慢。說白了就是簡單的一個參數配置問題!
這些問題你是否有?
這樣那樣的問題到底是什麼原因呢?誰又該來改善這樣的現狀呢?
用戶的問題
在很多傳統行業里,IT部門沒有專門的DBA,或者所謂的DBA是這樣一種角色:往往身兼數職(網管、項目管理、協調廠商、DBA、開發、應用、寫報告),既有很多協調性的管理工作,又有一些專業技術工作。這其實和網上產品經理的段子很類似。
其實也就是說用戶沒有管理好自己的資料庫,很多時候資料庫的一些運維配置都停留在軟體廠商部署時候的配置,經過幾年的業務和數據的積累這些配置可能早就不適用了。再說日常的體檢,隨著業務增長的長期規劃....好吧,那就更是沒有了!
而且更糟的是,在日常的使用過程中對資料庫還存在一些改造,比如毫無規劃的添加數據表,一些周邊功能的開發,其他方案的拼接。
所以問題慢慢的積累慢慢的爆發。
看到這有些看官自然會想,我們購買的軟體,資料庫不應該是軟體廠商管的東西麽?為什麼我們要請DBA呢?
軟體廠商的問題
我幾年的開發經歷中就有過在軟體廠商做運維的經歷,那個時候真的是頭大,天天電話不斷今天這問題明天那問題:業務問題,數據不一致問題,功能修改,新功能上線,無聊的會議,客戶突發奇想我還得跟著聽聽吹牛。我可以誇大點說當時在做開發沒有轉到DBA的時候,我的資料庫技能可能是整個運維團隊里最好的:基本的調優,索引的應用,一些系統視圖的應用,指標的檢測,聽起來挺厲害了吧!
所以我就是運維中的DBA了?
現在回想起來,其實那個時候對資料庫的瞭解根本沒有成體系,對問題的分析也是比較片面的。解決問題也是東一錘子西一棒子,加個索引CPU指標降下來了,語句也快起來了,認為問題解決了,其實可能並沒有。
呵呵,但是!在運維的時候我一天天忙的狗一樣,客戶不反應問題,我肯定不會主動做優化做體檢,客戶反映問題了,簡單看一看能推就推,客戶急眼了,能安撫就安撫,迫不得以出手解決一下,長期積累的問題花了很長的時間,還很可能解決不了[苦笑][苦笑]。
看到幾個指標高,又解決不了,那麼第一反應基本就是加硬體吧。
矛盾點
用戶不會配置專門的人乾這樣的事情,感覺都是廠商的問題,而廠商的人手技能也有限,很多軟體廠商沒有專業的資料庫人員,又不一定能做這樣的事情,最酷(苦)的就是運維人員、開發人員整天從早忙到晚連口水都喝不上,卻被打上差評的標簽。廠商在客戶面前慢慢的失去了信服力,客戶對於遲遲不能解決的問題更是很氣憤,還想繼續收運維費用?廠商有時也很無奈,很多時候又並不是軟體的問題。
矛盾 矛盾 矛盾
扯皮 扯皮 扯皮
說說企業運維
也許是崇洋媚外,接觸過幾家國外的軟體公司他們的運維保障服務做的確實好,但價錢也確實高,反觀國內的一些軟體公司很多公司在開發階段基本是賠錢賺吆喝,而運維保障費用才是收入的開始,但是運維保障的效果確實不怎麼理想,當然如果你是大客戶給得起錢,那自然駐場工程師多多,服務周到,解決不了的問題也要死磕到天亮。
慢慢的國內協作運維服務已經熱起來,專業的人乾專業的事兒~也許這樣的第三方運維引入可以解決上面的問題,一部分企業已經先行嘗到了這種你好,我好,他也好的甜頭。
企業運維服務已經是這個樣子了:
企業服務市場,橫向按客戶規模分為大客戶市場和中小客戶市場,縱向目前最火的三大領域分別是大數據、雲計算和運維服務市場,雲再細分為SaaS、PaaS和IaaS,這樣就構成瞭如下市場佈局:
從運維服務產品角度來說,至少分為三層不同的能力,每一層都有各自不同的特點和要求:- 可視化統一管理能力:從統一信息採集、監控告警到可視化運維管理能力,這個是ITOM的基礎能力,做到運維服務的統一管理和可視化;
- 自動化運維服務能力:從運維自動化的統一控制、任務編排、網路業務開通和執行到自動化運維服務場景迭代,這是ITOM升級進化的必然之路,做到工具解放人力。
- 場景化驅動業務能力:運維產品最終要為運維服務、要為業務服務,從敏捷開發到敏捷運維,實現工具優化業務,讓運維更敏捷。
--------------博客地址-----------------------------------------------------------------------------
博客地址 http://www.cnblogs.com/double-K/
歡迎轉載請保留出處
-----------------------------------------------------------------------------------------------------
總結
專業的人乾專業的事兒~協作運維的時代已經來臨!
現在自己公司的SQL Server的SaaS雲平臺也已經上線,一改傳統的觀念,跟著這波新的浪潮玩轉企業運維,不斷學習不斷思考,不斷的學習...
充實自己 ~ 寫在2016的最後一周~
----------------------------------------------------------------------------------------------------
註:此文章為原創,歡迎轉載,請在文章頁面明顯位置給出此文鏈接!
若您覺得這篇文章還不錯請點擊下右下角的推薦,非常感謝!