写点什么

在 Spotify 运维团队应用看板方法

  • 2011-04-14
  • 本文字数:3992 字

    阅读完需:约 13 分钟

InfoQ 访谈了 Spotify 的运维工程师 Mattias Jansson。Spotify 是一家为桌面计算机和智能手机提供流音乐服务的公司,旨在为用户提供各类无延迟的音乐专辑。Spotify 公司在内部的运维团队中采用看板(Kanban)方法,Mattias Jasson 向运维团队推荐了看板方法。 InfoQ 曾经多次推荐过看板方法,但主要是从软件工程的视角介绍看板方法。Jasson 在与 InfoQ 对话中详细地阐述了 Spotify 的运维团队在尝试使用以看板方法为基础的工作方法应对日常的工作压力所取得的经验。

Q:你们团队在最初使用看板方法时遇到了哪些问题?

我们 Spotify 的运维团队有 7 名成员,需要处理各种不同的任务。我相信这种情况是每一个运维团队都面临的。这一刻你在设计一个要花费很多钱的新网站,下一刻又要为开发人员修改防火墙规则。

当我们开始尝试看板方法的时候,这种情况导致了一个问题:有些故事卡片描述了一个耗时几个月的项目,而其它的故事卡片只是个需要 15 分钟就能搞定的小任务。为这些卡片给出合适的估算大小也很困难:例如更新一台服务器上的应用程序库时会不会影响到看似不相干的领域?还有些时候写下故事(story)的详细内容也是件痛苦的事,因为有些故事实在太小,以至于修复这个问题的时间比写故事的时间还要短。

但我试着超越自己。

在尝试采用看板方法之前,我们注意到虽然在解决问题上是把好手,但不能做长期的计划:只是被动而不是主动地解决问题。一大堆从其它部门派过来的“紧急任务”总是干扰我们的内部项目。我们经常因为众多来自人和系统的干扰而频繁地切换工作情境(context)。我们意识到公司的成长速度已经超过我们的适应能力了。

这听上去挺可笑,我们团队的主要问题是可扩展性(scalability),而不是我们的流服务(虽说这也是另外一个非常有意思的故事),但不管怎么说无论团队还是工作方法都没有为公司成长的需要做好准备。

Q:那么你们是如何解决这个问题的呢?

我们决定远离办公室开几个会,坐下来讨论实际在做的事情。通过这些讨论,我们对取得的成果和今后的目标有了清楚的认识(希望如此)。下面是一些我们问自己的问题:

  • 我们实际在做什么样的事情?我们花在各类工作上的时间各是多少?
  • 有没有可能把我们的工作用合理的方法归为不同的领域?
  • 我们的任务从哪里来?我们自己发起工作吗?还有其它来源吗?如果有,是谁?
  • 我们如何彼此分享知识?
  • 我们如何保证运维开发所需的时间?
  • 是不是有可能减少我们切换工作情境的时间?
  • 还有很多…

在我们开会讨论之后(包括计划的和临时的会议),得出了结论,那就是可以通过引入一个“团队守门员(goalie)”角色使团队更高效地完成工作,这个“团队守门员”负责捕获各种临时的工作请求并将其合理分类:小任务立即处理完成,把大一些的任务写成故事卡片。有了团队守门员的好处是:

  • 更高效有力地为其它部门提供服务
  • 在我们团队内部传播知识
  • 减少团队其他成员切换工作情境的情况

我们决定至少在开始使用看板方法的阶段尽量保持简单。我们的方法是:

  • 设立了三个垂直的泳道:待办(todo)、进行中(doing)和完成(done)
  • 作为上面的补充,我们还在看板上为两类主要的工作划分了两个水平的泳道:普通任务和暂不明确的故事(多数我们主动发起的工作都在后者中)。将暂不明确的故事分开后,我们能够确保这些暂不明确的故事最终能够做完。
  • 我们的故事只分为三种大小(就象 T 恤尺码一样):小、中和大。小的工作和任务是估计一天之内能完成的。大小为中的任务乐观估计半周能够完成。估计为大的工作是可能需要花一周才能完成。我们忽略了“实际的”估算,因为多数情况下这种估算是浪费人力。
  • 我们给待办泳道设定了一个较小的并行任务限制值(WIP - Work In Progress)”,因为我们把普通任务和暂不明确的故事分在两个不同的水平泳道中。我们一周(或当 todo 泳道空了的时候)才向里面放入新的故事,以此保证我们内部的长期的任务能够完成。
  • 进行中的并行任务限制值我们定为比运维团队的人数少 1,因为那个人是团队守门员。为了鼓励小组成员一起完成故事,我们还考虑进一步减小并行任务限制值,不过那是在我们熟悉了看板方法之后。

