评估你的微服务
稳定性和可靠性
开发周期
l 是否有一个可以存放所有代码的中心代码仓库？
l 开发人员所在的开发环境是否准确反映了产品状态（例如，是否准确反映了实际情况）？
l 是否有代码检查、单元测试、集成测试和端到端的测试？
l 是否有代码审查流程和策略？
l 是否具有自动化的测试、打包、构建和发布流程？
部署管道
l 微服务生态系统是否有一个标准化的部署管道？
l 部署管道里是否有full staging 或partial staging阶段？
l Staging环境对生产环境有怎样的访问权限？
l 部署管道里是否有canary阶段？
l Canary阶段是否有足够的时间来捕捉所有的缺陷？
l Canary阶段是否准确地模拟了生产环境的业务流量？
l Canary和生产环境的服务端口是一样的吗？
l 生产环境的部署是一步到位还是循序渐进的？
l 对于紧急情况，是否存在直接跳过staging和canary阶段的情况？
服务依赖
l 微服务的依赖项都有哪些？
l 微服务的客户端都有哪些？
l 微服务如何缓解依赖失效所带来的影响？
l 对于每个依赖项，是否都有备份、替代服务、回退方案或防御性缓存？
路由和服务发现
l 微服务的健康监测可靠吗？
l 健康检测是否准确地反映微服务的健康状态？
l 健康检测是否运行在独立的通道上？
l 是否使用了回路断路器来防止不健康的微服务发出请求？
l 是否使用了回路断路器来防止生产环境的业务流量被发送到不健康的主机或服务上？
服务和端点的解除
l 是否有解除微服务的相关流程？
l 是否有解除微服务API端点的相关流程？
伸缩性和高性能
增长规模
l 微服务的质的增长规模是怎样的？
l 微服务的量的增长规模是怎样的？
资源的有效利用
l 微服务是运行在专门的硬件上还是共享的硬件上？
l 是否使用了资源隔离技术？
资源感知
l 微服务的资源需求是怎样的（CPU、内存等）？
l 每个微服务实例能够处理多少流量？
l 每个微服务实例需要多少CPU？
l 每个微服务实例需要多少内存？
l 微服务还需要其他的资源吗？
l 微服务的资源瓶颈在哪里？
l 微服务是否需要被横向或纵向扩展，或者两者兼顾？
容量规划
l 容量规划是否基于调度进行?
l 新硬件多久能够到位？
l 申请硬件的频度是怎样的？
l 是否根据优先级为微服务分配硬件？
l 容量规划是自动化还是手工操作？
依赖项的伸缩
l 微服务的依赖项有哪些？
l 这些依赖项是否具备了伸缩性和高性能？
l 依赖项能否随着微服务进行伸缩？
l 依赖项的所有者是否做好随微服务进行伸缩的准备？
流量管理
l 是否很好地了解了微服务的流量模式？
l 是否根据流量模式来安排服务的变更？
l 流量模式的急剧变化（特别是流量爆发）是否被小心地处理了？
l 在服务失效后，流量是否能够被恰当地重新路由到其他数据中心？
任务处理
l 微服务所使用的编程语言是否具备伸缩性和高性能？
l 微服务在处理请求时是否存在伸缩性和性能方面的限制？
l 微服务在处理任务时是否存在伸缩性和性能方面的限制？
l 微服务团队的开发人员是否了解他们的服务是如何处理任务的，处理任务的效率是怎样的，以及当任务和请求数量增加时他们的服务将会如何应对？
可伸缩的数据存储
l 微服务是否以可伸缩和高性能的方式处理数据？
l 微服务需要存储什么类型的数据？
l 微服务的数据需要怎样的schema？
l 每秒需要处理多少事务？
l 微服务需要更高的读写性能吗？
l 微服务是读密集、写密集还是两者兼顾？
l 微服务的数据库可以横向或纵向扩展吗？它是可复制或者可分区的吗？
l 微服务使用的是专门的还是共享的数据库？
l 微服务是如何存储和处理测试数据的？
容错和灾备
避免故障点
l 是否存在单点故障？
l 是否存在多点故障？
l 故障点是否能够被移除，或者需要对它们进行缓解吗？
故障场景
l 是否所有可能的故障场景都已被识别出来？
l 有哪些横跨整个生态系统的常见故障？
l 硬件层有哪些故障会影响到这个微服务？
l 通信层和应用平台层有哪些故障会影响到这个微服务？
l 哪些依赖项故障会影响到这个微服务？
l 哪些内部故障会拖垮这个微服务？
弹性测试
l 这个微服务是否通过了适当的lint测试、单元测试、集成测试和端到端测试？
l 这个微服务是否经过合法的负载测试？
l 是否通过混沌测试对所有可能的故障场景进行了测试？
故障监测和修复
l 在组织里是否有标准化的事故处理流程？
l 这个微服务的故障是如何影响业务的？
l 是否对故障进行了清晰的分级？
l 是否有清晰的缓解策略？
l 当发生事故时，团队是否遵循了事故处理的5个步骤？
监控
关键性度量指标
l 这个微服务有哪些关键性的度量指标？
l 有哪些主机级别和基础设施级别的度量指标？
l 有哪些微服务级别的度量指标？
l 这些关键性度量指标都被监控起来了吗？
日志
l 这个微服务需要把哪些信息记录到日志里？
l 这个微服务是否记录了重要的请求消息？
l 日志是否准确反映了微服务在各个时间点的状态？
l 这个日志方案是否具有伸缩性和高性价比？
仪表盘
l 这个微服务是否有仪表盘？
l 仪表盘是否简单易懂？是否所有的关键性度量指标都展示在了仪表盘上？
l 是否能够从仪表盘上看出这个微服务是否运行正常？
告警
l 是否每个度量指标都设有告警？
l 是否所有告警都设置了合适的阀值？
l 告警阀值设置是否恰当。以便在发生中断之前触发告警？
l 告警是否具有可操作性？
l 运行手册里是否包含了用于诊断、缓解和解决问题的排查步骤？
轮班待命
l 是否有一个专门的轮班待命机制用于微服务的监控？
l 每次待命排班是否有至少两个开发人员参与？
l 这个待命流程是否在整个工程组织内进行了标准化？
文档化和理解
微服务文档
l 微服务的文档是否被集中存放在一个公开的、人们容易访问到的地方？
l 文档是否方便搜索？
l 微服务发生重要变更时，文档是否也得到相应的更新？
l 文档是否包含了微服务的描述？
l 文档是了否包含了架构图？
l 文档是否包含了待命信息？
l 文档是否包含了开发上手指南？
l 文档是否包含了微服务请求消息流、端点和依赖项的信息？
l 文档是否包含了运行手册？
l 文档是否包含了问答章节？
微服务理解
l 团队里的每个开发人员是否都能回答与他们的微服务的生产就绪相关的问题？
l 微服务是否遵循了一系列原则和标准？
l 对于新的微服务，是否有RFC流程？
l 已有的微服务是否经常得到评审和审计？
l 是否每个微服务团队都举行架构评审？
l 是否有生产就绪的审计流程？
l 是否有生产就绪路线图用于把微服务带向生产就绪的状态？
l 生产就绪标准是否推动了组织的OKR？
l 生产就绪流程是自动化的吗？
351
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
