正文

最近有两个特别讨厌的趋势：DevOps 和「全栈」开发者的思想。

时下，DevOps 已经非常流行，以至于讨厌它就像讨厌 x86 架构或单内核一样，那么究竟是什么造成了这样的结果？让我如此痛苦的根本原因，又是什么？

事实上，并不是每家公司都是创业公司，但却又要去表现得像创业公司一样。

「DevOps」旨在表示密切合作，让原本纯粹的开发、运营和 QA 角色之间协作运转。

因为软件发布的频率越来越高，传统的「瀑布型」开发—测试—发布周期已经不能满足业务的需求，后果就是，开发者还必须为测试和发布的环境质量负责。

随着「开发者」（这个词是否恰当仍存争议）的责任范围不断扩大的同时，综合的全能型开发者需求也被触发——「全栈」开发者。

这样一来，开发者要既能做开发，还需要兼任 QA 团队成员、业务分析师、系统管理员和 DBA 的工作。

那么，DevOps 和「全栈」开发者，这些概念是从哪里冒出来的呢？

当然是来自创业公司（和敏捷方法）：

不容否认的是：初创企业就像一种“蛰伏“的野兽，在最初的几年往往默默无名，而且过的也非常艰辛（人员配备不齐，所以急需DevOps 和「全栈」开发者）。

但不幸的是，当下 DevOps 这个潮流正在迫使开发者在一个成熟的公司中继续扮演这些角色，迫使开发者担任由于基础资源缺乏而不得不为的「开发者」角色。

身兼数职

想象你在一个只有七个人组成开发团队的创业公司。花一年的时间去开发一个 web 应用，各个项目都进展顺利，但是这个过程绝对让你混乱——如果有一个特别严重的问题出现，似乎需要深度的数据库知识。

这种情形下说：「这不是我的专长」这样的话，或者将它交给 DBA 团队进行调查显然是不可行的。由于资源限制，你不得不承担 DBA 的角色，自己去解决问题。

现在，扩展这个场景到之前所列的角色下。在任何时候，开发人员在一个初创企业可能会兼任开发者、QA 测试员、部署/业务分析师、系统管理员或 DBA。

这完全由创业公司的性质所决定，而有些人在这样的环境下可以飞速成长。但一路走来，我们不断欺骗自己，因为在任何时候，开发者都不得不身兼多职，甚至有时候要承担所有角色。

即使这样的人真的存在，「全栈」开发者仍然不会以正常的方式去工作。创业公司并非只是想着开发者暂时短期内担任某个角色，然后过渡到下一个角色；相反，会要求你一直担任所有的角色。

这真的很糟糕，这意味着，可能需要最优秀的开发者。

也谈等级

优秀的开发者都是聪明人，这么说可能会被很多人吐槽，然而在一个机构内，技术人员却是存在多个不同的等级。开发者最高，接着是系统管理员和 DBA。「运营」人员、发布管理员等角色处于最底层。

为什么这样排序呢？

因为，若有必要，每个角色都能够承担低于这一层次所能做的所有工作。

这一点在创业公司已经得到证实。在需要的情况下，优秀的开发者可以转成合格的 DBA、不错的测试员、「部署开发者」以及各种所需的角色。

他们的工作需要他们尽可能的了解底层角色的工作范围。但这存在着一个大的隐患——反之则不成立。

在紧要关头，测试员却干不了开发者的活，也不能成为构建开发者做 DBA 的工作。他们从未获得这些角色的专业知识。

举个例子说得更清楚吧：

比如一名牙医，他开了家私人诊所，然后聘请了秘书、卫生员和牙医助理等很多人员。一般情况下，秘书可以帮忙做预约，卫生员可以帮助消毒，牙医助理也可以帮忙做一些基础的工作，但是如果需要给牙齿钻孔或者进行根部的治疗时，就必须需要牙医亲自“出马”，毕竟没有专业的知识是绝对搞不定的，如果没有专业的“牙医”，即使是全部的“雇员”加起来，也搞不定这件事。

