Hugo Gu

几乎所有的系统设计都会涉及到状态，需要理清楚有几个状态，状态之间是如何流转的。状态本身设计的好坏，常常对系统的后期演化有着深远的影响。本文试以电商订单为例，聊聊设计状态的时候，需要关注的点有哪些，如何通过系统化思考来尽量保障状态设计的适应性。

背景

电商订单是大家再熟悉不过的场景，从客户提交订单开始，到商品交付结束，再加上期间的用户支付，一个最简单的订单状态机大概会长这样（其中绿色表示终态）。

这个状态，一般会被放在Order表里的State列上。

然后，请仔细思考一下，上面的状态设计是否是合理的。按多数剧本，作为第一个模型，一定是不合理的。

好了，现在假设你已经想好了。无论你觉得这个设计里有哪些问题，先放下答案，再去思考这样一个问题：你是从哪些角度、维度和方向思考的？你为什么会选择那些角度去评估这个设计？你思考这个设计合理性时，所遵循的原则是什么？有没有什么假设？你选择的这些角度、维度、原则，是针对这一个电商场景才需要的？还是对所有类型的状态机设计都是普适的？有没有哪些原则，是所有的状态机设计都需要考虑的？你如何验证自己认为的这些普适原则，真的是普适的。

本文的目的，不是做出一个最合理的订单状态设计案。而是通过电商订单这个例子的状态机设计一步步地演进，同时展示错误的和经过一定思考的不同方案，让大家对于如何做设计，状态设计的原则和标准，形成一些初步的认识。（意思是，你不要有，看一篇文章就可以掌握一个思维模式或方法论的期望，即使有一定概率。）

问题

回到上面的状态机设计上，我们结合现实场景，再思考一下，上面的状态机，是否能应对如下几个问题：

• 如何支持货到付款？
• 如何支持更多的支付和快递相关状态？比如，支付中和投递中。
• 如何支持一个订单，多个快递？

我们一个个地处理一下。

方案

第一个问题，支持货到付款，本质上，是把Paid放在Delivered之后。显然，支付货到付款不是“全面切换”货到付款的意思。所以，两种情况会并存。于是，我们顺理成章地得到如下新的状态机。

有问题吗？好像不太对劲。比如终态怎么还能迁移呢？讲道理哈，针对每一个具体的订单，只有一个固定的流程。要么是走蓝色线，要么是走紫色线。所以并不存在这个“终态再迁移”的问题。

第二个问题，支持更多的状态。加就是了啊。这有什么难的？只是可能要分别处理一下要不要支持货到付款的情况。我们有点儿追求，两个方案都做。

至于到底要用哪个方案，产品来拍个板就好，到底要不要支持货到付款，是个非常重要的，影响整体设计的关键决策呢！

最后一个问题，如何支持多派送单？既然都有了多个派送单了，拆表是肯定要拆了，但是还有一个问题，就是如何在订单状态上体现出一部分派送了一部分没派送这个情况。只是现在情况有点儿复杂，要考虑前面两个问题的答案，才能知道这个如何做。所有的方案排列组合一共有4种，就不一一列出了，只列一个最简单的吧。如下图所示。

补充一下，其中Partially Paid和Partially Delivered都是可选状态，如果一起到的话呢，是可以直接到Paid和Delivered状态的。这是多么灵活，多么人性化的设计啊。

以上，所有问题都解决了。

---

以上方案都是扯淡。这是停止扯淡的分隔线。

---

解题

状态机设计，最核心的问题是：先搞清楚是在设计什么东西的状态。

想一想，我们是在设计订单的状态吗？可以想象自己是一名客服。接到了客户的电话，这么讲：

你好，我的订单号是1234567890，我能问下这个订单现在是什么状态吗？怎么卡住了？

你有大体两种响应方式。一、把这个订单的所有细节，包括多个物流及支付单都过一下，看看哪里卡住了，原因是什么。二、先问客户确认一下，是哪部分，出了问题。

所以你看，订单其实是多个不同的东西的聚合体，里面的每个部分都是独立的，都有自己的状态。而且状态的变化相对独立。

那么问题来了，订单里的各个服务，又如何划分呢？我按前后端分行不行？当然不行了。这里便引出了，判断模块、组件划分合理性的基本原则：划出的各个模块之间是否正交（即，改变一个模块，而不对其它模块产生影响的性质）。

支付和物流属于订单的一部分，彼此又没有强业务上的依赖关系。那么把他们独立为一个模块，并自己维护自己的状态，会是更合理的选择。从而不难得出如下设计：

这样，三个不同的状态，维护三个不同的对象的状态。每一个对象的状态都是相对稳定的。

我们怎么知道分成这三个状态是不是合理的，是不是足够正交了呢？只要试着，把其中一个对象独立出Order，看各自是否需要做什么改变就好。理想情况下，不用做业务变更，就可以做到下面这样——直接把Delivery拆分成独立服务：

于是产品也不需要被迫天天做些莫须有的关键决定——比如，要不要支持货到付款。在这个设计下，根本不是一个重要的问题。当然，处理货到付款的逻辑还是存在的，只是这个决策的影响范围只是在顶层业务逻辑上，而不会影响到底层状态机的设计。

这又引出另一个良好的设计的判定标准。好的架构设计，能让人更晚地去做关键的业务决定（因为好的设计，能在无额外成本的前提下，支持更丰富的业务模式）。良好的设计，从实际场景出发，归纳、整理、抽象出能普适的模型，在解决具体问题的同时，又能维护好通用性。

最后，展示给用户看的状态，可以是这三个不同对象的状态，在不同模式的下的灵活组合。如下图所示：

注意这里展示给用户的状态的命名，和订单上每个对象上的状态并不需要一样，而且也并不一定要合并成一个状态来展示。这里只是表达这样一个理念：用户状态和系统内部状态分离，以便两个状态都可以独立发生变化。

结语

设计的优劣，是决定服务长期可扩展性和可维护性，并持续产生价值的关键因素。而好的设计，需要结合业务实际场景，应用合理的原则，做进一步的分析和建模才能得出；它既不能是原始需求的简单堆砌，也不能是既往经验的原封照搬。

最后，也是最重要的是，是真的能把以上道理用到该用的地方去。如果你发现你没有用上过，或是没有机会用上，那其实只说明你还不是真的懂。

未有知而不行者。知而不行，只是未知。——《传习录》

我不是厨子，也没有兴趣教别人如何做饭，毕竟做什么饭，怎么做饭，都是看个人爱好的。我既无权，也无意发表太多意见。然而遗憾的是，我绝大多数时候都是吃别人做的饭，而且觉得很难吃，所以对做饭这事儿，还是想说说自己的看法。又考虑到我不是专业的厨师，所以我只讲开始学做饭这段儿。

我开始做饭的理由很简单，自己爱吃的东西，总得自己做出来的才对味。简单到番茄炒蛋这种最基本的国民菜，去每家餐馆，口味都是不一样。更要命的是，哪怕同一家，你每次去，做出来，口味也都能不一样。作为一个吃货，这很要命，于是我决定自己做。我最开始练手的菜就是番茄炒蛋。大概自己炒了三五次吧，就已经是家里炒番茄炒蛋炒得最好吃的了。这不是自己觉得的，是家里人和邻居朋友都说不错。包括家里四岁的小屁娃。

