首度来到中国的DevOpsDays北京站昨天顺利举行了。有幸得到赠票，在大会上见到了DevOps之父Patrick Debois还有诸多业内专家。当天的盛况及ppt下载请移步此处。

传统的DevOps主要涵盖了CAMS（Culture文化、Automation自动化、Measure度量、Sharing分享）四大方面。而要落地DevOps，需要两条腿：一条是组织方面的转型，另一条是技术方面的自动化工具。组织转型是要涉及到利益的，不容易下手。所以大部分的分享还是以技术方面为主。只有Patrick的好基友Kris Buytaert的ppt讲的是reorg。乔梁讲的是他在百度和腾讯的经历，但可能是受时间所限并没有太多的实际内容。如果没有自上而下的变革，很难推动起组织转型。对于许多人来说，也许能够做到的，也就是自动化工具罢了。下午的Open Space深度交流专场里，不乏对组织转型方面的问题，但是嘉宾们其实也没有什么非常好的办法。有些技巧（比如说拿数据说话）可以让你把DevOps推销给老板，但终究一场战斗的胜利很难能够左右战略上的部署。没有自上而下的决心和后盾，在触及利益的时候肯定是各种痛啊。两条慢腿可能凑活着还能走走，一条腿快一条腿慢必然会驱使着变革的前进或倒退。DevOps讲究痛点驱动，相信以后的DevOpsDays会有更多组织转型方面的分享。

在技术上，专家们一直强调，没有DevOps团队，别叫他们DevOps工程师。DevOps需要融入到跨功能团队中的每一个人，不是某一类人，不是某一个团队。这里我感觉有一个词很重要：同理心。有了同理心，你会理解其它角色的痛点，反之亦然。由此，便可以催生出分享。有了分享，理解痛点，便能从“像部署一样痛苦的事要多做”出发，提取出最佳实践，催生自动化。要衡量效果如何？数据说话。于是催生度量。这几方面相辅相成，在整体的良性循环之下，团队文化的成型便是顺理成章。怎样让大家拥有同理心？除了依靠人的素质进步，百度的刘俊还提到了一个做法，据说甚是有效，那就是开发运维轮岗。想想也对，把你推到别人的位置上，自然就有同理心了。

我在《DevOps实践》的译者序上也说过，DevOps是要很高成本的。在应用它之前，先问自己这样的问题：为什么要上DevOps？它能解决我的什么问题？不要说我想提高工作效率，提高程序质量，要从更高层次的业务上说。换句话说，从战略层面上想清楚应用DevOps的目的，然后在战术层面上依照战略来有根据有优先级地安排资源打硬仗。跟性能调优一样，搞清楚哪里才是瓶颈，针对性地动手解决。而不是直接拍胸脯就上DevOps，把最宝贵的资源浪费在可能对这个组织最没用的地方上。

对于中小企业来说，不要开发自己的自动化工具，不要重复发明轮子，直接拿现成的开源工具来用吧。不是BAT这样的量级，玩不起自研版的工具，它们其实是很重量级的。针对开源工具有些功能不符合自己的需求这方面，ThoughtWorks的黄博文说道：可以从另一个角度来看待这个问题，为什么你要的功能没有？这是一个正常的功能吗？究竟是功能的缺失，还是说只是你走错了路？此言深得我心。据说业界运维做得最好的应该就是谷歌和Netfilx。它们都有不少开源的运维工具，值得业内人士仔细研究。

最后放一张乔梁对DevOps和持续交付的看法，四个角色分别是产品、开发、测试和运维。先剧透一下并不是所有人都同意这个观点，少年，你怎么看？