EP 做什么
　　我们回头说 EP 团队，EP 团队也有自己的人生理想，那是一个三部曲：替、教、独立。
　　第一个是替的阶段，其实是比较老式的开发过程，我替你测试、替你上线、替你运维。
　　这个阶段，完全不符合我们「吃狗食」那一条价值观，按照狗食法则，一个人自己设计开发编码，当然要自己测试，自己写的代码 bug 多要一遍遍回归，这个苦果自己不吃谁来吃？但没办法，大多数程序员在如何测试自己的程序方面没有受过什么训练，为了尽快发布产品，只能替，但这个替的时间要越短越好，尽快进入下一个阶段，教。
　　第二个是教，是教技术团队的其他成员，如何测试自己的程序，如何构造环境、构造数据，如何部署和运维自己的产品。这里的自己做，并不是回到蛮荒时期，例如创业初期只有一个程序员的时候，他当然是自己开发自己测试自己部署，但我们到了第二阶段的自己做，是自己规范的做，通过我们提供的相对完善和规范的工具做。我们处于这个阶段的初期。
　　第三个阶段是独立，独立是说 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，影响非常大了。