收到变态需求怎么办？橙汁测试有启发

前段时间，一个现有的客户来找我们，说根据当地的监管要求，他们的数据在我们的所有系统都必须要做加密处理。

这里的具体需求是，任何存储和传输他们的客户数据和交易数据的介质、通道和系统都必须是加密的。

大家可以想象，银行系统间的关系都是盘根错节的。要挖出接触到相关数据的整条链路，确定影响范围，本身就是一个难题。

而我们只负责其中几个系统。有大量涵盖的系统并不在我们的掌控范围内，要说服那些系统做整改也是困难重重。

整个需求，对我们来说，是Mission Impossible（不可能的任务），所以我们把它归类为“变态”需求。

而且，作为全球金融机构，我们本身就有严格的全球标准来保护数据。按照内部规定，像我们这样的内部系统，数据敏感度也不是最高级别的，只需要满足传输信道加密、职责隔离以及权限控制的要求，确保数据传输安全和只有授权的人员才能接触到数据即可，没有存储加密的要求。

因此，一开始，我们是拒绝的。

但客户不依不饶，说这是监管要求，我们必须满足，并威胁，如果我们不能满足，有可能会和我们绝交。

过去，有另一个客户提出过类似的需求。我们要求对方的IT团队和我们进行IT对IT的沟通，因为大家都在同一个频道上，能对得上话，也能拿出切实可行的解决方案。最后协商的结果是，由于双方都要做大量投资才能满足，从商务角度考量，对方撤回了需求。

这一次，我们也试图照葫芦画瓢，要求对方派出IT团队和我们沟通。但对方的安全部门一直档着前面。我们知道面对对方的安全部门，我们完全不占便宜，因为对方站在“道德制高点”上，并手握对所谓监管要求的解释权，也不会谈出什么具体的方案。

无奈，我们只能硬着头皮和他们谈，果然谈崩了。我们试图询问对方，需求的需求是什么。因为加密，无非就是想保护数据，如果需求的需求就是保护数据的话，我们已经完全满足公司对于数据保护的规定，也完全可以满足对方在数据保护上的要求。

但是对方并没有理会这个问题，只是不断强调，他们的需求非常清晰，就是要加密！

橙汁测试

罗胖在《知识就是力量》里分享过一个叫橙汁测试的故事。

有家公司要办年会，需要选择一家酒店作为年会场地。他们公司有1000人，这也是这家酒店需要接待的人数。

这事对负责组织年会的人来说，压力很大。因为如果酒店选得不好，会有1000人指责、抱怨。

他想了个办法，打电话问每一家候选酒店：“我们需要酒店在早上7点为每位员工提供1杯鲜榨的橙汁，能否做到？”

这是一项酒店平常没有的服务，而且1000杯鲜榨橙汁意味着酒店可能半夜就要开始忙碌了。这是一个“变态”需求。

这时候，直接回答不能的酒店，可以pass掉。直接回答能的酒店，也pass掉，因为这意味着这家酒店的负责人不假思索地想接下业务，根本没有考虑过这意味着背后有多少的坑。

只有一种酒店是值得选择的，那就是听到这个要求后，说：“好，请给我一点时间，我测算一下，为了完成这个任务，我们需要添加什么样的资源，这些资源大致的价格，我会给您生成一张账单，您看一下账单，您再决定需不需要这样的服务。”

给我们的启发

联想到我们开头讲的故事，你得到什么启发了吗？

面对那样的需求，我们既不能直接说不，客户一定不放过我们，他们一定会告到老板，甚至是老板的老板那里，而且搞不好还真的会和我们绝交，使我们失去一个重要客户。我们也不能满口答应，过度承诺，吃不了兜着走。

我们认真研读过当地的监管要求文档，文档中对加密并没有具体的要求。因此，我们定位这个需求为客户请求，而不是我们必须接受的监管需求，这涉及到谁掏钱的问题。基于这个定位，对方需要对这个额外需求埋单。

然后，我们应该认真地做好尽职调查，把所涉及的所有系统、通道和介质都罗列出来，找出每个环节的联系人，游说他们参与讨论，和他们大致确定解决方案，并给出初步报价。整理好后，清清楚楚地告知对方，要实现这个需求所涉及的范围以及成本和时间。这样，对方便要做出相应的商务考量。

我们后来就是这么干的。而且，在我们的回复中，针对每个解决方案，有哪些是已经有成熟的且在使用的方案，比如数据库加密；有哪些只是假设，未经验证是否可行的，也会标注出来。

比如像NAS、SAN这样的存储介质，最好的方案应该是在硬件上实现，但由于我们公司的数据中心并没有提供这样的解决方案，我们需要在应用层上实现，也就是说接口文件在生成时就要加密，这样存储在NAS、SAN的只有加密了的文件，但下游也要有对称的解密能力，而且需要有一个Key的管理机制。

这样的方案既费劲，又不算非常可靠，只能说是无奈之举，但我们也会在回复中清清楚楚地说出来。

可以预期的结果是，对方最终一定不会再要求全部都要做，会做出取舍和裁剪，对于具体的方案，肯定也做更深入的探讨，从而达成更合理、双方都能接受的协定。