Workflow 是如何一步步逼疯运维的...「文末福利」

来源:云技术实践

ID:kvm_virt」

和CMDB一样,Workflow在设计过程中也存在着各种各样的问题。不过文章平铺直叙到这里,我自己也觉得有些烦躁了。不如这样,我们这次来个特别的安排,一边讲笑话一边分析问题。当然,这是一个根据关于需求变更的经典笑话改编而成的,也许你看过第一个,但我保证你没有看过后面几个。

运维的故事1:宫保鸡丁

1. 讨论功能而非流程

小二:有位客官点了一份宫保鸡丁。

厨子:好嘞!

厨子做到一半……

小二:客官说菜里不要放肉。

厨子:你大爷,我肉都回锅了。

然而,厨子还是一点点把肉挑出来了。

又过了一会儿……

小二:客官问菜里能给加点儿腐竹吗?

厨子:你不知道腐竹得提前泡水?炒到一半才说?你去跟他说,想吃腐竹就多等半天。

小二:啊,你怎么不早说?

厨子:我怎么知道他要往宫保鸡丁里放腐竹。

然而,厨子还是去泡腐竹了。

又过了一会儿……

小二:客官问菜里有没有加茄丁?

厨子:加了茄丁,那还能叫宫保鸡丁吗?哪个店家这么做菜?

又过了一会儿……

小二:客官说还是加上鸡丁吧。

厨子:你这不是玩儿我呢么?你顺道问问他,腐竹还要不要?不要我就扔了。

客官:咦,怎么这么慢?反正还没付钱。那个什么,小二,菜我不要了,退了吧。

Workflow在设计时,需要考虑实现的是功能而非流程。流程并不是一成不变的,往往需要在使用过程中不断地优化和调整,展开讨论并实例化一个Workflow是无意义的,需求的反复变更是令人崩溃。不论怎样,实例化的Workflow都没法满足你的业务需求。因为,在你的开发周期还没有结束的这段期间里,需求和流程可能已经变更好几次了。

因此,Workflow管理系统在设计和实施中,需要提供足够的柔性,来满足不同应用的需要。完成组件化的功能模块,让用户自己去构建流程。而不是把所有的流程全部写死。让厨子负责提供组件,把鸡丁、茄丁、腐竹什么的统统都做好。至于怎么搭配,让食客自主选择。

2. 无“锁”不能

场景二

小二:有位客官点了一份宫保鸡丁。

厨子甲:好嘞!

厨子乙:好嘞!

过了一会儿……

小二:客官,你要的两份宫保鸡丁来啦,请你慢用。

客官:我只要了一份,为啥端了两盘上来?怎么着,想黑某家?说话间,探臂膀伸手拉出了二十八斤重的鱼鳞紫金刀。

Workflow在下发Case的时候,往往是面向一个角色、一个群组而非一个具体的自然人。两个厨子相互之间是没有沟通的,所以有可能出现多人操作的情况。

假如这个操作是幂等的(操作多次和操作一次的影响是相同的)则无所谓。反之,多次操作就会出现很严重的问题。

程序开发时,必须要考虑到并发操作所带来的影响,这是起码的意识。在Case派发的时候,必须有“锁机制”。实现方法可以使用Case认领的方式来解决,只有认领的人才能看到任务内容。如果一个Case已经被人认领了,那么它将被锁定,不能进行第二次点击,除非Case的状态被修改(比如放弃或者转交)。必须注意,Case的执行在任何一个环节上都不能出现多头管理的情况。

3. 色即是空

客官:小二,给我来一份宫保鸡丁。

小二:客官,你这鸡丁是要山鸡、野鸡还是家养的土鸡?

客官:某家自是要家养的土鸡了。

小二:客官,鸡丁是切长块儿,还是方块儿?

客官:刻意地啰嗦了,随你罢了。

小二:客官,你这配菜是要黄瓜丁、花生米、还是胡萝卜丁?

客官:都要都要,你等只管快些上菜。

小二:客官,我们这有李、高、王三位师傅,你要谁伺候你这顿饭食?

客官:滚!

把流程设计得太复杂,是一件非常糟糕的事情。切记,少就是多,多即是无。

