最近整理应用可靠性保障评估建议，吸取之前做微服务的一些经验，同时也参考了许多书籍，大致整理了一些细则。分别从可靠性、高性能、伸缩性、容错和灾备、监控以及文档化的角度来评估应用是否具有高可靠保障。大致整理如下，有需要的同学，可以参考！
可靠性
- 有遵照标准化的部署流程，包括功能测试阶段、UAT测试阶段再到生产上线
- 有遵照应用分类做高可用性部署
- 两地三中心（同城多活）部署
- 数据中心内部应用高可用部署（接入层、应用层、持久化层）
- 可靠的依赖关系管理，避免依赖项失效
- 有清晰的服务间或外部服务依赖列表；
- 每个依赖项，是否都有备份、回退方案或防御性缓存；
- 有微服务（或模块）接口变更列表；
- 有稳定可靠的路由和服务发现机制
- 服务配置了健康检查和探活机制；
- 服务的健康检查结果真实可靠；
- 服务失效后，路由能够准确切换流量；
- 有使用断路器来应对反复出现异常的实例；
- 有服务分级与降级设计
- 明确的服务（模块）分级，明确的降级条件
- 有服务（模块）的、前端页面的降级控制开关，预先定义的降级逻辑
- 预定义大规模流量压力时的降级控制流程
- 有流量控制设计
- 合适的限流算法（固定窗口、漏桶、令牌）
- 流控策略（API网关、服务入口、中间件服务）
高性能
- 应用在发布前已通过压力测试
- 已识别出单个微服务实例（单体应用）资源需求与吞吐量的平衡点
- 平衡点上的资源需求
CPU
内存
外部资源（数据库连接数、文件描述符限制、日志配额等） - 平衡点上的吞吐量（QPS）
- 平衡点上的资源需求
- 高效率的服务间通信
- 协议（报文封装效率）
- 路径
- 方式（阻塞、非租塞）
- 合理使用中间件，提升读写效率
- MQ
- Cache
- 数据库网关
伸缩性
- 使用专门的硬件，或支持资源隔离
- 微服务配置了严格的CPU、内存限制
- 单体应用使用专门的VM或者物理机
- 已预估流量增长规模
- <质>总请求用户数量级，业务流量预测
- <量>具体的QPS、RPS数
- 服务可伸缩
- 清晰的流量拓扑
- 服务失效后，流量是否能够路由到其他IDC
- 依赖项可伸缩
- 清晰的依赖项列表
- 依赖项是否可伸缩或已预留足够资源
- 数据存储可伸缩
- 数据库HA（主备切换）方案
- 数据分库
- 数据分片（分表）
容错与灾备
- 清晰的各层级故障域隔离策略
- 线程
- 进程
- 集群
- 用户
- 识别潜在故障场景，并做好故障应对方案
- 基础设施故障
- 网络故障
- 平台层故障（中间件、日志、监控、负载均衡等）
- 服务内部故障
- 服务依赖项故障（SLA不达标等）
- 识别并消除单点故障问题
- 提供软件和部署架构图，确定是否存在单点故障
- 故障点是否能被移除，或者对它们进行缓解
- 故障演练，通过所有计划测试流程和探索式测试
- 单元测试
- 集成测试
- 端到端测试
- 压力测试
- 探索式测试
- 有实施故障探测和制定对应补救策略
- 回滚（部署引起）
- 备份（依赖项失效）
- 监控告警（探测预警）
- 服务都配置了故障恢复策略
- 遵照故障的事件响应机制
监控
- 确定关键性度量指标，以及是否已被监控
- 服务级别指标
- 基础设施级别指标
- 平台级别指标
- 中间件级别指标
- 适当的日志
- 日志等级合理
- 明确定义微服务日志配额，日志保存时间
- 可参考的调用链指标，以及调用链监控
- 易理解的仪表盘
- 已包含关键性度量指标
- 能准确反映服务健康状况
- 有效可操作的告警
- 每个度量指标都设置了告警
- 告警分级设置合理的阀值：正常、警告、严重
- 告警应该可操作（若T1团队无法立即对告警采取行动，就不设告警）
- 有告警处理的文档（包含常见问题的缓解、排查流程）
- 开发人员轮班待命
文档化
- 最新的、集中式的文档
- 服务描述文档
- 服务对外API接口列表
- 服务软件、部署架构图，架构评审记录
- 服务处理的数据流程图
- 服务依赖项，依赖项监控仪表盘链接
- 监控关键指标，仪表盘链接，告警阀值设置信息
- 服务T2开发人员排班信息，联系方式
- 服务常见问题，以及其诊断、缓解和解决方法