5.1 网站可用性的度量与考核
5.1.1 网站可用性度量
网站不可用时间(故障时间)=故障修复时间-故障发现(报告)时间点
网站年度可用性指标=(1-网站不可用时间/年度总时间)x100%
2个9是基本可用，网站年度不可用时间小于88小时；
3个9是较高可用，网站年度不可用时间小于9小时；
4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；
5个9是极度高可用，网站年度不可用时间小于5分钟。
由于可用性影响因素很多，对于网站整体而言，达到4个9，乃至5个9的可用性，除了过硬的技术、大量的设备资金投入和工程师的责任心，还要有个好运气。
5.1.2 网站可用性考核
网站可用性，跟技术、运营、相关各方的绩效考核息息相关，因此在架构设计与评审会议上，关于系统可用性的讨论与争执总是最花时间与精力的部分。
当然不同的公司有不同的企业文化和市场策略，这些因素也会影响到系统可用性的架构决策，崇尚创新和风险的企业会对可用性要求稍低一些；
业务增长快速的网站忙于应对指数级增长的用户，也会降低可用性标准；
服务于收费用户的网站则会比服务于免费用户的网站对可用性更加敏感。
5.2 高可用网站架构
高强度频繁读写会导致硬件故障。高可用架构设计的目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。
实现高可用的主要手段是数据和服务的冗余备份和失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。
三层分层架构
不同业务产品属于应用层
不同产品依赖的一些共同的复用的业务，如注册登录服务、Session管理服务、账户管理服务等，属于服务层
数据层：数据库、文件服务、缓存服务、搜索服务
应用层高可用：
通过负载均衡技术，将一组服务器组成一个集群共同对外提供服务，当负载均衡设备通过心跳检测手段监控到某台应用服务器不可用时，就将其从集群列表中剔除，并将请求分发到集群中其他可用的服务器上，使整个集群保持可用，从而实现应用高可用。
服务层高可用：
通过集群实现高可用，这些服务器被应用层通过分布式服务调用框架访问，分布式服务调用框架会在应用层客户端中实现软件负载均衡，并通过服务注册中心对提供的服务器进行心跳检测，发现有服务不可用，立即通知客户端程序修改服务访问列表，剔除不可用的服务器。
数据层高可用：
数据层高可用一般会热备，在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。当服务器宕机时，应用程序将访问切换到有备份数据的服务器上。
上面是应对硬件故障的可用性措施，除了这些，还要应对发布升级引起的宕机，因为发布越频繁，发布的内容越多，越复杂，更容易出故障。
需要通过发布自动化将认为发布引起的故障降到最小。