写在前面
我也不知道为什么发cal的时候把话题起成了“再说devops”（至于为什么写成devops，请参考我的这篇blog《关于devops的拼写》），因为我们之前其实也没有说过这个。但是可能觉得我们其实平时在不停的说devops，所以就内心里面这个是一个再次重提的话题。
什么是devops
Wiki上的定义如下，这个也是我们能看到的绝大部分资料上的定义。
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
不过一千个人心中有一千个哈姆雷特，虽然我们都认同了这个定义，但是对于组成这个定义的那些词语的解释却是各自一表。
今天的讨论中刚开始也是这样，有基于概念本身阐述的。
devops是一种打破dev和ops之间边界，把两个角色的工作磨合到一起，从计划制定开始，到需求分析，开发，测试，部署上线。使用一些自动化工具和项目管理实践，提升项目的交付质量和速度。
也有结合自己经历过的devops组织结构模式的变化，提出来自己对于devops深层的本质的理解。
1. 建立统一标准。
2. 屏蔽技术壁垒。
而在这个讨论过程中，就有一些更具体的问题，我们在devops实践过程中碰到的一些做法对不对？比如说：为什么我们能看到devops这个角色或者职位，到底devops是一个工种，他要去负责dev+ops的活，还是一种站在对方的角度思考问题的文化？如果我们不了解对方的专业领域的知识，我们又怎么去理解对方，打破壁垒？这个讨论中小伙伴们都拿出了自己的案例来说明自己的观点。在我看来，如同人类社会发展一样，从原始社会，奴隶社会到封建社会，再到我们今天的资本主义社会和社会主义社会，下一步是共产主义社会。目前我们能看到的这些不同的做法和组织形态，都可以算的上是devops，只不过是成熟度不同所在不同阶段而已。
下面这张图是Jez Humble提出来的devops的5大基石/支柱，也算是在圈内认同度比较高的一个解释框架。
请注意最下面部分那句 “In DevOps, it’s always people over process over tools"，所以如同我上面的所述，当我们还知识关注于工具和实施自动化的时候，相对的还处于比较初级的阶段。之后再进一步开始引入精益，建立成熟的流程，就高级了一些。最后上升到关注人文，能够共担责任的时候，就可以称得上完美的devops实践了。hmm~这么说来，倒是更像马斯洛的需求层次理论，我们之后讨论的内容应该更能佐证我的这个观点吧。
怎么才能更好的推动devops
这个是最现实也是最无力的问题，毕竟devops怎么听都是一个很美好的东西，但是为什么我们在推行devops的时候还是遇到了各种各样的阻力？
大家用自己的亲身经历总结出来的最有效的方法是：切身的痛点(利益)才是内在驱动力。不论是从上向下的被动模式还是从下往上的主动模式，一定是驱动的人从中看到了这个事情能给他带来所谓的“价值”，也就是我前面括号里面赤果果的翻译：利益。
至于什么是“价值”，讨论到最后终是变成了最正确的废话：对方真正看中的东西。不同的人和角色在不同的时段对于看重的东西是不一样的，了解他们在当前关注的能给他带来的“价值”的点，然后有对应的方案就比较好推动了。
而另外一个切入点，就是有足够的权威，当对方足够信任你或者你有足够的威信的时候，你说的就是对的，即使它是错的。如果你不幸搞错了，可能实施的人觉得是自己哪里没做对，然后失败了。现实就是这么冰冷，无情而残酷。
国内外devops实施的差别
这个是很有趣的一件事情。在国内做devops，最终十有八九就是以采用了一些devops工具或者开发了一个devops平台来宣告成功。而在国外，你要和行内人士说devops平台，他肯定不能理解，为什么有了一个平台就算是落地devops了？这个看起来更多的是我们主流的发展思路不同导致的，如同我国在国际上的优势领域多是效率驱动型的一样，我们在devops上也是以提升效率为主，很少讨论人文层面的比较虚无的东西。而国外很多的时候是反着来，所以也就如小伙伴笑称的：国内关注结果，国外享受过程。
相关资料
Last modified on 2020-04-18