DevOps Master课程总结：招聘DevOps工程师必问的12个问题

作者：北京老李：DevOps布道师、IT管理咨询师。EXIN授权EXIN DevOps Master（大师级）讲师(首批全国十名)、首批ITIL Expert讲师、EXIN授权EXIN Agile /Lean IT 认证讲师、PMP、Prince2专家级、EXIN云安全管理、ISO20000 LA、ISO27001 LA等多项认证。先后在北京、上海、广州等地主导软件开发、系统集成、咨询服务等工作，主要研究方向云安全管理、DevOps落地实施。

1.你理解的DevOps是什么？
参考回答：DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。融合了精、敏捷、持续交付、轻量级的ITSM(ITIL4、The Toyota way、chatops、AIOps)，通过文化、自动化、精益、度量、共享等管理实践，实现了业务价值的持续交付，也可以称做敏捷2.0版。

DevOps有很多反模式，也有很多DevOps的神话（myths）。其中包括:DevOps是一个过程、敏捷= DevOps、我们需要一个单独的DevOps组、Devops会解决我们所有的问题、DevOps是指开发人员管理产品、我们不能做DevOps因为我们已经很牛了等等内容。

DevOps的核心内容：CALMS
2.敏捷开发与DevOps的关系
参考回答：敏捷开发被用作瀑布开发实践的替代方法。在敏捷中，开发过程更加迭代和增量，在开发的每个阶段都有更多的测试和反馈，而不是瀑布开发的最后一个阶段。DevOps2.0是敏捷过程的解决最后一公里的综合方法。没有敏捷管理方法就没有DevOps。

EXIN pre-Master课程：DevOps基础实践方法Scrum、Lean IT
3.DevOps工程师的职责是什么?
参考回答：DevOps工程师与敏捷开发团队紧密合作，站在业务价值视角，拉动IT从业务需求到运营交付，确保通过高质量（JKK）的自动化测试,实现持续集成和持续交付等IT技术功能所需的环境。DevOps工程师必须经常与开发保持联系（SRE模式、丰田模式、持续交付模式、协作模式），使环境中所有需要的部分都能无缝地工作，实现高质量的增量迭代。可以扩展说说相关工具。

DevOps元素表
4.DevOps可以与ITIL最佳实践融合？
参考回答：DevOps实践可以与ITIL流程兼容。可以支持更短的交付周期，提升业务的前置时间和更高的部署频率，通过DevOps可以解决配置管理的相关的问题和版本管理过程的快速反馈。当应用DevOps中的轻量级ITSM，使敏捷的组织更加高效。

DevOps可以与ITIL完美融合
5.DevOps完美实现一定要用容器吗?
参考回答：Docker 是容量实现的一种技术，Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。DevOps应用容器，可以完美实现DevOps2.0所需要的功能。

容器是轻量级虚拟化的一种形式，比chroot重，但比虚拟化的功能实现轻。它们在使用与主机相同的内核时提供进程之间的隔离，并在内核中提供cgroups功能。  每个VM实例化都需要启动一个完整的OS。vm占用大量系统资源。这很快就会增加大量的RAM和CPU周期。容器主机使用linux内核的进程和文件系统隔离特性。

CoreOS是为运行容器而设计的linux发行版，主要使用自己的rkt格式，但也支持其他格式。它最初基于ChromeOS并支持Docker。替代它的是canonical的ubuntu snappy或red hat enterprise linux原子主机。 

6.持续集成做为最基础的DevOps功能具有哪些特性?
参考回答：大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

持续集成服务器的功能是持续集成不同开发人员正在进行的提交工作，实现代码存储库的所有变更，并检查编译单元测试、集成测试错误，应用敏捷XP方法，可以实现需要每天构建几百次到上千次(业务需求)，在每次提交之后，实现高质量的代码集成输出工作。

7.应用DevOps推荐的脚本语言有哪些？
参考回答：《凤凰项目 一个IT运维的传奇故事》指出：转变主要不是基于自动化，相反，这种不可思议的改进来自于调整关于工作系统的策略和控制半成品的策略，确保有一个高效的跨职能团队，让所有事情都为约束点服务，以及管理好工作交接。