做得顺手了之后，逐渐做过稍大的家常菜，比如红烧肉、糖醋鱼、小鸡炖蘑菇、酱汁扣肉什么的。只是到现在也还没有做过干煸刀豆（因为太费油），佛跳墙（因为太复杂）还有烤鸭（因为没有设备）。这些也没打算自己做，一则自己做不合算，二则，也给下馆子留个念想。要是自己什么都比别人炒得好了，好到下馆子的欲望都没有了的话，人生也失去了一种乐趣不是？

学做菜的窍门其实就一个，就是想要把菜做好，而不是想填饱肚子，也不能是想省钱，也不是做家务尽义务，更不能是想发朋友圈。

头几十年，国家物资匮乏的时候，要米没米，要油没油，要糖没糖，好多人也没有这心思去琢磨怎么做饭更好吃，那时候人们天天主要都在琢磨怎么让家里人不饿死。至于做饭的手法和技巧上，不少都是在考虑如何用最少的时间，最少的物料，喂饱最多的人。在这个心态下，做了几十年。然后现在物资充沛了，做饭很难一下子好吃起来，因为之前的做法已经习惯了，改不了了。

有些被迫做饭的，因为本来就不想做，做的时候也就不走心。一真要做，就装不知道怎么做啊，不知道火要开多大，不知道油要倒多少，做个最简单的煎荷包蛋，倒上一层油，然后怕烫到，往锅里窝鸡蛋的时候，把鸡蛋举得老高，鸡蛋就像高台跳水一样跳到滚油里，然后把热油溅得到处都是，还害身上、脸上起几个大包，于是自己便得了理，说，我说我不会做的，这下好了吧。自此以后就心安理得地告别了厨房。

如果做菜是为了发圈，那东西总得做得好看些，拍的照片也得漂亮些。于是菜还没炒，炒菜的家伙事儿就先提上了日程。比如切菜板就有讲，木质不能太软，一切菜就掉木屑；也不能太硬，刀工不到家刀刀切到木板，刀就开始卷刃蹦刃。再说刀，切菜的和砍骨的要分开，蔬果刀要锋利，须得高硬度，高碳锰钢比较合适。其它的锅啦、灶台啦花样就更多了。可能做菜的原料都还没有准备好，各式的调查研究已经走全乎了。然后做饭的过程中，总得给人讲讲吧，让看的人知道是怎么回事吧。于是还得准备上各式的温度计、计时器及秤等。做菜的用料须得精确到克，用时须得精确到秒，火候须得精确到度。（话说前几年给奶娃喂奶差不多也是这阵仗。）最后摆盘更是重中之重，最好如一盆景一般重视，好好的一盘番茄炒蛋，总不能在装盘上功亏一篑。好不好吃呢？管他呢，反正朋友圈里的看客们是吃不到的。

其实呢，准备充分不是个坏事儿，只是有的时候，周末睡个懒觉，十点钟才起床，打算开始做个早饭兼午饭，脑子突然抽筋，想要吃蛋挞，然后就躺床上拿着手机，先开始百度“如何做蛋挞”，然后再知乎“哪款烤箱最适合烤蛋挞”，然后再淘宝烤箱。就感觉哪里有点儿不太对劲。而且脑子老是这么抽筋，怕烤箱到了，心里又想着吃别的去了。

话说回来。如何开始做饭呢？重点在做饭上，不在如何上，也不开始上。就是这么简单。

《坐井观天》是人教版小学二年级语文课文。小时候学的时候，只知道这大概是教人开阔眼界。但是最近吃饭遛弯聊到这则故事，于是我又复读了一遍，却发现自己看不出，把这种故事放到小学课文里，到底是想说什么了。

这个故事的原型出自《庄子·秋水》。原文如下：

北海若曰：「井蛙不可以語於海者，拘於虛也；
夏蟲不可以語於冰者，篤於時也；」

《荀子·正论》中也有演绎：

彼楚越者，且时享、岁贡，终王之属也，
必齐之日祭月祀之属，然后曰受制邪？
是规磨之说也。沟中之瘠也，
则未足与及王者之制也。
语曰：“浅不足与测深，愚不足与谋智，
坎井之蛙，不可与语东海之乐。”
此之谓也。

然后我们看看小学语文的版本。我就不作评论了。

工作久了，不难发现一个现象：在一些公司被奉为圭臬的原则，在另一些公司却被弃若弊履。当然，各个公司业务模式不同，阶段不一，在实操层面应用不同的术，是非常自然而且合理的事儿。每个公司都可以而且应该，根据自己的实际情况，选择最适合当下环境的术来处理每天的具体事务。

这个根据情况决定适用的“术”的过程，本身也是一种“术”。每个公司都会有不同的做法。比如有的公司会期望充分发挥员工本身的主观能动性，自行分析情况决定使用什么“术”。有的公司呢，会由管理层分析并决定，层层领会学习贯彻实施。这两个方式都在各自的条件下可行。

让员工自行决定“术”的这个方式，在员工能力非常强，而且“术”相近的情况下会更适用。否则很容易产生彼此格格不入的“术”，轻则影响工作效率，重则引发员工冲突。这种做事儿方法与理念上的冲突通常都不太好调和，处理不当就会以某方退出收场。这也并不是说上令下行的模式就不会产生这样的冲突，但是毕竟“术”是事前沟通好了的，不过至少比事事、时时上都可能产生冲突的模式要好得多。对于需要激发员工创造力和主观能动性以便更好地完成工作的公司，一般都给员工一定的自由度去决定达成具体事务的“术”，这也是当今科技公司的流行做法。那么问题在于，在这种环境中，如何缓解“术”上的冲突问题呢？

想缓解冲突，就必须先了解其产生的原因与来源。其实很简单，当大家对同一件事儿，有不同看法的时候，就会有冲突。而当这个事儿的最合适的方案不是那么明显的时候，这种冲突就会更加明显。因为这时，常常是双方都认为自己是对的，自己是理客中，认为对方冥顽不灵，食古不化，不可救药。

这种例子不胜枚举。比如我之前待过的一家公司的CTO在一次小事故之后跟我们讲，你们少写这些自动化的东西，搞不好产生环境就搞坏了，以后所有动生产环境的操作，必须纯手工。以防出错。当时想，这可糟了，我对我工作的定义就是，我要让电脑把我需要干的活都干了，而不是反过来。所以没多久我就借故离职了。我之前还待过的一家公司的运维负责人，要求所有的权限必须给到人，不能给服务，不能给机器 ，不能给脚本，不能给CICD，给也给到人然后委托给到这些东西。跟他讲服务间授权体系的需要，他说，这我不管，反正“权限只能给到具体的人”，这是原则！后来我到另一家公司，运维的方式简直是180度倒转，企图把人身上的权限全收回，最好都给服务和机器。说实话，我特别希望能有机会请这两家公司的运维负责人一起喝个茶。:-)

