很多团队做到一定规模，流程就开始变长。角色变多，每一步该谁处理、处理完交给谁，光靠文档和口头同步越来越说不清。这时候画一张流程图是最省事的办法。在阿里云的一些产品里，流程图还能直接变成可以运行的任务，不只是挂在会议室墙上的示意。这篇文章从概念、几个场景和具体做法，说说阿里云流程图该怎么用。
什么是阿里云流程图
阿里云流程图，指的是在阿里云的产品里，用图形界面把任务节点、判断分支和执行顺序画出来的能力。它有两种用法。一种是设计用的流程图，帮产品、开发和运营对齐每一步的理解。另一种是执行层面的可视化编排，画出来的节点可以直接对应到计算、数据处理或审批这类实际动作。
同一种能力在不同产品里叫法和做法不一样，常见的有以下几类。
- Serverless 工作流，用状态机定义函数之间的调用顺序，包括并行、重试和异常处理。订单处理、图片批量转换这类由事件触发的场景比较合适。
- DataWorks 可视化工作流，拖拽节点来编排数据同步、清洗和调度，数仓和报表链路常用它。
- 云效流水线，把代码检查、构建、测试、部署串成一条可视化流水线，适合持续交付。
- 宜搭流程设计，面向企业内部的表单审批和业务流转，请假、报销、采购这类流程可以放进去。
具体功能、界面和计费方式以阿里云官网的最新文档为准。选型前先确认当前版本支持哪些节点类型，别等画到一半才发现某个节点用不了。
案例一：电商订单处理
某中小型电商团队原来靠一个大服务处理订单。支付成功后，依次做库存扣减、优惠券核销、物流下单和短信通知。哪一步出错都要人工排查，最糟的时候库存扣了，货却没发出去。
后来他们改用 Serverless 工作流重画这条链路，大致是这样的。
- 接收支付成功事件，进入流程入口。
- 库存扣减和优惠券核销并行执行。
- 两个分支都成功，才进入物流下单；任何一个失败，就触发补偿逻辑，回滚已经完成的操作。
- 物流下单成功后，异步发送短信通知。
- 异常全部写入日志，超过重试次数的订单转入人工处理队列。
改完之后，最明显的变化是出了问题能查清楚。运营同事打开执行历史，就能看到某个订单停在哪一步，不用再找开发翻日志。
案例二：数据报表的每日调度
一家零售企业的数据团队，每天凌晨要从业务库同步订单数据，清洗后汇总进数仓，最后生成销售报表。以前几个定时任务各自运行，时间点凭经验估。上游还没跑完，下游就已经开始，报表经常是不完整的。
后来他们用 DataWorks 可视化工作流，把整条链路画成一张有依赖关系的图。同步完成才触发清洗，清洗通过质量校验才进入汇总，汇总结束再推送报表，每个节点都设了失败告警。一个月下来，报表延迟从每周几次降到基本没有。这个例子说明，流程图的很大一部分价值，是把原本藏在经验里的依赖关系写到明面上。
案例三：研发团队的发布流水线
一个十几人的研发小组，过去发版要手动做代码扫描、构建镜像、跑测试，再登录服务器部署。整个过程靠一份检查清单撑着，偶尔会漏掉某一步。
换成云效流水线后，流程固定下来。代码提交触发扫描，扫描通过后构建镜像，镜像推送到仓库后执行自动化测试，测试通过进入预发布环境，最后由负责人审批，才发布到生产。审批放在最后一步，人仍然在把关，重复性的动作却不用再人工盯着。
画流程图时要注意什么
从上面几个案例看，好用的流程图通常有几个共同点。
- 先和业务方对齐每个节点的含义，再去匹配具体的产品节点。工具细节放到后面考虑，否则图很容易越画越偏。
- 成功、失败、超时各自往哪里走，都要画清楚。线上事故很多出在没人设计过的异常分支上，失败路径值得花的时间比正常路径还多。
- 涉及库存、支付这类数据的节点，要写明重复执行会不会产生副作用，失败后怎么回滚。
- 节点超过二三十个，就拆成子流程，不然维护起来很费劲。
- 流程改了，图也要跟着改。图和线上配置一旦脱节，它就不再是参考。最好纳入变更管理，每次改流程都同步更新。
有三个坑比较常见。画完就放在那里，没人再看，是第一个。需要人判断的环节被硬塞进自动化，结果流程频繁卡住，是第二个。权限没管好是第三个。流程节点能调用的资源越多，越要说清楚谁能改流程、谁能触发执行。涉及生产环境的流程，建议加上审批和操作审计。
流程图最有用的时候，是业务、依赖和执行过程被放进同一张图里讲清楚。不管是订单链路、数据调度还是发布流程，先想清楚每个节点的输入、输出和异常去向，再选产品去实现，通常比直接上手拖拽省事。团队规模和业务复杂度上来以后，再把关键流程逐步迁到可视化编排上。
