DevOps反模式

在实现DevOps的五大关键要素(CALMS: 文化 - Culture,自动化 - Automation,精益 - Lean,度量 - Metrics,分享 - Share)中,排在第一位的是文化,并不是(仅仅)因为这样写是个有意义的单词,而是因为文化才是判断团队是否达到DevOps的最重要因素。然而,事实上,这也是最容易被忽略的一点。很多团队以为,只要用上各种fancy的自动化工具,就是DevOps了。这种做法恰恰是DevOps的一种反模式。

一家面馆

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

  • 进门之后,一个服务员很热情的询问是几个人,然后将我引到座位上,然后转身拿了菜单回来,开始给我介绍店里的特色,并把我点的菜记到一张纸上;
  • 点完菜,服务员拿着那张纸走到收银台,因为离我不远,我听到点餐服务员把我点的菜跟收银员复述了一遍;
  • 收银员告诉点餐服务员,我点的一个菜已经没有了,点餐服务员又回来告诉我那个菜没有了,要不要换一个,我换了一个菜之后,点餐服务员再回到收银台;
  • 确认了我要点的菜之后,收银员在一个点菜机上点了几下,打印出两张小票,交给点餐服务员;
  • 点餐服务员将一张小票交给站在厨房门口的另一个服务员,然后拿着另一张小票和一个号码牌回到我这里,让我付钱;
  • 因为是开放式厨房,我付了钱之后就一边观察他们做菜,一边等着上菜;
  • 厨房里有4个人,一个做菜,一个做面,两外两个站在旁边看着;
  • 我点的菜做好后,厨师将菜放在一个托盘上,服务员看到有菜做好,就到厨房拿托盘,边拿边问站在厨房门口的服务员,这些菜是哪一桌的,得到回答是我这桌之后,就把托盘送到我这里;
  • 就在我吃面的过程中,听到一个老板样子的人从楼上下来,对着几个在聊天的服务员说,楼上一桌客人已经走了,怎么还不去收拾了,然后其中一个服务员就赶紧上去收拾;
  • 服务员从楼上端下来碗和盘子,放到厨房的台子上,之前站在一旁的两个人开始洗碗;因为没有客人新下单,之前做菜的两个人就在旁边看着他们洗碗。

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

另一家面馆

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

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

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

DevOps反模式

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

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

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

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

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

第五,因为每个人都只关注自己负责的部分,导致在出现阻塞(有个桌子的客人已经离开,但没有服务员去收拾)时,需要团队的lead来负责协调资源(指定一个人去收拾桌子)。

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

DevOps正模式

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

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

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

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

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

今天你DevOps了么?

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

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

DevOps虽好,可不要贪杯噢!