如何从高层把握住DevOps的实质
DevOps是一个大杂汇，把近十多年来的多项技术和变革都涵盖进来了。
DevOps涵盖开发和运维的一系列技术、方法和理念，并尽可能让一切过程自动化、敏捷化、简单化。
DevOps最致力解决的，是把从业务需求到持续运行的全过程中各种琐事、杂事、难题的尽量地简化、顺畅化和自动处理。
它采用了一系列技术，如敏捷开发、分布式、微服务、版本控制、IaaS、PaaS、docker、配置管理、故障自愈、智能分析、AI协助（ChatOps）等。
它提倡一系列理念，如MVP、迭代、一键化、一切皆代码（包括基础设施，也即软件定义一切）、持续优化、以用户为中心（拥抱变化、持续交付、体验至上）等。
它在组织架构上和团队文化上采用了一些列敏捷化的方法，如看板、全栈团队、自助服务、高度透明、岗位轮换、特性团队（跨职能的完整团队）等。
它通过采用聪明的技术（大多是软件技术）和方法（大多是敏捷方法），摆脱掉以往让人头疼的繁文缛节、无聊操作、手忙脚乱、难以控制、部门隔阂，让开发人员和运维人员可以更轻松更有趣的从事工作。
前面多次提到敏捷，这里有必要再延伸解读一下。
以下是敏捷方法的精要：
变化（尤其是需求的变化）是不断发生的，没有谁一开始就能想到最后，不要排斥变化，更不要试图固化需求（比如让客户盖章确认）。
关键是对于任何变化，能够很快很好的应对，锻炼出一种迅速响应变化的能力。
一个项目相关的一帮人要坐在一块，比如需求人员、开发人员、运维人员、客服人员坐在一起，有一个用户打电话给客服抱怨一个功能bug，需求人员立刻就听到了，开发人员立刻把bug就改了，运维人员立刻就将其发布了，客户立刻就满意了，这就是敏捷的。这个团队就是一个跨职能的特性团队（Feature Team）。
尽管粗糙一些，先尽早先拿出一个可运行的解决方案（比如先做一个MVP），然后再不断优化，这样的好处是尽早地建立起自信，尽早地得到激励，然后再逐步完善、细化、精益求精。这让人在整体上会一直保持着一个健康和振奋的精神。Thompson只用了两周就把UNIX主体写出来了，Linus只用了一个暑假（虽然这个暑假放了好几个月）就把Linux的0.01版写出来了，同样地，他只用了10天就把git第一版从无到有写出来了。
要激发知识工作者（knowledge workers）的能动性，并给他们提供安静而便捷的工作环境，知识工作者需要较长时间、较为安静的全情投入，这样的效率和产出都最佳，对他们要尽量少一些打扰和打断；要让他们的工作尽量便利一些，尽量减少低效的协作和迟迟没有反馈的等待。
虽然工程师们倾向于用邮件和IM工具交流，但面对面交流仍然是不可少的，而且在效率和效果上都是最好的。在最重要的事上，要采用面对面交流，但要精简，不要滥用，不要频繁，否则就是打扰。
要尽量保持简单，要尽量精简工作（砍掉那些对目标缺乏价值的事），在每个层次上保持内部模块的清晰和对外接口的简单（在各个层次隐藏和屏蔽其复杂性），这样你面对的麻烦会急剧减少。要让你的客户觉得简单，要让你的上下游同事觉得简单，还要让你自己觉得在分析和处理一个事物的不同层次不同模块时觉得简单。
在团队内部定期思考如何变得更有效，并修正及优化自身的行为。要尽量考虑让一切健康、可控、顺畅，而且关键是要让人心情舒畅。
我们的总的目标，是及早交付、并持续不断交付有价值的内容，使客户满意。
DevOps，则是要让我们IT工作者自己满意，或者说我们也要给自己人提供服务，也要享用自己人提供的服务。
2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》传递给世界，同时即宣告了敏捷开发运动的开始：“我们正在发现更好的方法以开发软件，通过这样做和帮助他人这样做。通过这项工作，我们可以获得以下价值：个体与交互重于过程和工具；有效的软件重于完整的文档；客户合作重于合同谈判；响应变更重于遵循计划；也就是说，虽然有价值的条目在右边，但我们更重视条目的左边。”
参考文献：
1、到底该如何理解DevOps这个词：https://www.cnblogs.com/yibutian/p/9561657.html
2、敏捷开发宣言：http://www.scrumcn.com/agile/scrum-knowledge-library/agile-development.html#tab-id-2