DevOps不能缺少自动化，自动化不能缺少脚本。但也应注意这不是成功的所有，是必须之路之一。脚本语言又被称为扩建的语言，或者动态语言，是一种编程语言，用来控制软件应用程序，脚本通常以文本（如ASCII)保存，只在被调用时进行解释或编译。就脚本语言而言，建议是越简单越好。但，脚本语言本身并不像理解设计模式和开发范例(如过程式、面向对象或函数式编程)那样重要，因为我们要关注业务与业务价值。

目前，有几种脚本语言可用，什么语言最适合DevOps方法?没有完美的回答，但在今天2019年来看，如果你在使用Ansible那么Python语言是最好的，如果你在Chef那么Ruby是最好的。如果你在用HP opsware或BMC bladelogic,当然厂商的脚本语言在你已有厂商产品的前提下是最好的，我们要学会“适境而为”，不要想着总很家里买新衣服，而家里的衣柜都没有地方了，并且服务器的运行压力越来越大。

不是哪一个脚本语言好，而是要应用保证现有财务投资的前提下，什么最合适，这才是关键。

8.配置管理工具在devops中的作用是什么?
参考回答： 配置管理工具是指支持完成配置项标识、版本控制、变化控制、审计和状态统计等任务的工具。 自动化的配置管理工具可以帮助DevOps实现持续流水线的技术支持基础。使用CM工具，可以帮着管理与存储关于系统、软件、测试相关的版本和构建及配置信息，并提供软件和测试软件之间的可跟踪性。成功的DevOps从配置管理开始。

例如：Puppet是全面配置管理领域的标准工具之一。 Puppet 基于 Ruby 开发。

例如： Chef 是一个配置管理开源工具，Chef 作为 master-client 模式运行，需要一个单独的工作站来控制 master 。Chef 基于 Ruby 开发。

 例如：Ansible是一种开源工具，可以根据需要将其设置为 master-client 模式。 基于 SSH , 不需要在远程节点安装任何代理。使用 YAML，应用Python语言。

9.DevOps可以应用在AWS上吗？
参考回答： AWS提供了一组灵活的服务，旨在使公司能够使用AWS和DevOps实践以更高的速度和可靠性创建和交付产品。这些服务简化了调试和基础设施管理、应用程序代码部署、自动化软件发布过程以及对应用程序和基础设施性能的监控。Amazon使用了AWS CodeCommit、AWS CodeDeploy、AWS CodePipeline等工具，这有助于简化devops,快速交付业务价值。

AWS：DevOps流水线与codePipeline
10.与CVS相比，Git的主要优势是什么?
参考回答：最大的优势是Git是分布式的，CVS是集中式的。CVS中的更改是按文件进行的，而Git中的更改(提交)总是引用整个项目。Git提供的工具比CVS多得多。功能对比

北京老李：CVS、SVN、GIT功能对比
11.什么是post mortem meetings？
参考回答：在这个会议上，我们讨论出了什么问题，应该采取什么步骤，这样失败就不会再次发生。事后分析会议并不是要找出问题的症结所在，而是要防止再次发生类似的工作，和ITIL中的问题管理是相类似的管理方法。并应重新计划新的设计基础设施，以便尽可能减少停机时间。如果错误我们无法避免，那么我们应从错误中学习，以提交IT整体的质量管理。

12.你如何在我公司实践DevOps？
参考回答：作为一名DevOps工程师，我会对DevOps项目管理的管理目标、敏捷交付、持续集成进行管理，并从敏捷项目管理新三角《敏捷项目管理》出发，与团队一起设定目标，实现简化的ITIL工作流，维护敏捷的DevOps管理范围，研究和引入新的技术或框架，通过DevOps 流水线，实现从需求转化为工作流从整体工具链进行全局优化。

Lean IT：精益看板与精益领导力课程与DevOps
北京老李建议的实现DevOps管理路径为三种：

实践DevOps有多种路径和方法，基于EXIN DevOps2.0课程体系，实现DevOps三种路径的实现,，三条实现路径分别是：

EXIN：三条DevOps实践路径
第一条从精益Lean IT看板出来，实现DevOps管理与DevOps流水线的管理与技术融合工作实践。

第二条从敏捷scrum出发，实现DevOps管理与DevOps流水线的管理与技术融合工作实践。

第三条从轻量级的ITIL出发，实现DevOps管理与DevOps流水线的管理与技术融合工作实践。

