2017-12-21就像自动化取代传统手工业，技术的发展使得生产率提升的同时，也使得行业内的职能配置不断发生变化。现在大部分的软件行业由于敏捷开发的流行也逐渐的淘汰或替换了传统的QA部门，运维的职能也逐渐的从传统的手工业向自动化不断的改进，软件的生命周期也早已不是传统瀑布开发所规定的那样简单。从软件开发的历史来看，代码层级的一些规范也逐渐的向架构层次延展，像微服务的出现不就是kiss原则和dry原则在架构设计上的应用嘛。所以，从大的方向上来看软件行业的发展其实并没有那么快，绝大多数的改变和革新都只不过是过去的理论在现在合适的时刻得到了应用而已。作者回复: 赞！技术应用也是需要看场景和时机的。
10
2017-12-21有具体的Netflix原则和最佳实践参考吗？作者回复: 推荐两个Netflix的技术网站(需要翻越)：
Netflix的Tech Blog：https://medium.com/netflix-techblog
Netflix公开分享的PPT合集：https://www.slideshare.net/netflix
特别是第一个，Netflix会持续更新他们的技术动态和实践，很好的学习案例。slideshare这个虽然内容大部分是前些年的，不过仍然会有很大的启发意义，在这里会体验到Netflix的技术前瞻性。
后面我也会有文章分享我们的一些实践，期望对你会更有帮助。 5
2019-04-18运维价值
1:定义范围:除了业务需求实现层面，其他都是运维
价值所在：运维能力就是架构能力,运维层面爆发问题或者故障，一定是技术架构中的问题，单纯看待没有意义
矛盾:割裂运维和开发，按照软件生命周期开始划分运维和开发，所以应该先转换运维思路，后提升运维技术，让运维和研发团队保持一致，聚焦效率，稳定和成本
netflix 运维现状
sre运维: 用软件工程的方法重新设计和定义运维工作
方式：微服务化
代价和成本:架构复杂度大大增加,无法人力掌控，后续的交付和线上运维难度提高，必须通过软件工程思路打造工具体系支持。
例子：比如服务上下线、路由策略调整、并发数动态调整、功能开关、访问...
为什么微服务会产生sre: 微服务架构复杂到了一定的程度，已经远远超过单纯开发和运维的职责范围，也超过了单纯人力的认知掌控范畴，所以必须的有效的统一的解决方案必须出现
自由与责任并存的企业文化:ower意识，谁构建谁负责
netflix启示一：微服务架构模式下，我们必须换一个思路来重新定义和思考运，运维一定要与微服务架构本身紧密结合起来
Netflix 带给我们的启示二：合理的组织架构是保障技术架构是落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案
应用:从整体服务拆出来的独立模块，每个模块只执行一个功能，可以独立运行和部署。每一个应用都有单一的业务职能，如果要完成整体的业务流程和目标，那么需要和其他应用交互，同时执行过程中会和其他的基础设施和组件进行交互，比如机器，域名，db,缓存，消息队列等展开 3
2017-12-20在组织架构设计方面有没有什么方法论层面的内容和方向作者回复: 会有的，专门有两篇介绍组织架构和协作，以及个人转型的文章。
3
2018-09-03老师您好，听了两小节了课程了，有几个想法想听听您的见解:1.案例中提到的毕竟是整个行业的风向标或者说是趋势，但是这毕竟是大公司或者具备很强团队才能达到预期效果，如果一个公司才几十个人或者上百人，这种情况该如何处理？2.我相信大部分中小型公司运维岗位还是必须要设立的，而且更多的是人肉运维，是否能给这些人一些建议或者发现方向，谢谢！ 2
2018-03-26owner 直接体现了自带责任属性 可以避免好多推锅和定位故障难问题作者回复: 把事情当作自己的，处理起来最高效
1
2017-12-25我能明白市场选择所带来的阵痛，不管是对企业对个人。其实运维主要面临两个问题：一个是企业方面，如果市场趋势如此，那企业在选择业务服务的话，是否应该把运维独立出来以服务的形式提供，并且押宝在上面。另一个就是运维人员，因为如果按照这种趋势下去，运维最终会由工具的使用者转变为工具的制造者。这个转变是巨大的，也有会一部分开发者进入这一领域，对传统运维冲击很大。另外就是对第三方独立应用来说，如何提供产品，以及后续的交付都是值得深思的地方。 1- 2017-12-22作为运维人员如何权衡自己的发展呢？如果将来的运维人员的发展方向更偏于容器，k8s，自动化。那企业内应用，比如说windows的AD运维，exchange运维。企业如何在没有开发团队的基础上实现运维？开发团队如何在远离生产环境的模式中实现owner&build？
作者回复: 我看下来应该是三个问题，也确实是一个个非常典型的现状，我的答复如下：
第一个，关于如何衡量个人发展，这个问题说实话有点大，我可能无法回答全面，我建议可以把问题再具体一些。然后，个人是否能够有发展，是否能够发展地还不错，这里暗含着一个关键的前提，就是要看你个人想要什么，想要成长成什么样子。
第二个，容器、k8s和自动化，一定是未来的演进趋势，因为它们确实能够带来更高的效率，让人工作的更轻松，任何技术的发展只要能够起到上面这两个作用，就一定是有生命力的，代表着未来趋势。
第三个，关于企业内第三方产品的运维和开发问题，我的建议是当内部无法基于这些产品进行运维效率和稳定性提升方面的二次开发时，还是尽量依赖第产品方的服务，看产品方是否可以提供一些运维方便产品技术支持。
从你反馈的单个案例来看，如果还是保持现状，你提到的运维和开发这两个事情都很难改变，因为受限于产品形态和合作模式。但是从整个业界来看，你提到的这两个产品，其实微软都已经将它们上云了，如果是在云上应用，这些问题是不是就不是问题了？
可能有些问题的答案是在问题之外的，这一点可以多考虑一下，因为随之而来的还会有其它一系列问题要去考虑。
思考之后，可以继续留言给我。 1 - 2017-12-21期待后续更新 1 1
- 2017-12-21传统应用的运维模式会逐渐转变到这种模式下吗？那运维外包业务岂不是会慢慢萎缩，运维人员的成长也被局限了
作者回复: 必然会向这个方向发展，是不是会萎缩不一定，但是发展空间一定会受限。后面我也会有一篇也想来介绍这个情况。
1 
2020-01-04我觉的说 Netflix 没有运维岗位，和之前一段时间说某某大公司没有测试岗位一样，其实职能还在，只不过合并到了开发人员那一端。
另外我觉的 Netflix 的“You Build it, You Run ti”，和之前常说的“Eating your own dog food”还不完全一样。dog food 更多的时强调要自己去使用自己的产品，而 “Run” 似乎就包括了运营和运维。自己的产品如果不好用，那么自己明显能感受到种种不便；自己的产品如果故障太多，或者没法运维，那么也会让 Owner 焦头烂额。
但是有一个想法，是否是因为 Netflix 的产品线相对比较单一，我知道的只有视频网站这一块，所以它才能把微服务包括其运维体系做成这个样子，当然其开发人员的功力应该也比较高。如果业务比较复杂，是否就没有办法按照 Netflix 的风格去做运维。
在体制内单位，对市场上的软件行业不是特别的了解，但是我觉的应该还没有到“用敏捷开发代替传统 QA”的程度，甚至很多开发商连测试和配置管理可能都不是很正规。那么对于现阶段的情况，一般的软件公司瞄准 Google 的 SRE 体系，是否更加合适一点？
无论是 Google 还是 Netflix 其实都把运维提高到了相对全局，并且权重比较大的位置；而且对于个人能力的要求也比较高，我觉的这应该也是运维人员的机会。
（不好意思，因为遇到了敏感词，所以留言分了好几部分，最后发现是 dog food 的中文，不知道为什么这个比较敏感）展开
2019-03-27you build it ，you run it
2019-01-08那具体的话，作为一个owner如何保障自己“随意”每次提交的代码没有问题？
2018-11-19很有感触，我觉得这种模式正是需要的，运维不能只做背锅侠
2018-09-05这种技术储备要掌握那些技能
2018-05-20Netflix 带给我们的启示二：合理的组织架构是保障技术架构落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案。
2018-01-23从专精的角度上考虑，开发和运维技术栈，看待问题的角度还是有所区别的，我比较好奇Netflix的开发人员如何做到既能关注自身开发的功能，又能关注到产品上线后的运维和部署架构？他们到达今天这个程度是开发的能力推动，还是因为运维基础平台的完善推动？作者回复: 这个是自驱动型的，当然，很重要的一个前提是，他们技术能力非常强大，这个是国内达不到的，所以更多的需要组织架构上互补。