这里并不想讨论到底哪种是对的，哪种是好的，也不想分析各自的使用场景什么的。这些都不重要。这里想说的重点是，你看，完全对立的做事儿方式，其实都可以工作，而且都能工作得很好。引发冲突的，其实只是类似这样态度和思路：“你说得不对，这事儿就是这样的，这是原则，这是制度，这是公司条例，没得讨论”。在一些人脑子中，什么事儿定下来就是定下来了，不讲环境，不看变化，拒绝讨论。但是当你真这么说他的时候，他就会说，我哪有拒绝讨论，你到底要什么？你有方案吗？没有？没有你BB个毛线啊？要不你出个方案吧？【注：这就好比你去商场买东西，售货员说没有。你说，哦，没有啊，售货员一听就怒了，你怎么说话的？怎么能说我们没有呢？你有你做一个啊，我们马上就可以卖给你！】我一向都不大擅长和这种人打交道。

这里其实想说的是：永远不要认为，自己的某个认识，是最正确的。也永远不要认为什么事儿，就一定只能如何如何，不能如何如何。所有的理念，方法论，术，都要看环境，看时机。小到求职就业，大到吃喝拉撒睡，无不如是。最重要的，是能自始至终地，针对具体情况分析、探寻问题的根本，追求更适合的方案。一但你开始感觉自己已经找到答案了，其实你也就同时停止前进了。所谓“Stay Foolish, Stay Hungary.” 大概就是对此最著名最精炼的解释。

上面说的主要是认识冲突。并没有讨论利益上的冲突。因为利益上的冲突相对容易处理些。

每个深刻的领会后面，一般都会有点儿故事。在我工作5到8年的那段时间，我一度非常迷茫，迷茫于不知道到底如何做才能做到最好，才能不出问题，才能最能让领导满意。有次我领导的领导来上海，就坐我边儿上，我和他闲聊，我问他，你认为工作中最重要的原则是什么？或者说，我应该用哪些原则来指导我的工作？他想了一会儿，大概是猜到了我这个问题的背后是颗多么天真的大脑，一脸严肃地和我说，Hugo，没有什么原则是能帮你解决所有问题的，总是要看具体情况的。（大意）当然，我也并没有随着这句话大彻大悟什么。只是这几年间，才慢慢体会到这句话其实是多么的有含金量。这个我或许和一些人讲过，我现在最大的原则就是：没有原则。【不知多少愣头青要意会为不讲原则。】

遗憾的是，我现在依然会和很多人有冲突，我也并不觉得会有不再有冲突的那天。只是在我眼中，那些冲突都已经不再让我忧心忡忡，因为说得简单些，只要把产生冲突的问题解决掉，冲突就不在了。只要专注解决问题和解决问题的方案就好。

作业：从阿里的过往的新闻来分析，阿里会如何处理冲突与矛盾呢？

【防杠精小贴士：不要拿什么“小孩子才分对错，成年人眼中只讨论利益”。这种陈词滥调说事儿了，利益就能算得清了吗？扯淡我也会：“小孩子才觉得利益就是个数字，算算就一清二白的；成年人只讨论取舍”。这种讨论没头，吃饭的时候拿来吹吹NB就算了，这说正事呢。】

面试的时候我见到过不少毕业没几年的候选人，被问到自己想换工作的原因，会说感觉现在做的事情没有什么技术含量，所以想找个有技术含量的公司，做点儿有技术含量的事儿。

然后我让他举个例子，讲讲怎么个没技术含量了？他会说，天天就是写些业务代码，天天就是CRUD，代码Copy来Copy去，用的技术也特别陈旧，感觉自己的能力完全发挥不出来，已经到了职业生涯的天花板了。讲得头头是道，让人感觉他不换工作，就要被整个公司拖累了，这辈子都要白活了。

然后我再问，你感觉什么是有技术含量？他说，怎么着也得有上千万活跃用户，几十亿PV吧。要不然数据量没到这个量级，根本遇不到太严重的问题，也根本用不到那些有技术含量的方案去解决。

一般聊到这里，我就开始准备收场送客了。客观原因是我们目前没有几十亿PV，怕他会觉得工作内容匹配不了他的能力与愿景。主观原因是我认为他对于什么是有技术含量的有偏见，同时自身能力也不合格。在我看来，对于绝大多数十年以下工作经验的人来讲，没有技术含量低的项目，只有技术含量低的实现方式。不要抬杠说一个登录页面和自动驾驶系统能一样吗？

但是礼貌起见，我会继续和候选人聊聊他们的技术栈。问问他，现在在写的CRUD代码，是哪部分让自己感觉特别无聊，有没有什么可以改进的地方？他在Copy Paste代码之前，有没有想过其他的更合适的方式去实现同样的功能？如果在这部分，这个候选人能够表现出任何一点先调研再开发，有任何一次用公司尚没有人用过的方式去做事的心气，我都会充满兴趣地继续聊下去。然而遗憾的是，几年中，但凡是前述方式解释自己换工作原因的人，能表现出自这一点的，我印象中是一个都没有。

这些东西干巴巴地讲比较模糊。我举个例子。

曾经遇到一位3、4年经验的候选人讲，他们公司的接口层代码，全部都是从HttpServletRequest中解析参数，自己反序列化，天天好多时间就写这种get/set代码。感觉特别无聊，而且学不到任何东西。我问他你知道PathVariable和RequestParam么？他说好像见过，但是公司现有的代码没有用这个的，自己也就没有用。我问他，你觉得现在这个不好，那你有试着找过更好的方式吗？他说他天天就忙着写代码，天天加班到10点11点，哪有时间学新东西呢？

其实这种人非常被动，如果没有人强压着灌输一些新知识，他永远就只会用自己已经熟悉的方式去做事儿。我有时在想，这是我们从小接受的教育模式使然，还是说有的人性格就是这样呢？我倾向于两者共同作用的结果。

那位候选人倒还比较谦虚，面到后面就闲聊了些东西，他问我有什么建议，我便建议他，如果想有进步，以后可以这样做：假设有一个任务，做过类似的，也知道如何做，估的时候大概要花一天。怎么做呢？先不要去做，先花4-6个小时尽可能多地找可行的方案，然后用自己能找到并能控制的最佳方案去做；大概率2个小时就可以搞定；如果找不到怎么办？这个时候再加班搞定；这样坚持个几年，基本上工程技术上就没什么问题了。

只是不知道他后来有没有听进去。因为现在想来，我当时漏了一个关键点没有提醒到他。就是这种做法，大概率会受到保守型的上级领导的挑战。一句话就能让这些主观能动性不高的人打起退堂鼓：用什么新的做法？出了问题，你负得起这个责任吗？如果自己他不坚持，他是不会有机会实施这种做法的。如果他坚持，哪怕是保守型的领导，大概率也会支持的（当然，如果不是什么大事儿的话）。

这种事儿还有另一种做法。就是先做，只是做的过程自己需要保证不出问题，做足预案，出了问题自己第一时间搞定，全部搞定之后，直接拿结果说话。当然这种做法一般会非常累，因为时间是不变的，要做的事儿可远比沿用老的方式直接做要多得多。很多人自己就不愿意承担这种多做些不一定有成果的事儿的风险。当然也就失去了这种方式快速成长的机会。虽然这种机会其实天天都有，事事上都有。

