通过阅读《大型网站技术架构：核心原理与案例分析》第五六七章，结合《xx系统》，分析如何增加相应的功能，提高系统的可用性与易用性的感想：
网站的可用性描述网站的可有效访问的特性（不同于另一个网站运营指标：Usability,通常也被译为可用性，但后者强调的是网站的可用性，即对最终用户的使用价值），相对于网站的其他非功能特性，网站的可用性更牵动人们的神经，大型网站不可用事故直接影响公司形象和利益，许多互联网公司都将网站可用性例如工程师的绩效考核，与奖金省钱等利益挂钩。
不同于其他架构指标，网站的可用性更加看得见摸得着，跟技术、运营、相关各方的绩效考核息息相关，因此在架构设计与评审会议上，关于可用性的讨论与争执总是浪费时间与精力的部分。
通常企业级应用软件为提高系统的可用性，会采用比较昂贵的软硬件设备，如IBM的小型机乃至中型机大型机及专有操作系统、Oracle数据库、EMC存储设备等。互联网公司更多的采用PC级服务器、开源的数据库和操作系统，这些廉价的设备在节约成本的同时也降低了可用性，特别是服务器硬件设备，低价的商业级服务器一年宕机一次是一个大概率事件，而那些高强度频繁读写的普通硬盘，孙环的概率则要更高一些。
既然硬件故障是常态，网站的高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保存并且能够被访问。而实现上述高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。
应用层主要处理网站应用的业务逻辑，因此又是也称作业务逻辑层，应用的一个显著特点是应用的无状态性。所谓的无状态性是指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的逻辑处理，多个服务实例（服务器）之间完全对等，请求提交到任意服务器，处理的结果都是完全不一样的。
通过负载均衡进行无状态服务的失效转移。不保存状态的应用给高可用的架构设计带来了巨大便利，既然拂去其不保存请求的状态，那么所有的服务器完全对等，当任意一台或多台服务器宕机，请求提交给集群中其他任意一台可用机器处理，这样对终端用户而言，请求总是成功的，整个系统仍然可用。对于应用服务器集群，实现这种服务器可用状态实时监测、自动转移失败任务的机制是负载均衡。在网站应用中，当集群中的服务是无状态对等时，负载均衡可以起到事实上高可用的作用。
除此之外，具体实践中，还可以有以下高可用的服务策略：分级管理、超时设置、异步调用、服务降级、幂等性设计等。
即使是经过严格的测试，软件部署到线上服务器之后还是经常会出现各种问题，甚至根本无法启动服务器。主要原因是测试环境与线上环境并不相同，特别是应用需要依赖的其他服务，如数据库，缓存、公用业务服务等，以及一些第三方服务，如电信短信、银行网银接口等。也许是数据库表结构不一致；也许是接口变化导致的通信失败；也许是配置错误导致的连接失败；也许是依赖的服务上线环境还没有准备好，这些问题都有可能导致应用故障。因此在网站发布时，并不是把测试通过的代码包直接发布到线上服务器，而是先发布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行一些典型的业务流程，确定系统没有问题后才正式发布。
网站架构发展史就是一部不断向网站添加服务器的历史。只要工程师能向网站的服务器集群添加新的机器，只要新添加的服务器能线性提高网站的整体服务处理能力，网站就无需为不断增长的用户和访问而焦灼。网站的伸缩性可分为两类，一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。前者是不同的服务器部署不同的服务，提供不同的功能；后者是集群内的多台服务器部署相同的服务，提供相同的功能。