Workflow如何一步步带动运维疯狂……

运维故事11：宫保鸡丁

1. 讨论功能，而不是流程

服务员：有位客人点了宫保鸡丁。

库克：好的！

厨师已经到了一半了.

服务员：客人说菜里不能有肉。

厨师：你叔叔，我的肉又都煮熟了。

但厨师还是一点一点地把肉挑出来。

一段时间后.

服务员：客人问我是否可以在菜里加点腐竹。

厨师：你不知道腐竹需要提前泡水吗？你说到一半了吗？去告诉他，如果你想吃腐竹，就等很久吧。

服务员：啊，你为什么不早点告诉我？

厨师：我怎么知道他要在宫保鸡丁里放腐竹呢？

然而，厨师却去泡腐竹了。

一段时间后.

服务员：客人问菜里有茄子吗？

厨师：如果加上茄子，还能叫宫保鸡丁吗？哪家餐厅做这种菜？

一段时间后.

服务员：客人说我们应该加鸡肉丁。

库克：你不是在开玩笑吧？你可以顺便问他还想要腐竹吗？如果你不想要它，我就把它扔掉。

客座官员：嘿，为什么这么慢？反正我还没付款。那是什么，服务员，我不想要食物了，请把它退回来。

在设计Workflow时，您需要考虑实现功能而不是流程。该过程不是一成不变的，在使用过程中往往需要不断优化和调整。讨论和实例化一个工作流是没有意义的，需求的反复变更令人沮丧。不管怎样，实例化的Workflow无法满足您的业务需求。因为，在开发周期结束之前的一段时间内，需求和流程可能已经发生了多次变化。

因此，工作流管理系统需要在设计和实现上提供足够的灵活性，以满足不同应用的需求。完善的组件化功能模块，让用户自己构建流程。而不是把所有的流程都写下来。让厨师负责提供配料，制作鸡肉丁、茄子、腐竹等各种食材。至于如何搭配，就让食客们自行选择吧。

2、没有“锁”就做不到

场景2

服务员：有位客人点了宫保鸡丁。

厨师A：好的！

厨师B：好的！

一段时间后.

服务员：先生，您要的两份宫保鸡丁到了。请慢慢使用它们。

客官：我只想要一份，为什么给我送来两盘？这是怎么回事，想黑别人的家人吗？说话间，他手臂一伸，取出一把重达二十八斤的鱼鳞紫金刀。

Workflow发布Case时，往往是面向某个角色或者某个群体，而不是某个特定的自然人。两个厨师互相不交流，所以可能会有多人操作。

操作是否幂等并不重要（多次操作与操作一次效果相同）。反之，多次操作就会出现严重问题。

开发程序时，必须考虑并发操作的影响。这是最起码的认识。 Case派发时，必须有一个“锁定机制”。其实现方法可以利用Case索赔来解决。只有领取任务的人才能看到任务内容。如果案件已被领取，则该案件将被锁定，并且无法再次点击，除非该案件的状态被修改（例如放弃或转移）。必须注意的是，案件执行的任何环节都不能出现多头管理。

3、色即空

客人：服务员，给我来一块宫保鸡丁。

服务员：先生，您要野鸡、山鸡还是家鸡？

客人：某户人家需要养鸡。

服务员：先生，鸡肉应该切成长块还是切块？

客座官员：我是故意啰嗦的，这取决于你。

服务员：先生，这道配菜需要黄瓜丁、花生丁还是胡萝卜丁？

客人：我全都想要。尽快为他们服务。

服务员：先生，我们有三位师傅，李师傅、高师傅、王师傅。您想请谁为您用餐？

客官：滚出去！

让流程变得过于复杂是一件非常糟糕的事情。请记住，少即是多，多则一无是处。

我们以硬件修复过程为例。我们团队曾经讨论过谁来发起报修申请的问题，出现了两种不同的声音。传统观点认为发起人应该是SE。还有一种不同的观点认为，每个人都可以发起报修申请，这样做可以及时报告报修情况。第二种观点是典型的“多此一举”的做法。硬件是否有故障需要专人确认。例如，如果我拔掉两个电源并重新插入一个，则系统出现故障，但实际上电源不需要维修。由于需要有人确认，所以这个角色只能是SE。只有SE负责服务器管理。他不仅是最有权威查看的人，也是最有权威判断的人。如果大家都发起维修申请，最后还是需要SE确认。如果采用这种方式，不仅无法及时报修，还需要凭空增加一个额外的确认链接。

