本帖最后由 adminlily 于 2018-9-22 11:06 编辑
本文内容包括：
1. DevOps 起源
2. DevOps 切入点
3. DevOps 四大改进方向
4. DevOps 八个实践场景
5. DevOps 实施五大级别
6. DevOps 五个常见问题
7. DevOps 20个实践点
序：听教父讲DevOps起源的故事
你们记不记得这个游戏，这是一款很老的电子游戏，将这个球会从左边扔到右边，这是我当初想到 DevOpsDays 的时候，我可能需要Dev一点东西，Ops 一点东西。
下边这个图给我的感觉，就是我最初做 DevOpsDays 的时候，开发人员和运维人员之间总是相互不满意，相互指责，在一个公司里有很多矛盾。
然后我们开始做敏捷，敏捷给人的感觉很好，变得更加有生产力，我们工作更加的出色，大家都非常高兴。
ITIL 我们也在用，ITIL 在运维里给了我们很多的条条框框，很多的规则来遵循。
我之前是做运维的，大家看到有很多烟在冒（如下图所示），有很多的问题：Agile 大家觉得很高兴，ITIL 给我们很多原则、条款，但是，
我们在运维这块还面临很多问题。
在2008年的时候我写了一篇论文，当时我们说到在一个运维团队当中用看板，我开始在这些东西上面进行一些试验。
与此同时，Flickr 也有人做了一个演讲，当时2008、2009年的时候他们说每天做10次部署，然后有人说这个想法很疯狂，然后问他们怎么做得到，下图就是他们的秘密所在。
Flickr 把开发和运维人员放在一起，让他们相亲相爱，他们不再对彼此指手划脚、指责对方，他们一起工作。
当我把这件事解释给我的孩子们听，他们说这个有什么可奇怪的，大人教导我们小孩子在教室里面要跟小朋友玩在一起，但是你们工作却不在一起，本来就应该大家坐在一起工作嘛。
之后我们在一些活动当中引入精益理念和端到端流程，我们用敏捷来让我们的进程变得更快。你可以看到这里有很多的原则和实践，但是都没有运维什么事儿。
所以我们最终决定发起这个 DevOpsDays 的运动。
1、Patrick 亲述 DevOps 切入点
我们有开发、测试和QA，然后是生产环境，从终端用户那边获取反馈，之后反馈流转到项目中，这就形成了一个循环。 这中间有一道高墙（部门墙）。我们需要让信息流动的更快来打破这道墙，获得更多的反馈。
1.1 怎么落地DevOps？
我们不仅仅是来优化开发这部分，也不仅仅优化生产部分，我们要怎么做？在整个系统当中找到瓶颈所在，找到方法来解决它，而不仅仅做一个局部的优化。
图中上边是技术问题，下边则是人的问题，比如说人们之间不合作，有人不喜欢他的工作，这是人方面的问题。通常会分为这两方面的瓶颈。
1.2 DevOps从什么地方开始？
从任何一个地方开始都可以。我没有办法说你的公司的瓶颈是什么样的，你只有自己去找到瓶颈所在。
2、DevOps四大改进方向
当你的公司刚开始走上DevOps道路的时候，你可以找到四个部分进行改进。
1）端到端交付
第一部分更多谈论流水线，持续集成，持续交付，更快投入生产。
2）持续反馈
第二部分强调更多的反馈，让生产环境中的信息以及终端用户的信息反馈到项目组当中，也就是一个反馈回路。
3）开发向运维
第三部分关注将项目研发知识传递到运维领域，在第一个部分中我们需要很多的技术，比如说自动化工具等等，当这部分变得成熟的时候，我们就开始将更多的知识、更多的流程放在里面。
比如说有一个人他发布了一个新的软件，他自然成为第一个月的运维人员，通过这一个月的时间，他可以更好地了解到运维人员的痛点，能够感同身受的知道他们的痛苦所在。
4）运维向开发
第四部分关于将运维知识传递到项目开发环节，一旦我们部署到了生产环境中，我们就是知道终端用户的反馈，知道下一步应该做什么新的特性。
3、DevOps实践场景3.1 配置管理
我看到有很多运维人员首先开始做配置管理，他们有很多的工具，能够让服务交付更快，加快工作的进度。
做配置管理的时候，我们在开发和测试方面也要用同样的方式，这不仅仅涉及到我们的服务器，而且涉及到我们是否可以实现一个跨环境的运作。开发人员可以以代码的方式定义基础设施。
3.2 环境管理
另外一个例子，要可以重复创建各种环境，我们现在有相关的技术，开发组可以重新创建出相关的一套设施。
3.3 监控与度量
接下来是监测，通常是由运维人员来做，但是他们不会和开发人员来交流观察到的信息，或者说通常也很难能够让这些开发人员拿到相关评测的信息。
如果我们能够让开发和运维的人员在一起工作，不仅可以让这个数据对运维人员了然于心，所有人都可以拿到这个数据，它会变得更有价值。
3.4 On-Call
让开发人员和运维人员都实时值班，可以让他们更好的感受痛点。
3.5 Chaos-Monkey
“创造混乱的猴子”的概念里，我们假设事情会出问题，用这样一个假设的情景是为了让我们改变思维，我们总是假设一切都是完美的，不会出现任何问题。现在用这个工具，我们假设事情一定会出现必然的某种问题，那么我们怎么样可以来解决它。
这个猴子可以用随机的方式来让某一个环节彻底崩溃，这个时候我们就需要知道我们用什么方法能够进行补救和修正。
如果我们进行更多的相关练习，系统会变得更加可靠。如果我们缺乏这种练习，一旦现实的工作当中出现崩溃，我们将很难加以应付。
3.6 ChatOps
你们听说过ChatOps吗？好像不是很多。大家都用手机聊天，原理就是你和人们聊天，但是在这个概念当中，在聊天室里面，所有技术的信息都包含进来，当我们进行了一次部署这里面会出现相关的信息，如果有人提交了一段代码，聊天室里的人也都会知道。
我们在部署服务器的时候会说我们要发布一个新的版本，我们把它都放到聊天室里面，这里面很好的一个部分是所有东西都有一个聊天记录，它不是一个把任何人排除在外的过程，所有人都是局内人，我们可以通过对话的方式在团队里形成一个很好的氛围。
3.7 事故分析
接下来是做事故分析，我们在发生某一个问题之后研究为什么会出现这样的问题，做一个分析，我跟我的同事说，有的时候出现一个问题我会不高兴，但我绝对不会指责你。
我实际真想知道的是如何来改进，这点更重要，这点也是我们能够更好服务客户的根本。我们做一个产品，没有办法保证产品不会出现任何问题，我们能够做成的是可以尽我们最大的努力在最短时间内解决出现的问题。
然后我们发现我们的客户也非常乐于接受这样的方式，他们能够看到我们真正是在努力，能够为他们提供更好的产品，能够提供更好及时的服务，这点也是我们一个可以考虑的方式。
3.8 游戏日
还有游戏日，有的时候我们会和整个公司进行沟通，大家可以共同总结一下整个系统之内出现哪些问题，我们可以对这些出现的问题状况来进行记录，
我们来看自己的系统如何能够通过 DevOps 得到更好的提升，DevOps 其实是让整个生产流程变得更加流畅，形成一个闭环，逐步为我们提升企业的实力。
4.1 个人级别——一马当先
大家可能玩过这个游戏，DevOps 可以是个人，比如说像我这样。但是个人可能还没有办法做到完全自动化的方式，可能要找其他人加入，找一些有共同想法的人加入，将各自的技能放在一起。
我会问他你怎么样使用你的技能，你怎么样与别人分享你的信息。这就是我们作为个人级别来实施 DevOps。
4.2 团队级别——人多力量大
作为一个团队，比如说我们有一个发展的策略，我们的团队可以和其他的机构来进行合作，这是一个团队层面的 DevOps 的案例。
4.3 IT组织级别——化敌共存
其实现在已经看到了运维人和开发人他们之间其实以前是有堵部门墙的，有一个筒仓的概念，但是现在通过 DevOps，跨越筒仓，我们能够更好的让他们合作在一起。
4.4 业务组织级别——众人拾柴火焰高
我们要有非常好的技术，但是一定要有一个业务的视角来看待这些事情，不仅仅是局限于技术层面。
4.5 跨越组织级别——达者兼善天下
之前我们听过很多 DevOps 可以用到的工具和技术，非常包容。但是我们指的并不仅仅是这些工具，工具可以让我们工作更快，但是更好的思维方式可以让我们更好的工作，这是一定的。
5、DevOps实施常见问题1）我该如何开始？
第一个问题，大家经常问的是我怎么开始的，我会给大家讲我是做了这件、那件或者是另外的事情，就做到了现在这样。
1. 和其他的转型没有太大的区别
2. 不要花费太多的时间在反对者身上，专注于寻找志同道合的盟友
3. 不要过于自负，要寻求管理支持，个人影响力有限，我们要与管理层进行非常好的合作
4. 选一个小的项目并达成目标，成功最建立信心和信任的最佳方式。
5. 要选的第一件事情是一个大家都比较关注的痛点，做一些有意义的事情，但是一定要比较小，这样你自己就可以用有限的资源完成。这会提示大家改变的意愿
6. 开始动手做，不需要做过多的解释，动手做就可以了。
7. 做了再说
8. 做出成果之后要及时沟通，可以有效建立信任
9. 度量改进效果
10. 持续改进
英语里面表达的方式是先做再去求原谅，可能听起来有一点奇怪，其实我们最终的目的就是想把工作做好，如果说我们有理由将我们的工作做得更好，没有人可以对你有任何的非议。
特别是在一开始的时候，人们总会说我们真的能做到吗，因为在过去，我们可能会去找很多人来进行这样的一些沟通，会有很多的人来组织我们做这件事情。
但是不管他们怎么说，我觉得还是有价值有必要去尝试一下，一旦取得成功以后，再去找之前沟通过的一些人，比如说现在这件事情已经做成功了，然后跟他们讲我现在需要你更多的帮助。
对于发展、提高，现在对于提高，我们不要很笼统把它称为确实比以前好一些，要有实际的能够量化的能够测量的进展和提高，
如果仅仅跟人家说我们现在变得更好了，可能没有人相信你。再有是可追溯性。要有一个独立的 DevOps 团队，个人可以做 DevOps，团队可以做DevOps，其实并不重要，如果仅仅是想一个小的团队开始做一件小的事情，可以把它叫 DevOps 团队。
最开始做的时候，它是一个很小的团队，我相信这是一个渐变的过程。过了一些时间以后，相信大家对 DevOps 都有自己不同的思维方式和理解，可以是一个自动化的团队，也可以是 DevOps 的团队，特别是对公司来讲，每个人都要有 DevOps 这样的思维方式。
2）我们应该设置独立的DevOps团队吗？
当你拥有一个专门的 DevOps 团队，那么你做错了，而且DevOps也不应该是一个岗位。但是临时存在的 DevOps 推进小组是合理的。
3）如何衡量DevOps的效果
让成果可衡量、可测量。如果说人们不相信合作会获得更多的资源，我们一定要主动去相信我们通过更多的合作能够获得更好的结果。
如果是在聚会的时候，我们讲很多的话，健谈，这样你可能会没有办法享受一个聚会，但是你的个人关系和周围参加聚会的人可能会获得比较好的推进。
我们也要看到合作是一种好的选择，但是合作并不代表一定能给你带来更好的更多的资源。
4）DevOps宣言是什么？
我其实还没有写下真正 DevOps 的宣言是什么样的，我们现在刚刚开始做，但是我们已经取得了一些成绩。对于我个人来讲，我不需要什么样的宣言。
5）DevOps和ITIL的关系？DevOps追求协作，ITIL中导致官僚主义和抵触变化的内容应该避免。
还有另外一个问题，ITIL 合作是什么样的状态，如果有些人知道 ITIL，刚开始使用这项工具，大家知道 ITIL 是一个什么样的工具。如果大家关注 ITIL，它其实是很有价值的。
其实现在有很多的资源和工具可以使用的，而且我们也很关注持续的提升和改进。我昨天提到的 CMDB 自动化，现在很广泛，它已经深入了我们很多的环境里面，这项工具可以让我们更好地跟进这个市场。
现在关注的是人的问题，我还没有提到这些，其实我们更应该关注信任，如果不相信其他的团队，可能你就失去了了解他们的机会。 了解他们，与他们合作在一起，逐渐建立信任，相信他们的工作，信任是非常重要的一点，不管是我们以流水线的是在工作或者说使用工具，信任都是非常重要的。
有一点共情的能力，一定要去了解其他人是否他现在过得不顺，再有就是他们真正解决不了的一些问题，我们要真正去理解他们现在面临的很多情况。DevOps 的文化是重建信任，让人们走在一起。
“我们通过他人的行为来评判别人，但却按照我们自己的意愿来评判自己”
这是两句话，如果我们的意图是好的，有很多人他有意图想要做一些事情，但是他们做不到。
对于您这边想做一些事情的时候，但是我们首先要考虑到其他人有什么样的想法和意图，他们可能由于时间不够或者其他原因，我们要尝试去了解他们的一些问题。
还有新的拓展，然后是云服务，我们会有很多合作伙伴工作在一起，我们不仅仅是在公司内部来进行，很多人都来问我问题，DevOps 实现之后，其他的都能实现API自动化，所以我们也不需要再与彼此沟通，我不相信这是 DevOps 最终的目标。
我之后也发现，如果用很多服务，我们可以把很多不同的服务用在不同的位置上，比如我们有很多的实践，CDN 也是提供服务的，监控也是一种服务。我们现在没有运营服务，我们使用的都是别人的服务，我们并没有所有权，但是我们依然能做我们的事情。
6、常用实践与工具
1）沟通你承诺的状态并监控
2）监控服务并 度量信息(API) 3） 内部信息(API)
4）关心其他人
5） 日志
6）明确错误信息
7）备份外部数据
你对自己的数据应该负责，你应该自己想一想怎么去做备份。如果你将你的运维所有都外包给其他的公司或者都把这些重要的工作给到其他的系统，这个是不太具有保障的。
8）更快的反馈 9）让内外部依赖更清晰 10）主动让别人保持承诺 11）让别人了解变更
12）建立技术博客
然后可以用博客，博客也是可以每天进行更新的一种交流的方式。我和外部的服务有很长的合作时间，做一个很大的记录，我需要什么东西，将一个反馈发给他们。
如果我不做这项工作，我就没有办法获得更好的服务，只有把我自己的需求陈述清楚的时候才能获得更好的服务。
13）去大会演讲
14）让别人很方便的使用服务
15）给别人反馈
16）表达你在关注外部对你的依赖
之前和亚马逊的一次合作当中，我是当初这个服务最早一批用户，而且当初我收到任何一个反馈，我每提出一个问题一个需求，他们都及时给我反馈，我每提出一个投诉或者建议，他们都能很快进行反应。
另外我们还需要倾听他人的看法，比如有的人会在社交网络上，一些聊天软件上发布一些信息，表示他们遇到了什么问题，这个时候我们可以通过这样的渠道来更好的了解他们的诉求。
有一些公司甚至还可以允许我们的用户直接和工程师见面，他们并不害怕这么做，我们并不害怕这中间隔着好几层的架构和阻碍，我们可以直接建立起这个乔梁，因为这对于公司来说也是非常具有价值的。
17）告诉别人你在参与改进
18）告诉别人你的工程师们不怕与人交谈
19）对访问请求负责
这是一个App的应用商店里面的评价次数
20）让其他人参与进来
大家发现问题，然后有什么建议，都可以在里面写出来，这个时候就可以让我知道我有什么痛点，如果可能的话，我会尽可能来解决这些问题，通常有些问题会非常大。
有一些合作伙伴，他并不是非常具有合作的精神，这个时候如果短时间之内要换掉这些合作伙伴也非常的肯定。现在在公司的内部和外部，我们都可以看到有帮助我们改进的一些方法。
今天在自己的公司里面，很多人都在说 DevOps，我们在公司外部的这些东西不能够被看作是完全隔绝的，我们不能把自己的公司作为一个小团体、作为一个筒仓，而把自己的公司和外部隔绝开来。
其他一些可以给大家的启示，有很多书籍，大家可以进行相关的阅读，它可能未必是一个 DevOps 的操作手册给你让你按步骤完成，但是它会帮你理清思路，为什么我们要进行公司内部的 DevOps 的改造。
如果大家对第三方的合作感兴趣，我建议大家看这个视频，解释了相关的合作关系，一个非常有意思的演讲。
之前我也说到过，我们非常努力地编写了这本书，集合了我们多年的经验，出版了这本 DevOps Handbook，这里面的信息非常多，可以作为一个参照文件，从这里面甚至也可以找到新的思路和新的启发。
当然我们也欢迎大家分享你们的经验，我将会非常期待听到你们所有的意见和建议，谢谢大家。
原创：Patrick Debois本文由『高效运维社区』的DevOps专家@景韵等人，根据3月18日DevOpsDays·Beijing大会上全球公认的 DevOps 之父 Patrick Debois 的演讲整理而成。
| 
转播
分享
淘帖
()