一直沿用老的低效率的方式做事，从不思变，看着是勤快，其实是懒。就这么一直懒着，怎么可能有技术含量呢？

所以说回面试，以后面试，除非你真的已经是个大牛了，否则不要讲公司的东西没有技术含量，那只能说明你自己没有水平，而且没有成长空间。哪怕你就说钱没给够，哪怕说你觉得你领导是个混蛋和不来，也比说你觉得公司的项目没技术含量要好些。

PS. 虽然我印象中，我自己被面试时，好像也有这么说过。然而不同点是，如果我说了，我也能证明我是对的。

《Google Java编程规范》里有这么一条：

3.3.1 import不要使用通配符

即，不要出现类似这样的import语句：import java.util.*;

不少公司也的确是这么要求的。但是当我面试时问起为什么不要这么用的时候，不少人就开始语焉不详了。

其实稍微有点儿心的人，稍微花个几分钟，就可以从网上搜到这个问题的答题。诸如：

• 会导致不同包的同名类之间会有冲突。比如java.util.Date和java.sql.Date
• 使用具体的完整的类名，每个类的来源会更明确，代码会更好读。
• 编译速度更快。

更有意思的讨论，可以移步到这里观战。

然而我写这篇文章，并不是为了解释为什么不要用import *。

恰恰相反，我想说的是：上面说的这些不要用import *的原因，听上去是有一定道理，但是其实全是放屁。

• 对于类名冲突的问题。要考虑是代码的分层是否合理？类的命名是否合理。自己把一个类名叫Thread，还要和处理多线程的代码放一起用，不去反思自己类名是不是起得太混蛋，代码分层是是不是太混乱，然后还跑去怪编译器处理不了。不知道是谁给你这么厚的脸皮的？不拿去磨刀真是可惜了。
• 在这个AI都叫嚣着要写代码的年代，你还把各种IDE当记事本用，别人写个import *，就说自己找不到这个类是在哪儿定义的，还说这代码不好读。想用代码行数算工资就直说，不用这么拐弯抹角的。
• 先去把测试代码里的Thread.sleep(1000)处理干净啊。就现在这些工业代码，还不需要计较import *与否造成的性能差异。你真要计较这些，也要先测试一下自己码代码的手速。1分钟之内没办法把26个英文字母打10遍，按你的逻辑就是，你的手速太影响开发效率了，不适合当程序员。麻溜的，主动辞了吧。

最后，再补充一下。我也不是在说import *，我是在说所有的这些，不过脑子，不讲道理或是讲着歪理，然后单纯就是这么做着的，一切屁事儿。

这里指的配置，泛指一切能改变服务行为的变量。其生效的位置可以在编译期、部署过程中、运行期；其存在的形式，可以是代码中，本地文件，资源文件，环境变量，数据库甚至其它服务。也正是因为这种灵活性。配置管理大概算是软件工程里人们分歧最严重的领域。而且，由于“反正无论怎么样搞，怎么样都能搞定。搞定不就行了吗？”的“结果导向”的态度的存在，这部分也常常最不受实质上的重视和控制，于是对配置项肆意随性的使用，最终将导致配置混乱，配置漂移，配置变更风暴乃至生产事故的发生。（顺便说下，我这里当然就是在曲解“结果导向”，但是我见过无数人在想说一个实现细节不重要的时候，便把“结果导向”搬出来说事儿了，所以这里说是“结果导向”是为了便于一些人理解。）

服务配管管理这个话题非常大，一篇文章显然说不完。下面我仅仅讨论几个我感觉人们误会最深的点。主要内容与理念来自《Continous Delivery》一书，但是重点不同。

代码与配置分离

“代码与配置分离”常常被从字面上理解错，从而产生两个严重的误会：

1. 代码中，不要出现与配置文件有关的任何东西。
2. 另外，哪部分算“代码”呢？我们要求高些，就整个代码库吧。

于是在犯了这两个误会的代码库中，连个完整的配置文件都找不到。于是你连这个服务都有哪些配置项都看不出来，要去实际环境中，把环境变量啦，本地配置文件啦统统拿出来过一遍才搞得清楚。我遇到过的，更极端的做法是样的：写一个服务维护各个环境的配置项，这个还不错，但是呢，又在CI中加入一个自定义的步骤，把已经打好的Jar包解开，把相关配置下载下来，替换掉里面的application.properties文件，然后重新封成Jar包。我一开始还以为有什么高深的不为人知的原因才这么搞的。后来我发现我想多了，他们就是不想用或是不会用Spring的Profile机制罢了。虽然所有项目都的确是“用了”Spring Boot框架的。但是真的只是用了个框架，本质上这个项目连Spring 4的功能都没用上。

再说回原题，我不想解释“代码与配置分离”是什么意思，因为这只是个处理方式，我想介绍一下这个处理方式要解决的问题是什么。它要解决的主要问题之一是：同一份代码产生的包，能够不经修改地，在不同的环境下运行，配置可以在代码之外进行控制。避免出现“因为生产的配置不一样，所以要改下代码，再打个包再发到生产”的问题。那为什么临时改下，再打个包再发生产不行呢？我乐意加班不行吗？不行，问题在于：

• 效率低。你改下代码，再打包，要不要再测试呢？即使不要，也10来分钟过去了。能不花额外时间的事儿，就不要花1秒额外时间。加班要创造价值，不是创造问题。
• 风险高。你说你只改配置，谁知道是不是真的呢？要不要人来检查呢？你手改的怎么保证不出错呢？
• 成本高。这是上面两条的推论。

其实《CD》这本书，全书基本都是在说提高效率和降低风险。抓住这个主旨，再去理解“代码与配置分离”，至少不会跑得太偏，也不会纠结于怎么分，分到什么程度这种问题。

虚拟化场景下的代码与配置分离

到了虚拟化的环境，情况会略有不同，部署的单位是镜像，那么问题来了，镜像里面应该是纯代码？还是代码与配置的合体？这个复杂些，两个说法都不对。

镜像本身是包含运行环境的，比如OS,JDK，一部分环境变量什么的。所以环境相关的配置，好多都是和OS, JDK相关的，本就应该放在镜像内部，不允许随意从外部修改的。非要从镜像里拿出来，当然技术上是完全可行的，但是没有意义和价值，而且效率会变低。拿出来统一管理所有配置？不不，统一是手段，不是目的。餐具有筷子和勺子，是为了吃饭方便高效，但是吃一碗汤面，不需要为了用筷子和勺子，就非把面条单独捞出来放一个碗。这叫脱了裤子放屁。 配置项到底是在镜像里还是镜像外只是手段。你要看你的问题解决了没有，目的有没有达成。而且，配置放镜像里，就无法统一管理了吗？就无法从外面控制了吗？

当然，还有一些配置，比如密码，密钥什么的，安全起见，就不可以放在在镜像内，加密过的也不行。否则镜像一旦泄漏，别人直接就能把你的服务原模原样地跑起来，这个风险是不可承受的。

