2 个月内如何在千人团队落地压测平台？

昨天下午看到一篇技术文章，讲到了从零开始落地项目的经验。正好我也有过类似的实践，临时写了这篇文章，如标题所述：3 个人，如何在 2 个月内在千人团队推广并落地压测平台。

项目背景

大概是 21 年底，我刚入职某互联网企业的基础架构团队，负责质量保障方面的工作。

12 月底，技术总监立项决定开发一套供公司其他业务线使用的全链路压测平台，而且项目周期比较短，只有 2 个月时间。

当时由于我所在的基础架构团队同时开展了多个项目，技术资源少的可怜，最终整个全链路压测平台，只有一个后端开发，一个前端开发，还有一个半吊子的产品经理 &项目经理 &测试，就是我。当时面临的其他的问题还有：

• 没有 PRD，没有一行代码，甚至技术方案调研都没来得及做；

• 2 个研发同学在北京，我 base 上海，业务线同学甚至在海外，协作和沟通成本巨大；

有过项目开发经验的同学都知道，3 个人，2 个月，完成一个千人级别的平台开发，并且要落地让用户使用起来，是很扯的一件事。但职场嘛，没有很扯淡，只有很操蛋，硬着头皮上呗，行动起来总比原地等死好得多。

项目过程

前期准备

由于整个项目只有我们三个人，2 个开发同学又没有太多项目管理和产品设计经验，因此项目管理和产品设计的活儿，我就自告奋勇的揽下来了，虽然挑战很大，但对自己来说，也是个很好的锻炼和成长机会。

负责项目管理后，我主要做了如下几件事：

1、用户需求调研

因为平台后续的使用者主要是各业务线的技术同学，因此需求调研是一定要做的，在需求调研时，我主要关注如下几点：

• 当前的工作痛点（最核心最紧迫的问题是什么，便于排列需求优先级）；

• 对平台的功能诉求（用户想要什么功能，背后的出发点是什么，平台能否提供很好的解决方案）；

• 是否愿意参与项目的试用（这点对项目的前期落地和运营推广很重要，有种子用户，有意愿帮助推广项目）；

2、技术方案设计

• 时间很紧，资源不足，因此采用了更高效的前后端分离模式；

• 为了满足快速迭代，环境部署采用了容器化的方式，降低配置和部署运维成本；

3、项目迭代规则

人少不可能憋大招，只能采用快速迭代 mvp 方案的做法，因此定下了如下几个项目迭代规则：

• 一周一迭代，每次只交付最核心的 2-3 个功能；

• 周二下午提测，周四下午发布/晚上评审排期下版本需求，周五下午过产品原型图 &PRD/技术方案/测试 case；

• 每个版本发布，在内部用户群同步信息，重点说明新功能特性，解决了什么问题，以及对用户反馈的内容进行答疑；

4、沟通协作机制

• 每天上午站会同步进度；

• 每天下午项目经理负责同步任务进度和风险提醒；

• 建立轮值技术客服，由团队 3 个成员轮流解决用户使用平台遇到的问题；

• 建立紧急问题 oncall 机制，线上问题录入协作文档，问题排优先级，设定 fix 的 deadline 并添加提醒；

研发阶段

花了一周时间搞定前期准备后，专门组织了一个会议，拉上技术总监，项目几位同学以及业务线的积极种子用户后，做了一个进度汇报和方案同步。这样做的好处有如下几点：

• 同步信息，暴露风险，收集反馈（需要提前准备好原型图 demo，PRO 文档，技术方案文档，项目整体规划）；

• 体现能力，说明规划，申请资源（体现短期的解决问题能力，说明规划和进度安排可以给上级和用户一定的预期，如果超过上级对项目的预期，也许可以获得一定的资源倾斜）；

PS：会开到一半，CTO 被半路拉进来了，快速做了一个汇报后，CTO 比较认可，拉了其他几个业务线技术 VP 进来，直说让业务线配合，提需求提建议（当时的场景让我有点压力山大，但长期来说，出现了我意料之外的好的结果）。

信息同步之后，就进入了研发阶段。其实研发测试运维阶段，都是大家熟悉的套路，没什么特别的点。但整个研发过程也踩了不少坑，下面是我的一些踩坑总结：

• 尽量利用公司或团队现成的技术栈或者技术组件，不要造轮子；

• 比如环境部署容器化，我们有专门负责容器化的团队，只需要申请资源即可；

