运维系统是这样做烂的

半年多的时间,眼睁睁看着dd运维平台从臃肿到积重难返,很痛心。其中,有公司业务发展迅速的原因,有早期设计方案不合理的原因,有系统开发人员经验不足的原因,等等。本文要讲的,是另一方面的原因: 需求到产品的转化不当

page.png

需求到产品的转化不当,主要体现在两个方面:

  • 对需求的把控,不够严格
  • 需求到产品的转化,不够严肃

下面,我们以dd运维平台的需求处理过程为例,做简要分析。为了说明问题,过程描述有删减调整。

提出需求

运维系统80+%的需求,来源于SRE(SRE的需求来源于RD需求和运维业务)。由于种种原因,SRE不能完全正确的提出需求,比如:

SRE对需求把控不严格

SRE通常很热心于运维平台的功能建设:-D 但有时,对新需求的过滤不严格,导致过多的、非大众的功能进入运维平台。典型的场景,有:

  • SRE个人需求。SRE个人在使用运维平台时遇到了一些问题,未经SRE团队整体讨论、确认,就抛给平台开发方(DEVOPS)、希望尽快转化为新功能。如果这个SRE个人经验不足, 那么被提出的”需求”常常带有较重的主观色彩、不够大众化,结果就是好心办成了坏事。此时,需要SRE团队集体做需求过滤
  • RD个人需求。部分RD习惯以激烈的方式,反馈问题给SRE;SRE被动决策,有时候会直接将问题抛给平台开发方、转化为新功能需求;后者的举动,更加鼓励了RD的做法,如此往复加剧。运维平台完善之前,会经常被RD吐槽;SRE帮DEVOPS背了黑锅、承担了很大压力,此处的case情有可原。此时,需要DEVOPS直面RD的指摘、吃自己的狗粮,需要SRE识别RD的需求合理性、尝试引导RD表达合理的诉求

SRE需求分析不彻底

SRE没有拿到RD的真实需求。比如,SRE得到RD反馈后,没有弄清楚RD想要做的事情,或者,没有弄清楚RD所提问题的进一步的原因,只根据表象做需求判断。

SRE没弄清楚自己的本质需求。比如,SRE想要做一件事情,有时自己也没弄明白,为什么要做这件事、为什么要用这种方式做。如果一件事情可以不做,那就不做;如果必须做,优先复用已有方式。

为了提升需求分析能力,需要SRE沉淀需求分析的经验、刻意培训需求分析的能力

SRE提出需求的实现

对于经验丰富的SRE,有时候会如是行为:正确的拿到需求,帮DEVOPS想好实现方案(产品方案),然后对接DEVOPS开发人员、告知如何去实现。

如果我们有一位懂需求、懂技术、同时又能做产品设计的OP童鞋,那是所有人的福音。如果在一段时间内没有如此牛逼的大拿,我们最好退而求其次,合理分工,由SRE抛出较纯粹的需求,再由SRE和DEVOPS一起确认产品形态,大家分别做好擅长的事情。

把控需求

SRE将需求提给DEVOPS后,需要DEVOPS做进一步的过滤。当前,这一环节,DEVOPS做的很不好。比如,DEVOPS不能正确区分需求的大众性,习惯性的、无意识的接受”小众”需求。比如,DEVOPS不能正确理解SRE的功能需求,或者不能站在技术角度、协助SRE提取需求&分解需求。再比如,DEVOPS的童鞋不能正确区分功能需求和实现方案,常常会全盘接受SRE的实现方案

这里,有DEVOPS童鞋经验不足的原因,也有DEVOPS需求把控机制的原因。个人觉得,可以通过两方面来改善:

  • 建立集体决策机制。既然我们个人经验不足,又暂时没有统领全局的架构师,那就集体决策、大家一起确认需求是否合理。虽然集体决策会降低效率,但总比做不正确的事情好很多。此处,要 (1)选择合适的决策人群,同时 (2)开放决策过程、及时公布决策结果。
  • 提升个人需求把控能力。自不必说,能够把控需求的DEV才是好DEV。

实现需求

在需求的实现上,DEVOPS做的也不够好。主要问题,有:

  • DEVOPS缺乏长远规划,被动的让需求推动着平台发展。”随波逐流”,只能”江河日下”,最好也就是原地踏步。说句心里话,DEVOPS团队真心需要一个架构师,来指导平台的长远规划
  • DEVOPS往往偏向于多加功能。KPI驱动模式带来的一个恶果。当然,大部分人都倾向于增加功能,这是人性的一个默认设置,因此,需要DEVOPS的童鞋时刻保持对新功能的克制。可以”以暴制暴”,针对滥加功能这一现象 做一个KPI减分项:-D
  • 等等。

深夜BB这么一大堆,归根结底,还是因为公司发展太快。在这种情况下,大家只能亦趋亦步、相濡以沫、共同成长! 道路是坎坷的,前途是光明的,欢迎各位大牛加盟



Prev     Next