这几天有幸参加了高维社区组织的EXIN DevOps Master国际认证课程，有理论学习，有沙盘模拟，还有真实的考试，可谓紧张而充实，接触到的一些经验和理论，还是值得在实际工作中，借鉴以及落地。
DevOps这词儿不是最近，才开始流行起来，一些互联网巨头Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb，传统软件公司Adobe、IBM、Microsoft、SAP等，亦或是苹果、星巴克等都在采用DevOps或提供相关支持产品，国内则有各种互联网公司，甚至一些传统的企业，都在进行着各种实践，特别是Google SRE这本书引入之后，DevOps就像成为了标配，但实际上，对于DevOps，可能还有不少的误解，甚至炒作。
究竟什么是DevOps？
这问题有很多大牛的解释，官方专业的回答，各位可以自行google。
以下则是wiki对于DevOps的解释，可以看出，他强调了DevOps其实是一种软件工程的文化以及实践，目标就是统一“软件开发”，以及“软件维护”，DevOps不是一门单独的技术，旨在增强自动化以及监控整个软件创建的过程，从集成、测试、发布，到开发和基础设置管理，目标就是为了，缩短开发周期、提高部署频率和独立的发布，和商业目标能紧密结合。
DevOps (a clipped compound of "development" and "operations") is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.
如果从字面含义来看，DevOps是Development开发和Operation运维的缩写，但正如赵班长所说的，DevOps既不是开发运维，也不是运维开发，就是“开发”和“运维”，两者互不为对方的形容词，之所以这么说，我认为强调的是，开发和运维相互之间的融合，InfoQ上木环有篇文章，里面有张图片，很有意思，
以往开发和运维，如图中所说的，即使属于同一个部门，可能之间还是有堵墙，原因就是各自的目标不同，开发的目标就是，按照需求，按时按量完成开发任务，运维的目标则是，保障线上应用的稳定，从各自角度看，没有对错，但从整体来看，由于目标的不同，有时候就会形成矛盾，开发写出的代码，可能不具备“可运营性”，给运维设置各种各样的坑，运维则为了保证线上，给开发设置各种要求，”阻止“其进行各种危险的上线。但往往受限于业务的压力，不具备”可运营“的代码，依旧需要上线，随之带来的则是各种，故障-堵窟窿-背锅，矛盾更深。
对于开发和运维来说，实际的需求则是，开发想让自己的代码，尽快上线，而运维则想让自己维护的系统更加具备“可维护性”，从这一角度看，其实双方有一些共同点，开发在写代码的过程中，其实可以将一些运维的考虑加入系统设计当中，让其更具“可维护”，满足运维的基本需求，运维同样可以通过自动化，实现一些开发可以自服务、自诊断的工具，将运维要考虑的地方，封装起来，让开发人员使用，同时可以利用持续集成、自动化部署上线，一系列方法提高部署频率，满足业务和开发的需求。
某种意义上可以这么说，DevOps强调开发运维一体化，之前阿里曾为了全面践行DevOps，分拆整个应用运维团队，合并至每一个BU开发团队，从组织结构上，打通了开发和运维的关系。
当然不能说开发和运维，属于同一个部门，就一定是DevOps，就一定能是DevOps最佳实践，重要的是开发和运维，能否为了同一个目标，利用各种技术、工具，保证开发质量的前提下，高效、可靠、频繁地进行线上部署和运维，即实现软件产品交付过程中各环节和团队的打通，使得各个团队减少时间损耗，更加高效地协同工作。
DevOps涉及了不少知识体系，例如CI持续集成、持续开发、持续部署、配置管理，还有一些日本制造业，创造的工程思想，例如JKK质量检查、PDCA、KaiZen持续改善、Lean精益，同时包含一些文化理念，例如blameless免责，当然还要务实，技术上会包括微服务、云计算等，下面这张图形象描述了，DevOps做到极致，需要经历怎样的阶段，
只是务虚没意义，实现DevOps各环节技术栈一览，
(http://blog.csdn.net/FIRim/article/details/52681704)
版本控制&协作开发：GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar
自动化构建和测试：Apache Ant、Maven 、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit
持续集成&交付：Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go
容器平台：Docker、Rocket、Ubuntu（LXC）、第三方厂商如（AWS/阿里云）
配置管理：Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible
微服务平台：OpenShift、Cloud Foundry、Kubernetes、Mesosphere
服务开通：Puppet、Docker Swarm、Vagrant、Powershell、OpenStack Heat
日志管理：Logstash、CollectD、StatsD
监控，警告&分析：Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana
我们正利用业余时间，研发一套系统，我们为其起名”Sherlock”，旨在让开发人员可以自服务，涉及的领域业界有成熟产品，但要么是太贵，要么是具体实现有偏差，至少我们公司，目前在这一领域，没有先河，因此算作尝试，待机会成熟时，再向各位介绍。
回到这次培训，EXIN DevOps Master。其中EXIN，全称Exam Institute for Information Science，国际信息科学考试学会，由荷兰经济事务部创办，现今已经从荷兰政府部门独立成立了EXIN基金会。EXIN是一家面向全球ICT从业人员的中立认证考试机构。听着可能陌生，但提到著名的“全球IT服务管理最佳实践知识体系-ITIL”，可能就有不少人，比较了解，EXIN就是其最初的创始机构之一。
以下是EXIN官方对于DevOps Master介绍，
EXIN DevOps Master is an advanced-level certification that teaches candidates a combination of principles, knowledge and practical skills. This enables them to introduce and promote DevOps in their organization in order to better manage application and service lifecycles whilst facilitating collaborative teamwork.
简单来讲，就是围绕DevOps的知识体系，结合一些案例和最佳实践，进行整体宣讲，涉及的领域很广，从项目管理、开发、测试到运维，从Scrum、Lean、KanBan到JKK，理论结合实践，灌输DevOps的思想理念，以及文化，但这其中，不会涉及一些技术细节。
这是EXIN DevOps Master认证考试的介绍，
(https://www.exin.com/en/certifications/exin-devops-master-exam)
这次授课，是来自高维社区的三位牛人，做为讲师，第一天是业界著名的赵班长，从DevOps基础开始说起，介绍了整个DevOps理论体系，结合一些案例，让我们从感性到理性，对于DevOps有了认识。第二天则是景韵，做为敏捷教练，带着我们，进行了“凤凰项目”的沙盘模拟，可以说将DevOps理论，通过沙盘模拟，进行了一次落地的实践，加深我们对于DevOps中，一些理论的认识和应用。第三天是张乐，主要关注持续集成和流水线，经验也很丰富，理论和案例结合，让我们对于持续集成、DevOps理解有了新的体会和高度。另外，教务非常nice，无论是课程安排、午餐以及茶歇，非常到位，可以说和讲师们一起，践行了培训的"DevOps"，非常感谢所有人的付出。
对于DevOps，总结一下，强调了开发和运维人员，做为一个整体，消除以往的隔阂，为了同一个目标，协同工作，但能否真正落地，一方面要看公司的文化，以及战略，只有一腔热忱，制度上有限制，白搭，另一方面需要技术的实现，空有各种理念，技术上无法支持，自然只能空谈，用Linus Torvalds一句话解释，“Talk is cheap, show me the code.”。
如果您觉得此篇文章对您有帮助，欢迎关注微信公众号：bisal的个人杂货铺，您的支持是对我最大的鼓励！共同学习，共同进步:)
本文分享自微信公众号 - bisal的个人杂货铺（gh_e8769c7350b1）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
