开发者不懂产品运维的痛？Netflix想让你亲自做运维试试看！
大数据文摘出品
编译：朱一辉、涂世文、Aileen
你也常常遇到这个令人头疼的事吗？每次产品出现问题，开发团队和运行维护团队就开始互相踢皮球，很难直接定位问题所在。全周期开发模式是一条看起来艰难，但是值得去探索的道路。
本文来自付费视频网站Netflix的开发者博客，介绍了Netflix如何从软件生命周期开始思考，优化服务的开发和运营流程。2018年，Netflix已经发展成为拥有1.25亿全球用户，每天超过1.4亿小时的浏览时长的流媒体巨头。希望他们踩过的坑能对你有所启发。
整个团队的心路历程
Edge Engineering团队负责支撑Netflix流媒体业务的AWS服务的第一层。在过去，Edge Engineering拥有专注于运维的团队和SRE（网站可靠性工程师）专家，他们负责软件生命周期中的“部署+运营+支持”部分。新功能的发布意味着开发人员需要与运营团队协调处理诸如各项指标、注意事项和性能等事宜，然后将代码交付运维团队部署和维护。
为了代码的高效运行并配合开发部门同事的工作，运维团队需要就新增的功能和已修复的bug持续进行培训。拥有独立运营团队的主要好处是，在事情进展顺利的情况下，开发人员可以专注于的开发而不被运维方面的事情所打断。
但是当事情进展不顺利时，各种成本就会增加。开发人员与运维人员之间的沟通和信息传递是失真的，需要他们进行进行额外的多轮沟通来调试Bug或解答同事的疑问。
由于运营团队对正在部署的服务的更改没有直接的了解，因此部署问题需要更长的检测时间和解决时间。代码完成和部署上线之间的时间间隔比如今要长得多，新功能的发布需要几周而不是几天。
直接的反馈来自运营人员，他们直接经历了诸如警告/监控或性能问题以及延迟增加等痛苦，而开发人员听到的都是二手消息，不利于直接定位和解决问题。
为了改进这一点，Edge Engineering团队尝试了一种混合模式，在这种模式下，开发人员可以在需要时自行推送代码，还负责解决非工作时间的生产问题和支持请求。这种模式缩短了开发人员的“反馈-学习”周期。但是，只承担部分责任会留下了缺口。
例如，即使开发人员可以自行部署和调试通道破损，他们通常也会推迟到运营发布专家那里。对于以运维为中心的人员，他们有动力去做日常工作，但是很难优先考虑自动化，因为自动化一旦实现，其他人则不再不需要依赖他们。
为了寻找到更好的方法，我们退后一步，决定从最基础的原则入手。我们试图完成什么？为什么我们还没成功？
软件生命周期
软件生命周期的目的是优化“从时间到价值”这一过程；有效地将创意转化为对客户具有针对性的实用产品和服务。开发和运行软件服务涉及到一整套责任体系：
设计 开发 测试 部署 运营 支持
软件开发生命周期（SDLC）组成部分
在过去，我们一直在细分这些责任。理想情况下，每个功能区域都由不同的人/角色负责：
设计 开发 测试 部署 运营 支持
架构师 开发人员 测试人员 发布工程师 系统管理员 客户支持
软件开发生命周期（SDLC）专家
这些专业角色可以在每个环节中有着高效的工作水平，但这样同时可能使整个生命周期的效率低下。专家在重点领域发展专业知识，并优化该领域的需求。他们能更高效地解决对应领域的难题。
但软件需要整个生命周期为客户提供价值。各自拥有生命周期一部分的专家团队会造成孤岛效应，从而减缓端到端的进程。将不同的专家组合成一个团队可以打破孤岛效应，但是由于不同的人担任每个角色会增加沟通开销，引入瓶颈并抑制反馈闭环的效果。
亲自运维你构建的内容
为了重新思考我们的方法，我们从“开发-运维”（DevOps）行动原则中获得灵感。我们可以通过打破孤岛效应并鼓励整个软件生命周期所有权的共享，来优化“学习-反馈”循环：
用开发运营（DevOps）原则处理SDLC
“运维你构建的内容”是指通过让开发系统的团队也负责该系统的运维和后期支持工作，将DevOps原则付诸行动。将这一责任分配给每个开发团队，而不是外包给其他团队，从而创建直接反馈闭环并协调激励。
感觉运维痛苦的团队更有动力通过改变系统设计或代码来消除痛苦；他们对这两项职能负责并具有解释权。每个开发团队都拥有部署问题、性能Bug、性能规划、警告缺口、伙伴支持等权利。
借助开发者工具进行规模化
完整软件开发生命周期的所有权极大地增加了软件开发人员预想的工作量。将那些可以简化和自动化开发的共同需求做成工具，有助于减轻一部分负担。例如，如果软件开发人员需要管理其服务的代码回滚，那么需要丰富的工具，既可以检测并警告问题，也可以帮助回滚。
Netflix创建了集中式团队（例如云平台，性能和可靠性工程，工程工具），其任务是开发通用工具和基础设施，以解决每个开发团队都有的问题。这些集中式团队通过将他们的专业知识转化为可重复使用的块，增强生产力。例如：
构建工具 部署管道 评测和警告 洞察分析工具
专家创建可重复利用的工具
有了这些工具，开发团队可以专注于解决其特定产品领域内的问题。随着更多的工具需求的出现，集中式团队会评估多个开发团队的需求是否共有。如果是，那么合作就开始了。有时候这些局部需求太过特定，就不能保证集中团队会处理。在这种情况下，开发团队决定他们的需求是否足够重要，以便他们自己解决。
在类似问题上局部平衡与集中处理，是我们方法中最棘手的问题之一。根据我们的经验，寻找针对开发人员需求的新颖解决方案的价值，值得让多个团队冒险去创建并行解决方案，这些方案需要在未来能够融合。沟通和协调是成功的关键。通过一开始就良好协调需求和它们可能的普遍程度，我们可以更好地使全体Netflix开发团队的投入与收益相匹配。
Netflix常用工具和架构可参考
https://netflix.github.io/
全周期开发者
通过将所有这些想法结合在一起，我们创造了一个模型，在此模型中，开发团队装备着令人惊叹的开发者生产力工具，负责整个软件生命周期：设计、开发、测试、部署、运行和支持。
火力全开的全周期开发者
全周期开发人员需要对软件生命周期的所有领域都熟悉且高效完成。对于许多新到Netflix的开发人员来说，这意味着要加深他们之前并不关注的领域的了解。
我们举办开发训练营和其他形式的不间断培训，以传授这些知识并增强他们的技能。知识是必要的，但还不足够；用于部署通道（例如Spinnaker）和监控（例如Atlas）的易于使用的工具，对于有效的全周期所有权也是需要的。
Spinnaker：
https://www.spinnaker.io/
Atlas：
https://github.com/Netflix/atlas/wiki
全周期开发者将工程原则应用于软件生命周期的所有领域。
他们从开发者的角度评估问题，并提出诸如“我如何使的运营维护此系统所需的操作自动执行？”和“什么自助服务工具能够帮助我的合作伙伴解答他们的问题，而不需要我参与？”这有助于我们的团队，通过倾向于以系统为导向而不是以人为导向的思维和自动化，而非人工方法，来形成规模效应。
转向全周期开发人员模式需要转变思维。有些开发人员将设计+开发，以及测试，视为创造价值的主要方式。这导致产生了相悖的模式，将运营视为干扰，倾向于修复短期运营和支持问题，以便他们能够回到“真正的工作”。
但全周期开发人员的“真正的工作”，是利用他们的软件开发专业知识来解决整个生命周期中的问题。一个全周期开发者的想法和行为要像SWE、SDET和SRE一样。有时，他们创建解决业务问题的软件，有时他们会为此编写测试用例，有时还会将系统的运维工作自动化。
要使这个模式成功执行，团队必须致力于发现其带来的价值，并认识到成本。
团队需要配备足够的人员来管理构建和部署工作，处理生产问题并响应同伴的支持请求。需要花时间培训。需要利用和投入工具。需要通过集中式团队培养同伴关系，以创建可重用的组件和解决方案。在规划和回顾过程中，需要考虑生命周期的所有领域。像自动化警告响应和构建自助式协同支持工具等投入，需要与业务项目一起按照优先顺序排列。
通过适当的人员配备，分配优先次序和协作关系，团队就可以成功运维他们所建立项目到内容。如果没有这些，团队就会有超负荷和倦怠的风险。
要在Netflix之外应用此模型，有必要进行适当修改。在你的开发团队中，常见问题可能类似于对持续传递通道、监控/可观察性等方面的需求。
但许多公司没有足够人员投入，来组建像Netflix一样的集中式团队，或者没有达到Netflix规模所需的复杂性。Netflix的工具通常是开源的，将它们作为第一次尝试，可能会引起大家的兴趣。
但是，针对这些问题的其他工具和SaaS解决方案可以满足大多数公司的需求。首先分析潜在价值并计算所需成本，然后进行思维转换。评估你需要什么，并注意要用最不复杂的必要工具。
权衡利弊
科技行业有多种方法来解决开发和运维需求。这里描述的全周期模型在Netflix中很常见，但也有其不足之处。在选择模型之前了解利弊，可以增加成功的几率。
采用全周期模式，在这些更广泛的领域中，通过工具，优先考虑有更大的所有权和有效性领域。广度需要在不同的技术领域有兴趣和能力。一些开发人员更愿意专注于一个狭小领域而成为世界级专家，我们的行业在某些领域需要这些类型的专家。
对于那些专家来说，让他们广泛了解很多领域，并对每个领域有适当深入的理解，可能会使他们感受到不适，有时甚至觉得无法取得满足感。Netflix的有些人更喜欢在需要研究深厚专业知识，而不需要持续的广度的领域，我们支持他们找到自己的角色定位；而对于其他人则自由享有并鼓励承担更多的责任。
在我们构建和运行基于云的系统的经验中，我们已经看到了那些拥有全周期所需广度的开发者所产生的效果。但是这个广度增加了每个开发者的认知负担，这意味着团队每周需要平衡的优先事项，比他们专注于一个领域的要多。
我们通过“调用轮转”的方式来减轻负担，开发者轮流处理“部署+运维+支持”责任。如果做得好，就为其他人做专注的、流程性的工作，创造了空间。如果做得不好，团队会进入每个人都投入到如产品问题的高中断工作状态中，这会导致整个团队精疲力竭。
工具化和自动化有助于扩展专业技能，但没有任何工具能够解决开发者生产力和运维空间的每个问题。Netflix有一套,由集中式团队支持的“铺好的道路”般现成的工具和方法。
我们不强制要求采用这些现成的工具和方法，而是通过确保使用这些技术进行开发和运维工作有更好的成效，来鼓励团队采用它们。我们方法的缺点是，“每一个团队使用每个工具中的每个功能来满足他们最重要的需求”这个理想几乎不可能实现。为了实现我们集中式团队解决方案的投资回报，需要付出努力、保持一致性以及进行不断调整。