所以总结一下：镜像里应该要包含并固化所有环境的多数配置，通过一个参数决定运行哪套配置，少数有特殊要求的配置要独立出来。但是建议保持从镜像外部改变现有配置项的值的能力。以便可以在不重新构建的情况下，直接调整运行时参数来解决一些比较紧急的问题。但是尤其要注意的是，所有这些紧急调整的参数，一定要签入代码库以固化到镜像中。

注意：上述这些行为，Spring通通自带支持，默认就这样，你不需要为这些事儿写一行代码。除非你放屁要脱裤子，那是要写不少代码来支持的。

配置应该放哪里

能放配置项的值的地方非常多，我们先来看下都有哪些地方可以放置配置项及值。

• 代码里。
• Jar包的resources。比如：application-xxx.properties文件等。
• Docker file
• Host机上挂载的文件
• K8s的配置文件
• Host机上环境变量
• Java, Docker, K8S等的启动参数
• 各种云平台自身中。如Aliyun, OpenShift

正是因为可以配置的地方太多了，所以必须严格控制好“应该”在哪儿放配置，否则非常容易失控。在没有控制的情况下，多数人会选择自己已经知道的方式或是最方便的方式去做配置变更，而不是去探求最合理的方式去做配置变更。
所以我们先讨论一下，配置有哪几类，分类的维度会有如下几种：

• 谁来决定值是什么？开发，产品，运维？
• 要不要随时修改？ 实时生效？
• 是否敏感（需要保密或脱敏）？
• 是否因环境而不同？
• 是否有足够的权限。比如你需要有一个Kafka的Topic，这个可以是一种配置，也可以自动化配置，但是如果运维不给你权限的话，你配置这个东西的方式会有极大的不同。

上面并不是所有的维度，但是仅仅上面的维度就有2^4*N种情况，N是公司需要做配置的角色数。当然，你并不需要2^4*N种配置的方式，配置的方式是越少越好。但是要能满足以上所有情况。并且，还要满足以下对配置管理的要求：

• 版本控制。是的，配置本身也要有版本控制。不是随手改的。至于放在代码之外，或与代码放一起都可以。如果你不想搞得太复杂，就和代码放一起。放在代码之外的话，你还要管理好配置的版本与代码的版本的兼容的对应关系。有了版本，也好做回滚。版本控制的另一个潜台词是配置共享的，团队新来一个成员，应该是可以用得到这些配置，并一键把服务按配置好的参数跑起来的。不需要满世界问人，有哪些参数要配置啊？要配置成什么值啊？你把值拷我一下啊？
• 统一配置的能力。比如Kafka，常常是多个服务都要配置这么个地址（或ZK的，一个意思）。那你是感觉每个服务各自配置自己的好呢？还是用全公司统一的一个配置好呢？（假设公司只有一套Kafka）
• 抽象配置存储方式的能力。比如密码，你本地环境的，开发环境的密码，可能会感觉放properties文件就好了。生产的是要通过环境变量的。然后有一天，公司打算用Vault了。你的代码，你的配置定义，应该是都不需要修改才对。这样，你的配置系统，才是与配置存储的方式是解耦的。

好，上面说了一堆要求了。方案呢？很简单。放配置项的值就三个地方，

• Properties文件：开发负责。通过发版，或Config的Refresh Scope来变更。
• 数据库：产品负责变更的配置，一般要有相配套的后台页面在运行时修改。
• 环境变量。环境变量的注入方式运维团队自己决定就好。因为这个是他们负责的。

其它地方，什么Docker file啦，K8S配置啦，启动参数啦，原则上统统不放配置。
至于实现，用Spring自带的properties支持就可以达成效果，通过profile来区分环境。日后如果要用Vault，与Spring Cloud Config集成也简单。

应该谁来配置？

这其实就是上面一节中的一点。但是我感觉非常重要，所以想单独拿出来再说一遍。因为“谁来配置”，基本上决定了配置的方式甚至能进而影响服务的设计乃至架构。有人可能从字面上看到这个问题就反感。因为一般情况下，一个事儿，一旦聊到“谁”来做这个问题，大都就开始推诿扯皮了，因为很多人的心态就是“多一事儿不如少一事儿。”，而不是考虑这个事儿“应该”谁来做。这里的“应该谁来配置”的重点，恰恰就是“应该”是谁。而不是“谁”来做比较快，比较简单。

那么配置到底“应该”是谁来配置呢？一般而言，谁有权力决定这个值应该是什么，谁来配置。注意这里的“权力”是发言权、专家权，而不是职权。那么谁有专家权呢？

比如，API的错误率的告警阈值，传统的做法就是负责系统监控的运维人员来决定一个全公司统一的值。比如5%，高于这个就告警。但是每个API的情况不一样啊。比如12306的图片验证API，错误率正常情况下肯定不止5%，谁不得试了两三次的？你配置个统一的阈值必然没办法普遍适用。 （注意，不要抬杠说这里验证失败也应该是200，这里只是用这个接口举个例子）

于是有的公司改进了，专门做个页面，允许每个Team的负责人去配置每个API自己的阈值。于是又有新的问题了，比如：

• 负责人说，我也不知道每个API正常情况下，错误率是多少啊？那个谁谁谁，你来拉下数据。
• API改进了，用异步操作了，总是直接返回结果，然后错误率忘改了，然后一直没有任何告警。

Team Lead是专家吗？Team Lead其实也不可能事无巨细地知道一切，不可能实时跟进API的变更，也不可能不顾实际情况地强行配置一个值，那和一开始由运维配置一个全局的值没有本质区别。本质问题是什么呢？Team Lead其实也决定不了一个API的错误率。只有写这个API的人才能根据自己对API的了解做出判定。即开发本人，确定每一个API的合适的错误率告警阈值。对于非常专业的工作，实际做的那个人，才是专家，而且必须是专家，不然他是做不好的。这里的专家并不是方方面面的全才，而是指在自己负责做的这一个小部分，在整个公司范围内，他必须是专家，至少是之一。

当然，这么做是有两个假设，一是假设开发都是认真负责的，不会配置个99%然后就安心地去睡大觉了，其次Team Lead也要愿意相信Team Member的判断。另外，“合适”并不表示“符合预期要求”。比如开发人员确定了一个数据查询接口，由于bug多，其错误率本来就高，认为告警阈值配置到30%才真表示有问题。Team Lead的责权在于，决定让开发人员改进接口，把错误率降到3%，才允许上线。

重点来了，如果一个东西让开发去配置，那方式就多了。而且一般不用单独做个配置页面这么重。常见的有：

• 配置文件。比如properties文件。
• 数据库migration脚本。比如Flyway或是DbMigration来修改数据库表中的配置信息。
• 甚至代码本身

这里说的在代码中做配置并不是hardcode在代码里，具体的例子可以参考bucket4j和bucket4j-spring-boot-starter这两个项目中的示例。对于需要由开发来配置的参数，这种方式势必会是方案之一。

注意：这两个框架我并没有用过，而且是做限流，不是做告警阈值配置的。只是按自己解决问题的思路，找到的现成的和上面说的方式比较一致的框架，提一下给大家做个类比参考，我也省下自己去写example的时间。