我们举一个硬件报修流程的例子。我们的团队曾经在讨论由谁发起报修申请的这个问题上,出现过两种不同的声音。传统观点认为发起人应当是SE。还有一种不同的观点认为,所有人都可以发起报修申请,这样做可以及时报修。第二种观点就是典型的“画蛇添足”。硬件有没有故障是需要人去确认的。你比方说,我把两路电源拔掉一路再插上,对于系统来说就是一次故障,但实际上电源并不需要维修。既然需要人来确认,那么这个角色只能是SE。只有SE是负责服务器管理的,他既是有权限查看的人,也是最具权威判断的人。如果所有人都去发起报修申请,最后还是需要SE来确认的。采取这样的方式,不但不能及时报修,还凭空多出一个确认环节,岂不是庸人自扰么?

再说一个关于硬件报修的例子。当SE发起报修申请后,需要由Owner(服务器的业务使用方)进行审批,因为一些故障的维修需要停机,审批的过程也就是告知Owner做好准备。只有Owner审批完成后,邮件才会发送给厂商。假设这台故障机需要停机维修,Owner在收到申请的时候有两种选择。第一,Owner只是审批通过,但什么都不干,等厂商的维修人员到现场后再做停机处理。第二,Owner先完成业务迁移工作并关停设备,然后审批通过发送报修邮件,厂商到现场后可以直接维修。

第一种做法,厂商的维修人员到了现场不能及时处理,还要等待系统迁移下线。整个确认过程中涉及到业务、监控、SE、IDC、硬件厂商五方进行沟通,大大增加了个角色之间的交互工作。这种流程的发布,会导致各角色之间反复的多次确认。在不管怎样都需要停机的情况下,先做和后做是没有区别的,一个线上系统如果发现硬件问题,应当在第一时间及时迁走,而不是等待。如果业务不能停,是部署规划不到位的问题。如果确实没有条件在第一时间展开迁移工作,那么应当尽快搭建迁移环境,待完成迁移工作后再发送报修邮件。

4. 君臣不分

客官:小二,小二,快些出来。

小二:客官,你有何吩咐?

客官:你这鸟店家,某家点了一坛老酒,五斤牛肉,两张大饼,清蒸黄鱼、红烧鹿肉、孜然羊腿、宫保鸡丁各一份,现在已过了半个时辰,为何不见上菜?

小二:客官莫急,其他的菜都已做好。只因后院鸡肉不曾备得,掌柜的回家去取了。客官稍带片刻,待那宫保鸡丁做好,小的一并给你端上来。

客官:混账,你这厮好生无礼。待到那时,黄花菜都凉了,那还能吃吗?不要走,且先请你吃我一拳。

我们还是用硬件报修系统的流程来举例。SE在发起报修申请的时候,为了合并处理,允许一次提交多个故障设备。Workflow把所有的设备,作为一个Case发布出去了。但是,这些设备不一定一次性修完。因为,有些设备可能没法下线,而有些不是一个供应商,所以如果等待Case内的所有设备都修完再终结就会出现逻辑问题。有些设备明明修完了,在流程中却属于未完成的状态。而且Case里可能会有很多Owner,到底谁来关闭这个Case也是个问题。

所以Case应当是分级管理的。一个Case下面包含若干个Task,一个设备对应一个Task。Case由报修人创建,Task随着填写设备自动生成,每一个Task完成后由SE确认关闭,当所有Task都关闭时,Case自动关闭。

5. 死路不通

掌柜:小二,客官点的宫保鸡丁为什么迟迟没上来。

小二:鸡肉没有了,所以没做。

掌柜:混账东西,那你为什么不和客官打声招呼,让他换个菜,害得人家在那里等了半个时辰。

小二:不是你说,客户为先,不能Say No的吗?菜又做不了,拒绝又不行,你让我怎么办?

Workflow在没有结束之前,不管流程走到哪一步,都必须能够进退自如,不能丢在一个角落里面就没有下文了。假使一个操作我执行不了,那么应当允许我拒绝执行,让业务状态回退或者结束。一些Workflow系统的“官本位”的设计理念非常严重。往往是审批这一步有拒绝权限,而审批人面对申请从来都是看也不看,一律“同意、谢谢、请支持”。反而是在执行环节,执行人在面对错误的请求时无法拒绝,只好到线下去找申请人进行沟通。

