在这一节课上，我们学习了系统质量属性其中的可用性和易用性。那么质量属性是什么呢，质量属性是高于对系统功能（即对系统能力、服务和行为）的基本的要求的。系统质量属性讲重点放在了可用性、可修改性、性能、安全性、可测试性和易用性。从设计师方面，系统质量属性一般存在三个问题：（1）为属性提供的定义并不是可操作的。（2）重点通常是一个特定的方面属于哪个质量属性。（3）每个属性团队都开发了其自己的词汇。
今天我们就根据《大型网站技术架构：核心原理与案例分析》将重点放在可用性和易用性的学习讨论上以及将其方法和实发项目结合起来，来增强我们实际系统的可用性和易用性。
先来了解一下可用性。可用性与系统故障及其相关后果有关。当系统不再提供其规范中所说明的服务时，就出现了系统故障。系统的用户（人或其他系统）可以观察到此类故障。系统可用性是系统正常运行的时间比例。一般将系统可用性定义为：α=平均正常工作时间/（平均正常工作时间+平均修复时间）。有两个著名的例子。2011年4月12日，亚马逊云计算服务EC2发生故障，其ESB服务不可用，故障持续了数天，最终还是有部分数据未能恢复。这一故障导致美国许多使用亚马逊服务的知名网站受到影响，并引发了人们对使用云计算安全性、可靠性的大规模讨论。2010年1月12日，百度被黑客攻击，其DNS域名被劫持，导致百度全站长达数小时不可访问。
网站不可用也被称为网站故障，业界通常用多少个9来衡量网站的可用性，对于大多数网站而言，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站的年度不可用时间小于53分钟，比如QQ就是4个9；5个9是极高可用性，网站年度不可用时间小于5分钟。可用性指标是网站架构设计的重要指标，是网站或者产品的整体考核指标。网站可用性是更加看得见摸得着的质量属性，所以在架构设计上，系统可用性的部分就需要花费更多的时间和精力了。而实现高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。所以就我们的《XXX系统》来说，不是只要完成系统的功能就等于完成了这个系统，根据系统的可用性，做好数据的备份和还原是最重要的保障之一。但是我们在设计和开发这个系统时，却把大部分精力放在了功能的实现上，这是一个很大的误区。在数据库的设计方面也是很重要的，加密存储、及时备份、保存日志都不失为是一个好的方法。保证数据的可持久存储，数据的可访问性，在数据有多份副本的情况下的一致性，都可以更好的维护我们的系统，提高我们系统的可用性。在服务器宕机时，进行失效转移可以保证数据访问不会失败，失效确认、访问转移、数据恢复都可以保证网站的数据不会丢失。对于我们的这个系统，为了保障高可用运行，我们还可以使用发布脚本来完成网站的更新发布，可以减少重启服务器和重新部署，而且不会影响用户使用。
我们都在使用微信，但是恐怕不清楚微信从发布到拥有一亿用户，仅仅用了一年时间。而且据说摇一摇功能是两个实习生用一个星期就开发完成的。那么他们是如何做到轻易地开发新产品，快速地实现一个新功能的呢？答案就是有赖于网站的扩展性架构设计，也就是指在对现有系统影响最小的情况下，系统功能可持续扩展及提升的能力。这样在系统增加新功能时，不需要对现有系统的结构和代码进行修改。也就是说我们的系统在开发时同样有一个目标就是开发低耦合系统，这是度量一个系统、一个开发框架的重要尺度。我们现在做的系统还比较小，可能不会有太大体会，但是对于一个大型网站来说，功能复杂，产品众多，更新也非常迅速。如果不分割模块管理的话，不久网站的维护就会变得很困难。所以我们的系统眼下需要做的一个修改就是功能的封装。将小功能封装在不同的类里，再进行调用，系统结构就会清晰的多。也不用担心功能的增加带来的影响。数据库的表结构也需要实现低耦合的关联。
现如今的网站，想要引人瞩目，在激烈的竞争市场上生存下来取决于谁能更快更好地推出新产品。也就是意味着我们需要一个更具有扩展性的网站架构实现一个效率更高、可用性更好的网站。这也就是网站架构的意义所在。