最后再强调一点，我写这篇文章，并不是要鼓吹在“代码里做配置”这种方式。 而是在讲，做一件事的时候，最好先把思路打开，别把思路局限在一个小圈圈里找方案。“代码里做配置”，只是一个代表，代表着那些从一开始，由于一些成见、思维定势而被排除在可选项外的可选方案之一。

压力测试的目标主要有两个，一是验证服务技术指标是否符合要求，二是为服务的实际部署方案的规划提供基础数据，以便回答这个看上去很简单的问题：要什么配置的服务器？要几台才够用？然而这个问题其实并不那么简单，因为服务规划并不是简单的四则运算。因为其相关指标之间是有相互影响的，会需要做些权衡取舍。
为了达到以上两个目标，压力测试的一般步骤可以这样做：

1. 确定服务能达到的最小响应时间。这个一般是在低压力情况下得出。
   • 同时，根据最低响应时间，我们可以大体计算出单个用户，单服务节点的最大QPS。
2. 在高并发的情况下，测算出单个服务节点所能承载的最大QPS。
3. 通过模拟真实请求的使用模式，测算出目标响应时间下的最大并发用户数。
4. 验证上述最大并发用户数下，长时间运行的服务稳定性。同时系统负载小于60%（后面解释）。

真实请求模式的模拟

这一点非常重要。因为测试时请求模式的不同，会导致压力测试的结果的差异非常大，尤其是系统响应时间。请求模式真实与否的主要考虑点有以下三个：

• 请求发出的时间点，是否符合平均分布。而不是出现一个个的请求量尖峰。
• 每个连接发出的请求间，是否有合理的间隔（也称为思考时间）。而不是全火力发请求。
• 模拟过程中，系统负载也要控制在合理范围内。

我们做这样的一个最理想情况下的思想实验。假设一个接口的响应时间是1ms，支持的并发量为1（即一次只能处理一个请求），用1000个请求来做压力测试。我们来讨论一下两种不同的请求发送模式：

• 模式一：假想这1000个请求是每隔1ms发一个过来。那么每个请求发来的时候，上一下都刚好处理完，新请求都会毫无延迟地得到处理。从客户端看来，这1000个请求的响应时间都是1ms。
• 模式二：假想这1000个请求是在一开始一起发到服务器端。第一个请求会被及时处理，之后每个请求的等待时间都比前一个多1ms，到第1000个请求，要等999ms才会被开始处理。从客户端看来，这1000个请求，虽然和模式一一样，也是在1秒内全部处理完成，但是平均响应时间是500.5ms。

可以看到，在上面的两种不同请求模式中，最终测试出来的响应时间相差500倍。当然，这个例子是理想情况下的两个极端。现实中的差别不会这么大，但是也非常可观。由于压力测试脚本产出的请求模式的不同，在结果上产生几十倍差距的情况也是屡见不鲜的。

系统负载与响应时间的关系

在上一个思想实验的模式一中，我们发送请求是均匀分布的，但是更真实的分布，是时间齐次的一维泊松分布（一种随机分布）。有什么不同呢？请求平均分布的情况下，我们可以想象，只要负载没达到100%，响应时间就应该一直是1ms。但是在真实的情况下，我们这个假想接口的响应时间会是系统负载的一个函数。关系函数如下（其中，s表示请求处理时间，p表示系统使用率，r表示响应时间。）：

r=s(2-p)/2(1-p) 

函数图像如下：

我们可以看到，负载在80%的时候，响应时间就会是三倍于处理时间，而负载在90%以上时，延迟就会直接彪高。

注意这个公式并不具有普遍适用性，只能用于等候理论中，符合M/D/1型队列的情况，而且是假设服务器本身的性能不会因为负载的变化而变化。而真实的情况，会比这个更加复杂，服务接口的处理时间，常常本身也是负载的一个函数。通过这个分析及图表想要说明的是，如果想要保证系统的延迟在某个范围内，就要确保服务本身的负载不能过高。

一开始说，压力测试的一个目标是验证服务的技术指标是否达标，但是技术指标有很多，不同指标的压力测试方式也是不同的。不可能用一次压力测试，把所有的指标都能验证完成。如果想测试系统延迟是否达标，就要在测试过程中保重负载不过高。要知道，实际生产环境中，一般负载大于60%就要开始着手扩容了。根本不允许负载过高的情况出现。压力测试，还可以验证，在负载小于某个点时，比如60%，能撑住多大的量。用100%去测试，但是生产又不跑到100%，测试的效果就要打折扣。100%负载的压力测试当然也有用，可以用来验证服务在高强负载的情况下，服务的可用性、稳定性是否依然符合要求，不能宕机，不能无响应，不出错，基本上就可以说稳定性就是好的，但是这个时候的系统延迟是不可能好看的。

对压力测试一个常见的误解就是：压力测试嘛，时时刻刻的负载都得是100%才叫压力测试。

集群测试的目的

到4为止，对单台服务器的测试基本完成。后面就可以开始集群测试了。集群测试的目的是，验证服务的水平可扩展性是否良好。水平可扩展性良好的服务，加一倍的容量，就能多承载一倍的负载。水平可扩展性不好的服务，多加多少节点，都没办法支撑更多的负载。造成水平扩展不良的的原因，一般都是服务内部有核心操作串行化。更常见的情况是：加一倍的容易，可以多承载X倍的负载(其中因子X小于1)。对集群进行压力测试的主要目标，就是测算出这个X因子的值。以用于服务容量规划。在实际的规划过程中，会有两个方向：

1. 保目标响应时间。一般用于对响应时间要求高的系统。就直接用最佳并发用户数去做规划就好。最最理想的情况下，如果1台能支撑100用户，10台能支持最多1000用户。
2. 保每台最大并发用户数，以节省服务器资源。如果可接受的响应时间比较高，那么每台服务器就可以承载更多的用户。这时需要再进行一次，以测算单台服务器的最大并发用户数为目标的压力测试。并以这个最大并发用户数去做容量规划。

所有服务容量规划的前提，都是服务本身是可以水平扩展的。

下面以K6压力测试的结果为例，简单演示一下以上过程。

示例测试环境

Mock的被测试服务接口如下所示。没有数据库访问。没有同步。这样做的主要目的是简化模型。现实情况的结果，会比下面的演示复杂得多。

@GetMapping("/say")
fun sayHello(@RequestParam greeting: String): Mono<Any> {
    return Mono.just(greeting)
}

运行环境：Docker 4 Core 4GB on Mac Book Pro with 2.8G i7 CPU 同环境还运行：Spring Cloud Gateway, Prometheus, Grafana, InfluxDb及K6 Test Engine。

最小响应时间的测量

测试方法：使用少量用户（比如一两个），无思考时间（全负荷）发请求。

期望结果：响应时间保持极低水平。QPS也要足够高。

如下图所示：

平均响应1ms，95%分位1.5ms。后文为便于计算，最低响应时间记为1ms。 下图中，QPS最高1500。但是可以想象，这并不是这台服务的最大QPS，毕竟用户太少了。 根据响应时间，我们大体可以知道，单个用户，在单个服务节点上，最大QPS是1000。

最大QPS的测量

测试方法：使用大量用户（使用10，30，100，300每别测算），无思考时间发请求。

