有了自动化就是 DevOps?浅谈 DevOps 中的反模式

在实现DevOps的五大关键要素（CALMS: 文化 - Culture，自动化 - Automation，精益 - Lean，度量 - Metrics，分享 - Share）中，排在第一位的是文化，并不是（仅仅）因为这样写是个有意义的单词，而是因为文化才是判断团队是否达到 DevOps 的最重要因素。然而，事实上，这也是最容易被忽略的一点。

很多团队以为，只要用上各种 fancy 的自动化工具，就是 DevOps 了。这种做法恰恰是DevOps 的一种反模式。

一家面馆

我家附近有两家相邻的面馆，口碑都不错。昨晚去其中一家吃饭，就餐过程就是一个DevOps反模式：

• 进门之后，一个服务员很热情的询问是几个人，然后将我引到座位上，然后转身拿了菜单回来，开始给我介绍店里的特色，并把我点的菜记到一张纸上；

• 点完菜，服务员拿着那张纸走到收银台，因为离我不远，我听到点餐服务员把我点的菜跟收银员复述了一遍；

• 收银员告诉点餐服务员，我点的一个菜已经没有了，点餐服务员又回来告诉我那个菜没有了，要不要换一个，我换了一个菜之后，点餐服务员再回到收银台；

• 确认了我要点的菜之后，收银员在一个点菜机上点了几下，打印出两张小票，交给点餐服务员；

• 点餐服务员将一张小票交给站在厨房门口的另一个服务员，然后拿着另一张小票和一个号码牌回到我这里，让我付钱；

• 因为是开放式厨房，我付了钱之后就一边观察他们做菜，一边等着上菜；

• 厨房里有4个人，一个做菜，一个做面，两外两个站在旁边看着；

• 我点的菜做好后，厨师将菜放在一个托盘上，服务员看到有菜做好，就到厨房拿托盘，边拿边问站在厨房门口的服务员，这些菜是哪一桌的，得到回答是我这桌之后，就把托盘送到我这里；

• 就在我吃面的过程中，听到一个老板样子的人从楼上下来，对着几个在聊天的服务员说，楼上一桌客人已经走了，怎么还不去收拾了，然后其中一个服务员就赶紧上去收拾；

• 服务员从楼上端下来碗和盘子，放到厨房的台子上，之前站在一旁的两个人开始洗碗；因为没有客人新下单，之前做菜的两个人就在旁边看着他们洗碗。

乍一看，这个流程很标准，引客->点菜->下单->上菜->收拾碗碟->洗碗，流程中的每一项都有专人负责，而且还使用了自动化工具——点菜机——来打印小票，而且老板也起到了很好的监督作用。

另一家面馆

隔壁的面馆我也经常光顾，所以不由自主的开始对比两家店。先看看隔壁面馆的流程：

• 进店后，顾客自己到收银台点菜；
• 点好菜，收银员打印两张小票，一张放在厨房的台子上，把另一张和一个号码牌交给我；
• 厨师拿起台子上的小票，看了一眼后，插在一根钉子上，然后开始做菜；
• 菜做好后，厨师将菜放在托盘上，然后将小票压在盘子下面，取菜的服务员看一眼小票，就知道要送到哪个桌子；
• 服务员上完菜，如果在回到厨房的路上发现有客人已经离开，服务员会顺手将桌子收拾好，把碗碟拿回厨房；
• 在高峰期，洗碗工会充当服务员帮助上菜，收回的碗碟会先堆在一旁，等到客人不多时，再集中洗碗。

对比两家店，直觉上可以判断出，第二家店要比第一家店更赚钱，尽管两家店口味都很好，价格也差不多，店面大小一样，员工数量也接近。

DevOps 反模式

从 DevOps 的角度来看，第一家店的根本问题在于，**局部过度优化，忽略全局目标。这也是大部分号称采用了DevOps工作方式的团队，实际效率并没有提升，甚至有退化的主要原因。

第一，为了方便收银员计算价格，第一家店引入了点菜机，工具的使用确实简化了收银员的工作，但是顾客点菜还是要通过服务员先写在纸上，再念给收银员，相比以前直接将菜单交给收银员手工算价格，实际上并没有节约时间；

第二，在顾客和收银员之间增加了点餐员这个缓冲层，本意是改善用户体验，让用户觉得即时响应，但实际上让需求方（顾客）和研发团队（厨房）的反馈链断开，导致需求不断确认（某个菜卖完了），浪费人力成本和时间成本；

第三，厨师觉得每次先看菜单再做菜很麻烦，于是让一个人站在厨房门口，给厨师念菜单。但这个念菜单的人可能念错，也可能漏掉其中一个菜。增加了这个流程，除了增加了成本外，还带来了系统的不稳定性；

第四，为了让洗碗工能够快速响应，安排专人负责，结果在没有碗可洗的时候，这个人就浪费了，而顾客实际上并没有从这一改进中体会到任何好处；

评价一家面向上班族、价格不高、以量取胜的面馆，要想在有限的店面空间实现利益最大化，最重要的就是让顾客尽快吃完，好让其他客人进店消费，在餐饮行业，这个指标叫做“翻桌率”，即每天消费的桌数/店内总桌数。尽管第一家店不断的优化各个环节，但客人在店里吃一碗面的时间没有减少，翻桌率就不可能变高，利润也就不可能增长。

DevOps 正模式

我们来看看另一家店为了提高翻桌率，做了哪些努力。

第一，进行需求收集时，让顾客和研发团队直接交流（客户直接到收银台点菜沟通），研发团队可以第一时间对需求进行反馈（CALMS中的L，即精益）；

第二，团队专注在核心业务上（点菜->做菜->上菜），其他事情（找座位）尽量让客户自助（CALMS中的A，即自动化）；

第三，需求信息在团队内共享（收银员、厨师、上菜的服务员都通过订单小票共享哪一桌顾客点了什么菜），看似每个人都要多做一点点事情，但是从整体上看，减少中间环节，信息流动速度更快（CALMS中的S，即分享）；

第四，以完成全局目标（提高翻桌率）为驱动力，实时反馈系统状态（是否有客人离开，上菜的服务员是否充足），调整资源分配（上完菜的服务员去收拾客人离开的桌子；洗碗工在高峰期帮助上菜）（CALMS中的M，即度量）；

今天你 DevOps 了么？

打造DevOps团队，并不是用点工具，改改流程，讲讲方法论就够了。最关键的，是要在团队中形成DevOps文化，即系统思考，全局优化。

对于软件研发团队来说，最主要使用的全局度量指标，就是特性的周期时间（Lead Time），即新特性从需求提出，到正式上线交付给用户的时间。可以这么说，所有不以降低特性周期时间的工具和流程，都是耍流氓。

DevOps 虽好，可不要贪杯噢！

来源：http://tong.im/2016/02/19/devops-anti-pattern/