无论乐意与否，每个组织都有层次结构，人们按不同技能和能力水平分类。所以，当你一昧要求开发者担任其他角色时，最后的结果可能是：没人能担当得起开发者的角色。

如此运转会损害所有人员，除了雇主。这场实验本意是提高软件质量，却无意之间成了闹剧，让最有才华的员工过度工作（做了很多无用功），同时低层次的职位没有存在感。

而这正是问题的症结所在。所有最初由不同层次的人所担任的岗位，都是由「全栈」开发者进行的。大型公司非常喜欢这一点，因为这意味着他们可以雇用更少的人来做同样的工作。

尽管在这个过程中，实际开发成为开发者的工作中很小的一部分。这就是为什么我们看到这么多的开发者无法通过 FizzBuzz：

他们几乎没写任何代码。这个问题非常普遍，你能想象一下面试一位厨师，问他每天有多少时间真的花在烹饪上？

博而不精

如果你是一个中等规模软件的开发者，你应该需要一个适当的部署系统。考考你，请马上说出下述这些系统各自的优缺点：

Puppet、Chef、Salt、Ansible、 Vagrant 和 Docker。现在开始实现你的部署解决方案吧！你是否注意到以上系统有一项是完全无关的吗？

专业化是有原因的：人们只能专注于有限的知识。任务切换无疑是昂贵的。强迫开发者承担其他角色意味着：

·         无法专注开发

·         需要补充庞大的知识领域

·         不堪重负

更重要的是，通过迫使开发者承担“全栈”责任，他们会支付其远远高于完成大部分工作的市场平均价格。

如果开发人员每年挣100K ，你可以支付4个开发者每年100K 来做一两个人的任务，50%时间完全做开发，剩下50%的时间做发布管理。或者，只是雇一个发布经理，花大约75K，但两个开发者全职开发。

注意一下兼职发布管理的开发者在无需发布时浪费了很多时间。

不要再扼杀开发者！

这样做的效果是摧毁「开发者」这个角色，以一种「全能技术工人」来替代。

就笔者所知，每个进入编程领域的开发者，都是因为他们实际上喜欢开发（或者一度喜欢）。当你强迫最聪明的人承担额外角色时，其实伤害了所有人。

并非所有公司都是创业公司。创业公司不得不让开发者身兼多职，也有其必要性。但是请根据实际情况进行判断，你是否需要 DevOps。

推荐9个 DevOps 实践公司

你可能知道 Netflix 和 Etsy 在 DevOps 领域的突出表现，但是下面的9个 DevOps 实践公司却可能让你感到不可思议，我们一起来盘点下。

1. Starbucks

星巴克在2015年4月的 #DevOpsTogether 开始了其 DevOps 计划。尽管「在一起」已经是个陈词滥调，但是不用担心。从 这篇文章①了解到，星巴克 CEO 非常支持 DevOps 理念，并且一直努力让公司保持技术上的创新。

2.  

  是 DevOps 运动的早期采用者，是 Continuous Delivery 和 DevOps 运动的先锋。

早在2013年，这些流行的方法就对发布次数和公司满意度上有了显著提升。想了解更多关于他们的过程、迁移和 DevOps 文化，不妨查看一下他们的系列文章②。

3. Ashley Madison

没人会觉得这是一个 DevSecOps 博客，尽管其数据库被黑已经成为 DevOps 安全的反面教材。冒着风险开始一个更大的话题，这个著名公司的失败有助于阐明事实，也许 DevOps 并不总意味着更快和更经常。这里有一些不错的DevOps安全文章③，仅供参考。

4. Etsy

Etsy 也在实践 DevOps。Etsy 不仅是一个超级酷的公司，专注于节日礼物，他们同样也在努力的 DevOps。