期望结果：一开始增加并发用户量，可以显著提高QPS压力，但是用户增加到几十个（甚至几个）之后，QPS基本就上不去了。

如下图所示：

我们用100个高并发用户去压，并没有把QPS压到100*1000这个量级。我们发现最高也就到3200QPS，就上不去了。而且服务的响应延迟显著增加。这是非常正常的。因为无思考时间的用户，等同于在做DoS攻击。正常用户的正常API调用，是不可能出现这种全负载狂发请求的情况的。如果你说你的API特殊，就是每个用户要1秒调用1000次以上，那你其实最好重新思考下这个设计是否合理。

真实负载下的并发用户数的测算

上面我们已经讨论过什么是真实负载。于是在这个压力测试中，我们要引入思考时间这个概念。

测试方法：从0开始，逐渐增加用户数到200。加入50ms的思考时间（即每个用户，每秒最多发20个请求）。

期望结果：观察响应时间的增长情况，用户量达到某个点后，响应时间开始快速增长。这个点，即是单台服务所能承载的并发用户数。当然，如果你对响应时间的要求不太高，也可以根据某个特定响应时间，比如200ms，来确定并发用户数。而不是非得用响应时间的增长拐点。

如下图所示：

用户在达到100左右开始，响应时间开始变高，QPS也不再随着VU线性增长。所以我们可以说对于这个服务节点来说，最好只用来支持100个用户。但是你也可以发现，即使到200并发用户，系统也还是OK的。只是延迟比较高。

这里的压力测试中使用的假设的思考时间的长短，是非常影响并发用户数测算的。如果我们把思考时间加到500ms，就可以支持更多的VU，因为QPS一般是固定的。下图展示了600VU在500ms思考时间下的测算结果。是不是看上去比上面100用户的时候还好？（注意，QPS都是1000左右。）

业界有很多种权限控制的设计模型。做过访问控制的人或多或少都比较过这些方案的优劣。我过往的一些相关经历，让我发现一些在做这个选择的时候，可以思考的问题。简单梳理一下，以作备忘。

引入访问控制的目的是什么？

这是非常重要的问题。是“为了安全”吗？不，这个目的太宽泛了，宽泛到无法指导你做任何有效而且合理的决策。作为一个安全策略的制定者，除了“为了安全”之外，必须要搞清楚，你要防范的人是哪些，想要控制其的哪些行为。不用很细，但是至少是“原则上”地。比如：

1. 要防范的人，分哪些？公司内部，公司外部两类吗？防范方案有什么不同？
2. 防范他们的什么行为？是要防范他们无意的误操作？还是要防范他们恶意的删库跑路？真的都要吗？
3. 你愿意为了“安全”将效率牺牲到什么程度？比如，为了保护代码安全，最安全的做法，显然是给电脑断外网，并且禁用除显示器外的所有输出设备，不允许带入手机，也不允许把电脑带出，而且办公室不能有窗户，以防对面办公楼的长枪短炮拍摄到你屏幕上的代码。这个时候，你可能牺牲的不仅仅是效率，可能还有员工的技术成长、身心健康，以及这个岗位的离职率。这可不是说段子，很多外包IT公司的部分项目就是这么搞的。

访问控制的主体是谁？

或者说，谁应当受到访问控制？

1. 人。人分哪些？内部员工，外部用户，还有吗？他们的权限模型需要统一吗？能够统一吗？
2. 服务。首先，服务本身需要访问控制吗？我认为是必要的。因为服务所应当有的权限，是很难和公司内部某一个人的权限完全一致的。而且，人的变动会远多于服务的变动。对服务本身的访问控制的管理成本，一般也会远低于对人的访问控制的管理成本。另外，不要觉得对服务这个东西的访问控制很不自然，你手机上的App，也算是一种服务。而你肯定是想管理App的权限，而不是App的开发者能在你的手机上干什么。我见过的最奇怪的规矩是，权限只能给人，不接受给服务本身设置访问控制方案，但是接受服务以root身份运行，也接受负责服务的人，拥有本当属于服务的权限，也即生产环境的所有权限。当然，我也理解他们给出的解释：出了事儿，他们可以很方便地定位到责任人。而且他们只需要维护人的权限，完全不需要考虑服务的权限这么个事儿。这对他们自己而言，这的确是最安全的方案。
3. 要统一吗？人类才华产生的最大非理性的冲动，就是见到分开的东西，就想找到一个统一的方式去处理，比如爱因斯坦干的那事儿。也许能统一，但是作为一个企业，而非一个科学家的时候，你要着重考虑的是成本收益及可操作性。而不是一个方案看上去有多完美多NB。当然，如果你要拿着这个方案去骗某个风投的话另当别论。

访问控制的客体是谁？

或者说，控制对什么东西的访问？显然并不是所有的东西都需要访问控制的。但你判断一个东西要不要做访问控制的条件有那些？要不要花钱？会不会失控？举几个例子：

1. 办公室空调的按钮。据我了解很多人都希望有，但是这并不需要权限系统来解决，如果真要暴力解决，这只需要一些胶带并让公司行政把遥控器收好。
2. 数据库DDL。这个一般都是要控制的，但是再考虑下主体，你要想好想让哪个主体来做。是人，还是服务？是开发还是运维？如果你选择人，那基本上就和市面上的DB Migration框架说再见了。这也说明了，访问控制上的一些高层面的决定，会影响你服务内技术栈的选择。
3. 服务运行时环境变量及参数。这个伪逻辑是这样的，环境变量的变化，可以彻底改变应用程序的行为，所以要严格控制对环境变量及参数的改动，只能由维护人员有权限改。于是上线的过程，就需要由开发给运维交待一整页配置变更。于是，基本告别Continous Delivery了。当然，这个时候人们一般都会安慰自己说，我们其实也并不需要CD，而不是反思前面的问题有没有更好的解决方案。毕竟项目都是有Deadline的。

谁负责设计资源访问的细节？

我之前在一家投行工作，公司使用的是一个内部自研的权限控制系统，混合了ABAC和RBAC两种方案的优势，其权限数据结构是可定制的，由各个业务团队自行定义资源的一切细节，非常强大灵活。那段时间，负责这个框架的那个团队，开始做这样的一个事儿：用AI技术，分析当前的权限配置中不合理的部分。因为公司当时面临这样的一个问题：连业务团队自己，都已经无法看出自己的权限数据中有什么问题了。因为绝大多数情况下，人们使用这个框架的方式都是：简单看下原来的数据是什么样的，用最少的改动，最少的数据量，就可以完成这次权限配置变更的要求。而不会去深入地思考，“应该”做什么的数据变更是最合理的。最后这个权限控制数据库就失控了。不过好在人们都知道这个问题，并且在积极解决。所以再好的框架，再好的设计，也会因为不当的使用而难以发挥其里大的价值。那么哪些是使用上的细节和设计上的细节呢？比如：

1. 公司到底有哪些角色？这些角色应该有哪些权限？这些细节是技术人员先定一个，还是先和相关方讨论清楚？
2. 公司有哪些资源是比较容易分辨的，但是每类资源应该有哪些属性呢？是加属性好？还是加新资源好？
3. 可以为每笔交易都定义一个独立的资源项吗？
4. 客服需要客户信息，交易员也需要客户信息，但是需要的部分不同。这时，这两类客户信息，是两种资源吗？

