08 | DevOps、SRE的共性：应用全栈思路打通开发和运维
该思维导图由 AI 生成，仅供参考
DevOps 和 SRE 的定义和异同
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
DevOps和SRE是当前软件研发领域的重要趋势，旨在打通开发和运维流程，提高研发效能。DevOps强调文化和惯例，SRE则是具体实践。全栈开发通过引入新型运维角色和修改开发者职责描述，将开发人员和部分运维人员的职责从单一扩展到产品的高效开发上线，实现了两个角色的对齐。推动高效沟通和优化从开发到部署的整个上线流程是实现DevOps和SRE目标的重要原则。落地步骤推荐包括对团队目标达成共识、设计流程、引入工具实现自动化。实践案例中，通过统一认识、增加发布工程师角色、设计问题沟通流程和工具自动化，实现了全栈开发，提高了交付效能。全栈开发是解决开发和运维之间利益冲突的关键，让工程师不再只对某一单一职能负责，而是对最终产品负责。随着云技术的流行，懂得开发的运维人员和全栈工程师将会越来越受欢迎。
《研发效率破局之道》，新⼈⾸单¥59
全部留言(15)
- 最新
- 精选
刘丹全栈工程师不一定全领域，准确的说法应该是多领域，掌握大部分领域，精通少数领域。作者回复: 是的。全栈的开发是T字型人才。一横表示了解多领域。一竖表示精通少数领域。
2019-09-0915
刘晓光全栈!=全干 全栈的支撑基础是服务化和技术封装。其实还是底层支撑越来越牛逼了。如果一个组织没有很好的底层技术支撑，作者回复: 全栈!=全干 简介明了！
2019-09-0911
兴国成为全栈工程师也是分阶段，分领域的。比如平常主要做java的开发人员，基于工作需要，也需要写前端，会golang/php等语言；也需要对运维服务器进行部署/使用，使用运维工具进行发布等。刚开始可能对前端等只是会写，并不能搭建框架，不了解其原理；对服务器部署原理，网络搭建原理也不了解。但是能够满足日常的开发，运维需要。随着时间的推移，业务的发展以及问题的不断出现和解决。慢慢的能够更深入了解除java开发之外的东西，慢慢加强巩固自己的技术栈。当然也不是说什么都要会，更多的还是工作中，业务中用到的，主要还是要服务于业务发展。所以是分时间段，分领域的。作者回复: 分时间段这个思考维度是对的。同时也说明了我们软件开发挑战和有趣的地方：不断有新的东西出现需要学习。
2019-09-096- ヾ(◍°∇°◍)ﾉﾞ其实早起在土鳖公司都是全栈的，全栈的好处很明显减少扯皮，对功能聚焦。刚开始可能觉得有难度，其实刚开始比如可以有一个资深的前端搭建框架，后面更改和填充功能就容易多了
作者回复: 是这样的。很多公司一开始都是全栈的。不过。这种全栈和我们在文章中提到的全栈有一些区别。这种全栈是什么都要从头到尾做，而文中提到的全栈是专注于开发这一领域。其他的领域会有领域专家提供一些技术和工具支持。
2019-09-104 
名贤集这位大佬，你也没说使用devops遇到什么问题，如何解决的。 devops跟9999没有直接关系，用devops不一定能达到9999，不用也不一定达不到。 全栈开发跟devops有关系吗？前端和后端都是写代码-单元测试-签入-集成测试，所用的devops也是一样的。怎么感觉你的文章都飘在天上呢？作者回复: > 这位大佬，你也没说使用devops遇到什么问题，如何解决的。 你是指DevOps是用来解决什么问题，还是使用DevOps遇到的问题？ 如果是前者的话，文中已经讲了是为了打通Dev和Ops，从而使得研发流程顺畅，提高效能。 如果问的是后者，跟这篇文章的主题相关性不大，所以没有专门提。不过既然你提到了，我觉得DevOps的一个大问题是当前方法论提的比较多，大家理解的还不深入，更关注的是工具。 > devops跟9999没有直接关系，用devops不一定能达到9999，不用也不一定达不到。 DevOps可以大大帮助提高质量，帮助实现9999。至少从我在Facebook的经验和Stand公司来看，是这样的。 > 全栈开发跟devops有关系吗？ 文中已经说了，全栈开发是实现DevOps的一个重要方法。 > 前端和后端都是写代码-单元测试-签入-集成测试，所用的devops也是一样的。怎么感觉你的文章都飘在天上呢？ 谢谢你给反馈。你觉得什么算”飘在天上“，什么才算“不飘在天上”？
2019-09-1733
iMARS全栈=全开发流程和生命周期作者回复: 全栈有多种定义。比如 * 研发流程方面：设计+开发+测试+运维 * 技术栈：数据库+后端+前端
2020-10-272
xiaozhi239Team Topologies这本书里介绍里四种开发团队类型，其中最多的一种叫Stream-Aligned teams，负责业务的输出，在我的理解里就是一种DevOps的团队。其它团队类型就是用来服务Stream-Aligned团队的，比如封装复杂的系统调用、提供工具、提供技术支持等。我觉得大中台、小前台也是一个类似的理念。通过对全栈的支持，减少全栈团队所需要掌握的知识，让他们可以更专注focus在业务迭代上。 关于Team Topologies我也写了两篇文章介绍： https://blog.csdn.net/xiaozhi239/article/details/108163138 https://blog.csdn.net/xiaozhi239/article/details/108326635作者回复: 写得很好啊！推荐其他读者都读一读！
2020-09-102
DoFacebook是没有测试团队的吗？所有功能都是对应的开发自测？作者回复: 是的。可以参考一下文章中的相关介绍：https://techbeacon.com/app-dev-testing/5-effective-powerful-ways-test-tech-giants
2019-10-202
桃源小盼全栈工程师，在面对一些非常见问题时，会更快的定位问题，而不是以前那样，大家都觉得跟自己没关系，就等着别人去解决。作者回复: 是的。这就是目标一致的好处。
2019-09-092
quietwater全栈是趋势，意味着独立地交付客户价值，所以通过平台和各种工具的支撑，可以直接承接客户的需求是更高的全栈。最后甚至可能包括市场洞察等更多的东西。作者回复: > 可以直接承接客户的需求是更高的全栈 是的。 全栈很好。如果平台、工具、流程支撑得非常好，研发可以更加全栈。不过一个人的精力毕竟有限，所以这个扩展应该是有一个限度的。
2020-01-201
