2019-05-24需要指出“Devops工程师”是一个概念错误。事实上Devops并不是一个职位，如果按照文中所说：“Devops工程师帮助团队搭建CI/CD工具”则应该叫做持续交付工具架构师，而这与文首所说：“运维工程师纷纷改名Devops工程师”在工程师的技术栈领域互相矛盾，难道所有持续交付系统都是由运维工程师搭建的吗？
而《Devops实施手册》提出了DevOps能力中心的核心角色其中包括：协调资源的项目经理；推动工具方案实施与评价结果的执行经理；交付DevOps平台的基础架构经理；DevOps教练和技术布道者。由这些角色配合才能完成传统企业Devops的全面转型。
即使是初创企业推行Devops也不是只有一个工具链工程师可以完成的。
参考连接：https://www.jianshu.com/p/7cf36451ee83?from=groupmessage展开作者回复: 谢谢指正
“以前的运维工程师也纷纷变成了 DevOps 工程师。”是为了说明DevOps火爆，比如你可以到招聘网站去搜索一下职位。这其实也类似于“以前的软件测试也纷纷变成了QA”。
我也知道这个定义是有争议的，所以文中已经说明：“对于 DevOps 工程师的定义其实是有争议的”，并且“在这里我们没必要陷入这种争论，而是从 DevOps 实践的角度，来看看 DevOps 工程师，要做什么事情，可以帮助团队来实践 DevOps 的工作方式。”
对于DevOps这种观点，不像瀑布模型这种定义已经很明确了，大家都可能有不同解读很正常，但核心本质其实是类似的，就像楼上 @纯洁的憎恶 同学总结的那样：DevOps的道：开发与运维紧密协作的工作方式，以更快更可靠的构建、测试、发布软件。
所以要实施DevOps，不是说需要有一个实施手册，需要有一个教练，要有一个Title才可以，恰恰相反，如果你是遵循DevOps的道，开发与运维紧密协作，高效的构建、测试、发布软件，那就是DevOps的开发方式。
这其实也是专栏最开始就提到的：我们学软件工程，还是要掌握好其中的“道”，再通过“道”去学“术”和用“器”，而不是去追求“术”和“器”而反而忽视了“道”。 5
2019-05-23前面听老师介绍了很多自动化测试的方法、工具以及现在的devOps，听到这些可以快速提高生产效率的方法，使我有点跃跃欲试了。宝玉老师能不能介绍一整套可以简易部署使用的devOps的工具，方便小公司快速部署、实现，在实践中感受devOps的魅力。作者回复: 如果你要部署持续集成环境，可以先试试Jenkins或者Gitlab CI。如果你要部署日志和监控系统，可以试试ELK，也就是Elasticsearch、Logstash、Kibana三者的结合。网上可以找到很多安装使用教程。
5- 2019-05-25如果标题改成“Devops这样实施就对了”也许会好些。这样至少不会混淆所有Devops实施的工作只需要一个角色就能完成。（招聘岗位title写着Devops工程师？一定是一个不懂Devops的HR所为）
就像文中提到的“道 法 术”概念，首先有定义，然后根据定义建立体系，而不是使用有争议的词汇，让读者对论述产生误解。
就像软件工程通过一套方法使得软件交付可预期，Devops如何实施也是一套严谨的知识体系，有不同的分工和角色。只有用严谨的方法才能得到可预期的结果。展开作者回复: 👍你这个标题《Devops这样实施就对了》的建议不错
4 
2019-06-11我个人觉得devops是个很大的概念，理论上开看更侧重的是一种协作方式，也就是想法先行，单从目前的IT业态发展趋势来看，devops下面包含了很多学科，与基础设施相关的云计算，容器化，自动化运维监控等，与软件工程相关的敏捷开发，CI/CD，微服务等，以及与组织架构相关的诸如SRE这种角色的导入还有OKR考核方式等作者回复: DevOps目前解读比较多，我觉得如果什么都往里面装，那么DevOps就会变成“现代软件工程”了：）
3
2019-05-23传统运维工作：程序部署到生产环境、保障服务器稳定运行、日常更新维护（操作系统、应用软件、数据库、配置文件）。
变化：服务器规模与日俱增，因此带来的自动化运维计划的普遍应用；生产环境程序部署的频率更高，高频部署与系统稳定的冲突助长引发运与开发的职能壁垒。
运维人员的新要求：应用大量自动化运维技术，具备搭建自动化运维工具或功能的能力，更多的了解、参与、引导开发环节工作。
DevOps的道：开发与运维紧密协作的工作方式，以更快更可靠的构建、测试、发布软件。
DevOps的术：通过软件技术打通开发与运维环节的信息壁垒，提高软件工程全过程自动化水平，固化、引导跨职能协作文化，提升整体效能。
本公司有多个外包团队，每个规模都比较小，所以往往几个人同时负责产品、测试、运维的工作，没有明确的分工反而挺高效。规模较大的公司由于管理的项目更负责、人员也更多样，所以岗位上区分的比较明确，也有利于专注本职工作。但这也在一定程度上助长了岗位壁垒，需要强调跨职能协作的工作方式与手段。“分分合合”的过程中，效率是不变的追求。展开作者回复: 👍👍非常好的总结和补充！
2
2019-05-23曾经部门里有一个运维工程师觉得工作不饱和，成就感不强，一个是因为业务一直上不去规模，还有一个是他自己也有一点焦虑，觉得基础的运维越来越被云计算厂商给做完了，所以他就想到自己开发一点日志监控和预警、甚至应用程序的性能追踪和异常发现，今天看到老师的文章，发现这种发现问题解决问题方式在实践devops的方式好像也挺好的，并且更容易落地作者回复: 👍你们运维方向应该是没问题的，能站在技术的角度去思考如何更好的发现系统潜在问题。
运维如果往开发这边跨一点，能做的事情还挺多的，可以帮助搭建持续集成环境、搭建自动化监控、实现自动化部署等等。 2
2019-05-23对于Devops我只是听说过，并没有具体的去了解过它的使用和应用场景。根据宝玉老师的讲述，Devops 的基础是自动化，那么自动化之外好像更多的是一种概念，可以因环境而产生各种不同的方式和方法，并没有比较明确的定论。感觉就像敏捷开发一样，满足敏捷宣言思想的操作都可以是敏捷开发，最终适合自己或团队的才是最好的。作者回复: 自动化确实没有明确的定论，重要的是得要有应用自动化的意识，让自动化变成你项目开发流程的一部分，从而提升效率、改进质量。
应用自动化本质就是应用工具和基于工具二次开发，常用的自动化工具比如说自动测试框架、持续集成、日志监控报警。这些都是基础工具，还需要针对自己项目的环境，基于工具提供的API，去定制化的写配置脚本，让它可以适合你的项目。
最重要的还是要把这些工具整合到你的开发流程中，比如说：
当你提交代码的时候，持续集成能帮你自动运行自动化测试脚本，可以直观看到测试结果，根据结果再决定是否合并或者继续修改；
当你合并代码后，持续集成能帮你自动化部署到测试环境，并且构建生成生产环境的部署包，甚至帮你自动部署生产环境。
当你要部署的时候，通过自动化的脚本直接部署到生产环境，而不需要手工去干预太多，避免人为因素的失误。
当你部署上线后，通过日志监控报警系统能实时看到部署后的数据变化，及时发现问题。
这样的流程其实是比较通用的、大部分项目都是适用的，只是前期需要投入一定的时间精力去研究和搭建，但是搭建好了这样的整套自动化环境和建设好了相应的开发流程，相应的从效率和质量上的回报也是很大的。 2
2019-05-23搭建自动化测试，自动化部署，自动化监控系统，都自动化了，开发都做了，是不是就不需要运维和测试了.......作者回复: 自动化只是把重复的体力活做了。
自动化测试的话，还是需要测试人员写测试用例才能有更好的测试效果；
自动化部署和监控，也离不开专业运维人员的设计和搭建。
但是可以预见的是，以后低端的手工测试和运维岗位会被挤压的很厉害。如果你看大厂的招聘岗位，这些低端手工岗位都极少或者根本就没有。 2
2019-10-071、有什么软件企业不适用于DevOps 吗？比如嵌入式软件产品？2、有没有一套比较成熟拿来可用的DevOps 产品，比如Tomcat+mysql+git的？3、现在有DevTestOps概念，DevOps 与DevTestOps区别在哪儿？作者回复: 1. 我觉得像对于嵌入式软件产品，一样要提倡紧密协作、自动化、可度量。所以DevOps对于软件企业，都是值得提倡的。
2. 如果从自动化和可度量的角度，是有不少软件产品的，比如像《26 | 持续交付：如何做到随时发布新版本到生产环境？》、《38 | 日志管理：如何借助工具快速发现和定位产品问题 ？》里面介绍的一些工具。
3. DevOps通常指开发（Dev）和运维（Ops），DevTestOps就是把测试（Test）也加进来了。其实本质都是指构建跨工种的协作文化。 1
2019-06-27确实说出了目前我们团队中的痛点，不同岗位人员之间的不理解。 不同岗位工作内容的渗透，跨职能协作，是可以融入我们的团队中的方法。当然这个不是能一步促成的事，需要一步一步走。作者回复: 👍发现问题是最关键的一步，解决问题的方案反倒是有很多选择。
1