类似以上这些问题，无论如何选择，都是可以完成工作的。但是质量上却有云泥之别。只是有些差别，有些后果，要出现后续的状况时，才会体现出来，做决定的时候，常常因为“都可以”而无视掉。

谁负责设定资源访问的权限？

即授权。一个简单的回答是：owner。然后下面的问题就是，谁是owner？我只想表达一点，从权限控制的角度，同一个东西的不同方面，其owner可以是不同的。比如：开发写了一个接口，这个接口谁能调用谁不能，肯定不是这个开发人员决定的，至少也要构架师才能决定；但是同一个接口，假设为了保护自身稳定性，添加了访问频率的上限的设定，在不影响整体服务功能和可用性的情况下，这个设定的owner可以是而且应该是开发者本人。

“对事儿不对人”大概算是少有的几个无论内资外资都会声明认同的行为准则之一。但是却少有写进公司官方员工手册进行详细解释的。我不是官方，但是我想解释一下，也许你还能顺便悟出这个词为啥没有官方的详细解释了。

开宗明义，对事儿不对人，更合理的做法，是指做决定、决策的时候对事儿不对人，而不是指提建议或批评的时候对事儿不对人。容我娓娓道来。

声明

体制内的看官看看笑笑就好。我这里说的是体制外的情况。

建议与批评时

我们回想一下，批评一个人，或是给一个人提建议的时候，最重要的一条是什么？是要私下进行。对不对？你公开批评一个人，哪怕你批评得对，哪怕你职位比他高，有的人也会不接受，因为面子挂不住啊。他面子挂不住了，搞不好还要牵扯出你祖上十八代来撑场子。所以说正常人根本不会在公开场合批评某个人，还有什么“对事儿还是对人”的问题呢？

那么，公开场合，审明公司组织纪律算什么？比如有人天天拿公司牛奶洗脸，公司开全员大会，你猜会怎么说呢？会说是谁干的吗？不会啊，会说牛奶洗脸这事儿吗？也不会啊，你如果说，不让牛奶洗脸，那洗手呢？不让用牛奶，我用咖啡粉行不行？场面上会这么讲，公司将严厉惩戒将公司资产私用的情况。这叫既不对事儿，也不对人。使用官方用语。泛指你们所有这些烂人干的所有这些破事儿。普通员工去批评人，哪怕是批评一个群体，也不敢用这种“既不对事儿，也不对人”的口气，因为规格不够。也就CXO才可以。所以公开批评也没有“对事儿不对人”的问题。

好，那我们说私下批评，想象一下，你找到了那个用牛奶洗脸的员工。用对事儿不对人的说法怎么说呢？

A: 小王啊，我听说公司的牛奶常常失窃，搞得大家天天只能喝黑咖啡。你离厨房近，你帮忙看着，发现了告诉我一下，我们看能不能把这个小王八蛋逮着。

W: 你拐弯抹角地骂谁小王八呢？

而且，其实公开场合提建议也应该针对具体人。 比如代码评审会的时候，

我提一点儿，不针对任何人（哦，原来是要说我们所有人）。按编码规范，方法参数最好不要超过5个。我看刚才不少代码的参数都十七八个了，这个会后改进统一改下。

完了，这事儿肯定没人干。有人感觉我没问题不用管，有人有问题，还没到十七八个，等别人改好了我再改吧。最多的那个人压力本来最大。一听到“统一”改就想着这事儿不用我个小愣头青操心了，肯定要大牛出手啊。 当然我这里YY，实际情况不会这么糟，但是显然也不会太好。

试问，提出问题又不针对人，这事儿还怎么SMART化？每次都是：“我不是在说某个人，我是说在座的所有人。”不成？ 所以提建议，批评，就应该对人。否则起不到效果。

换一个角度，如果一个人连别人私下的中肯的批评都承受不起，我不知道这个人还能承受得起什么？ 而且如果你批评得对，也不用担心被批评的人，用“对事儿不对人”反驳，因为听上去很二。比如：有人随地吐了口痰，你应该不大会听到这样的对话：

A: 唉，你怎么随地吐痰啊。

B: 唉，你这人批评不要针对人好不好。

倒是可能会听到这样的对话：

A: 唉，你怎么随地吐痰啊。

B: 你找打？

人与人之间意见不同是非常正常又常见的，有分歧就打开门讨论。拐弯抹角地旁敲侧击得搞到什么时候？ 当然，对人，不表示针对某个人，更不表示人身、人格攻击式的批评与建议。

决定与判断时

最后来说说，什么叫做决定做判断的时候，对事儿不对人。

我举个例子， 线上一个服务负载过高，需要找运维人员加一个节点。我相信如下对话模式，做过开发的应该都不会陌生。

开发: 能给XXX服务加个节点吗？

运维: 你说加就加啊？自己服务有性能问题先解决自己性能问题啊。

VS：

总监：能给XXX服务加个节点吗？

运维：好的，马上，好了告诉你。

另一个例子：

开发：能不能从你们的ElasticSearch里直接读数据啊？

运维：这不行的，万一你们做个大查询什么，直接就把日志服务搞挂了啊。

VS

总监：能不能从你们的ElasticSearch里直接读数据啊？

运维：我想想啊，也行，注意控制下查询参数不要太宽哈。

这就属于对人不对事儿。一个客观的事儿，能不能做，要不要做，应该由客观情况决定，不应该看这个事儿是谁来问的。至于某天晚上聚餐去哪儿玩，如果领导有想法，当然要听领导的。因为这是主观的事儿，没有客观是非。

对于这个问题，我还得意和一些从阿里出来的人聊过，我以为阿里这种政委风气重的地方，简直就是培育看人办事儿风格的沃土。结果对方十分肯定的讲，同一个事儿，谁去问都是一样的，不会有不同的答案。我对阿里的印象因此还好了些。

反过来讲，就算做决定的时候对人又怎么了？问题多了。比如工作低效啊。本来可以交给某个小弟去处理的事儿，搞得什么事儿都得我自己来，而且小弟们也会挫败感十足，好像自己什么事儿都搞不定一样，虽然问题根本不在他们那儿。我要再有点儿心，还要去安抚小弟。我怎么说呢？这不是你的问题，这边儿风格就这样，适应适应吧。他心想，哦，公司这个问题好像有点儿严重啊，我还是换一家吧。

更宽泛地讲，对事儿不对人，本质上是在说，在工作上，要以事实为依据通过理性思维做决定，而不要感情用事。 回到一开始的问题，你猜为啥一般公司都不会详细解释“对事儿不对人”呢？

有人听到这儿就上头了，说实现中，你看看哪家公司是这么做的，完全不切实际！你说得对，就像几十年前会随地大小便那帮人，看着“不要随地大小便”的标语时，也是一脸的莫名惊诧：大家都随地大小便啊，这个标语完全没说到重点啊，明明应该写“随地大小便时请注意遮挡”，这才合多数人的心意。 是吧？