对于一个系统而言，常有的组成部分有，服务器、基础服务、业务逻辑和第三方服务。而我们要保障整个系统的质量，就需要在这几个方面着手。
在系统构建初期，也就是需求阶段，除了理解需求之外，还需要知道系统的受众是谁，将来大概会有多大的流量，根据估算的数值，采取相应的措施：
- 服务器分布式部署，根据流量大小选择几台服务器
- 根据业务实际情况选择基础服务
- 是否需要缓存方案，以及方案的选择
- 数据库的选择和设计，是否需要分库分表
由于以上措施均针对系统流量，故系统的流量、性能监控，对我们而言也是非常重要。在服务器和基础服务层面，我们可以如下做：（以PHP + Nginx + Redis + Mongo 为例）
- 机器硬件指标监控及报警。监控机器CPU、内存、硬盘的使用率
- 基础服务的监控与报警。监控PHP、Nginx的错误日志和慢查询日志；监控Redis、Mongo服务器的使用情况
- 定时清理系统日志，保持硬盘空间可用
- 创建Mongo表的查询索引
在业务层面，最主要的是保障业务逻辑正常。在这期间通过设计测试方案、多轮线下测试、自动化回归测试、小流量测试以及灰度发布的方式来减少我们系统的问题。
- 一个好的测试方案可以帮助我们发现80%的问题。测试方案中至少包括测试方法、测试策略以及测试用例
- 线下测试可以是代码的单元测试、接口的测试、系统的整体测试。对后端而言，接口测试就可以发现大部分的问题，而前端除了接口联调外，mock测试可以发现大部分APP的crash和ANR
- 自动化测试在成熟稳定的系统中作用较大。接口的全自动化应该是可以达到90%的代码覆盖率的。它可以在系统更新时，自动检测之前的功能是否受影响。多用于预发布环境
- 小流量和灰度发布是在用线上的真实流量来测试我们的系统功能，只让一小部分人可以看到新功能，即使有问题，影响面也不会太大
当然我们有了上面的一些措施，仍然不可避免线上出现问题，所以我们需要业务监控。
- 系统级错误监控
- 业务异常逻辑监控
- 接口超时监控
- 主要业务指标监控
- 系统只要接口流量监控
在系统中往往存在一些第三方服务，在测试时，碰到第三方服务不可用时，可以使用mock server代替。第三方服务一般不需要我们测试，但是我们仍需要关注调用时的处理
- 查询服务的超时处理
- 订单类服务的订单唯一性
上面的措施会将问题暴露出来，这时候就需要快速定位问题，来有效止损
- 构建日志规范化标准
- 日志统一管理
- 构建日志一键查询平台