惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

B
Blog
C
Check Point Blog
The GitHub Blog
The GitHub Blog
Y
Y Combinator Blog
SecWiki News
SecWiki News
有赞技术团队
有赞技术团队
Latest news
Latest news
D
DataBreaches.Net
Blog — PlanetScale
Blog — PlanetScale
Project Zero
Project Zero
H
Help Net Security
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
G
GRAHAM CLULEY
Engineering at Meta
Engineering at Meta
T
Threat Research - Cisco Blogs
腾讯CDC
P
Proofpoint News Feed
L
LINUX DO - 热门话题
C
Cisco Blogs
P
Palo Alto Networks Blog
Vercel News
Vercel News
P
Privacy International News Feed
爱范儿
爱范儿
Scott Helme
Scott Helme
L
Lohrmann on Cybersecurity
MyScale Blog
MyScale Blog
K
Kaspersky official blog
B
Blog RSS Feed
美团技术团队
Microsoft Security Blog
Microsoft Security Blog
O
OpenAI News
博客园 - 叶小钗
量子位
T
Tenable Blog
C
Cybersecurity and Infrastructure Security Agency CISA
J
Java Code Geeks
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Hacker News: Ask HN
Hacker News: Ask HN
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
L
LINUX DO - 最新话题
F
Fortinet All Blogs
N
News | PayPal Newsroom
The Hacker News
The Hacker News
C
CXSECURITY Database RSS Feed - CXSecurity.com
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
博客园 - 【当耐特】
N
News and Events Feed by Topic
V
Visual Studio Blog
Google DeepMind News
Google DeepMind News
Last Week in AI
Last Week in AI

顾宇的博客

用 AI 重启生活 初始化 MacOS 关于我 再次见面,期待相遇 演讲和分享 如何通过政策红利获利?——海南发展(SZ.002163)交易复盘 2025年的总结 2024年的总结 2023年的总结 2022年的总结 《敏捷测试价值观、方法与实践》序 【翻译】函数式编程中的领域驱动设计 【翻译】通过跟踪技术债来改进你的开发实践 【翻译】不要把测试用例自动化 【翻译】持续部署 vs 持续交付 【翻译】测试替身 【翻译】做多少测试才足够 【翻译】蓝绿部署的起源 【翻译】持续部署 【翻译】作为演进式架构的微服务架构 【翻译】gRPC 的动机和设计原则 【翻译】分布式计算谬误 【翻译】微服务和分布式对象第一法则 采用 Multipass 管理本机虚拟 K8S 集群 博客主题升级到 Congo 2.0 【翻译】Terraform 最佳实践:模块组合 【翻译】Kubernetes 部署语言(Kubernetes Deployment Language) 通过 Vagrant 一键初始化 K8S 集群 2021年的总结 通过 Github Actions 部署 Mkdocs 文档 博客迁移到了新的 Hugo 主题 2020年的总结 2019年的总结 千人规模组织级 DevOps 演进的 9 个实践技巧 从技术雷达看 DevOps 的十年——容器技术与微服务 DevOps 模式 - 引入 DevOps 顾问 DevOps 模式 - 索引 DevOps 模式 - 定义你的DevOps 从技术雷达看 DevOps 的十年——基础设施即代码与云计算 DevOps 模式 - 采用模式语言讨论 DevOps 从技术雷达看 DevOps 的十年——DevOps与持续交付 【翻译】微服务安全:所有应该被问到的问题 云原生下的 DevSecOps 实践 【翻译】软件定义交付宣言 微服务演进中的经验和反思 迟到的 2018 年终总结 成功微服务实施的组织演进 从第19期技术雷达看 DevOps 的发展趋势 成功微服务实施的技术演进 我们如何衡量微服务的成功? 关于四周四 AWS 架构工作坊的设计和实践 讨论微服务之前,你知道微服务的 4 个定义吗? 公有云(AWS)上的生产环境架构优化案例和迁移套路总结 公有云(AWS)上的生产环境性能分析案例 一怒之下,我又写了一个开源流量测试工具 采用 DevOps 故事落地 DevOps 测试驱动开发 Nginx 配置 云原生 DevOps 翻译-混沌工程的原则 Serverless 风格的微服务的持续交付 从最新一期技术雷达看 DevOps 的发展 关于 DevOps ,咱们聊的可能不是一回事 Serverless 风格的微服务的架构案例 提升微服务实施效率的 7 个步骤 微服务实施常被忽视的 5 个难点 你的 CI 在挖矿吗? DevOps前世今生 - 4. DevOps 的文化 DevOps发展的九个趋势 不要让你的持续集成服务器成为安全隐患 DevOps 前世今生 - 3. DevOps 的目标和核心 DevOps 前世今生 - 2. DevOps 矛盾从何而来 DevOps 前世今生 - 1. DevOps 编年史
从星巴克店面运营学习 DevOps
顾宇 · 2019-05-10 · via 顾宇的博客
  1. 顾宇的博客/
  2. Blogs/
  3. 从星巴克店面运营学习 DevOps/