2008年，他们看到了 Flickr 每天发布10次部署，2009年，他们建立自己的工具来更好更快地发布代码，而且不仅由开发团队。「Etsy 如何应用 DevOps④」绝对值得一读，或者再看看他们的代码⑤。

5. U.S. Customs and Border Protection

这个肯定是你想不到的！在司法部、海关、边境保护署和美联储，美国政府异常活跃于采用 DevOps。

6. LinkedIn

LinkedIn 成为一个大型的 DevOps 用户不足为奇。早在2009年，LinkedIn 团队就开始使用自动化部署工具，用于管理在1000+节点环境下发布上千个应用/服务的复杂性。现在他们正在培养世界级的 DevOps 社区。看看这篇关于他们使用第一个工具⑥的文章。

7. NASA

不管你是否知道 NASA 正在使用 DevOps，这都非常振奋人心。我们最爱的方法可能正帮助人类登上火星，或许是有点夸张……或者也名副其实。无论哪种方式，NASA 一直在思考软件部署，自从2004年首先采用了 JIRA后，他们已经抵达 DevOps 星球。

8. Apple

不要让苹果巨大的 IOS 更新，以及它重要的九月发布季，让你误以为他们放弃了技术创新的风口浪尖。尽管苹果的 DevOps 还没有广泛使用，但他们正在寻找合适的工具，雇佣优秀的人才，来完善日常部署。

9. Airbnb

类似 Netflix 和 Uber，Airbnb 被认为是一个「第三平台公司」，因为他们利用社交、移动、分析和云。作为一个第三平台公司，DevOps 需求不可避免，这便于迅速发布多个小型部署。

如果你有兴趣学习更多关于 Airbnb 的数据和基础设施，可以参考这个slides⑦。

然而，是否每个公司都需要紧跟这个潮流，Jeff Knupp 在 “How ‘DevOps’ is Killing the Developer”⑧ 一文中发表了他的观点。

（王鹏原创）

正文

最近有两个特别讨厌的趋势：DevOps 和「全栈」开发者的思想。

时下，DevOps 已经非常流行，以至于讨厌它就像讨厌 x86 架构或单内核一样，那么究竟是什么造成了这样的结果？让我如此痛苦的根本原因，又是什么？

事实上，并不是每家公司都是创业公司，但却又要去表现得像创业公司一样。

「DevOps」旨在表示密切合作，让原本纯粹的开发、运营和 QA 角色之间协作运转。

因为软件发布的频率越来越高，传统的「瀑布型」开发—测试—发布周期已经不能满足业务的需求，后果就是，开发者还必须为测试和发布的环境质量负责。

随着「开发者」（这个词是否恰当仍存争议）的责任范围不断扩大的同时，综合的全能型开发者需求也被触发——「全栈」开发者。

这样一来，开发者要既能做开发，还需要兼任 QA 团队成员、业务分析师、系统管理员和 DBA 的工作。

那么，DevOps 和「全栈」开发者，这些概念是从哪里冒出来的呢？

当然是来自创业公司（和敏捷方法）：

不容否认的是：初创企业就像一种“蛰伏“的野兽，在最初的几年往往默默无名，而且过的也非常艰辛（人员配备不齐，所以急需DevOps 和「全栈」开发者）。

但不幸的是，当下 DevOps 这个潮流正在迫使开发者在一个成熟的公司中继续扮演这些角色，迫使开发者担任由于基础资源缺乏而不得不为的「开发者」角色。

身兼数职

想象你在一个只有七个人组成开发团队的创业公司。花一年的时间去开发一个 web 应用，各个项目都进展顺利，但是这个过程绝对让你混乱——如果有一个特别严重的问题出现，似乎需要深度的数据库知识。

这种情形下说：「这不是我的专长」这样的话，或者将它交给 DBA 团队进行调查显然是不可行的。由于资源限制，你不得不承担 DBA 的角色，自己去解决问题。

