MySQL數(shù)據(jù)庫運維的五大指標(biāo)
如何評價一個公司數(shù)據(jù)庫運維水平的高低？用什么來進行橫向與縱向?qū)Ρ龋孔詣踊脚_建設(shè)的目標(biāo)是什么？必須有相應(yīng)的指標(biāo)體系來指導(dǎo)，此指標(biāo)體系必須滿足以下條件：
- 可以用數(shù)字來測算和衡量
- 最終指標(biāo)，而不是中間指標(biāo)
比如有時DBA會關(guān)注數(shù)據(jù)庫的吞吐量，但吞吐量越高不能代表數(shù)據(jù)庫提供的服務(wù)質(zhì)量越好，開發(fā)人員關(guān)心這個指標(biāo)的原因也是因為擔(dān)心過高的吞吐量會影響響應(yīng)時間或者造成系統(tǒng)不可用，所以這只是一個中間指標(biāo)。
- 可以全面衡量一個網(wǎng)站的數(shù)據(jù)庫運維水平，而不會顧此失彼
- 有人文關(guān)注
1.1. 數(shù)據(jù)安全
數(shù)據(jù)安全是第一位的，DBA的首要職責(zé)必須保證不丟數(shù)據(jù)，丟掉數(shù)據(jù)就丟掉了飯碗！
這有3方面的含義：
1）在人為誤操作的時候（update,insert,delete,drop,alter)，能夠恢復(fù)數(shù)據(jù)到正確的狀態(tài)
2）在機房，硬件故障或者操作系統(tǒng)，數(shù)據(jù)庫軟件故障的時候，能夠恢復(fù)數(shù)據(jù)到正確的狀態(tài)
3）不丟事務(wù)，保證已經(jīng)入庫的數(shù)據(jù)能夠被正確的查詢到
另外，還要注意到需要保證主從數(shù)據(jù)庫的一致性，否則讀寫分離的情況下其實在用戶看來仍然丟失了數(shù)據(jù)。
對于1，主要靠備份來保證，因為復(fù)制可以容災(zāi)，卻不可以容錯（當(dāng)然延遲備份在一定程度可以）。
對于2，可能用備份來恢復(fù)，也可能直接進行主庫或者從庫的切換來恢復(fù)服務(wù)
對于3，電商，支付庫的要求會非常高，采用最高安全級別的數(shù)據(jù)庫軟硬件設(shè)置以及冗余設(shè)備，目標(biāo)是不丟任何1個事務(wù)，因為即使1個事務(wù)也可能造成大量金錢的損失，同時造成企業(yè)信譽的下降。
“911”事件曾造成1200家公司受災(zāi)，其中一半以上的企業(yè)因為IT數(shù)據(jù)損毀、丟失，導(dǎo)致業(yè)務(wù)無法恢復(fù)，以致于宣布倒閉。金融界巨頭Morgan Stanley 全球營業(yè)部第二天就恢復(fù)正常工作，正是因為先前建立的遠(yuǎn)程容災(zāi)系統(tǒng)保護了重要的數(shù)據(jù)。
可測量指標(biāo)：
- RPO（Recovery Point Object）：恢復(fù)點指標(biāo)，是指災(zāi)難發(fā)生后，容災(zāi)系統(tǒng)能把數(shù)據(jù)恢復(fù)到災(zāi)難發(fā)生前的哪一個時間點的數(shù)據(jù)，它衡量企業(yè)在災(zāi)難發(fā)生后會丟失多少生產(chǎn)數(shù)據(jù)
- RTO（Recovery Time Object）：系統(tǒng)恢復(fù)的時間
RPO說明了備份的可靠性和完整性，RTO說明了恢復(fù)的可靠性與速度。
由于MySQL開源版本并不提供熱備的工具以及備份管理的工具（ＭSSQL，Oracle是提供的，當(dāng)然它們是商業(yè)軟件），所以要求ＤBA開發(fā)出自己的備份還原管理平臺（腳本）。這也是DBA的首件工作。#p#
1.2. 無故障（停機）時間
運維和開發(fā)不一樣，開發(fā)最重要的是保證一定效率的情況下實現(xiàn)功能，同時程序Bug少。運維講的是提供穩(wěn)定服務(wù)的時間。用術(shù)語來說就是幾個9，具體含義就是年度不可服務(wù)（不管是主動的還是被動的）時間除以全年時間，百分比越高越好。具體和時間的換算關(guān)系見下表：
根據(jù)墨菲定理（If anything can go wrong,it will）的推論，世界上沒有 100% 可靠的 Web站點(除非不運行)。運維的最高境界當(dāng)然就是5個9了，一年停機時間只有5分鐘，這是相當(dāng)難以達(dá)到的目標(biāo)，往往一個大故障就會把全年的停機時間用完。
業(yè)界網(wǎng)站的可用性都是多少？引人注目的 Web 新貴 Twitter (http://twitter.com)， 2008 年前四個月的可用性只有 98.72%，有 37小時 16分鐘不能提供服務(wù)，連2個9 都達(dá)不到，甚至還沒達(dá)到”基本可用”狀態(tài)。電子商務(wù)巨頭 eBay 2007 年的可用性是 99.94%，考慮到 eBay 站點的規(guī)模與應(yīng)用的復(fù)雜程度，這是個很不錯可用性指標(biāo)了。
多數(shù)情況下，網(wǎng)站可用性會是 SLA （Service Level Agreement, 服務(wù)水平協(xié)議) 中的一個重要度量指標(biāo)，也是運維團隊向自己老板做出的正式承諾。但可用性是能夠持續(xù)改進的東西，運維負(fù)責(zé)人不可希望一步登天。
另外，如果是做第三方托管，需要明確第三方的服務(wù)能力與責(zé)任。否則，IDC 經(jīng)常斷電或者斷網(wǎng)，即使自身做的再好也無法保證服務(wù)時間了。
提高可用性的一些常規(guī)策略有消除單點，部署冗余設(shè)備等。如果要提供更高的可用性，比如 4 個 9 甚至 5 個9，就不是簡單靠硬件就能做到的事情，還需要建立自動化的工具與平臺，完善的流程制度與變更機制，7*24小時的專人值班等。
可測量指標(biāo)：
年度不可服務(wù)時間比例：年度不可服務(wù)（不管是主動的還是被動的）時間除以全年時間。#p#
1.3. 響應(yīng)時間
響應(yīng)時間是指一條查詢或者更新語句從發(fā)出請求到接收完數(shù)據(jù)的時間。
因為最大響應(yīng)時間的不確定性和不可重復(fù)性，所以一般使用X%的查詢響應(yīng)時間作為指標(biāo)。如果值為95%為10ms，意味著95%的查詢會在10ms內(nèi)返回。對于OLTP查詢來說，在50ms內(nèi)返回是比較理想的結(jié)果。超過200ms的查詢可以視為慢查詢。
此指標(biāo)較難收集，采用tcprstat雖然可以，但是tcprstat本身有一定的負(fù)載，另外也只收集最高到99%的響應(yīng)時間，如果想知道比如99.999%的平均、最大響應(yīng)時間就需要修改源碼了。
目前有2個思路收集此數(shù)據(jù)：
采用tcpdump+pt-query-digest，將tcpdump抽樣數(shù)據(jù)發(fā)送到中心機上利用pt-query-digest進行分析，然后入庫后顯示。此方法也需要修改pt源碼，因為原版的pt支持的粒度太粗了，如下圖，100ms直接跳到了1s：
此方法的優(yōu)點是可以顯示不同語句的情況，缺點是如果抽樣時間長，中心機分析不完，而抽樣時間短又可能信息沒有代表性。
另外一個更輕量級的方法是將慢查詢?nèi)罩鹃y值打到50ms甚至更低，然后統(tǒng)計慢查詢時間的分布，可以按時間和服務(wù)器維度進行分析（使用pt工具也可以得到不同語句的響應(yīng)時間分布）如下表所示：
- 4901 130421
- dt num avg
- —————————–
- 0 1839 605
- 1 920 596
- 2 1215 450
- 3 973 481
- 4 488 603
- 5 449 487
- 6 516 597
- 7 874 634
- 8 1129 532
- 9 1160 457
- 10 1115 502
- 11 987 529
- 12 1531 559
- 13 1185 537
- 14 2238 1235
- 15 1418 534
- 16 1589 535
- 17 951 548
- 18 1790 531
- 19 1520 503
- 20 1845 496
- 21 1855 542
- 22 1583 564
- 23 1840 562
- None 31010 587
- ip num ratio
- —————————–
- 10.73.xx.xx 4418 14
- 10.75.xx.xx 121 0
- 10.75.xx.xx 7905 25
- 10.75.xx.xx 5706 18
- 10.75.xx.xx 6812 22
- 10.75.xx.xx 6048 20
- None 31010 100
根據(jù)此結(jié)果可以發(fā)現(xiàn)慢查詢在服務(wù)器之間分布并不均衡，這也是分析問題的很好的切入點。
可測量指標(biāo)：
X%的查詢/寫入響應(yīng)時間（ms）。#p#
1.4. 成本
在解決了穩(wěn)定和速度后，就是成本的問題了。有人認(rèn)為如果不計較成本，任何功能都是可以實現(xiàn)的，并且不需要高深的技術(shù)。我不完全認(rèn)同這個觀點。但架構(gòu)師的使命的確不僅僅是“完成”功能，如果說完成功能可以有50種方法，
因為經(jīng)濟學(xué)上認(rèn)為找到最優(yōu)方案可能成本比回報還要高，那么至少要找出相對較優(yōu)的幾種方法并進行最終的選擇。
成本的構(gòu)成主要是硬件成本＋軟件成本＋人力成本，因為互聯(lián)網(wǎng)企業(yè)軟件以自主開發(fā)和開源為主，所以其中主要是硬件和人力成本，硬件成本也包含了機房的機架，帶寬，電力成本。
對大型互聯(lián)網(wǎng)公司來說，服務(wù)器規(guī)模都在上萬臺以上，Google的服務(wù)器規(guī)模更達(dá)到了百萬級。而互聯(lián)網(wǎng)公司的人才規(guī)模也是相當(dāng)驚人，TAB公司的人員都在萬人以上。
因此如何能夠提高硬件的使用效率，降低人工運維成本，提高人均產(chǎn)出，也就成為關(guān)系到互聯(lián)網(wǎng)公司生死存亡的事情了。
可測量指標(biāo)：
投入成本＝硬件成本（含機架，帶寬，電力）＋軟件成本(ＭySQL可忽略) ＋人力成本
1.5. 運維人員幸福度
運維自動化是方向不假，但目前階段來說，有很多工作還需要人來完成，越是復(fù)雜的工作越需要人工干預(yù)。對于一些創(chuàng)業(yè)公司，自動化平臺更是要從頭打造，此時間段內(nèi)的很多操作需要手工完成。
克拉克的《與拉瑪相會》描繪了一個完全靠機器人運維，在太空中飛行了上萬年的巨大人工飛行器。但現(xiàn)在科技畢竟離此階段還差得遠(yuǎn)。人也不是機器人，是有個性，獨一無二的智慧生物。
為了體現(xiàn)運維的人文關(guān)懷，必須加入人員幸福度指標(biāo)。
幸福度可以從3方面考量：
1）人均承擔(dān)數(shù)據(jù)庫讀寫量（如果數(shù)據(jù)庫讀寫量大，這個值低，那么必然運維人員多，人均產(chǎn)值/薪酬低）
2）運維人員長期從事機械化的，重復(fù)性工作的時間比例
3）運維人員在工作時間以外進行切換上線，故障處理的時間比例
如果這3項指標(biāo)差， 那就意味著團隊的幸福感差，必然離職率高。所以離職率也是衡量指標(biāo)之一。
如果有一個系統(tǒng)能夠?qū)⑸厦娴?個指標(biāo)都量化記錄下來，并采用各種方法持繼改進指標(biāo)，相信最終會建立一個比較好的運維平臺。
