研发团队全景方法论 TechOrg Blueprint

工程 Engineering

前端 Frontend

  • 组件库: 关键组件自行封装 (从组件库fork抽出),
  • 样式: 预处理器, 管理 Styling: Preprocessor, css-in-js, SASS, LESS
  • 状态管理 State management
  • 数据流 Data flow
  • 脚手架 Mocking, testing, proxy, transpilation
  • 代码规约 ESLint, 加在pre-push hook

后端 Backend

  • Authentication, authorization, token/session management
  • API design: response format, url convention
  • API management: - rate limiting, logging, filtering
  • 代码规约 阿里IDE插件/checkstyle

数据库 Database

  • Schema migration, 用简单直接的change script方式. Schema改动按序号, 合到某分支即为应用到某环境. 一段时间之后将一批Schema改动压缩合并. 每个Schema改动immutable

运维 DevOps

DevOps极为关键. DevOps is a key component to a productive RnD team.

  • Kubernetes集群, 采用Rancher管理, 包括, 滚动式发布, 回滚, 扩缩容, 秘密管理等. 每个环境一个命名空间. Ingress来对外暴露服务

  • 分支模型 / 部署流水线, 每个环境对应相对的分支, 合并到X分支即用钩子发布到X环境. 同时不同环境的不同配置也在代码仓库提现, 除了秘密直接写在集群除外. 构建jenkins根据钩子开始特定环境的构建, 依赖包也根据环境后缀采用对应环境的版本. 构建完毕后推送镜像, 并在对应环境集群命名空间设定镜像. Branching / Deploy pipeline

  • 发布管理 / 版本管理, 合并到master分支, 即合并stage环境. stage环境高度拟真生产环境. 生产环境镜像只能来源于stage提升. 每次发布, 对master分支打tag. Release management

  • 监控, 包括容器监控 (进程, 资源, liveness/health), 集群机器监控, Java进程监控, 业务接口监控, 区块链块高监控, 区块链地址余额监控

  • 数据库, 中间件, 机器, 域名DNS, 邮件短信等管理在云服务上

  • 运维几个基本原则: 自动化 - 运维不是操作员, 工具化 - 引入工具审慎一旦引入妥善使用, 代码化 - 所有脚本配置进repo, 安全与权限

安全 Security

测试 QA

  • 接口自动化测试
  • 回归测试流程

量化 Quant

  • 做市
  • 做量 (K线, 盘口, 盘口大小要和最小diff比对)
  • 监控

流程 Procedures

  1. 一把手决策并负责. One ultimate decision maker with >50% voting right.

  2. 每日站会, DONE, WIP, TODO. 每周周报, 同样内容形式, 按bullet points整理发布. Daily Standup, report DONE, WIP, TODO in round-robin. Weekly, same content in bullet-point format, compiled and sent on last day of the week.

  3. 每周一11点需求评审会. 每周四完成验收回归测试, 周五早进行发布. 每月allhands全体会. Weekly requirement review meeting on Monday 11am.

  4. 任务状态: 待确认 - 待开发 - 开发中 - 待测试 - 已完成; 已关闭. 任务的创建和更新要有提醒机制, Teambition的桌面提示或是发送到钉钉频道. Task FSM: ToConfirm - ToDev - WIP - ToTest - DONE; CLOSED.

  5. 整体开发流程描述:

    • 产品产出需求, 通常周五, 最晚周一准备好. 产品创建粗粒度需求并放入待确认流水线. 确认清晰后移入待开发, 分配给tech lead.
    • tech lead分配到部门leader, 部门leader到开发, 开发移到开发中.
    • 从develop分支按任务号拉出feature分支, 同一个需求在不同仓库用同一个名字. 数个需求有依赖关系的可以用同一个分支.
    • 测试联调需要的, 从feature分支合并到环境分支来自动部署, 如dev1 dev2 test1 test2. 在环境中测试无误后通常是合适时机开所有相关PR, 从feature分支到develop.
    • Reviewer理清依赖并都合并到develop, 进一步提升到master, 此时自动部署stage预发布环境. 所有变更进stage后跑自动化用例以及回归流程. 完成后最终打tag, 并直接从stage镜像提升到prod. 发布完成.
    • 每一个发环境, 合PR, 提升镜像的操作都伴随相应表结构, 跑脚本和配置的改动. 这部分在单独release repo管理, 如 test1 - 101-add-country-col-to-users-table.sql prod - 100-fill-new-col-clientid.sql, 记录每个环境的情况.
    • 后续tech lead和部门leader根据需要再拆分需求, 分配到下一级 (如果不跨sprint, 倾向于尽量不拆过细, 一个大需求一个人, 自行管理).
    • 遇到线上bug的, master分出hotfix分支, 合并回master, 在stage环境校验, 打tag提升到prod, 并合并回develop.
    • 过程中有其他紧急需求的, 随时沟通随时排期, 走以上需求流程精简版.
    • 根据实际经验, 未引入flyway等, 因为环境状态包含队列缓存数据库结构和数据配置秘密乃至落盘快照hadoopHDFS等, 单个工具无法全部管理.

