从QA到EP(2)

　　第二个是教，就是教技术团队的其他成员，如何测试自己的程序，如何构造环境、构造数据，如何部署和运维自己的产品。这里的自己做，并不是回到蛮荒时期，例如创业初期只有一个程序员的时候，他当然是自己开发自己测试自己部署，但我们到了第二阶段的自己做，是自己规范的做，通过我们提供的相对完善和规范的工具做。我们就处于这个阶段的初期。

　　第三个阶段是独立，独立是说 EP 团队从一个替人做事的下游团队，到一个教人做事的教练团队，真正进化为一个提供技术服务的产品团队。这个产品团队的产品，大多数应该是以一个标准化的、健壮的服务的形式，而不是人力资源的形式，提供给其他团队的。当然这是我们的理想，能否达到或者是否切合实际，还需要时间来观察。

　　EP 团队和整个技术团队的关系

　　从这三个阶段的描述中，多多少少都提到一些 EP 团队和整个技术团队或整个公司的关系，那这个关系是什么呢?

　　前面提过，我们不希望是个下游替人收尾的团队，我们也有「吃狗食」这样的原则，所以我想到一个比喻，来说明 EP 团队和其他技术团队的关系。

　　我们都知道有一个行业叫做汽车制造业，他们遵循一定的规范和标准，还能巧妙的将创意和标准结合在一起，制造出一些工业奇迹，这些汽车被卖给各式各样的人，汽车企业并不关心他们的产品用在什么地方，不过他们又发明了一种叫做 4S 店的东西，用来给那些工业奇迹定期维护、修理、还可以收集市场反馈以便改进产品。

　　还有另一个行业叫做物流业，他们的目的就是将货物从一个地方运到另一个地方，这种空间的转移，就是他们为客户创造的价值。在这过程中，他们会利用到汽车制造业产出的汽车，但他们不太关心汽车本身的标准、设计细节，他们只是使用，他们关心的是使用成本、维修方便。出问题，他们会找 4S 店。

　　这两个行业之间的交集是汽车，汽车制造业的价值是制造出好的汽车，物流业的价值是货物的到达，汽车制造业不关心你的货物的目的地，物流业不关心他的汽车的制造工艺。但汽车制造业会很关心你怎么用这个汽车，以及积极的帮助你保养，而物流业也会很关心这个车费不费油，好不好开。

　　说到这里，你可能已经看明白 EP 团队和其他技术团队的关系了：EP 团队就像汽车制造业，提供高效、低耗的工具;产品技术团队就像物流业，使用工具，快速前进，创造用户价值。他们之间互相依赖，却又彼此独立。

　　EP 都有谁

　　了解了 EP 和周围团队的关系之后，来看看我们的 EP 团队的角色和成员。

　　我们的 EP 团队，大致分成如下几个角色(而实际上的工作是混合的，之所以要分开成角色，主要是从招聘的角度出发)：

　　SED，Software Engineer in DevOps。顾名思义，这个角色首先是个软件开发工程师，其次，面向的领域是 DevOps，DevOps 的概念我们就不必多讲了，在实际工作中，SED 工程师是个真正的多面手，他们可能今天在开发一个 Linux server 的自动化上线和回滚的工具，明天就要设计或优化 CDN 的部署，后天又要解决一个 Windows 平台编译加速问题，还有还有一个自动性能 benchmark 工具等着他来开发。这个角色目前我们只有两位，而且这个角色的工程师是最难招聘的，因为新人，或者很小的公司出来的人，很少有受过系统的训练或有比较先进的软件工程思想，而从大公司出来的人，已经被大公司条块分割的工作方式同化，一般只擅长一个领域，而对跨界的或者不懂，或者没兴趣。所以这个岗位的工程师，都是有成熟公司工作经验的 Geek 型的人。

　　SA，System Admin。系统工程师，和很多公司的运维工程师很想像，实际上我们现在的状态，做的事情也和大多数公司的运维工程师一样，处理监控，优化服务部署等等，但不一样的是我们的目标是将绝大多数应用层面的运维工作交还给开发团队，所以我们在不断的将监控系统改造为友好的，自助的，也不断的将各位上线部署类的工作做成自动的，现在已经有了很多成果，我们的 SA 主要精力可以放在系统以及更底层的部分了。

　　TE，Testing Engineer。测试工程师，其实这个称呼有点名不符实，我们的唯一一位测试工程师，主要的工作其实是发布和迭代控制，要保证整个交付团队的迭代节奏，例如在代码上拉发布分支、触发发布事件、监控数据等等工作，这个工作要求非常精确，又很繁琐，因此和 SED 工程师有非常多的交互，他们负责将这个过程自动化。这里插入介绍一下我们的发布过程，可能大家会更理解为什么还有个「发布工程师」：

　　我们有三个发布 Channel：Beta、RC、Release，作用各有不同。例如 Beta Channel，主要用于一些新特性的提前发布，这里面可能会多少有点缺陷，所以一定要控制人数，并且是那些喜欢尝鲜的用户，他们会用的比较彻底。而 Beta Channel，可能每天都有版本更新，会有一些用户喜欢跟着 Beta 版。而这些新的特性如果用户反馈不错，并且没有什么严重的问题，就会进入最近一次 RC(Release Candidate)，这个量就很大了，大概能占到我们每日活跃用户的十分之一到五分之一，这里面的功能在没有意外的话，就是正式发布的功能了，需要注意的是，不是每个 Beta 都会变成 RC。而 RC 在发布几天之后，如果一切正常，就会切换为 Release，Release Channel 一般会在一天之内，让绝大多数活跃用户升级完毕，这个时候，如果程序有 bug，影响就非常大了。

　　Venders，外包测试团队。我们有大约六七个人的外包测试团队(on-site)，主要负责我们主要产品的人工验收测试。我们对外包测试团队的工作方式也有一个设想，就是一个项目刚开始的时候，外包测试团队应当是先上很多人，然后随着 SED 的介入，让自动化程度加强，慢慢人少下来，直到下一个新项目开始。但这个设想在国内想实现，却没那么容易，主要有几个原因：1)国内的外包测试的工程师，通常是技术和经验都比较初级的人来做，外包测试成了一个门槛低天花板也低的行业，技术和经验缺乏，导致进入新项目以后没办法非常快的上手，而有经验有能力的人，很快就会脱离外包行业;2)外包测试的公司，人才储备不足，很少有人力资源池，都是有需求，现从市场上招，或从竞争对手那里挖，有的人都没见过，就派到客户那边来面试，这也导致了没办法几个月就撤下来，因为他没办法跟候选人签合同。这两个客观原因，我们也比较无奈，所以我们的外包测试团队基本上还是长期 on-site。

原文转自：http://www.wangyuxiong.com/archives/52072