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万，改变速约~~~~