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