总结工作中遇到的坑, 思考如何搭建完善的系统.

开发

设计

  • 明确对象: 系统面向用户是内还是外, 需要设计出周密的权限管控和用户友好性.
  • 分层和模块化: 抽象出可选的逻辑层, 以批量管理, 如组概念.
  • 可扩展性: 想象未来场景, 考虑可能冲突的点, 权衡业务逻辑设计的灵活和严谨, 抽象出可自定义的字段配置, 提高可扩展性.
  • 高可用性: 是否分布式, 以及熔断/降级/限流机制, 重试和超时机制.
  • 状态机制: 以目的状态替代状态流转, 会简单很多

开发和维护

  • 遵守规范:
    • 设计逻辑: 升级和维护时要遵守最初的设计规范, 并定期整理和重构, 切不可图一时方便而乱来.
    • 管理流程: 遵守严格review流程, 和开发测试上线流程.
    • 变更规范: 可监控可回滚可灰度.
  • 可干预: 前端操作或自动化任务, 要留出方便人为干预的入口.
  • 可批量: 可预见的大批量操作, 要设计出利于批量处理的方式. 或者留下升级入口.
  • 可检索: 数据库设计一定要留出时间戳/描述等与业务本身无关的字段以检索, 最好有核心操作日志.
  • 简洁: 代码和注释尽可能简洁但明了, 权衡复用模块和独立逻辑.
  • 文档: 及时更新行内注释, 文件头注释, readme说明等. 最好有同级docs目录.

运维

运维一定要有完善的文档, 和runbook/sop
标准的runbook应该:

  • 记录事件任务
  • 提供团队成员所需的信息
  • 确保内容最新无误
  • 每个流程都有独立的文件
  • 运行手册标准化IT任务，保持执行的一致性与效率

监控

采集方式:

  • 最好和系统本身自动联动, 自动更新, 但要解耦
  • 日志设计

采点指标:

  • APP本身指标
  • 调用方之间的指标

日常

需要凝练一些常用脚本, 简化日常重复操作.

常见痛点

工作中遇到的, 懒得喷

  • 不规范: 各自乱写, 百花齐放, 美观和可维护性都极差.
    • print洪流, 异常pass, 变量滥用, 注释/commit瞎写, 巨长函数, 胡乱命名, 甚至false=true
  • 不自动: 很多功能依赖手动修改, 不能自动联动.
  • 不解耦: 功能之间硬编码, 升级/变动牵一发动全身.
  • 低性能: 接口不异步, 调用方式守旧命令.
  • 不统一: 接口配置不抽离出来统一管理.