DevOps Master凤凰项目沙盘总结：同理心是DevOps
作者：北京老李：DevOps布道师、IT管理咨询师。EXIN授权EXIN DevOps Master（大师级）讲师(首批全国十名) 、EXIN授权EXIN Agile /Lean IT 认证讲师、首批ITIL Expert讲师、PMP、Prince2专家级、EXIN云安全管理、ISO20000 LA、ISO27001 LA等多项认证。先后在北京、上海、广州等地主导软件开发、系统集成、咨询服务等工作，主要研究方向云安全管理、DevOps落地实施。
1.为什么需要DevOps
DevOps对于开发人员与运维人员来说是个好的整合，并且是可以加快软件交付的一种敏捷方法，并且被业内称之为敏捷2.0的管理方法。需要DevOps有如下几个常见理由：
1.改被动为主动。传统IT管理的问题在于被动式的服务，DevOps模式让开发人员和运维，和业务一起工作，通过敏捷2.0，可以主动服务，可以拉进业务与IT的距离。可以让运营过程的的灾难性事件在用户发现之前已经就可以通过自动化、智能化发现，通过主动监控实现主动式管理。
2.质量前置（左移）。传统的软件一旦被部署，软件就会扔给测试及运维，通过质量前置，DOD的应用，在DevOps模式下，编写的即是可以发布的的软件及服务。让开发人员、运信人员可以一起保证软件的质量，而不是在完成软件以后。
3.交付一个IT价值流。开发人员与运维人员往往在很多企业是孤立的，当出现这样问题或那样的问题时，往往很多单位会找“临时工”。在DevOps模式中，可以把开发、测试、运维串连在一起，通过不断地软件交付，实现生产环境的快速业务价值交付。
2.DevOps与同理心？
同理心来自于《Effective DevOps》，也在《敏捷开发》中提及，同理心是指IT人员，应站在当事人的角度和位置上，客观地理解当事人的内心感受，并且把这种理解传达给当事人的一种沟通交流方式。同理心就是将心比心，同样时间、地点、事件，而当事人换成自己，也就是设身处地去感受、去体谅他人。
同理心减少争吵，同理心赢得共同成长
DevOps之父 Patrick 曾经说过DevOps的成功的关键在于人。北京老李总结：同理心DevOps成功关键，正是因为有了同理心才有了人与人之间的交流，团队与团队之间的交流，职能与职能之间的交流。
3.同理心的原则
站在DevOps的角度上通过同理心能够实现业务、开发、测试、运维的理解对方，并且能够提出切实可行的产品，以核心业务价值观驱动业务，而不是“锦上添花”，做一些没有用的产品或特性。同理心需要遵从同理心的原则即：
1.我怎么对待别人，别人就怎么对待我。
2.想他人理解我，就要首先理解他人。将心比心，才会被人理解。
3.别人眼中的自己，才是真正存在的自己。学会以别人的角度看问题，并据此改进自己在他们眼中的形象。
4.只能修正自己，不能修正别人。想成功地与人相处，让别人尊重自己的想法，惟有先改变自己。
5.真诚坦白的人，才是值得信任的人。
6.真情流露的人，才能得到真情回报。
同理心地图：让在别人的角度去倾听与思考
4.DevOps的核心可以用沙盘来体验
很多组织发现他们面临这样的挑战，即要求快速发布又要求及时响应。及时响应用户需求是每个软件开发团队的目标，但是这样会给组织内的特性团队造成压力。
DevOps正是解决组织面临VUCA时代解决方案。通过构建一种开发和运营（这就是DevOps名字的由来）之间合谐关系来解决问题。
DevOps整合了IT治理COBIT、IT敏捷（Scrum)Agile、IT服务管理（ITIL）、精益方法，強调的高价值识别与高价值产出，并通过【持续交付】快速交付软件及服务，同时要求企业、团队，建立学习型文化的组织，不断地优化，并进行事后剖析（PIR）。剖析的目的不是找人背锅[DevOps handbook]，强调blamelessness[Effective DevOps]，让成员专注于分析细节。此外，DevOps利用大事拆小、小事频发的方法，减少风险，把变化习以为常[DevOps handbook]、【Google SRE】。 DevOps不是一系列工具，而是一种团队文化和团队价值观。通过凤凰项目DevOps沙盘，可以让您亲身体会到这一核心价值观。
北京老李：凤凰项目沙盘实践课程
通过DevOps凤凰项目沙盘以后我们感受到DevOps核心价值在于试图打破这个职能墙。把开发运维团队协作起来，DevOps系统地看待IT价值，关注最终用户的体验，快速交付，通过自动化与智能化，实现业务的价值。DevOps并不是新的工具或组织，而是新的文化和流程。它是开发，质量以及运营相互工作来加快开发和解决问题。
5.通过凤凰项目可以让我们实践的实践有：
实践1：利益相关者的积极参与
DevOps的根本原则是开发人员,运营人员以及支持人员必须定期紧密的工作在一起。言外之意是他们必须互相视对方为重要的利益相关人，并积极争取一起工作。敏捷社区中一个普遍的实践是“现场客户”。这个实践出自于【极限编程】，它鼓励开发人员应该与业务人员紧密合作。规范的敏捷团队将该实践更进一步，即利益相关的积极参与，这意味着开发人员应该与所有利益相关者一起紧密工作，包括运营人员及支持人员，而不仅仅是业务人员。这是双向的：运营人员和支持人员也必须愿意和开发人员紧密工作。
通过凤凰项目沙盘可以让开发、运营、业务协作在一起。
实践2：集成配置管理
要实现以集成的方式来进行配置管理（CM），开发团队不仅要习惯于在解决方案层级应用CM，还需要考虑自身的解决方案与组织的其余基础设施之间的 产品环境配置问题。对于一些开发人员而言这是个不小的转变，因为他们往往习惯于只考虑当前他们工作的解决方案的CM。在DevOps环境中，开发人员需要拥有企业级视角，在更高的层次看待问题。他们的解决方案如何能在产品环境结合其它资源带来优势？其它资源是否能支持被开发的解决方案？言外之意是开发团队需要了解及管理他们产品的所有范围的依赖。集成配置管理也使得运营人员了解新的发布潜在的影响，从而更容易决定进行发布的时间。
通过凤凰项目沙盘可以让理解配置管理对于IT运营的重要性。而不仅仅是IT运维。
实践3：综合变更管理
从IT的角度来看，变更管理是一门确保IT基础设施的演化能对整体组织的支持成功及有意义的艺术。但是对于项目-团队层级则颇具挑战。这是因为非常多的技术，甚至相似技术的多个版本会被使用在单个解决方案的开发过程中。由于DevOps引入了与运营有关的企业级问题，综合变更管理策略会变得越来越复杂，因为需要考虑大量的解决方案能够在产品环境中同时运行和交互。为了实现综合变更管理，开发团队必须与运营团队紧密合作，来从组织层面了解任何技术的改变带来的影响。该方式依赖于前面的实践-利益相关者的积极参与，集成配置管理及自动化测试。
通过凤凰项目沙盘可以让理解快速变更管理的价值与意义。
实践4：集成部署计划
从开发团队角度而言，部署计划总是需要与该组织的运营人员交互。有些情况下，与运营人员接口的专家被特称为发布工程师。经验丰富的团队将使开发，运营及支持团队这些利益相关者一起持续的制定部署计划。当你采用了DevOps策略，你会很快意识到需要一种跨团队的方式来完成发布计划，因为需要运营人员与整个开发团队一起工作。对于运营人员来说这不是什么新鲜事，但是对于只习惯工作于孤立环境的开发团队来说却很惊奇。如果你的团队还没有这样做，你需要开始从组织层面来考虑部署时间表。更远一步，为了支持持续部署，发布工程师需要增加发布次数，因为敏捷团队已经可以持续及一致地达到发布的质量要求。
通过凤凰项目沙盘可以让学员理解发布路线图、敏捷发布的价值
实践5：持续部署
持续部署是持续集成实践的扩展。对于持续部署，当集成在一个沙盒中成功完成时，变更会被自动升迁到另一个沙盒中，集成会自动的在这里进行。自动升迁一直持续，直到有人验证了所有的变更，特别是开发向运营的过渡期。
持续部署使得开发团队减少了新功能从被验证到部署到产品环境的时间，使得业务更具响应性。然而，持续部署增加了运营风险，因为如果开发团队没严格遵守规范，会增加缺陷被引入到产品环境的潜在风险。在企业级环境中成功的执行持续部署要求实现前面介绍的所有实践。
通过凤凰项目沙盘可以让学员理解持续部署对于业务的价值
实践6：产品支持
企业级环境中，大多数的应用程序开发团队工作在已经存在于产品环境的解决方案的新的功能上。他们不仅工作于该新功能，还有解决严重的产品问题的职责。开发团队往往被称为产品的“第3级支持”，因为他们是解决棘手的产品问题的第三个（也是最后一个）团队。尽管做第三级产品支持的需要是普遍的，但是看板和规范敏捷交付（Disciplined Agile Delivery， DAD）则是例外，很多敏捷方法只解决传递这些影响。该实践的一个重要的副作用是给予了开发者发生在产品中的此类问题的鉴别能力，提供给他们一种学习机会，从而在设计解决方案时就考虑到相应的问题。
通过凤凰项目沙盘可以让学员理解通过产品支持，近而优化与改进产品或软件
实践7：应用监控
正如其名称所示，这是一个运营实践，监控已经发布到产品的环境的正在运行的解决方案和应用程序。技术基础设施平台（比如操作系统），应用程序服务器，以及通讯服务通常提供监控功能，可以工作于一些监控工具（比如微软管理终端，IBM Tivoli 监控， 以及jManage）。然而，为了监控特定应用程序的功能，比如只给特定用户使用的用户界面，仪表化该信息需要与你组织的监控基础设施兼容，这需要构建到应用程序中。开发团队需要知道该运营要求，或者，更好的方式是可以访问一个框架，该框架可以直接提供相应的仪表化。
通过凤凰项目沙盘可以让学员理解通过看板的新形管理方法
实践8：敏捷的仪表盘管理
使用自动化仪表盘的实践是IT领域的商业智能（business intelligence， BI）。该实践分为两个方面,开发智能以及运营智能。开发智能需要使用开发工具来仪表化产生的指标。例如，你的配置管理（CM）工具已经记录了谁以及什么时候迁入代码。持续集成工具可能同样记录了构建发生的时间，运行了多少个测试，测试运行的时间，构建是成功还是失败，运行成功的测试数量等。这些原始数据会被分析并显示在一个自动化的仪表盘中。运营智能是之前讨论过的应用程序监控的一个方面。使用了自动化仪表盘，组织的整体指标开销将被显著降低（但是不能完全淘汰，因为不是所有的事情都能被自动化）。自动化仪表盘提供了实时的对组织的管理团队的洞察。
通过凤凰项目沙盘可以让学员理解敏捷图形化管理的价值
6。通过凤凰项目应建立的什么样的DevOps文化
同理心是一种团队精神。培养团队精神应从同理心开始。社会生活中人与人相处最重要的是诚信，有同理心，互利。结对编程中大家会出现分歧，如何更有效地合作要做到对事不对人，只有建立了企业文化，才能实现DevOps精神，而不仅仅是工具
同理心是一种文化
团队、组织或公司需要营造一种利于构建学习型组织的无问责文化。 devops强调无问责文化，因为只有充分了解事情是如何发生的，才能真正开始学习。这里的两个关键点分别是：无问责文化、学习型组织都应建立在同理心上。
DevOps应该是先有学习型组织的概念，后有无问责文化的概念。DevOps从学习型组织说起，想要得到提升，成功与失败的经验或教训是最好的老师，自然地，学习型DevOps组织更容易获得成功，
北京老李：凤凰项目沙盘实践:过程是痛苦的，结果是满意的
通过凤凰项目沙盘让我们学习到，DevOps中强调与定期回顾、事后分析类似的组织性的学习行为。但如果团队或组织中充满问责文化，那么这类组织性学习所取得的效果不如在无问责文化的环境中取得的效果，因为人们在后者中，由于没有担心被问责、惩罚的心理压力，更容易自然地、开诚布公地说明有关情况。devops是真正强调的应该是持续不断的学习。无问责是为了提供一个有利于个人、团队、与组织都持续不断地学习，成长的环境。
欢迎爬楼，看更多北京老李-DevOps相关内容，ITIL内容请关注”豆列“
DevOps凤凰项目沙盘：IT涅槃重生之路 https://www.douban.com/note/681066663/
https://www.douban.com/note/645016138/ DevOps凤凰沙盘：一场精益敏捷探索之行
https://www.douban.com/note/629890513/ DevOps凤凰沙盘：一场百玩不厌的质量感悟
https://www.douban.com/note/685272342/ DevOps Master课程：Google SRE系列之SRE概述
https://www.douban.com/note/636259649/ ITIL飞机运营模拟沙盘游戏
https://www.douban.com/note/661156795/ ITIL沙盘：从运维到运营之路
https://www.douban.com/note/630638887/ DevOps课后总结之DevOps游戏系列-DevOps的独孤九剑
https://www.douban.com/note/660291760/ DevOps Master：如何一次通过DevOps Master考试
https://www.douban.com/note/647732431/ DevOps：10本DevOps推荐书及47个DevOps兼容工具
https://www.douban.com/note/637665261/ DevOps Master课程:回忆我与DevOps之父Patrick的交流
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/641427886/ DevOps应用：DevSecOps云下安全与云等保（云博会内容提前曝光）
https://www.douban.com/note/646007197/ 敏捷辩论
https://www.douban.com/note/655617439/ 敏捷服务管理：数字化转型核心
彩蛋：2018年DevOps推荐十本书
1.ThePhoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
Gene Kim ， Kevin Behr ， George Spafford
本书于 2013 年出版，受前一本书影响：它讲述了一个汽车零部件公司的 IT 经理 Bill ，接手一个全新的 IT 首创代码工程叫做 Phoenix ，然而这个项目已经严重超支和超时。就如同前本书的主角 Alex 一样， Bill 也必须在 90 天内解决问题，否则他的整个部门将会被外包。他学习到 IT 在制造业工厂的工程中有很多共性，弄清楚了如何组织工作流，让各个部门之间流线型通信，提升 IT 运维效率。
2. TheDevOps Handbook: How to Create World-Class Agility, Reliability, and Securityin Technology
Gene Kim ， Patrick Debois ， John Willis ， Jez Humble
DevOps 手册建立在 Phoenix 项目概述的课程之上，充当了企业实践 DevOps 解决方案的操作指南。本书包括来自 Google 、 Amazon 、 Target 、 Netflix 和其他公司的案例研究，证明 DevOps 实践有利于提升企业的业绩。它为 IT 管理者提供了一系列技巧，让他们能够将产品经理，开发人员， QA ， IT 运维和信息安全人员整合在一起，从而使公司更加成功、具有竞争力。
3.Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling atScale
Jennifer Davis&Katherine Daniels
《高效 DevOps 》是一本覆盖一系列 DevOps 技能和理论的实用手册，包括对工作流各种基础概念的介绍。作者为提升团队内部合作、跨团队之间的联系、选择正确的工具和工作流、以及高效实践提供了多种不同的方法途径。
4.Continuous Delivery: Reliable Software Releases through Build, Test, andDeployment Automation
Jez Humble&David Farley
本书获得了 2011 年的优秀震撼大奖，它阐述了企业如何将想法快速可靠地实现。作者列举了将软件快速发布交付用户的种种原则和技术实践，提供了在自动化、部署、测试和提升开发测试运维团队之间合作的许多技巧。同时也介绍了自动化基础设施管理、数据迁移、虚拟化等技术。
5.Implementing Lean Software Development: From Concept to Cash
Mary Poppendieck&Tom Poppendieck
2006 年的这本《实现精益软件开发》是作者 2003 年精益软件开发的后续，介绍了利用“ Lean ”原则实现快速交付价值。本书指引读者实现精益软件开发，包括设法达成利用敏捷实践，创建开发团队，以及通过快速反馈驱动质量提高，也包含了软件公司的许多案例研究。
6. ThePrinciples of Product Development Flow: Second Generation Lean ProductDevelopment
Donald G. Reinertsen
2009 年， Reinertsen 在本书中断言，目前管理产品开发的主流模型是完全错误的。他解释了为什么无形的非管理队列是产品开发表现糟糕的根源，并提供了改变和提供效率的指引。 Reinertsen 在精益生产中提取原则的同时，也合并了电信网络、运输系统、计算机操作系统、军事系统等诸多想法，提出了改善商业决策、加速反馈和管理流的方法。
7. TheDevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline withContainerized Microservices
Viktor Farcic
《 DevOps 工具箱 2.0 》于 2016 年出版，阐述了最新的高效软件架构技术，微服务中的容器向服务器持续地进行测试和部署。 Farcic 也解释了微服务使用例如 Docker 、 Kubernetes 、 Ansible 、 Ubuntu 、 Consul 和 Registrator 等工具和技术进行开发和部署的生命周期。本书提供的理论知识对于企业的 DevOps 实践非常有帮助。
8.Leading the Transformation: Applying Agile and DevOps Principles at Scale
Gary Gruver&Tommy Mouser
在多个行业中，软件变得越来越重要，许多技术高管们争相改造老旧系统和生产过程，向能够快速交付大型软件项目的 DevOps 和敏捷原则进行规模扩展。本书出版于 2015 年，作为管理层的一本指南，提供了一个让企业关注改善开发和交付、尤其是跨团队的协调工作的框架。
9. TheGoal: A Process of Ongoing Improvement
Eliyahu M. Goldratt&Jeff Cox
本书前言就很不同寻常：这是一本关于工业管理的惊险小说，关于 DevOps 的早期预言。 1984 年， Goldratt 和 Cox 虚构了一个工厂经理 Alex Rogo ，他必须想方设法在 90 天内改善工厂的业绩，否则工厂将要倒闭，数百员工将失去工作。和同事一起， Rogo 试着以一种非传统的方式来解决工厂困境。
在 DevOps 这个词还未诞生之时，这本书已经出版，故事阐述了商业顾问 Goldratt 的约束理论，表明管理者必须明确过程中影响业绩的瓶颈，努力去解决它们然后提高生产效率。这本小说如今在无数的大学和商学院作为教科书使用。
10.Practical DevOps
Joakim Verona
《 DevOps 实践》，出版于 2016 年，是一本关于 DevOps 、持续交付、以及它们如何影响架构的初级读本。本书帮助读者熟悉提高 DevOps 效率的各种工具，教会他们利用 DevOps 实践设计一个适合持续部署系统的应用软件。同时它引导读者高效存储和管理代码，例如使用 Git ， Gerrit 和 Gitlab ，然后进行代码的测试、部署和监控。
推荐书目作者： Alison DeNisco 原文链接： http://www.techrepublic.com/article/10-books-to-add-to-your-devops-reading-list/#ftag=MSF8469b3d
