数据库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