Netflix是这样炼成的：谁构建，谁运维

时值2012年，Netflix正在勉力支撑自身关键服务运维。整个部署过程，就如穿越泥潭般费时费力。金丝雀测试只能用于考查持续能力（「只要连续一周不出问题，就推进至下一步」），而非真正验证功能的正确性。研究问题就如皮球一般在不同团队间被踢来踢去，而且人们很难找到问题的根本原因，更遑论阻止这种踢皮球现象。很明显，这一切都需要得到改变与纠正。

时间快速推进至2018年，Netflix如今已经拥有1.25亿全球会员，每天视频内容播放量超过1.4亿小时。我们在改善工程团队的开发与运维方面投入了大量资金。在这一过程中，我们尝试了多种服务构建与运维方法。在今天的文章中，我们希望分享一种在Netflix内部较为常见的解决方法，同时探讨其优势与缺点。希望这一经验分享能够激励更多朋友勾勒出替代性方案，同时从我们的经历中总结出心得与教训。

一支队伍的发展旅程

Edge Engineering负责AWS服务中的第一层，这些服务正是Netflix媒体流得以顺利运转的前提性基础。过去，Edge Engineering团队拥有众多以运维为重点的SRE，他们主要负责软件生命周期当中的部署+运维+支持部分。而新功能的发布，意味着开发人员需要与运维团队共同就指标、警报以及容量相关问题开展协调，而后由运维团队进行代码分发以实现部署及运营。为了高效推动代码运行以及合作伙伴支持，运维团队需要建立持续性培训制度以确保人员理解新功能并修复各类bug。总体来讲，建立起独立运营团队的主要助益，在于当一切进展顺利时，开发人员不致因运维任务的介入而分神。

然而，当工作进展遭遇阻碍时，成本就会快速叠加起来。开发人员与SRE之间的沟通与知识转移往往存在严重损耗，且需要额外的往来以实现问题调试或解答合作伙伴的疑问。由于运维团队对需要部署的变更本身缺少直接了解，因此问题部署通过会带来更长的检测与解决周期。当时在代码完成到部署之间的时间断档要远远长于当前，发布时长往往需要数周而非数天。这方面反馈主要来源运维人员，他们大多亲身经历过诸如警报/监控缺失或者性能问题以及延迟增加等挑战，而这些问题最终又会被转移至开发人员手中。

为了改进这一点，Edge Engineering团队尝试了一种新的混合模式，即开发人员可以在需要时自行推送代码，同时在非工作时间内负责生产问题与支持请求。这种方式改善了开发人员的反馈与学习周期，但仍存在部分职责性空白。举例来说，尽管开发人员可以自行部署并调试整个代码发布流程，但一般仍会遵循运营发布专家的意见。对于这些以运维为关注重点的人员，他们更有动力完成自己的日常工作，但却很难确定具体事务的自动化优先级——毕竟一旦体系明确，企业可能将不再需要他们这类职能角色。