那么更大的任务怎么办?嗯,其实我们把所有超过一周才能完成的任务称为“项目”。这些项目需要更多的描述,因此我们用 wiki 记录详细信息,同时把项目分为若干从小到大的故事。然后我们把这些故事放入 backlog 中,通常是在“暂不明确”的泳道中。

后来,我们意识到我们还得支持快速问题,为此在待办和进行中加入了第三个水平的泳道。这个泳道的并行任务限制值设为 1,因为我们希望少用这个类别。

Spotify 运维团队使用的 Kanban 截图

Q:从关注于软件开发的看板方法到关注于运维的看板方法,你们对看板方法做了哪些调整?

其实并没有太多改变,因为看板方法本身就是一种非常简单的系统。我想说的是,看板方法在所有组织中都需要改造,无论其类型如何,我们使用看板的方式可能和传统的软件开发环境稍有不同。

一个运作良好的软件开发团队通常只有一个故事的来源:可能是产品开发部门,他们和开发小组领导或和所有开发团队成员一起定义每个故事。这种情况下,一个可以预计的结果是,所有的故事某种程度上是“同构体”,就是说这些故事的大小类似、书写方式也遵循某种通用的标准。

一个典型的运维团队会有许多任务的来源:从个别的开发人员、产品开发团队、其它部门到运维团队自己产生的任务。这对运维团队来说是个问题,因为所有这些来自外部的任务都会干扰我们计划的长期项目,每一个运维团队成员都面对这个问题。对于运维团队内的资深工程师来说这个问题更加突出。

更糟糕的是,我们希望尽快从这些干扰中解脱出来,因此我们经常忘记记录所做的改变,或者通知小组内的其他同事。

仅仅引入看板方法而不去处理这些经常性的外部工作是不能解决我们运维团队面临的干扰过多的问题的,所以说适当的改造是必要的。

我们团队的改造方式是,就像我刚才提到的,每周设置一个专人作为“团队守门员”,有了这个“团队守门员”我们就能真正地应用看板来管理我们的日常工作,因为团队守门员为团队处理掉了所以琐碎的干扰。

开发团队和运维团队另外的一个区别是,我觉得相比开发团队,运维团队自己产生出的任务或者计划的内部项目比较少。我们的问题是,发现在为任务排优先级的时候,来自外部的任务总是优先于我们自己的内部工作。一方面这是因为助人的本性,另一方面是外部的问题通常都很具体。
就像为早先说的一样,我们按照 David Anderson 的建议,在看板中加入了“暂不明确”的故事类型。我们把 8 个并行任务限制值平均的分配到两个泳道上,这样我们就能保证有一半的人手在做“暂不明确”的故事。到目前为之,这在我们团队运作得很好。

Q:你是怎么发现看板方法的呢?

几年前,在我加入 Spotify 之前,听说了敏捷和精益方法,非常想在我的团队中试一下。但是我们是支持和运维团队,不能很好地使用 XP 和 scrum。

后来,大约是 2 年前,Henrik Kniberg 向我介绍了看板方法。我们只是试验了一下但并没有真正用在工作中。回想起来,我觉得因为没有花时间去分析我们的工作,所以浅尝辄止。

结果在 Spotify,我和同事及运维主管讨论了看板方法,然后决定试一试。

Q**:在Spotify你为什么选择看板方法进行运维管理?**

我们选择看板方法是因为它灵活而且实施成本相对较低。结果是,我们工作方式上很小的改变极大的提高了工作效率。

Q**:你有没有尝试过看板方法之外的敏捷实践,比如scrumXP等等?**

Serum 嘛,没有,因为我们的工作流程很难按照 scrum 的方式安排。

没试过 XP,但我想我们精心地选择了一些实践,比如结对编程。当我们对系统基础设施做出重大调整时,通常结对工作。

Q:开始使用看板方法时,你有没有接受过一些培训?

是的。除了读 Henrik Kniberg 关于看板方法介绍的书之外,我们中的一些人参加了一个 David Anderson(“看板之父”)主办的为期两天的课程。课程非常有启发性,如果有机会的话,其他人也应该去听。

我们也参加了一个由 Mary Poppendieck 主持的晚间研讨班。她谈到了精益软件开发,虽然这些主题没有立刻适用于运维团队,不过确实很有启发性!

Q:你们用什么工具来管理看板?为什么选择它们?

我们试用过 AgileZen,一个优秀的、漂亮的看板工具,不过它不支持水平泳道,这对于我们来说是个限制。

在发现 LeanKit Kanban 后,我们就从 AgileZen 迁移过来了,因为 LeanKit Kanban 不仅支持水平泳道,而且你还能更自由地定义自己的看板。我们还用自己的 wiki 来描述项目。

Q:你们用了多长时间让这个看板流程运转起来?

大约花了一个月,包括分析我们团队的情况,发现团队任务的来源、瓶颈等等,还包括在用 AgileZen 实现了看板后培训团队成员。

