如何做一款面向企业客户的商用级 SDK https://mp.weixin.qq.com/s/DcDZad4UP4VUSWRnfVy9MQ
如何做一款面向企业客户的商用级 SDK
作者：rexchang，腾讯 CSIG 客户端开发工程师
导读
我在 2008 年进入公司后，做的一直是面向 C 端用户的客户端产品—QQ，产品的可测性是很强的，虽然功能很多，但我们测试团队总是能成为产品质量的坚强后盾。2016 年我们团队加入腾讯云之后，依然在客户端方向，但所做的产品已经不再是一款软件，而是一套音视频通信领域的 PaaS SDK，即 TRTC SDK 和 IM SDK。
相比于 QQ 只需要做好一款 App，我们要面对的是服务好几千个客户的 App，而于此同时，测试资源又是有限的。在这种情况下，如何确保产品质量呢？
从一个小故事开始讲起
在几年前我们刚开始做 ToB 的 SDK 的时候，曾经对接过一家做社交 App 的公司，对方的技术负责人很年轻也很务实。在商务大哥给力的努力下，客户成功完成了产品的接入，并进入线上灰度阶段。
然而，在开始灰度的那天晚上，线上用户出现了很多消息延迟大的投诉，用户的一条消息需要很长时间才能发出去。客户虽然对我们很失望，但依然很努力地在配合我们排查和修复问题。
在两天的时间里，我们给客户改进了多个版本，每次给版本的时候我们都说“已经找到问题了，这个版本肯定可以”，但每次效果都不理想。两天之后，客户的技术负责人很严肃地询问了我们一个问题：“从这两天的排障过程和修复过程来看，我想确认一下你们这是一款商用级的产品吗？”
在那个晚上，我们开始冷静地思考一个问题：一款优秀的商用级 SDK 应该怎么做？
一年的努力功亏一篑
最近教育行业被政策打压地非常厉害，但在两年前，这是个 PaaS 服务的兵家必争之地。我们有一家做在线英语教学的客户，一直在对接我们的 TRTC。这个客户对质量要求非常苛刻，他们很早便引入了赛马机制，将多家 PaaS 服务商拉入到自己的供应商集群，互为灾备，并进行质量评估，看谁的质量好就用谁的产品。
在最开始对接的时候，我们的产品质量还不是很优秀，几个关键指标跟竞品都有差距。这倒不是问题，优化总要有一个过程，于是我们一个迭代一个迭代地去跟进。因为客户的版本发布速度非常慢，所以我们需要在两个版本之间都做好问题分析和优化落地，稳抓稳打地慢慢降低工单率。就这样，经过了将近一年的时间，产品各项指标都已经很不错了，我们非常有信心在下一个版本超过友商获得质量上的领先地位。
但就在我们信心满满地等待客户上线的灰度反馈时，客户突然抛出一个问题：“你们的 SDK 有一个对音频模块的自动重启逻辑，这个逻辑会在切换线路时影响到其他供应商的音频模块， 这是绝对不能容忍的”。因为引入多家供应商赛马的意义就在于保证可以有灾备，如果一家供应商影响了其他供应商的稳定性，这个灾备便没有了意义，因此客户对我们异常失望，放量计划无限期搁置。
面对一年的努力功亏一篑，我们开始接受一个现实：每位同事都可能会因为手滑引入缺陷，但对团队而言代价却是难以承受的，怎么办？
回到正题，接下来我会介绍一下过去的这些日子里，我们怎么去应对这个问题。不过在此之前，我需要先介绍一下我们的产品：
我们是做什么的？
我们团队所开发的是一套面向企业级客户的 SDK，包括用于实时音视频通讯的 TRTC SDK；用于消息通信的 IM SDK；用于直播推流和播放的 LIVE SDK ；以及用于短视频录制和编辑的 UGC SDK。
产品面向的客户群很多：有做泛互联网行业的，比如在社交领域长期霸榜苹果应用商店的某知名 App；也有在线教育领域的很多知名机构，教学模式包括 1V1、小班课、大班课等等；也有金融和保险领域的巨无霸，他们会使用我们的产品将现有的业务尽快地跟互联网融合；还有各行各业的中小型企业，他们虽然可能并不出名，但确实支撑我们国家互联网经济持续繁荣的基石；对了，还有做毕业设计的学生，虽然他们不会付费，但保不齐人家会在毕业后给自己的老板推荐我们的产品呢。
面对这么多行业领域的客户，有喜有忧，喜的是这是一桩很好的生意，忧的是这里有着车载斗量的压力：因为 SDK 这种形态的技术产品，如果要面向企业客户去服务，那真是打从娘胎里一出来就注定了坎坷的一生。
首先是客户群体：
- 客户所属行业分布广，教育、泛互、金融，不同的客户对产品的需求差异性大。
- 客户接入周期长，大客户在接入过程中会不断追加新需求和新特性，与此同时，客户对交付周期要求又很苛刻。
然后是产品形态：
- SDK 对专业性要求是比较高的，别人家的客户都只需要理解 http 的 get 和 post 就行了，俺们家的客户就得知道多线程安全、内存泄漏、前后台切换，苹果隐私合规要求，还有 android 的 gradle 配置方法和 windows 的 stl 兼容问题...
- 涉及平台众多，iOS、Android、Windows、Mac、Web，每个方向都需要很长时间的积累和沉淀。同时，在微信的强大的影响力面前，我们又增加了一个新的平台——微信小程序。
最后是交付成本：
- SDK 完成接入后，成不成要依赖客户的最终反馈，但往往客户的反馈周期很长，迭代周期也很长。
- SDK 版本多，平台多，这也就意味着测试工作是海量的。就说一个细节，这么多平台和版本，全量编译都需要两个小时，转测和发版就更不用说了。
面对这个问题，我们的友商做法是：加人。
当然，我们不能这么简单粗暴，毕竟粗放型经济是走不远的，我们还是得从研发体系上用集约的思想去解决问题，这就是接下来要说的重点：从研发、产品、数据和排障等四个方向去认认真真做好一款面向企业服务的 SDK 产品。
研发体系的优化
在研发体系方面，我们依然遵循腾讯倡导的需求评审=>技术评审=>开发=>测试的流程。但每个环节，我们都结合自身的特点进行了改进。
作者：rexchang，腾讯 CSIG 客户端开发工程师
导读
我在 2008 年进入公司后，做的一直是面向 C 端用户的客户端产品—QQ，产品的可测性是很强的，虽然功能很多，但我们测试团队总是能成为产品质量的坚强后盾。2016 年我们团队加入腾讯云之后，依然在客户端方向，但所做的产品已经不再是一款软件，而是一套音视频通信领域的 PaaS SDK，即 TRTC SDK 和 IM SDK。
相比于 QQ 只需要做好一款 App，我们要面对的是服务好几千个客户的 App，而于此同时，测试资源又是有限的。在这种情况下，如何确保产品质量呢？
从一个小故事开始讲起
在几年前我们刚开始做 ToB 的 SDK 的时候，曾经对接过一家做社交 App 的公司，对方的技术负责人很年轻也很务实。在商务大哥给力的努力下，客户成功完成了产品的接入，并进入线上灰度阶段。
然而，在开始灰度的那天晚上，线上用户出现了很多消息延迟大的投诉，用户的一条消息需要很长时间才能发出去。客户虽然对我们很失望，但依然很努力地在配合我们排查和修复问题。
在两天的时间里，我们给客户改进了多个版本，每次给版本的时候我们都说“已经找到问题了，这个版本肯定可以”，但每次效果都不理想。两天之后，客户的技术负责人很严肃地询问了我们一个问题：“从这两天的排障过程和修复过程来看，我想确认一下你们这是一款商用级的产品吗？”
在那个晚上，我们开始冷静地思考一个问题：一款优秀的商用级 SDK 应该怎么做？
一年的努力功亏一篑
最近教育行业被政策打压地非常厉害，但在两年前，这是个 PaaS 服务的兵家必争之地。我们有一家做在线英语教学的客户，一直在对接我们的 TRTC。这个客户对质量要求非常苛刻，他们很早便引入了赛马机制，将多家 PaaS 服务商拉入到自己的供应商集群，互为灾备，并进行质量评估，看谁的质量好就用谁的产品。
在最开始对接的时候，我们的产品质量还不是很优秀，几个关键指标跟竞品都有差距。这倒不是问题，优化总要有一个过程，于是我们一个迭代一个迭代地去跟进。因为客户的版本发布速度非常慢，所以我们需要在两个版本之间都做好问题分析和优化落地，稳抓稳打地慢慢降低工单率。就这样，经过了将近一年的时间，产品各项指标都已经很不错了，我们非常有信心在下一个版本超过友商获得质量上的领先地位。
但就在我们信心满满地等待客户上线的灰度反馈时，客户突然抛出一个问题：“你们的 SDK 有一个对音频模块的自动重启逻辑，这个逻辑会在切换线路时影响到其他供应商的音频模块， 这是绝对不能容忍的”。因为引入多家供应商赛马的意义就在于保证可以有灾备，如果一家供应商影响了其他供应商的稳定性，这个灾备便没有了意义，因此客户对我们异常失望，放量计划无限期搁置。
面对一年的努力功亏一篑，我们开始接受一个现实：每位同事都可能会因为手滑引入缺陷，但对团队而言代价却是难以承受的，怎么办？
回到正题，接下来我会介绍一下过去的这些日子里，我们怎么去应对这个问题。不过在此之前，我需要先介绍一下我们的产品：
我们是做什么的？
我们团队所开发的是一套面向企业级客户的 SDK，包括用于实时音视频通讯的 TRTC SDK；用于消息通信的 IM SDK；用于直播推流和播放的 LIVE SDK ；以及用于短视频录制和编辑的 UGC SDK。