我们再讲一个关于硬件维修的例子。当SE发起修复申请时，需要得到Owner（服务器的业务用户）的批准。由于部分故障维修需要停机，审批流程是通知业主做好准备。只有在所有者批准完成后，电子邮件才会发送给制造商。假设故障机器需要停机维修，机主在收到申请时有两种选择。首先，业主只批准批准，但不执行任何操作。他等待制造商的维护人员到达现场，然后才关闭机器。其次，业主首先完成业务迁移并关闭设备，然后批准并发送修复电子邮件，厂家到达现场后可以直接修复。

第一种方式，厂家维护人员到达现场后无法及时处理问题，只能等待系统下线迁移。整个确认过程涉及业务、监控、SE、IDC、硬件厂商五方沟通，大大增加了角色之间的互动性。这个流程的发布会导致各个角色之间的多重确认。当无论如何需要停机时，先做和后做没有区别。如果在线系统发现硬件问题，应该尽快重新定位，而不是等待。如果业务停不下来，问题就出在部署计划不到位。如果确实不具备第一时间开始迁移工作的条件，应尽快搭建好迁移环境，待迁移工作完成后再发送修复邮件。

4、君臣无分。

客座：服务员，服务员，快出来。

服务员：先生，您要点什么？

服务员：你们是一家鸟店。点了一坛老酒，五斤牛肉，两个大煎饼，蒸黄鱼，红烧鹿肉，孜然羊腿，宫保鸡丁各一份。已经走了一半了。时间，为什么我们看不到上菜的样子？

服务员：先生，别着急，其他的菜都已经准备好了。因为后院没有鸡，店主就回家去取。客人会稍等片刻，待宫保鸡丁做好后，才会给您端上较小的。

客官：混蛋，你太粗鲁了。到时候黄花菜都冷了，还能吃吗？不要离开。请先给我一拳。

我们以硬件修复系统的流程为例。 SE发起维修申请时，允许同时提交多台故障设备进行合并处理。工作流将所有设备作为案例发布。然而，这些设备并不一定能够一次性修复。因为有些设备可能无法下线，有些设备可能不是同一家供应商，所以如果等待Case中的所有设备都修好后再终止，就会出现逻辑问题。有些设备明明已经修复过，但在修复过程中却处于未完成的状态。而且，本案中可能有多名业主。谁来结案也是一个问题。

因此，Case应该分层管理。一个Case包含多个Task，一台设备对应一个Task。案例由请求维修的人员创建，任务由填充设备自动生成。每个任务完成后，SE 确认其关闭。当所有任务都关闭时，案例将自动关闭。

5. 死胡同

店主：服务员，客人点的宫保鸡丁怎么还没到？

服务员：我们的鸡肉用完了，所以我们没有煮它。

店主：你个混蛋，怎么不跟客官打个招呼，让他换菜，害得他在那里等了半个小时。

服务员：你不是说顾客至上，不能拒绝吗？我不会做饭，也无法拒绝。你想让我做什么？

在工作流程结束之前，无论流程到达哪一步，都必须能够进退自如。它不能被留在角落里而没有任何进一步的进展。如果我无法执行某项操作，则应允许我拒绝执行该操作并让业务状态回滚或结束。有些Workflow系统的“官方导向”设计理念非常严重。通常审批步骤有拒绝权限，但审批人连申请都不看一眼，总是说“同意，谢谢，请支持”。相反，在执行过程中，执行人无法拒绝错误的请求，必须下线与申请人沟通。

6. 混合名词

客人：服务员，这个“火山喷雪”真有趣。请快点为某人买一份。

服务员：好的！ 《火山喷雪》是一个盘子，请慢慢使用。

客官：放开我，这是什么？竟然敢对某某家族下手？这不是西红柿加糖吗？

编辑推荐：

1）资深系统运维专家撰写，知名运维专家推荐，注重方法和思路，将无聊操作提升到设计和建模的层面

2）从IT基础设施角度，分析数据中心选型与规划、管理流程设计与实施、基础服务建设、系统运维实战处理、职业发展探讨等。