6. 名词乱入

客官:小二,这道“火山喷雪”煞是有趣,快些给某家来上一份。

小二:好嘞!“火山喷雪”一盘,请你慢用。

客官:我去,这是什么?你这厮竟敢戏耍某家,这不是西红柿拌白糖么?

Workflow作为规范实例,在业务描述中要使该业务领域的专有名词。当行家要说行话,用词必须要准确,不能去自己造词。比如,我们有两个不同ISP的数据中心,要在它们之间构建一套DNS系统。为了实现流量划分,根据请求的客户端地址范围分别提供不同的域名解析结果,实现将不同线路上的用户划分到两个不同的数据中心去。这就是View的概念,View就叫View,而且只能叫做View,你不能叫分组解析等其他的名字,因为在DNS里面没有你那个所谓的分组解析的概念。乱起名字会引起混淆,对于操作者来说,有可能会引起误操作。

《Linux云计算及运维架构师高薪实战班》2018年07月16日即将开课中,120天冲击Linux运维年薪30万,改变速约~~~~

原文发布于微信公众号 - 马哥Linux运维(magedu-Linux)

原文发表时间:2018-06-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏申龙斌的程序人生

学会10多种语言是种什么样的体验?

80年代末,我第一次接触了Apple II电脑上的BASIC编程语言,从此走上了一条程序人生。十多年前我在博客园上开通了自己的博客,由于下象棋时经常出点“毒”招...

2926
来自专栏ThoughtWorks

其实你早就学过响应式编程 | TW洞见

今日洞见 文章作者/图片 来自ThoughtWorks:佟达。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网...

33312
来自专栏牛客网

三七互娱秋招提前批 java服务端

    我是在6月5号参加了三七互娱的秋招的web后端线上笔试,第二天又参加了java服务端的线上笔试,之后去三七大楼参加open day,然后面试时一面,二面...

901
来自专栏HenCoder

HenCoder 3-1 触摸反馈,以及 HenCoder Plus

这期的内容是之前说过的,自定义 View 的最后一部分:触摸反馈。触摸反馈的概念简单,但是内部逻辑比较复杂,往往把开发者难倒、让人总也学不会的也是因为逻辑太多绕...

592
来自专栏SAP最佳业务实践

SAP最佳业务实践:MM–有JIT交货计划的采购(230)-1业务概览

用途 此业务情景关注于即时(JIT) 采购流程。 描述了在典型的重复制造环境中的内向采购处理。 使用计划协议可以缩短处理时间并减少您要面对的文书工作量。一个...

2784
来自专栏BestSDK

勾引程序员的11个方法,第4招百试不爽

一、写纯文本格式的邮件 ? 程序员通常不喜欢你那些花里胡哨的邮件——比如粉红的标题、粗体的HTML格式的邮件内容、并且还内嵌图片。他们喜欢的是简洁命令的纯文字表...

37010
来自专栏镁客网

拔刺 | 大数据杀熟是真的吗?

有人觉得随着智能电视的功能越来越多,盒子的优势越来越不明显,盒子马上就会被取代了。其实不然,现阶段盒子仍然热销就有它热销的原因。

772
来自专栏腾讯Bugly的专栏

【MIG专项测试组】如何量化Android应用的“卡”?---流畅度原理&定义篇

腾讯Bugly特邀鹅厂MIG专项测试组,陆续为大家分享移动应用质量的有效评估方法。 MIG专项测试组 ? 致力于为腾讯移动互联网事业群(MIG)提供专项评测及...

4005
来自专栏北京马哥教育

Python Web不知道怎么学?看这篇就够了!

Python的用处太多,前端、后端、数据、ML\AI、自动化等等等等。很多小白不知道学习方向导致学的东西太杂,技能范围很广但是没有高度,自己玩可以工作就完蛋。这...

33910
来自专栏生信技能树

peerJ期刊探索

开放获取的期刊--PeerJ由Peter Binfield(曾在PLOS ONE任职)和Jason Hoyt(曾为Mendeley的首席科学家)于2012年6月...

2994

扫码关注云+社区