团队 Team

招聘 Recruitment

  1. 两级技术架构中, 优先招聘各个部门的leader: 大前端, 后端, 数据, 运维, 测试. 之后招聘面试工作可以更专业工作量向下分布. 吸引到这些leader需要很多时间精力去吸引, 还需要一些运气. 当缺乏相关专业知识判断某个候选人的时候, 1. 请其他人支援 2. 更多信任背景和工作经历, 对于在前公司的项目经历和工作成果要仔细推敲. 如果一上来不能填补这些空缺, 可以先招基层过渡.

  2. 招聘: 采用笔试, 笔试中有详尽的测试用例. 全部跑通用例通过. 然后看代码, 代码讲道理负责任, 做面试. 面试中技术考察之外, 也注重人的反应速度, 学习能力, 沟通能力, 解决问题能力. 宁缺毋滥, 不要让自己后悔 - 感受这个人的性格为人, 问自己是不是想和这个人共事, 这个人是不是符合团队的氛围和气味 (阿里将之称为阿里味).

  3. 不否认很多时候要对招聘质量和速度进行取舍. 有的时候种种因素之下, 需要作出一两个降低标准的招聘. 此时需要思考好后续步骤, 是作为基层人员, 还是有计划有考核地汰换.

  4. 实际中, 一个工程师的实际工作方式以及和团队的融合, 在面试中顶多体现四成. 在入职后的前一两周中, 才能对一个人有准确的判断. 此时如果决定不合适, 长痛不如短痛. 应当与这个员工及早谈话明确, 如果不能有改善则要离开, 给予对方铺垫, 改进的机会, 和心理缓冲. 另外, 大多数商业环境中不能支持普遍的试岗 (如前两星期), 但这不失为一个值得尝试的制度, 有成功的先例.

  5. 整体工程能力和职业素养胜于具体技能.

  6. Direct report倾向于每月1-on-1沟通想法和绩效分数.

薪酬, 职级, 绩效 Compensation, Progression & Performance

  1. 从经验看, 秘薪制是最不坏的一种选择. From experience, it’s wise to keep compensation strictly confidential. It’s hard but let’s do as much as possible.

  2. 绩效评价频率有月度, 季度, 半年度三个选项.

  3. 沿用阿里职级序列, 名称与代码如下. 增加正式的+级别, 增加晋升频率和体感.

    • P4/P4+ 初级工程师
    • P5/P5+ 工程师
    • P6/P6+ 资深工程师
    • P7/P7+ 专家
    • P8/P8+ 资深专家
    • P9/P9+ 总监
    • P10/P10+ 资深总监

技术团队影响力与建设