某次在星巴克等咖啡的时候,闲来无事开始观察店员的的工作。可能是出于职业习惯,我开始观察和分析星巴克的工作流程。突然发现星巴克的咖啡交付过程很像一个敏捷软件开发团队的交付过程。后来通过进一步观察和细聊,发现星巴克的店面运营是一个 DevOps 运作的榜样。

如果我们把星巴克的店员们看做是一个开发/运维团队,把咖啡的交付看作软件的交付,把店面的基础设施维护和清洁看作是运维工作。我们就发现了一个很好的 DevOps 学习榜样。

星巴克忙碌的咖啡流水线

让我们看看星巴克店面是如何做 DevOps 的。

星巴克咖啡交付团队的角色组成 #

在星巴克里,大家都相互称对方为星伙伴。我个人理解是通过弱化职级称谓提升每个人的责任心。所有的店员分为四个角色:

  • 店面主管(SS或IC):负责店面整体的管理。

  • 收银:负责点单、推荐产品和收款。

  • 吧台:负责制作饮品。

  • CS:负责门店补货,清理桌面。

店面主管主要负责团队的任务安排,你可以把它当做是 PM 或者 Scrum Master。在一切都井然有序的情况下,他的工作和一般的员工是一样的。只要他发现了临时需要处理的情况,他才会根据店面的资源来安排临时性的工作。

吧台内部分为三个部分:收银点单区、咖啡制作区、咖啡待取区,如下图所示:

星巴克区域

收银点单区的店员根据客人的需求点单,然后记录到咖啡杯上。

咖啡制作区的店员会根据杯子上的标记制作饮品。

制作完成后的咖啡会放到咖啡待取区等客人来取。

所有的店员都具备所有的技能(全栈工程师),并通过标准化的考试上岗。你会看到在星巴克里有绿色围裙和黑色围裙。黑色围裙的咖啡师是经过考试的,考试合格后会发黑色围裙作为通过认证的标志。

反思:你的工程师有标准化的技能考试吗?

星巴克咖啡交付团队的 DevOps 单向工作流 #

说到 DevOps,不能不提到"三步工作法"。首先,我们要用到第一步——构建端到端单向工作流——来观察星巴克店面是如何构建单向工作流的。

我们可以把交付一杯咖啡的流程和软件开发的交付一个用户故事的流程的关系做如下对应:

  1. 需求分析:和客人交流并记录客人对咖啡的需求。

  2. 产品开发:按照需求制作咖啡。

  3. 产品发布:制作完成并通知客人取咖啡。

  4. 基础设施运维:咖啡店面的日常清扫和补货。

在这个基础上,我们看看一杯咖啡从点单开始,星巴克的持续交付流水线就是它设备的摆放顺序,确保杯子的单一方向流动,避免返工和逆向流动。

点单:虽然星巴克的咖啡是流水化工业制品。但是也是存在定制的,比如类别、口味、冷热、大小。虽然顾客有需求,但需求控制在一定范围之内(哪些做得到,哪些做不到)并且通过产品价位板告知顾客。