现在，扩展这个场景到之前所列的角色下。在任何时候，开发人员在一个初创企业可能会兼任开发者、QA 测试员、部署/业务分析师、系统管理员或 DBA。

这完全由创业公司的性质所决定，而有些人在这样的环境下可以飞速成长。但一路走来，我们不断欺骗自己，因为在任何时候，开发者都不得不身兼多职，甚至有时候要承担所有角色。

即使这样的人真的存在，「全栈」开发者仍然不会以正常的方式去工作。创业公司并非只是想着开发者暂时短期内担任某个角色，然后过渡到下一个角色；相反，会要求你一直担任所有的角色。

这真的很糟糕，这意味着，可能需要最优秀的开发者。

也谈等级

优秀的开发者都是聪明人，这么说可能会被很多人吐槽，然而在一个机构内，技术人员却是存在多个不同的等级。开发者最高，接着是系统管理员和 DBA。「运营」人员、发布管理员等角色处于最底层。

为什么这样排序呢？

因为，若有必要，每个角色都能够承担低于这一层次所能做的所有工作。

这一点在创业公司已经得到证实。在需要的情况下，优秀的开发者可以转成合格的 DBA、不错的测试员、「部署开发者」以及各种所需的角色。

他们的工作需要他们尽可能的了解底层角色的工作范围。但这存在着一个大的隐患——反之则不成立。

在紧要关头，测试员却干不了开发者的活，也不能成为构建开发者做 DBA 的工作。他们从未获得这些角色的专业知识。

举个例子说得更清楚吧：

比如一名牙医，他开了家私人诊所，然后聘请了秘书、卫生员和牙医助理等很多人员。一般情况下，秘书可以帮忙做预约，卫生员可以帮助消毒，牙医助理也可以帮忙做一些基础的工作，但是如果需要给牙齿钻孔或者进行根部的治疗时，就必须需要牙医亲自“出马”，毕竟没有专业的知识是绝对搞不定的，如果没有专业的“牙医”，即使是全部的“雇员”加起来，也搞不定这件事。

无论乐意与否，每个组织都有层次结构，人们按不同技能和能力水平分类。所以，当你一昧要求开发者担任其他角色时，最后的结果可能是：没人能担当得起开发者的角色。

如此运转会损害所有人员，除了雇主。这场实验本意是提高软件质量，却无意之间成了闹剧，让最有才华的员工过度工作（做了很多无用功），同时低层次的职位没有存在感。

而这正是问题的症结所在。所有最初由不同层次的人所担任的岗位，都是由「全栈」开发者进行的。大型公司非常喜欢这一点，因为这意味着他们可以雇用更少的人来做同样的工作。

尽管在这个过程中，实际开发成为开发者的工作中很小的一部分。这就是为什么我们看到这么多的开发者无法通过 FizzBuzz：

他们几乎没写任何代码。这个问题非常普遍，你能想象一下面试一位厨师，问他每天有多少时间真的花在烹饪上？

博而不精

如果你是一个中等规模软件的开发者，你应该需要一个适当的部署系统。考考你，请马上说出下述这些系统各自的优缺点：

Puppet、Chef、Salt、Ansible、 Vagrant 和 Docker。现在开始实现你的部署解决方案吧！你是否注意到以上系统有一项是完全无关的吗？

专业化是有原因的：人们只能专注于有限的知识。任务切换无疑是昂贵的。强迫开发者承担其他角色意味着：

·         无法专注开发

·         需要补充庞大的知识领域

·         不堪重负

更重要的是，通过迫使开发者承担“全栈”责任，他们会支付其远远高于完成大部分工作的市场平均价格。

如果开发人员每年挣100K ，你可以支付4个开发者每年100K 来做一两个人的任务，50%时间完全做开发，剩下50%的时间做发布管理。或者，只是雇一个发布经理，花大约75K，但两个开发者全职开发。

