01 | 为什么Netflix没有运维岗位？

精选留言(16)

• 

  宵伯特

  就像自动化取代传统手工业，技术的发展使得生产率提升的同时，也使得行业内的职能配置不断发生变化。现在大部分的软件行业由于敏捷开发的流行也逐渐的淘汰或替换了传统的QA部门，运维的职能也逐渐的从传统的手工业向自动化不断的改进，软件的生命周期也早已不是传统瀑布开发所规定的那样简单。从软件开发的历史来看，代码层级的一些规范也逐渐的向架构层次延展，像微服务的出现不就是kiss原则和dry原则在架构设计上的应用嘛。所以，从大的方向上来看软件行业的发展其实并没有那么快，绝大多数的改变和革新都只不过是过去的理论在现在合适的时刻得到了应用而已。

  作者回复: 赞！技术应用也是需要看场景和时机的。

  2017-12-21

  

   10
• 

  白开水

  有具体的Netflix原则和最佳实践参考吗？

  作者回复: 推荐两个Netflix的技术网站(需要翻越)：
  
  Netflix的Tech Blog：https://medium.com/netflix-techblog
  
  Netflix公开分享的PPT合集：https://www.slideshare.net/netflix
  
  特别是第一个，Netflix会持续更新他们的技术动态和实践，很好的学习案例。slideshare这个虽然内容大部分是前些年的，不过仍然会有很大的启发意义，在这里会体验到Netflix的技术前瞻性。
  
  后面我也会有文章分享我们的一些实践，期望对你会更有帮助。

  2017-12-21

  

   5
• 

  朱雯

  运维价值
  1:定义范围:除了业务需求实现层面，其他都是运维
  价值所在：运维能力就是架构能力,运维层面爆发问题或者故障，一定是技术架构中的问题，单纯看待没有意义
  矛盾:割裂运维和开发，按照软件生命周期开始划分运维和开发，所以应该先转换运维思路，后提升运维技术，让运维和研发团队保持一致，聚焦效率，稳定和成本
  
  netflix 运维现状
  sre运维: 用软件工程的方法重新设计和定义运维工作
  方式：微服务化
  代价和成本:架构复杂度大大增加,无法人力掌控，后续的交付和线上运维难度提高，必须通过软件工程思路打造工具体系支持。
  例子：比如服务上下线、路由策略调整、并发数动态调整、功能开关、访问...
  为什么微服务会产生sre: 微服务架构复杂到了一定的程度，已经远远超过单纯开发和运维的职责范围，也超过了单纯人力的认知掌控范畴，所以必须的有效的统一的解决方案必须出现
  自由与责任并存的企业文化:ower意识，谁构建谁负责
  
  netflix启示一：微服务架构模式下，我们必须换一个思路来重新定义和思考运，运维一定要与微服务架构本身紧密结合起来
  Netflix 带给我们的启示二：合理的组织架构是保障技术架构是落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案
  
  应用:从整体服务拆出来的独立模块，每个模块只执行一个功能，可以独立运行和部署。每一个应用都有单一的业务职能，如果要完成整体的业务流程和目标，那么需要和其他应用交互，同时执行过程中会和其他的基础设施和组件进行交互，比如机器，域名，db,缓存，消息队列等
  

  2019-04-18

  

   2
• 

  玉剑冰锋

  老师您好，听了两小节了课程了，有几个想法想听听您的见解:1.案例中提到的毕竟是整个行业的风向标或者说是趋势，但是这毕竟是大公司或者具备很强团队才能达到预期效果，如果一个公司才几十个人或者上百人，这种情况该如何处理？2.我相信大部分中小型公司运维岗位还是必须要设立的，而且更多的是人肉运维，是否能给这些人一些建议或者发现方向，谢谢！

  2018-09-03

  

   2
• 

  岑崟

  在组织架构设计方面有没有什么方法论层面的内容和方向

  作者回复: 会有的，专门有两篇介绍组织架构和协作，以及个人转型的文章。

  2017-12-20

  

   2