反思:你的团队能做什么,不能做什么,什么时候做完,你是否对交付成果有信心?这些信心来自哪里?如果没有信心,如何获得信心?

标记:在点单阶段,收银会把客户的每一个需求记录到杯子上,包括顾客的姓名。星巴克咖啡采取的是“预付费”(先付费再生产)而非“后付费”(先生产再买单)的方式。这些记录是对一杯咖啡需求验收标准的分解。通过杯子大小来控制每个需求点的验收和用量。

反思:你的团队开发需求时是否把每个验收条件记录下来并且在不同的阶段控制质量和用时?

制作:每个带着记号的咖啡杯就是一个格式化的需求文档。上面详细的记录了这个顾客的需求,并且这些需求可以验证。每杯咖啡都有标准的验收样例和工序,所以每个店员都知道完成的标准是什么。这样,即便不是点单的店员,看到杯子上的记号,也能做出符合顾客验收条件的咖啡。此外,每个杯子上都会有顾客姓名的标记,以免点错单。

星巴克的杯子就是一个格式化的需求文档

反思:你的团队需求文档中的信息是否可以做到无解释交接?

出品:星巴克“完成”的定义是“顾客拿到了咖啡”,而不是“咖啡制作完毕”。如果顾客没有确认拿到的咖啡符合需求,是没有完成的。如果顾客对咖啡不满意,是可以要求重做的。这时候,会由专门的店员负责重新制作咖啡,直到顾客满意为止。

反思:你的软件开发流程中“完成”的定义是开发完成?测试完成?还是上线发布完成?

制作区运营:星巴克从点单开始,到制作咖啡过程中所有的设备、物料、卫生等都要每天维护使之保持最佳使用状态。这些基础设施的使用都是高可用且可以按需伸缩的:两个收银机、两台咖啡机——如果一台坏了,有另外一台备份。默认情况下只使用一台,如果到了忙时两台才会同时使用。这一切都要通过星巴克店面的看板信号机制来动态协调。

反思:你的软件交付基础设施和人员是否具备动态协调的能力?为什么?

星巴克咖啡交付的看板系统 #

当我们构建了单向的价值流之后,来看看星巴克是如何应用 DevOps 第二工作法——构建快速反馈的。

首先,从上述流程中,我们可以看到星巴克的四个积压队列(Backlog),分别是:点单队列、待制咖啡队列、制作中咖啡队列、待取咖啡队列。

这四个队列构成了星巴克咖啡交付的看板系统,每个环节都是一个单独的队列,并且通过不同的看板可视化积压情况。

点单队列 #

点单队列

如果你正在点单,收银员会在你犹豫的时候帮你推荐。然后它会记下你姓名,咖啡的类别和定制化的要求。并记录在杯子上,放到待做咖啡队列。

一般星巴克的店面都会有两个收银台。平常的情况下只有一名星伙伴收银。如果有客户在收银机排队,就是需求分析资源不足的信号,收银台需要补人。收银台补人的原则是把两个人看作一个单位,如果超出了 2.5 个单位。收银台需要再补充另外一个人。如果两个收银还是不够,值班主管会让一个伙伴拿着点单卡(如下图)提前记录客人需要。这样可以节约在收银台前的时候,客人选择和犹豫时耽误的时间。

这样就避免了点单队列(需求分析)的积压。

待做咖啡杯队列和饮品制作流水线 #

咖啡需求的 Backlog

此时待做咖啡队列就是一个个打上标记的空杯子。当空杯子数量超过5个,吧台里就需要有第二个人参与咖啡的制作,以减少待做队列里的积压。

简单的说,一杯标准的意式咖啡会包括三个环节:

  1. 制作浓缩咖啡(Espresso)。
  2. 制作奶沫。
  3. 混合并添加糖浆/冰块等配料。

在这三步中,第一步制作浓缩咖啡是需要等待的,在这期间星伙伴可以选择同时做其他的咖啡、制作奶沫或者增加配料。所以,咖啡不是一杯一杯交付的,而是一批一批交付的。

这样就减少的咖啡制作(开发)的积压。

待取咖啡杯队列 #

