數據庫HA
一般把數據庫層面的HA，和應用層面HA分開考慮
數據庫一般采用數據庫產品提供的HA方案，比如Oracle的RAC，mysql的集群，mongodb的replica set等
無HA的運維
在應用層面不做HA，我們產品有試過，后果十分慘重。無論是應用down了，還是硬件故障，都會造成業務中斷。而且這時候想定位問題就十分糾結，因為保留現場去定位問題比較理想，但是業務一直不恢復客戶又有意見，所以不做HA在生產環境是強烈不推薦的
如果真的沒有HA，那運維也就是人工觀察，發現業務中斷了，就趕快把應用再啟起來。好一點的話，可以做一點自動拉起引用的腳本，實現自動化。但是因為硬件始終只有一台，所以有時候沒有辦法啟起來，只能臨時遷移，業務中斷時間會很長。而且只有一套環境，會發生應用一起來馬上又down掉
冷備
基本上就是准備兩套硬件，一套跑業務，另一套備用。第一套壞了，就把備用的那套啟起來。這樣基本可以抗硬件故障，因為2套硬件同時壞的幾率比較低。也可以把2套硬件放在不同的網段，這樣還可以抗網絡故障
不過也有幾個問題：
1、成本高，硬件成本，以及相應的機櫃場租、電費也跟着上去了
2、第二套啟動需要時間，所以業務還是會中斷一會，如果是對可用性要求很嚴格的服務，冷備的方案基本無法滿足
一般會搭配一些HA管理軟件，業界比較有名的是VERITAS，可以自動改IP，自動啟應用等，不過也比較貴
N:1備份
也是冷備的一種，不過比硬件double的方案能省一些成本。前提是應用是分布式的，那么可以只准備一台額外的機器，把所有分布式組件都部署上，然后哪個組件壞了就啟哪個。如果同時2個組件壞了，那就沒辦法了。啟動過程中的業務中斷也是無法避免的。總的來說，可靠性不如完全的冷備方案，不過能省點成本
熱備負載均衡
這種方案是可用性最高的方案，同時啟動2套應用，在上層加一個負載均衡。如果一套壞了，就把請求發到好的那一台，再嘗試恢復壞的那一套。業務是不中斷的，但是只剩一套應用的那段時間，壓力會突然大很多
前提是應用需要是無狀態的，否則壞了那台機的請求，也沒法轉發到別的機器上。基本上應用只要滿足這個條件，都會選擇熱備，選擇冷備一般是無奈的選擇（無狀態改造短期做不到），因為消耗的硬件是一樣的，熱備的效果明顯要更好HA