影响力是行业常用的提法, 可用于tech lead个人或团队

  1. 影响力直接作用于招聘, 效果显著. 一个有博客, 有过硬开源项目, 有会议演讲分享的技术团队, 对技术人员的吸引力是巨大的. 参考阿里数据流形团队: https://zhuanlan.zhihu.com/FrontendPerusal https://zhuanlan.zhihu.com/purerender https://github.com/dt-fe/weekly https://github.com/recharts/recharts https://news.ycombinator.com/item?id=12277389 https://github.com/nefe/Hiring

  2. 建设影响力的过程中采取的常见方式: 开源项目, 写博客专栏, 出版书籍, 在外部会议演讲分享, 在内部组织学习技术分享, 申请专利. 这些方式对团队现有成员也有很好的学习提升, 提振士气作用.

  3. 业务需求与技术影响力建设在时间上是一对矛盾. 谷歌的做法是20%, 阿里的做法是业务项目必须满足, 技术项目决定更高绩效和晋升.

Culture & Conventions 文化与规范

Culture 文化

  1. 开发为创造价值. We don’t develop for sheer pleasure. We develop to create value.

  2. 名称极为重要. It’s very important to get names and terms right - especially for RnD purposes. A clear reference to matter & concepts lays the foundation of all communication.

  3. 文化规约很重要 - 提效, 推进, 减少错误. 每件事有法可依, 减少决策精力损耗. It’s important to have conventions & standardizations. Vastly accelerates all activities and reduce errors. Let’s have them even for small things like writing, commit message, emails.

  4. 什么时候做自动化? 当节约的手动时间数倍于开发所需时间时. 同时要考虑到自动化牺牲的灵活性. Automation is good. Let’s have it as much as possible, without losing flexibility and knowledge.

  5. 用轻量级通知广播信息, 让知识共享, 让每个人同步, 保持每个人的参与感与活力. 口头与面对面交流也能高效达到同一结果. Lightweight FYI notifications are good. They keep everyone on the same page, and they keep everyone active and outspoken. Verbal and face-to-face communications are also good.

  6. 好的文档和SOP应当: 简洁, 只记录主干信息和决定; 不容易过时, 不需要巨大成本维护; 有用, 有查阅价值. 典型例子如新人入境文档. 典型的好的保存方式是把和某个仓库相关的文档以Markdown格式提交到该仓库中.

  7. 提交一切有用信息到仓库 - 包括脚本, 文档, 生成的批量mock数据, 常用的本地配置, 测试尝试代码 (进unittest). secret和会产生冲突的除外. Everything, with almost no exception (perhaps secrets and ), should be in the codebase so that they are persisted and version-controled.

  8. 遇到问题30分钟不能解决再求助. As a capable and proud engineer, solve the problem as much as possible and only ask for help when you can’t solve after 30mins of grepping.

  9. 单点简化. 一个工具, 一个平台, 一个沟通渠道. 要搜要查的位置就减少. Less places to look for info. Less modes of communication. Less number of tools that serve the same purpose. Single point of truth.

  10. 引入任何工具会产生运维管理成本. 要么不引入用最简单直接清晰的方式管理 (procedure + md文本), 要么用好用充分每个引入的工具 (例: gitlab钩子, 钉钉通知从开会到线上告警, 钉钉考勤HR流程报销, jenkins各式任务, kibana日志维度等).

规范 Conventions

  1. We refer to the method of text-based searching, code searching, googling, chat history searching as a whole as grep grepping.

  2. Use correct casing. When starting a sentence, prefer capitalize.

  3. Simple English. Comfortable and clear meaning. Use America spelling because it’s shorter.

  4. 巨量的重复的容量加入仓库会造成搜索困难和效率下降. 只有强原因才允许加入大量外部文本进入代码仓库. Text search is a great tool for engineers, and info flooding is its biggest enemy. Do not add enormous amount of code/text/info without strong justification.

  5. 开PR, 早开, 多开, 开小PR. 同一个分支的PR会自动更新, 不需要合的时候标WIP. Incremental improvement - 几十个文件几千行的PR说code review就是形式

  6. 不回避外包. 两个时间节点是适合外包介入的时期: 早早期人员未到位 (交易所) or 业务大发展时期大量重复业务开发 (阿里云). 阿里至今采用大量外包

Written on October 26, 2019