如果你是DevOps的门外汉，不管是真汉子还是女汉子，希望这篇文章可以帮助你理解DevOps，掌握DevOps的主要知识点和实践。
龙门阵是四川话里聊天、唠嗑的意思，一群人坐在一起，喝着茶，天南海北的聊天。DevOps龙门阵会持续跟大家聊更多DevOps的话题，请大家多多关注。今天我们来聊DevOps门外汉须知，对于DevOps外行人或者站在门口的同学，你们需要了解的知识尽在其中。
先来一段闲话，最近我发现软件开发和去餐厅吃饭非常像，只是餐厅需要交付的不是软件，而是一桌菜，包含了前菜、主菜、甜点等等。拿去年很火的一部剧《好先生》来举个栗子：
吃饭的人就是用户； 点菜的服务员就是业务人员，负责收集用户需求进行分析； 主厨就是架构师，负责设计； 其他厨师就是研发，负责实现设计和用户需求； 试菜员就是测试，负责验证菜品是否符合标准要求； 上菜的服务员就是运维，负责将菜交付给最终用户，往往菜做的不好，做的慢，挨骂的总是上菜的人，因为运维是交付的最后环节，里用户最近，前序环节的问题都会累积到运维侧爆发。
餐厅做的好的地方在于：一道菜一道菜的上，要是等上一小时，一次性给你端一桌菜上来，而且是连桌子一起端，大家想想你的感受是啥？
好了，闲话完毕，我们今天重点聊三个话题：
- 我们正在经历的时代；
- DevOps是什么？如何理解？
- DevOps门外汉须知；
DevOps时代
为什么这么说？乐神 张乐老师分享过很多次VUCA，我们所面临的大环境就是易变的、不确定的、复杂的、模糊的。用户的需求很多时候是模糊和不确定的，在交付到用户手上之前，我们的软件和服务都存在着较大的风险。
同时我们这个时代正在经历最激烈的技术革命，开发流程、应用架构、部署和打包的环境、应用基础设施都在发生巨大的变化。PS：运维大神 赵班长说这张图让他睡不着觉，你呢？
尤其是技术架构，随着业务的发展，为了满足业务的要求和组织的复杂性，技术架构也在复杂化，面对右侧的架构，传统的开发方式、架构、基础设施都捉襟见肘。
下边这张图是2017年DevOps年度状态报告（高效运维和DevOps时代社区联合翻译中文版 ）中的数据：
报告中将IT组织分为：高效能IT组织、中等效能IT组织、低效能IT组织，如下数据就是高低效能IT组织之间的对比：
部署频率就是每天部署上线的次数，体现的是生产力，高效能IT组织高出46倍； 交付时间是指从代码提交到部署上线的时间，越短说明工程交付能力越强，高效能IT组织少出440倍； 变更失败率是指每次部署失败的比率，体现的是质量，高效能IT组织低出5倍； 故障恢复时间是指故障后的修复时间，也就是常说的MTTR，生产环境的每一分每一秒的宕机都是直接经济损失，高效能IT组织要快96倍；
DevOps是什么，如何理解？
说完背景，我们进入DevOps的主题，DevOps为什么会存在，DevOps的冲突来自哪儿？ 开发、测试团队和运维团队在思维、目标、KPI、技能、工具各个方面都是不一样的。
因为冲突的存在，DevOps之父Patrick作为IT工程师倍感沮丧，他在寻求使用敏捷的方式解决运维的问题，机缘巧合之下，举办了第一届DevOpsDays活动，并在Twitter上自发形成了DevOps运动，大家都在基于实践经验去解决开发与运维的协作问题。
在维基百科上概念是大家比较有共识的理解，很多人尝试诠释DevOps是什么？但是都不及这个概念精简。
我们一开始面对DevOps时就像盲人摸象一样，认为自动化就是DevOps、将看板运用到运维就是DevOps、DevOps需要开发去做运维、运维需要去做开发，这些理解都是片面或错误的。
我在学习DevOps的一开始认为，DevOps就是要解决最后一公里的交付问题，也就是从代码提交到发布上线的过程。
后来我从敏捷的思路去理解，DevOps可以说是敏捷的延伸，延伸到技术运营领域。每一次迭代都是开发、测试、运维协作完成，每个迭代都会有一次或多次发布上线。
后来，我参加高效运维社区的DevOps Master认证培训，对DevOps的知识体系有了更体系化的了解。
精益管理和TPS：是DevOps的基础理论支撑，包括持续改进、准时制、消除浪费、单件流等等。持续集成实践和TPS的安灯拉绳机制很类似； 敏捷管理：主要是敏捷开发的理论和实践； 持续交付：是DevOps最重要的工程实践，自动化的核心内容； IT服务管理：主要是讲究轻量级
DevOps是集大成者，它并不制造概念，它是讲很多理念和实践进行整合，打通端到端的过程，目标就一个服务业务，更快更好的交付业务。
DevOps门外汉须知
基于对DevOps的理解，我整理出了DevOps能力模型，包括如下五方面，后续的DevOps核心概念和实践参照这个思路给大家分享
敏捷研发
谈敏捷就一定会提敏捷宣言，我在学习敏捷的时候，老师说敏捷宣言最重要的一句话就是：我们一直在实践中探寻更好的软件开发方法。DevOps就是在探寻过程中逐渐演化出来，适合这个时代的软件开发方法。
下图是几种常见的敏捷开发方法：Scrum、XP和看板的关系
Scrum是最流行的敏捷开发方法，如下图是中国台湾精益和敏捷大师 李智桦老师的一张图看尽Scrum，大家可以详细研究，Scrum的重点内容：三种角色、四种会议、三种产物。
极限编程讲究的是工程与技术实践，尤其是对反馈的要求很高，持续集成、结对编程、重构、测试驱动开发等实践都来自XP，这张图代表了不同时间的反馈周期。
看板是Anderson在微软推行Scrum的过程中研究出来的一套方法，原本目的是为了更好的推行Scrum。李智桦老师有一篇文章专门说明了Kanban和Scrum的关系，应该结合使用。
如下这张图也是李智桦老师针对看板的六条规则，大家可以参考，对Kanban而言，识别出团队的工作流至关重要。DevOps Master认证培训里有一个《凤凰项目沙盘模拟实战》需要团队使用Kanban来改善交付节奏和控制产能。
持续交付
持续交付包括：配置管理、持续集成、自动化测试、代码质量、部署流水线等方面，大家可以参考图片和直播内容进行更详细的了解。后续龙门阵会更深入的为大家分享持续交付的内容。
持续集成的基础是配置管理，至少需要使用版本控制系统将代码和配置管理起来。然后使用类似Maven这样的工具标准化代码目录结构和依赖管理，之后才能实现自动化构建，进一步才能做到持续集成
测试三角形是比较经典的分析自动化测试的成本和效果的图，由于自动化的单元测试成本太高，一般和写生产代码的成本比例是1比1，甚至更多，所以发展出了叫自动化测试的橄榄球模型，UI和Unit测试少做，重点做接口级测试，目前这种做法也是大多数团队在实践的。
在配置管理、自动化构建、自动化测试的基础上，我们的持续集成才能使完成的，如下这是一个持续集成的测试，你可以问自己三个问题来判断你们的持续集成做的如何？
- 每个开发是否每天至少都向主干提交一次代码？
- 每次提交是否都触发自动化构建和测试？
- 如果构建和测试失败，是否可以在十分钟内修复？
根据我的经验，大部分团队都通过不了这三个问题的测试，但并不是说一定要这样，我在做DevOps的过程中有个原则：简单粗暴最有效！先解决问题，再完善。
持续交付的核心是要打造一条从代码提交的部署生产的流水线，就像车间里的流水线一样，更加高效和标准。
高效运维社区之前做过一个部署流水线的Demo，大家可以看看基于开源工具，我们是如何实现端到端的持续交付的。 关于持续交付，乐神 张乐老师的《持续交付的体系化方法》更详细的梳理了持续交付的框架，推荐大家仔细研读，有机会也可以到DevOpsDays或者GOPS大会听乐神的分享，面对面交流。
大家听了这么多概念，对DevOps、敏捷、持续集成、持续交付的关系一定有点懵懵懂懂，这张图可以帮助大家理解DevOps。
技术运营
关于运维，我并不专业，后续我们会在龙门阵专栏里持续要求运维的大神跟大家深度分享，我这里贴一张SRE的图，供大家参考
之前请教过我认识的一位运维总监，中小型运维团队能力建设顺序是：规范与标准—>监控—>自动化部署—>日志管理
组织文化
这是大神Martin Fowler博客里的一篇文章，深度介绍DevOps文化，这次不展开，后续龙门阵会跟大家详细解读，DevOps需要组织文化的改进才能最终落地，Netflix就是完全重新定义了自己的组织文化：自由与责任，他们的DevOps、产品创新、云原生应用、微服务都做的非常好。
根据我的经验，影响（改变）组织与文化的两大利器：实践与度量。
实践在落地和坚持可以让团队朝着我们希望的行为习惯改进。
度量更是可以改进团队的行为，度量要慎重，一旦开始考核，度量很容易变味道。体系化的度量框架也是非常重要的，据说乐神 张乐老师正在整理，希望能帮助到更多的组织实现DevOps转型。
可视化
可视化对团队了解现状，发现改进方向非常重要，可以分为：过程可视化、数据可视化。
实践分布地图
这张图比较复杂，让门外汉看会比较烧脑，仅供大家参考，在不同的能力领域，可以有很多的实践可以做，大家还可以去关注CNCF整理的工具分布图，有这么多实践和工具，DevOps落地不用愁。