欢迎爬楼，看更多北京老李-DevOps相关内容，ITIL内容请关注”豆列“

https://www.douban.com/note/708968150/ DevOps Master课程总结：知否知否，应是DevOps肥ITIL瘦（送ITIL4前生今世）

https://www.douban.com/note/708218842/  DevOps Master课程总结：学习没有捷径（送DevOps安灯正确方法）

https://www.douban.com/note/694641377/ DevOps Master凤凰项目沙盘总结：DevOps黄金三步法

https://www.douban.com/note/700603657/ DevOps Master凤凰项目沙盘总结：履霜坚冰至，转型应自强不息

https://www.douban.com/note/693053178/ DevOps Master凤凰项目沙盘总结：通过DevOps实现IT组织转型

https://www.douban.com/note/689504940/ DevOps Master凤凰项目沙盘总结：DevOps起始质量之独孤九剑

https://www.douban.com/note/645016138/ DevOps凤凰沙盘：一场精益敏捷探索之行

https://www.douban.com/note/629890513/DevOps凤凰沙盘：一场百玩不厌的质量感悟

https://www.douban.com/note/630638887/DevOps课后总结之DevOps游戏系列-DevOps的独孤九剑

https://www.douban.com/note/637665261/DevOps Master课程:回忆我与DevOps之父Patrick的交流

https://www.douban.com/note/647732431/ DevOps：10本DevOps推荐书及47个DevOps兼容工具

https://www.douban.com/note/647732431/ DevOps：10本DevOps推荐书及47个DevOps兼容工具

https://book.douban.com/review/9110485/ DevOps：转型从正确地认知开始

https://www.douban.com/note/651734552/ DevOps：从I型人才到E型人才

https://www.douban.com/note/651734953/ DevOps：智能服务台是企业不能缺少的基石

https://book.douban.com/review/8928323/ DevOps布道师:终身学习是终身成长的源动力

https://book.douban.com/review/8820627/ 《把读到的知识转化为能力三步法及完美学习的四步法》

https://www.douban.com/note/643862694/ DevOps Master课程:脚踏实地学Pre-Master，一步一个脚印成为DevOps Master

https://book.douban.com/review/8805640/ DevOps布道师为深度工作写的序：深度工作是心身的一种修练方法

https://book.douban.com/review/8795275/ 咨询基本功：咨询顾问基本功之书面沟通及“补充大餐”

https://www.douban.com/note/643251358/ DevOps定义编年史：通过DevOps定义看DevOps发展

https://www.douban.com/note/637838681/ DevOps应用：光大银行DevOps1.0到DevOps2.0研讨会

https://www.douban.com/note/639093367/ DevOps应用：民生银行IT一体化管理与自动化发展（1）

https://www.douban.com/note/638965340/ DevOps应用：工商银行DevOps进行时

https://www.douban.com/note/696842302/ DevOps应用：工商银行DevOps进行时（2018年）

https://www.douban.com/note/641427886/ DevOps应用：DevSecOps云下安全与云等保（云博会内容提前曝光）

https://www.douban.com/note/646007197/ 敏捷辩论 

https://www.douban.com/note/655617439/ 敏捷服务管理：数字化转型核心

https://www.douban.com/note/696148785/ DevOps Master课程总结：IT运维的昨天、今天、明天（IT运维四大“坑”）

艾利·高德拉特  “在瓶颈之外的任何地方作出的改进都是假象，在瓶颈之后作出任何改进都是徒劳的，而在瓶颈之前作出的任何改进则只会导致瓶颈处堆积更多的库存。” 

【1】精益管理方法的术语

【2】高维度思考法

【附】高德拉特《目标》五个聚焦步骤：

第一步是确认约束点，直到确定那的确是整个部门层面的约束点，对非约束点的任何改进都只是幻觉，得不到实际任何价值；

第二步是利用约束点，寻找突破这些约束的办法，确保不让约束点浪费任何时间，永远不要让约束点迁就别的资源而干等着，而是应该专注于IT运维部对当前所需完成工作中优先级最高的那一项，一直都要这样；

第三步，使企业或部门的所有其它活动服从于第二步中提出的各种措施；

第四步，具体实施第二步中提出的措施，使第一步中找出的约束环节不再是整个部门的约束点；

第五步，回到步骤1，别让惰性成为约束，持续不断地改善；