• 

  诺克大叔

  owner 直接体现了自带责任属性 可以避免好多推锅和定位故障难问题

  作者回复: 把事情当作自己的，处理起来最高效

  2018-03-26

  

   1
• 

  zyq

  我能明白市场选择所带来的阵痛，不管是对企业对个人。其实运维主要面临两个问题：一个是企业方面，如果市场趋势如此，那企业在选择业务服务的话，是否应该把运维独立出来以服务的形式提供，并且押宝在上面。另一个就是运维人员，因为如果按照这种趋势下去，运维最终会由工具的使用者转变为工具的制造者。这个转变是巨大的，也有会一部分开发者进入这一领域，对传统运维冲击很大。另外就是对第三方独立应用来说，如何提供产品，以及后续的交付都是值得深思的地方。

  2017-12-25

  

   1
• 

  zyq

  作为运维人员如何权衡自己的发展呢？如果将来的运维人员的发展方向更偏于容器，k8s，自动化。那企业内应用，比如说windows的AD运维，exchange运维。企业如何在没有开发团队的基础上实现运维？开发团队如何在远离生产环境的模式中实现owner&build？

  作者回复: 我看下来应该是三个问题，也确实是一个个非常典型的现状，我的答复如下：
  
  第一个，关于如何衡量个人发展，这个问题说实话有点大，我可能无法回答全面，我建议可以把问题再具体一些。然后，个人是否能够有发展，是否能够发展地还不错，这里暗含着一个关键的前提，就是要看你个人想要什么，想要成长成什么样子。
  
  第二个，容器、k8s和自动化，一定是未来的演进趋势，因为它们确实能够带来更高的效率，让人工作的更轻松，任何技术的发展只要能够起到上面这两个作用，就一定是有生命力的，代表着未来趋势。
  
  第三个，关于企业内第三方产品的运维和开发问题，我的建议是当内部无法基于这些产品进行运维效率和稳定性提升方面的二次开发时，还是尽量依赖第产品方的服务，看产品方是否可以提供一些运维方便产品技术支持。
  
  从你反馈的单个案例来看，如果还是保持现状，你提到的运维和开发这两个事情都很难改变，因为受限于产品形态和合作模式。但是从整个业界来看，你提到的这两个产品，其实微软都已经将它们上云了，如果是在云上应用，这些问题是不是就不是问题了？
  
  可能有些问题的答案是在问题之外的，这一点可以多考虑一下，因为随之而来的还会有其它一系列问题要去考虑。
  
  思考之后，可以继续留言给我。

  2017-12-22

  

   1
• 

  leo

  期待后续更新

  2017-12-21

  

   1
• 

  zyq

  传统应用的运维模式会逐渐转变到这种模式下吗？那运维外包业务岂不是会慢慢萎缩，运维人员的成长也被局限了

  作者回复: 必然会向这个方向发展，是不是会萎缩不一定，但是发展空间一定会受限。后面我也会有一篇也想来介绍这个情况。

  2017-12-21

  

   1
• 

  苦行僧

  you build it ，you run it

  2019-03-27

  

  
• 

  趁早

  那具体的话，作为一个owner如何保障自己“随意”每次提交的代码没有问题？

  2019-01-08

  

  
• 

  cc

  很有感触，我觉得这种模式正是需要的，运维不能只做背锅侠

  2018-11-19

  

  
• 

  kkgo

  这种技术储备要掌握那些技能

  2018-09-05

  

  
• 

  大爷静悄悄

  Netflix 带给我们的启示二：合理的组织架构是保障技术架构落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案。

  2018-05-20

  

  
• 

  希望

  从专精的角度上考虑，开发和运维技术栈，看待问题的角度还是有所区别的，我比较好奇Netflix的开发人员如何做到既能关注自身开发的功能，又能关注到产品上线后的运维和部署架构？他们到达今天这个程度是开发的能力推动，还是因为运维基础平台的完善推动？

  作者回复: 这个是自驱动型的，当然，很重要的一个前提是，他们技术能力非常强大，这个是国内达不到的，所以更多的需要组织架构上互补。

  2018-01-23

  

  