当然,因为看板流程本身是不断演进的,在运转起来之后,看板流程不断给我们新的视角让我们不断将新发现融入流程中。从这方面来说,我们永远无法“完成”解决方案而不再需要任何调整。

看着看板方法引导我们团队走向何方是件有意思的事情,问题是我一年后如何回答这些问题。

Q:你对看板方法有多满意?你是不是认为看板方法值得所有运维人员关注?

是的!我们对看板方法非常满意。看板方法让我们在没有对日常工作进行重大改变的情况下让团队变得更敏捷。我们注意到等待时间在变短,完成了更多的内部工作,同时服务的部门对我们的工作更满意。

Q:对看板方法感兴趣的人,你有没有推荐的资源?

查看英文原文 Use of Kanban in the Operations Team at Spotify

2011-04-14 00:005638
用户头像

发布了 32 篇内容, 共 95398 次阅读, 收获喜欢 1 次。

关注

评论

发布
暂无评论
发现更多内容

分享一个从源码快速构建应用的小工具

Draven Gorden

开发者工具 开发工具 开源项目

Cordova插件中JavaScript代码与Java的交互细节介绍

汪子熙

Java JavaScript 移动应用 28天写作 12月日更

常用项目部署方案和区别

进击的梦清

DevOps 运维 项目 部署与维护

☕【并发技术系列】「多线程并发编程」技术体系和并发模型的基础探究(夯实基础)

码界西柚

Java 并发编程 多线程 多进程 12月日更

PackML从会到不会——命令标签(4)

陈的错题集

标准化 PackML

Java和ABAP中的几种引用类型的分析和比较

汪子熙

Java 引用 28天写作 abap 12月日更

带你了解Typescript的14个基础语法

华为云开发者联盟

typescript 数组 开发 js 语法

基于星环科技大数据平台 辽宁城市建设职业技术学院打造智慧校园

星环科技

大数据

Selenium之css怎么实现元素定位?

六十七点五

大前端 软件测试 自动化测试 接口测试 selenium

我不用“996”,更不用“007”,可我赚的就是比你多

六十七点五

软件测试 自动化测试 接口测试 测试工程师 功能测试

模块五作业

危险游戏

架构实战营

短视频平台的风控系统设计

Bill Zhang

vCenter管理软件用什么牌子好?有哪些用处?

行云管家

虚拟化 vcenter

工具 | PG 集群复制管理工具 repmgr

RadonDB

数据库 postgresql RadonDB

如何在Flutter应用程序中创建不同的渐变 【Flutter专题14】

坚果

flutter 28天写作 12月日更

初识JVM的内存结构

Ayue、

技术专题合集

恒源云(GPUSHARE)_CIFAR-10数据集实战:构建ResNet18神经网络

恒源云

深度学习 算法

Sinfonia: a new paradigm for building scalable distributed systems--翻译理解【1】

Krysta

分布式 transaction Sinfonia DSM 两阶段提交改进

恒源云(GPUSHARE)_分享一个技巧!CV训练时容易忽视的数据标签问题

恒源云

深度学习 算法 CV

周边生态|RoP 重磅发布 0.2.0 版本: 架构全新升级,消息准确性达 100%

Apache Pulsar

Java 开源 架构 云原生 Apache Pulsar

12 月亚马逊云科技培训与认证课程,精彩不容错过!

亚马逊云科技 (Amazon Web Services)

架构师 培训 认证

云智慧正式开源运维管理平台(OMP),加速AIOps社区生态建设

云智慧AIOps社区

运维 运维监控 开源软件 运维体系 运维系统

等保工作中常见导致测评结论为差的高风险项

行云管家

网络安全 等级保护 等保测评 等保结论

使用工具Source Monitor测量您Java代码的环复杂度

汪子熙

Java 软件工程 28天写作 12月日更 代码复杂度

web技术分享| AudioContext 实现音频可视化

anyRTC开发者

Web 音视频 WebRTC 音频可视化 AudioContext

MySQL探秘(二):SQL语句执行过程详解

程序员历小冰

MySQL 28天写作 12月日更

Linux一学就会之Centos8用户管理

学神来啦

Linux centos 运维 linux云计算

当我们谈论“远程开发”时,我们在谈论什么

Draven Gorden

云原生 开发者工具 开发工具 远程协作 开发环境

Spark SQL之RDD转换DataFrame的方法

@零度

大数据 RDD DataFrame spark SQL

dart系列之:还在为编码解码而烦恼吗?用dart试试

程序那些事

flutter dart flutter 面向切面 aop 程序那些事 12月日更

小程序与H5适合的场景应用都有哪些

Speedoooo

ios开发 APP开发 容器安全 Andriod开发 容器应用

在Spotify运维团队应用看板方法_研发效能_Michael Prokop_InfoQ精选文章