注意一下兼职发布管理的开发者在无需发布时浪费了很多时间。

不要再扼杀开发者！

这样做的效果是摧毁「开发者」这个角色，以一种「全能技术工人」来替代。

就笔者所知，每个进入编程领域的开发者，都是因为他们实际上喜欢开发（或者一度喜欢）。当你强迫最聪明的人承担额外角色时，其实伤害了所有人。

并非所有公司都是创业公司。创业公司不得不让开发者身兼多职，也有其必要性。但是请根据实际情况进行判断，你是否需要 DevOps。

推荐9个 DevOps 实践公司

你可能知道 Netflix 和 Etsy 在 DevOps 领域的突出表现，但是下面的9个 DevOps 实践公司却可能让你感到不可思议，我们一起来盘点下。

1. Starbucks

星巴克在2015年4月的 #DevOpsTogether 开始了其 DevOps 计划。尽管「在一起」已经是个陈词滥调，但是不用担心。从 这篇文章①了解到，星巴克 CEO 非常支持 DevOps 理念，并且一直努力让公司保持技术上的创新。

2.  

  是 DevOps 运动的早期采用者，是 Continuous Delivery 和 DevOps 运动的先锋。

早在2013年，这些流行的方法就对发布次数和公司满意度上有了显著提升。想了解更多关于他们的过程、迁移和 DevOps 文化，不妨查看一下他们的系列文章②。

3. Ashley Madison

没人会觉得这是一个 DevSecOps 博客，尽管其数据库被黑已经成为 DevOps 安全的反面教材。冒着风险开始一个更大的话题，这个著名公司的失败有助于阐明事实，也许 DevOps 并不总意味着更快和更经常。这里有一些不错的DevOps安全文章③，仅供参考。

4. Etsy

Etsy 也在实践 DevOps。Etsy 不仅是一个超级酷的公司，专注于节日礼物，他们同样也在努力的 DevOps。

2008年，他们看到了 Flickr 每天发布10次部署，2009年，他们建立自己的工具来更好更快地发布代码，而且不仅由开发团队。「Etsy 如何应用 DevOps④」绝对值得一读，或者再看看他们的代码⑤。

5. U.S. Customs and Border Protection

这个肯定是你想不到的！在司法部、海关、边境保护署和美联储，美国政府异常活跃于采用 DevOps。

6. LinkedIn

LinkedIn 成为一个大型的 DevOps 用户不足为奇。早在2009年，LinkedIn 团队就开始使用自动化部署工具，用于管理在1000+节点环境下发布上千个应用/服务的复杂性。现在他们正在培养世界级的 DevOps 社区。看看这篇关于他们使用第一个工具⑥的文章。

7. NASA

不管你是否知道 NASA 正在使用 DevOps，这都非常振奋人心。我们最爱的方法可能正帮助人类登上火星，或许是有点夸张……或者也名副其实。无论哪种方式，NASA 一直在思考软件部署，自从2004年首先采用了 JIRA后，他们已经抵达 DevOps 星球。

8. Apple

不要让苹果巨大的 IOS 更新，以及它重要的九月发布季，让你误以为他们放弃了技术创新的风口浪尖。尽管苹果的 DevOps 还没有广泛使用，但他们正在寻找合适的工具，雇佣优秀的人才，来完善日常部署。

9. Airbnb

类似 Netflix 和 Uber，Airbnb 被认为是一个「第三平台公司」，因为他们利用社交、移动、分析和云。作为一个第三平台公司，DevOps 需求不可避免，这便于迅速发布多个小型部署。

如果你有兴趣学习更多关于 Airbnb 的数据和基础设施，可以参考这个slides⑦。

然而，是否每个公司都需要紧跟这个潮流，Jeff Knupp 在 “How ‘DevOps’ is Killing the Developer”⑧ 一文中发表了他的观点。

（王鹏原创）