• 比如构建部署流水线，我们有专门的效能团队负责 CICD 流水线的建设，直接接入即可；

• 及时的沟通和信息同步特别重要，并不是所有人都有高度的自驱能力去遵守规则；

• 谁的问题谁跟进谁解决，并且是该问题的第一责任人（团队其他人有责任和义务去提醒和驱动）；

• 对于时间紧资源不足的项目，快速交付可见可用的核心功能，比憋大招更能获得领导和团队认可；

上线运营

项目立项之初，领导对平台的定位是全链路压测平台，但限于资源不足的现状，我在项目规划中将项目分为了 2 个阶段：

1. V1.0-压测平台：提供基础和通用的压测能力，比如项目管理，任务管理和调度，脚本和数据管理，数据切割和文件自动下发，压测过程可视化，并发数动态可配置，压测过程日志采集展示，支持多工具和分布式压测等。这样做的好处在于：

2. 先提供基础通用的能力，解决最核心的痛点，获得用户和领导认可（有了成绩才能谈资源倾斜）；

3. V1.0 后期需求没那么紧迫，研发资源可以空出一部分做 V2.0 的调研和开发工作（给项目留出冗余空间）；

4. V2.0 全链路压测平台：提供线上全链路压测的整体解决方案和能力，主要包括如下几点：

5. 流量染色（比较成熟的请求头带标方式）；

6. 流量透传（由于多业务线多技术栈，采用 OpenTracing 的方法，提供 SDK 接入，低侵入，低成本改造）；

7. 数据隔离（基础架构 DBA 团队提供了统一的 DAL 组件，也在推业务接入，沟通后合作推广，效果更好）；

8. 过载保护（通过限流熔断降级和隔离等措施来识别和解决这个问题，正好基于 nacos 和 sentinel 二次开发的服务治理平台也是我负责质量保障工作，内部沟通后合作一起进行改造和推广）；

9. 日志定位（压测会产生大量日志，需要单独存储，也需要通过日志排查问题，接入运维团队提供的 ELK 即可）；

回到正题，项目上线后，如果不能很好的在业务团队落地，那项目是没有任何价值的。

关于项目运营，我总结下面几条经验；

1. 快速迭代很有必要，要不断满足用户的诉求，还要给它们一定的预期；

2. 每次发布后在内部用户使用群同步发布信息和更新的功能，重点说明新功能特性，解决了什么问题；

3. 做好用户服务很重要，比如帮业务团队协助排查解决性能问题并提供优化方案，比如协助进行方案评审；

4. 项目文档建设特别重要（很多技术同学忽略了），文档除了指引用户使用，更多的也是项目资产和产出的一部分；

5. 定时的平台功能演示，技术案例分享很有必要，这样可以拉近和用户的距离，听到更真实的一线用户的使用反馈；

关于文档建设，我当时主要做了这几项工作：

1. 提供平台使用说明手册和发布日志文档（树状鱼骨线），让用户直观感受到平台功能在不断丰富；

2. 内部协同工具签名改成使用手册，发布文档链接及个人联系方式，便于用户遇到紧急问题可以及时支持；

3. 提供常见平台使用问题解决手册和性能优化案例库，让用户认可项目团队的专业技术能力和职业的用心程度；

4. 产品/平台的短期和长期规划以及落地方案，只读模式开放出来，在内部的交流平台 share，吸引更多人参与了解；

经验总结

1. 解决问题除了硬技能，软实力也很重要（产品设计/项目管理/协调沟通）；

2. 遇到问题和挑战，尝试去分析解决问题，而不是逃避问题，才能获得长足的成长；

3. 适当的给领导画大饼是很重要的，但一定要学会暴露风险，提出诉求，表明如此做的产出和价值；

4. 工作中避免造轮子，利用现有或成熟的组件解决问题，比蒙头憋大招更有利于个人职场生存和发展；

5. 沟通中难免遇到大大小小的问题，寻求共同的利益点，抓大放小才能做好项目管理和落地运营工作；

其实整个项目的 V1.0 阶段，我们只用了 6 周时间就完成了交付落地，并且覆盖了五个业务线，将近 300 名技术同学使用了平台。2 个月期满时候，我统计了数据，压测任务执行超过了 2w 次，可以说最终的结果超过我的预期了。

最后这个项目也从 A 级项目上升到了 S 级项目，有了更多的资源倾斜。