这周我们学习这两个方面的内容了。老师上课的时候讲到了可用性和可修改战术。可用性战术将会阻止错误发展为故障，或者至少能够把错误的影响限制在一定范围内，从而使系统恢复成为可能。可修改性战术的目标是控制实现、测试和部署变更的时间和成本。
然后提到了《大型网站技术架构：核心原理与案例分析》第五、六、七章，通过对这三章的扩展阅读，对可用性和易用性战术也有了一些自己的认识。对于自己之的程序也有了新的认识，当时觉得网站已经很好了，现在想想，很多实际的功能还有不完善的地方以及有很多的bug没有提示也没有解决方案。根据文章中的内容，我们需要从可用性，易用性，可扩展性方面着手。
首先我们了解一些可用性。可用性与系统故障及其相关后果有关。网站的页面功能完整呈现在最终用户面前，需要经过很多个环节，任何一个环节出了问题，都可能导致网站页面不可访问。要保证一个网站永远安全几乎是一件不可能完成的使命。网站不可用也被称作网站故障。当系统不再提供其规范中所说明的服务时，就出现了系统故障。系统的用户可以观察到此类故障。有两个著名的例子。书中有两个涉及到可用性崩溃的较为著名的例子，一是2010年1月12日，百度被黑客攻击，其DNS域名被劫持，导致百度全站长达数小时不可访问。2011年4月12日，亚马逊云计算服务EC2发生故障，其ESB服务不可用，故障持续了数天，最终还是有部分数据未能恢复。
对于实发性的项目，都有一个可用性的度量，也就是对于网的可用性的考核。对于一个系统来说，当然是可用性越高越好。可用性度量的通常用几个9来衡量，对于大多数网站而言，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站的年度不可用时间小于53分钟，比如QQ就是4个9，QQ服务99.99%可用，这意味着保证其服务的在所有运行时间中，不可用的时间小于0.01%，一年中的不可用时间少于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟。其计算方式为：网站不可用时间=故障修复时间点-故障发现时间点。网站年度可用性指标=（1-网站不可用时间/可用时间）*100%
可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标。从管理层面，可用性指标是网站架构或产品的整体考核指标。由于可用性影响因素很多，对于网站整体而言，要达到高可用性，需要有过硬的技术、大量的设备资金投入和工程师的责任心。举个最简单的实发性项目的例子，比如说，上学期我们做过的《XXX系统》。之前的时候，同学们都自己开发者这个网站，都以为网站的运行的已经没有问题了，我也是这样，实际上等到那天审查的时候，当别人来使用这个网页的时候就会发现还有很多的问题。因为别人操作的方式跟我们测试的时候不太一样，就会发生一些我们不曾发现的错误。好多同学的系统甚至会跳到500的网页。当出现崩溃的时候，没有解决方案，解决方法就是重新修改代码然后再调试程序。用可用性标准来衡量，程序的可用性就很低了。
可用性战术将会阻止错误发展为故障，或者至少能够把错误的影响限制在一定范围内，从而使系统恢复成为可能。可以通过错误检测，自动恢复，错误预防来维护可用性。在写程序时候一定要有try Catch的错误捕捉，这样才能检测到错误使网站不至于崩溃。
将系统分层、分割的主要目的是增加系统可维护性，以及对后期发展提供更好的功能扩展能力、并发处理能力。目前一般公司都会进行有效的划分，如利用流行的SSHweb框架开发，按功能划分不同模块开发。要将网站的功能进行分开编写。
易用性。易用性与用户完成期望任务的难易程度以及系统为用户提供的支持种类有关。说得通俗一点，易用性是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。拿我们自己开发的系统来说，易用性是做到了，因为功能实在是太少了，基本上没有什么复杂的功能。但是有一个重要的问题要注意，易用性要基于可用性的实现，就好比功能再简单的《XXX系统》，停留在不能使用的apache页面，也就不存在什么易用性之说了。说到这里，我想到了大家平常都有使用的软件QQ。大家更喜欢用TIM，这个聊天工具功能简单。就和大多数人玩微信一样。
对于扩展性，就是在对现有系统影响最小的情况下，系统可持续扩展和提升的能力。在系统做的比较大的时候，利用可扩展性，可以较快速地扩展系统的功能。
通过可用性和可修改性的战术的学习以及对五六七章的阅读。知道一个成功的网站所需要的努力和工作有很多。每个网站都要通过战术的保证来防止和减少BUG的产生。网站的性能也是评判的标准
来源：https://www.cnblogs.com/kangy123/p/8627145.html