定位

  • 技术为业务服务，

稳定性

  • 设计
  • 开发测试流程
  • 故障角度
    • 预防演练，故障注入
    • 提早发现
    • 辅助定位
    • 快速恢复
  • 方法论和工具

效率

  • docker化
  • 中间件
  • 流程优化

稳定性和效率其实是双赢的关系，而不是稳定性如何双赢

上线流程

  • 上线流程规范：明确且落地到wiki
  • 上线checklist：明确可执行的检查项，必须包含预览机验证环节及灰度发布环节。落地到wiki或沉淀到共享文档
  • （可选）预览机验证环节&灰度发布环节实践：有落地沉淀并可以广泛推广借鉴的灰度发布实践，形成带实例的推广材料
  • （可选）工具创新及应用：工具的引入或创新，应用指南说明及实践沉淀的分享材料。

Coderivew实践

  • 有代码owner机制规范，落地到wiki
  • 采用了工具进行Codereview
  • 核心代码均采取了强制Codereview策略
  • 代码库、代码owner、CR单数据接入星辰平台统计大盘

持续集成

  • 接入静态代码扫描，有扫描结果报告
  • 接入自动构建和打包(接入Jenkins和SCMPF）
  • 自动化测试用例覆盖率达到50%以上，相应的测试报告、测试cas、及自动化测试实例代码，落地到文档或者wiki
  • （可选）自动化测试的实践分享材料

稳定性承诺

  • 具有明确的sla定义及可度量公式
  • 落地到星辰平台且所有核心链路上的调用方均签署完毕

架构设计

  • 有架构评审机制及流程规范，落地到wiki
  • 有明确的架构评审checklist检查项列表
  • 架构评审的结果有文档沉淀或者落地到wiki
  • （可选）有落地沉淀并可以分享的优秀架构设计实践实例材料

容量预估

  • 压测方案，执行结果及改进方案落地沉淀到wiki或共享文档
  • 明确给出容量核心指标：QPS、并发量、平均响应时间、机器规模
  • 有明确的容量预估方案并落地到wiki平台，其中必须包含“预估总访问量、预估平均QPS、预估峰值QPS，单机极限QPS”
  • 并包含明确的容量预估公示，和3个月内的峰值实际容量与系统压测数据
  • （可选）有容量预估系统，容量预警告警建设及机制

服务化实践

  • 服务标准化相关设计方案，实践效果沉淀落地到wiki或共享文档
    • 分层设计&服务拆分
    • 数据库拆分
    • 缓存拆分
  • API收敛
    • 数据流和特征收敛
  • 服务全部/核心接口文档
  • 服务发现接入：php版本服务发现接入、golang版本服务发现接入
    • 其他详细方案及实践【请提供监控指标清单及监控系统链接，wiki页面链接】

监控建设

  • 监控标准化Metrics已接入；
    • 具备监控大盘：含系统层面、DB层面、业务层面。明确提供监控指标及监控系统链接；
    • 核心指标配置了告警策略，有明确的告警后处理流程规范，落地到wiki。

降级实施

  • 有降级预案且预案已上线
    • 上线前预演生效，预演方案及结果沉淀到wiki
    • 有快速降级能力及技术策略并落地到wiki +（可选）有创新工具及可推广的分享技术实践建设

容灾设计和冗余

  • 单元化，双活是它的第二个阶段，多活是第三个阶段

  • 重大的机房或网络坏损灾难的容灾方案，落地到wiki，或共享文档

    • 部分容灾预案是可以进行定期预演的
    • 有定期预演的结果报告

  • 单元化实施完成，方案需要落地到wiki上