待取咖啡杯

当咖啡做完后,会加上盖子,咖啡师会根据杯子上的标记呼唤顾客的姓名。如果堆积的咖啡比较多,就会有一名星伙伴在咖啡待取区,通过呼叫客人的名字专门负责向客人交付咖啡。

这样就减少了咖啡待取区(发布部署)的积压。

店内外桌面队列 #

严格的说,店内的桌面的收拾是定时的。星巴克会有专门的伙伴,定时的来清理店面桌子上的咖啡杯和餐盘。这个角色就是我们之前说的 CS。由于店面内的清洁并不需要及时响应,所以只需要定时批量清洁就可以。

他们会采用定时器(上图左一胸口夹着的东西)来记录循环时间和需要做的事情,就相当于一个定时任务队列。并且通过把工作任务分类,任务清单可以确保每个步骤没有遗漏。

反思:你有维护清单吗?是否是定时任务检查的?

动态的减少各环节积压 #

从上文我们看到,任何一个队列的积压都是一个信号,这样的信号系统在使得每个人各司其职,无需主管协调。让店员能够及时的处理积压,无论需求积压(制作咖啡的量)有多大,都保保证稳定的产出。店面主管的作用就是时刻看住这五个队列,是否需要临时进行资源调配:

  1. 顾客队列就是看板,如果待点单的队列很长,就需要补充人员去收银台。

  2. 吧台内每个空的咖啡杯就是看板,如果空着的咖啡杯很长,那就说明需要有人来制作咖啡。

  3. 咖啡待取区也是看板,如果堆积的咖啡很多就需要有人来提示客户取咖啡。

  4. 桌面就是看板,没有人在座位上,且前面堆积了咖啡杯,就需要去清理掉。

一般来说,星巴克在非高峰时段保持五个店员:

  • 1~2个店员负责收银

  • 1~2个店员负责制作咖啡

  • 1 个店员负责叫顾客取咖啡

  • 1 个店员负责清理店内的桌面和地面

星巴克分为上午班和下午班,各8个小时。他们会在高分期安排换班,而且换班有1-2个小时的重叠,这个时间内星巴克的店面最多只有10 个人以应对高峰期的客流。

星巴克店员每个人都熟悉端到端全部的工作,任何一个人都可以顶替任何一个环节,在单一环节内高效产出。为了避免单一环节工作枯燥,则需要进行轮岗。这样,每个星巴克店员在不同的工作任务中慢慢树立起了整体观念。

此外,每个人会在8个小时的工作时间内休息2次。并且根据需要可以在4个不同的岗位中轮换。以保证每个人都能对每个步骤的操作熟练。

反思:你是否制定了相应的轮岗机制让每个团队成员体验不同交付环节的工作?

星巴克咖啡交付的自动化基础设施 #

星巴克的意式咖啡机和别处的咖啡机是不同的:咖啡豆的豆仓、研磨、出品意式浓缩在一台机器上。打奶沫的拉杆也是只有两档:开和关。

而大多数的意式咖啡机是和磨豆机分离的,制作意式浓缩前需要经历磨粉、压饼、萃取、去渣、冲洗 5 个步骤。相较于传统的咖啡机的磨粉、压饼、控制奶沫虽然缺少了定制性。但针对于大多数非专业的客群,这些标准和固定化的出品已经能满足需求。这样的自动化基础设施可以保证出品的稳定性。

反思:你是否分析了自己的交付流程的每一个动作?你是否拥有了自动化基础设施来降低技能的门槛并保证稳定的质量?

星巴克咖啡交付团队的自我学习和改进 #

制定目标的时候都有奖励和惩罚,惩罚的内容很简单,就是做最脏最累的工作:按照店面的整洁规范打扫,这被称之为深度清洁。并且不会让惩罚成为一种精神负担和压力。

反思:你是否可以通过把“提升熟练程度”当做一种替代的考评机制来提升团队成员的专业程度?

如果你下一次去星巴克,也许能尝试带着 DevOps 的眼睛去发现其中的秘密。

参考 #

星巴克营运岗位体系