![]()
创建一个能工作的软件产品是很困难的，卖欺诈性的软件产品要容易得多。
声明：本文已获作者Matt Stancliff翻译授权。
![]()
以下为译文：
福布斯（Forbes）最近发表了一篇文章“硅谷创业公司的另一面：丑陋与不道德”，描述了客观存在的欺诈性科技公司的兴起。在过去几年中，许多“超出产品本身”的过度营销泡沫已经破灭，还有更多的公司很快就倒闭了。
保护自己免受技术欺诈并不难，你可以非常容易地做到。尽管很难从软件开发的无休止的“无可指摘的错误”中辨别出很多不诚信行为，但客观地记录你的供应商是如何撒谎的，可以让你能够迅速并且清楚地揭示欺诈的模式。
假如说你想赚钱，但是不愿意承担创造一个好产品的责任，那你最好成立一家软件公司——软件欺诈可以给你抵赖任何指责的空间。因为软件通常被认为是如此复杂，以至于它被看作是一个“不可预知”的事物。所以你不能因为你的失败而受到责备，因为所有和软件相关的事情都是“该死地太难”了。
好吧，现在你决定了从软件中赚钱，你的产品甚至不需要能够工作，这是迄今为止更棒的主意了，但是，你最终如何用你的虚幻的产品套取客户的现金呢？
最简单的方法是：卖给那些非常自命不凡的，并且拥有高预算的公司。千万不要卖给技术型的用户，因为他们会看穿你的谎言的。
千万不要让技术型用户过早地参与销售过程，因为他们可能会在你讨好那些有购买权限的用户之前，就识破了你的软件欺诈行为。
当你说服一家大公司的首席技术官相信了你的产品愿景，进而相信他自己将会成为“公司的救世主”后，你就把他们的个人形象和使用你的产品的结果联系起来了。用业界行话来说，大公司的首席技术官将成为你的“内部拥护者”，使他们更难相信你卖给他们的价值高达7位数的软件是个欺诈软件。他们不愿意接受这样的指控：他们购买的基于闲聊、幻灯片放映和个人游戏的软件对工作没有任何帮助。所以他们永远不会承认自己被骗了。
如果客户开始觉察到你的欺诈行为，如果他们开始质问为什么他们要为一个每天都有故障、停机和数据丢失的系统支付7位数的费用时，你只需抛出一个或多个下列现成的“专业替罪羊”就可以了：
即使你的公司声称自己是软件领域的佼佼者，开发领域的佼佼者，测试领域的佼佼者，但你总是可以不断地重复这个谎言，毕竟这是软件，所以客户应该对这些常规失败有心理预期。
你也可以 “以过于复杂的依赖关系为借口来确保自已免受指责”。
你也可以通过“将付费客户用作非自愿外包的QA来确保自已免受指责”。
不过没关系，你正在将软件卖给一些孤立的公司，因此希望你的客户永远不会互相交流。宕机30天的客户A认为他们很不幸，你需要做的是确保他们永远不会有机会和同样宕机30天的客户B通话。因为多个客户的多次宕机会把你的软件打上“无用”的标签，而这不是可以重复地使用一个“无可指摘的”、“不可预见的”错误就可以忽悠过去的。
一定要牢记：你所出售的软件是不能工作的，并且是永远不能工作的。
你正在推销一种完美愿景，它能够将支离破碎的生产力整合越来。但是，如果客户尝试过你的软件，他们可能会发现你的想法实际上是不可能的。然而，没有人希望一开始就看到谎言。没有人愿意相信他们是被故意欺骗的，所以前几年里你会很安全。
如果客户开始怀疑你在撒谎和欺诈，只需要在CEO层面采取一些措施。劝说他们不要提早取消合同，消除他们起诉你欺诈的可能性。抛给客户一些用烂了的陈词滥调，以及可以免费延长6个月的合同之类的承诺。
当你创建的真正解决方案（软件）存在实际问题时，为什么不解决问题，而要进行欺诈呢？
创建一个能工作的软件产品是很困难的，卖欺诈性的软件产品要容易得多。
你公司的经营思想是单一产品理念，但你的单一产品被证明是不能工作的。
你公司的产品已经使用了5-10年，在任何意义上都无法进行维修和修理而让其变得可靠。
你必须让你的公司保持稳定，直到一个更大的傻瓜把你捞出来。
像MongoDB，它一开始的模式就相当具有欺诈性。MongoDB模型中的关于“面向非技术用户的技术产品特性”并不可靠。“你需要数据库吗？你需要使用数据库吗！不要担心我们的过失或不能履行我们的承诺。你始终可以购买咨询和支持服务来弥补功能的不完善。对于数据丢失，哈哈，我们只能表示（毫无歉意地）抱歉啦。”
发现软件欺诈的一个简单方法是看看它有没有“言过其实”：当把市场营销总是放置于优先产品的位置时，欺骗就总是优先于创造更好的产品。
一方面，经营一家欺诈性的软件公司很容易：雇佣22岁的年轻人，让他们在没有互相交流的情况下构建复杂的系统。这样你就有了一大堆永远无法工作并且无法修复的软件，同时你仍然有30个独立的非集成软件包，你可以把它们放在捆绑的价格表上，作为“解决方案”卖给客户。
如果你担心客户可能发现你缺乏专业知识（比如说你自己编造的术语和非标准的技术堆栈），并且试图进行平台锁定时，你只需要花费一年的法律费用就可以建立一个独立的“开源基金会”，并且将你的代码碎片容纳进去。这样你就可以告诉你的客户了，这里没有技术锁定，因为这些技术/代码都属于一个开源基金会。
你可以告诉你的客户这是一大优势：你的软件有一个“开放核心”，外加一个专有附加组件和托管服务的混合体。
投资者青睐采用“开放核心”模式的企业，因为它们给人一种“客户自由”的错觉（和没有“版权锁定”的幻觉）。你可以这样来忽悠你的客户：这是一个免费的软件样品，你可以围绕它来建立你公司的业务。哦，你需要对它进行一些修改吗？你需要安全更新吗？对于我们软件的“开放核心”，我们不提供支持。但是我们很乐意以每年一次的许可证向你销售我们的完整产品。如果你有兴趣，请进入这个网络研讨会…...
客户希望从你的付费版本转换回免费的“开放核心”版本，因为你声称你的软件没有技术锁定，他们很快就会追悔莫及。你的客户当然可以只使用“开放核心”，毕竟，你没有任何技术锁定。或者，根本没有什么锁定。但你会这样告诉你的客户：除了这个“开放核心”之外，你的客户将不会有安全更新、用户界面、季度功能更新（抱歉，“开放核心”版本每两年才更新一次功能）、以及在出现任何故障时访问支持的权限。运行你们专有平台的“开放核心”版本的客户，祝你“好运”吧！我们“最有价值”的客户！
以MongoDB为例，他们通过使用“胆小鬼许可证”来模拟开放的外表。你当然可以查看源代码，但是任何与源代码进行公开或私下交互的东西，不管你是否发布，都必须向公众发布。拥有一个正常运作的法律团队的企业根本不会触碰AGPL代码，因为根据它的不受欢迎的有毒许可证条款，所有内部商业机密都会被公开。
——不过没关系。只要风险投资者对你的市场营销、虚荣指标和不正当的市场行为保持着浓厚的兴趣就行，其他一切都无关紧要。
每个软件都有最低要求。但是，你不可能通过一个单一的软件赚钱，你需要一个互联的“意大利面”式的架构平台。
记住，你必须是一个平台，而不是对一个单一软件的一套要求（比如说4核和4GB内层）。你的平台需要在底层运行20个个庞大复杂的服务，每个服务需要3个虚拟机，并且每个虚拟机需要32 GBRAM。你的平台是企业级的。谁在乎浪费2TB内存来运行一个空闲的平台呢？记住：花钱是进步的标志。
以一个真实的例子来说，运行一个闲置的企业级Pivotal Cloud Foundy平台（一种开源PaaS云平台）需要每年为一个闲置系统（甚至没有用户应用程序在其上运行）花费50,000到200,000美元的“按实例付费”托管成本。你的平台很“重要”，因为它浪费了如此多的资源。
这些花费的美元并不包括在实际系统许可、合同和顾问咨询等等所需的成本之中。一个闲置的Cloud Foundry云PaaS平台需要至少20多个虚拟机（VM）并且拥有40多个IP地址，而这仅仅只是用来为一个新的云平台部署一个空的管理界面。
但这些还不是全部：如果你想运行应用程序，你需要更多的许可证。请致电销售部并安排一次网络会议，他们会给你按“应用实例”报一个每年重复收取的费用（或者按照“Tiles”、或“Cells”或“BBS”或“Cell Rep”或“Service Brokers”、或“Floating Stem Cells”、或其他二十多个没人懂的虚构术语的报价）。在你已经购买了一些无法真正运行的东西之外，你将获得“巨大的优惠”来支付额外的费用，将你自己的应用程序运行起来。
在基准现实之上推销增长的愿望是很容易想到的。你应该推销一个每月399美元的超级豪华健身房会员资格，而不是一个更实惠的每周3小时的4.99美元的会员资格。
始终要让客户相信，你的软件是他们实现数字化转型，使之成为一家灵活的、多云平台的、和面向未来的公司的唯一途径。
幸运的是，你的平台是构建在“每实例定期订阅许可”的基础之上的，同样幸运的是，你的平台相信“微服务”是未来的发展方向，它让你可以方便地增加执行最琐碎任务所需的实例数。多么大的增效作用！你对计算未来的愿景可以通过你喜欢的商业模式来实现极大的盈利。多么大的赚钱机会！
很明显，你的客户想要创建的每一个服务都需要100个单独的“微服务”，每个微服务都需要自己的实例许可证。你现在唯一的任务就是说服客户让他们的整个公司将所有系统都运行在你的平台之上。你要让客户相信，他们将会得到无如伦比的迭代速度，在下一季度结束前，他们可以部署2,000个具有商业价值的服务项（每个服务项都有100个微服务依赖项），这要归功于他们新的、按使用计费的、定期获得授权许可的硅谷心态（Silicon Valley state of mind）。
在支付6-8位数的许可费之前，听到仅仅一个闲置的系统每年的托管费用就要花费20万美元会让客户的头脑清醒过来。任何一个清醒的客户都会把销售人员赶出会议室，并且把你的公司永远放在黑名单里。如果一个闲置系统的效率如此之差，即使是你能想象到的最慷慨的客户，也不会相信这个部署到生产环境的系统在现实世界中是高效、可靠或稳定的。他们一定认为这个产品是他们进化的死胡同。
作为一个构建欺诈软件的人，你唯一剩下的方法就是加倍使用“共谋垄断”（Confusopoly，译注：如果[卖方]能够使消费者产生足够的困惑，那么消费者就不必知道他们正在做出什么选择）这一招了。如果顾客不明白他们在买什么，他们就必须相信你。信任是你赚钱的方法，信任是你如何获得客户和投资者的优势。
你可以使用他们的PCF Sizing Tool亲自查看定价示例。启用高可用性是可选的（什么？！），但如果你确实需要冗余，则必须运行所需服务的三个或更多的副本，因此只需将所有实例数量及其相关的每小时费用乘以三倍即可。
然而，在考虑不周的系统中启用高可用性会降低总体可靠性。你想添加冗余，但每个组件在其故障转移（failover）/冗余（redundancy）/高可用性（HA）系统上中都有不同的未经测试的故障场景。Cloud Foundry由16+个基础服务组件构成，每个组件都有自己独立的HA机制。
实际上，我们可以证明围绕“只需添加另一个依赖项”的思想构建的管理架构无法实现任何目的。
每个相互连接的组件都有独特的要求，这意味着客户必须对其生产平台的每个依赖组件中保留一些专家。这些依赖组件并不相互独立，由于它们的相互关联性以及在任何无害的网络故障期间发生灾难性共同故障的倾向，因此将它们组合在一起会很可能降低整个系统的可靠性。
将许多不同的“故障转移”模型作为系统的依赖组件来运行会使系统变得不可靠，并且难以理解。你无法对系统的当前状态做出预期，更不用说它未来的任何状态，因此当故障发生时，你只能重新启动所有组件。
享受你的宕机时间吧。（你可以“安慰”自己或客户）这只是个一次性错误。（在明天到来前）不会再发生。
恭喜：你已经创建了一个系统来销售你无法理解的东西，但这也意味着你的客户也无法理解它。你的客户会认为你已经控制了一切，而实际上你和他们一样迷失了方向。不过，别担心，你可以在这种混乱中混水摸鱼好几年，继续想方设法签一些大手笔地合同，直到客户发现你的欺诈行为。
说不定有人会在一切崩溃前收购你的公司呢，对吧？因为你已经在高层结识了很多有钱的朋友。当然了，你别想任何IPO的可能了，因为你在进入公开市场前，必须暴露出太多不可持续的财务状况。
当你进行一个软件欺诈时，你想把很多隐藏的成本转嫁到客户身上，但是不能让他们在一开始就觉察到。
拿MongoDB来说，某个公司的缺乏经验的暑期实习生可能会在公司生产环境中部署一个新的内部应用程序，安装随机软件包，然后使用MongoDB。这个实习生离开了，但是这个服务还在。这项服务并不可靠，因为MongoDB只是一个假象，公司失去了这个一个实习生，他在创建服务的时候负责照看这个MongoDB。所以现在你可以雇佣MongoDB来提供咨询/支持服务来维护这个没有时间重写的内部应用程序。系统可以工作了！
对于Cloud Foundry云平台，整个系统作为一个完整并可立即使用的平台销售，但是你必须花上六个月的时间来训练你的员工如何使用它。另外，因为现实世界中没有人真正使用这个东西，所以你永远无法雇佣有实际经验的人。如果你无视那些让你每天都会遇到错误和无限次重复宕机的逻辑，继续使用这个漏洞百出的系统，那么你就必须让每个员工经过6个月的错误跟踪培训，然后他们才知道如何才能不破坏你的这个神奇的、无限可扩展的、每秒不能处理超过4个请求的平台。
然后，在你的员工结束六个月的培训后（在你最初的合同的基础上又要添上一笔因为“结对编程”而产生的每小时双倍工资的费用），他们会发现系统根本不能工作。尽管整个系统（包括销售人员和卖给你系统的整个公司）声称它能执行X，Y，Z，但是当你使用这些功能时，系统就会失灵，什么功能都执行不了。你最终发现你什么都没有得到，只是你的公司在一个平台上浪费了6到18个月的时间。
进行软件欺诈时，你得寄希望客户公司没有足够的智慧在产品被证明不能工作时，抛弃这个坏的产品。通常公司都不愿意承认他们被骗以荒谬的高价从那些供应商那里购买了软件和服务。首席技术官认为他们自己是公司数字转型的唯一真正世主，如果他不得不承认自已受骗而选择了一家见不得人的供应商，那么这将是对他们个人自信的强烈打击。
很多公司宁愿无视被销售驱动软件平台欺诈而在软件许可、培训、员工时间和服务器硬件上耗费的数百万美元带来的负投资回报率，也不愿承认自己的执行决策能力差。
为了继续你的软件欺诈，你需要建立一个尽可能难以理解的平台。使你的公司免于对失败负责，可以使用“失败总是由些依赖项的一次性的问题导致的”这一借口。这样你就需要很多组件，包括许多功能目的相反的组件。
以Cloud Foundry为例，查看甚至启动所需的所有组件及其所需的实例计数（每个组件都在自己的VM中），甚至都需要启动Cloud Foundry 高可用系统。
你也可能会问，为什么同时需要consul和etcd组件？好吧，理由很简单。在真正的“如何构建软件，使其永远无法正常工作”的软件欺诈方式中，你不希望内部团队进行协调。让他们分成两个团队，强迫每个团队从零开始学习和重新发现所有东西，并且永远不要让他们在同一个任务上工作超过一天或两天。
这样，团队A决定使用consul组件作为一个特性，团队B决定使用etcd组件作为一个特性，这样你就有了两个系统（每个系统都有3个以上独立的虚拟机和故障场景），你需要照看好每一个以保持系统的可靠性。
要求相似但不相同的依赖项（组件）是构建一个“软件欺诈即服务”公司的一个很好的策略。每一个新的依赖项（组件）都会增加客户的困惑，让你增加了一个“一次性失败”的借口，这样你就更加容易以掩盖固有的体系架构崩溃的真相。
除了重复组件之外，你还希望以本来就不该有的方式重新使用现有软件。
你想监控一个服务吗？使用monit吧！虽然monit有自己的故障条件，并且它根本就不是进程监控系统的一个好用的替代品。不过那也没有大不了的，当monit与进程失去联系时，重新启动整个平台就好了。毕竟，没有人在生产环境中运行这些。作为一个客户，你付了一大笔钱，获得的只是为其他有类似问题的客户充当一个免费的分布式QA团队的特权而已。
构建欺诈性软件的最后一记妙招：要求所有东西根据你自己的错误抽象提供一个接口。这样，你可以将失败归咎于客户机软件和主机平台之间错误的抽象，而不是平台上运行的软件，或平台本身。
拿Cloud Foundry为例，一些神奇的错误发生了，但是你无法指责它，因为错误可以归咎于错误的Tiles抽象。
为什么要用“Tiles”呢？任何流行的软件都不会将自己重写为兼容规范“Cloud Foundry”，因此Tiles就成了软件和平台之间的桥梁。Tiles通知如何设置软件实例（如果软件是HA，则包括多个实例）、自动备份、监视软件、故障转移等等。
创建一个可行的Tile接口通常和底层软件本身一样的复杂，这违背了平台承诺给客户的“零介入和无须任何经验”的承诺。
创建一个可行的Tile需要对软件、系统、分发、故障转移、备份和tiled磁盘模式等领域知识相通精通。但是，作为一个欺诈性软件提供商，你不愿意相信这些“经验”或愿意相信这需要比任何一次性兼职、结对编程、列出任务清单、或从谷歌上复制答案更加复杂的工作，这样你的复杂抽象接口的可靠性就非常低了。
客户购买你的欺诈性平台是为了实现复杂操作的高可靠性，但结果恰恰相反，他们只是从你那里获得了所有操作的低可靠性。但这又有什么关系呢。客户已经支付并签署了多年的定期合同，这样你的公司至少在实现客户需要的功能前，可以再苟延残喘几年。
你想要部署一个高可用性（HA）数据库群集吗？很抱歉，该数据库的Tile仅支持在你的平台上的一台服务器上作为一个单独的部署。
你想要自动备份数据库吗？这个主意很棒！但是Tile仅能够在未加密的netcat上运行mysqldump并将结果通过网络传输， 这一点对你来说可以忽略。你一定不在乎你的数据或PCI或HIPA，是吧？你的竞争对手以前从未在网络中安装过这些软件。你也不需要考虑加密网络连接，因为我们所有的网络都是完全安全的。
与多个相互冲突的依赖项一样，Tile之所以“出色”，有一个原因：每个抽象的Tile接口都增加了平台的复杂性，降低了你对运行系统状态进行判断的能力。平台提供者可以在一次又一次地发生抽象故障转移错误时，轻描淡显地用一句“哦，又是一个一次性的错误”打发过去。毕竟事情太复杂了，怎么会有人预测到你所经历的那些错误呢？
你一定不会放弃你们的CTO买的这个七位数的系统吧？相信我吧，下一个bug修复序“肯定”是最后一个。
和所有“好”的公司一样，你希望根据个人关系和CEO社交网络的友谊度来决定招聘和晋升。
用80%的low-information程序员来填满你的公司，也有助于让你躲在“我们不认为这些失败是可能的，我们的无能是无可指责的！”的盾牌后面！”
作为一名员工，当你听到负责人讨论分布式工程时，你认为你来到了疯狂世界。你可能会听到诸如这样的言论：“只要不发生网络隔断，我们就高度可用”，或者“我们只支持单个数据中心部署，因为你不能在一个数据中心中有多个网络分区”，或者“我们不需要加密，因为我们只支持一个数据中心”。
当你的产品负责人做出决策选择一个不稳定或毫无用处的架构时，你的产品还能有什么希望？
如果你浏览Cloud Foundry的HA文档，你会注意到这是一个自说自话的架构。整个系统的前提是网络总是低延迟，从不出现故障也不会有性能降低的时候。你的平台必须基于这样的设计前提：网络永远不会失败。这个文档宣称你可以把它部署在高可用区（Multi-AZ），但是你够胆尝试在多个数据中心或区域部署这种混乱的架构吗！如果你的网络的任何部分出现故障，则必须重新启动整个平台，以便所有底层组件重新同步到一致状态。
你可以让那些专注于低值/高加成的Rails CRUD 咨询服务的“敏捷成对编程”的狂热者们来构建你的关键系统，这样你就可以在构建一个可证明的不稳定系统的同时，保留对故障的貌似合理的否认。最后，你会发现这和合并几十个stackoverflow上复制/粘贴的答案的效果完全相同。
销售欺诈性软件的最简单方法是：从一开始建立你的软件的历史时间表。
客户倾向于认为软件存在的时间越长，它就越稳定，所以如果你不能在第一年以你希望的速度销售你的软件，那就稍等一下。在接下来的几年里，继续推销“软件存在的证据”作为产品质量和客户价值的体现。客户自然会认为，既然你的公司还存在，你应该是值得信赖的。
举个例子，Cloud Foundry已经有6到10年的历史了，它最初是VMware创建的，然后移交给一家新公司，它的可靠性却仅仅达到一个6个月前才出现的、仍处于beta测试阶段的系统的预期。然而这似乎并没有阻止全球规模的客户受骗购买这样一个无法正常工作的、并在一个季度的时间内祸害掉内部系统架构的平台。
只要让你的客户高高兴兴地在他们期望工作的平台上玩“在生产环境中部署QA系统”的游戏就可以了。如果你幸运的话，他们不会有胆量怀疑这是一个彻头彻尾的软件欺诈。
原文 ：https://matt.sh/anatomy-of-a-fraud
☞GitHub 疑遭中间人攻击，无法访问，最大暗网托管商再被黑！
☞为何你的 SaaS 想法总是失败？没想清楚这 4 个原因可能会继续失败！
☞万字好文：智能合约编写之Solidity的编程攻略，建议收藏！
微信扫码咨询专知VIP会员