标题图片 | CSDN从东方IC下载
制作 | CSDN (ID:)
以下为译文：
这是一篇关于科技行业道德规范的文章。
福布斯最近发表了一篇文章，“硅谷初创公司的另一面：丑陋和不道德”，描述了客观存在的欺诈性科技公司的崛起。在过去的几年里，许多“超出产品本身”的过度营销泡沫已经破灭，更多的泡沫很快就倒闭了。
保护自己免受技术诈骗并不难，您可以非常轻松地做到这一点。虽然很难从软件开发中无穷无尽的“无可指责的错误”中辨别出很多不诚实，但客观地记录您的供应商如何撒谎可以让您快速而清晰地揭示欺诈模式。
构建可以无限期用作“替罪羊”的软件
如果你想赚钱，但又不想承担创造好产品的责任，你最好开一家软件公司——软件欺诈可以给你否认任何指控的空间。因为软件通常被认为非常复杂，以至于它被视为“不可预测”的东西。所以你不能因为你的失败而受到责备，因为与软件相关的一切都是“该死的”。
好吧，既然您已经决定从软件中赚钱，您的产品甚至不需要工作，这是迄今为止更好的主意，但是您最终如何用您的幻影产品 兑现您的客户布？
最简单的方法：向非常自命不凡且预算庞大的公司出售产品。永远不要卖给技术用户，因为他们会看穿你的谎言。
切勿让技术用户过早参与销售流程，因为他们可能会在您取悦拥有购买权的人之前发现您的软件欺诈行为。
当您让一家大公司的 CTO 相信您的产品愿景时，他本人将成为“公司的救星”，您将他们的个人形象与使用您的产品的结果联系起来。用行业术语来说，一家大公司的 CTO 将成为你的“内部冠军”，让他们更难相信你卖给他们的七位数软件是欺诈性的。他们不愿意接受这样的指责，即他们根据八卦、幻灯片和个人游戏购买的软件对他们的工作没有任何帮助。所以他们永远不会承认自己被骗了。
如果客户开始意识到您的欺诈行为，如果他们开始询问为什么要为一个每天都出现故障、停机和数据丢失的系统支付 7 位数，您只需抛出一个或多个以下现成的“专业替罪羊”就行了：
即使你的公司声称在软件方面是最好的，在开发方面是最好的，在测试方面是最好的，你总是可以不断重复这个谎言，毕竟它是软件，所以客户应该注意这些套路失败是心理预期的.
你也可以“以过于复杂的依赖为借口来保护自己免受责备”。
您还可以通过“将付费客户用作非自愿外包 QA”来确保自己免受责备。
不过没关系，您正在向某个孤立的公司销售软件，因此希望您的客户永远不会互相交谈。停机 30 天的客户 A 认为他们不走运，您需要做的是确保他们永远没有机会与同样停机 30 天的客户 B 交谈。由于多个客户端的多次中断可能会将您的软件标记为“无用”，因此重复使用“无可指责”、“不可预见”的错误不会被愚弄。
记住：您销售的软件不起作用，也永远不会起作用。
您销售的是一种完美的愿景，它整合了分散的生产力。但是，如果客户试用您的软件，他们可能会发现您的想法实际上是不可能的。然而，没有人愿意一开始就看到谎言。没有人愿意相信他们是被故意欺骗的，所以在最初的几年里你会很安全。
如果客户开始怀疑您在撒谎和作弊，只需在 CEO 级别采取一些措施。说服他们不要提前取消合同，消除他们起诉你欺诈的可能性。向客户抛出一些陈词滥调和承诺，例如免费延长 6 个月的合同。
为什么是“软件欺诈”？
当您创建的真正解决方案（软件）存在真正问题时，为什么不解决问题并进行欺诈呢？
创建一个有效的软件产品很难，销售一个欺诈性的软件产品要容易得多。
因为，您会发现自己受到以下因素的限制：
你有领导权，但显然没有技术能力。
贵公司的经营理念是单一产品概念，但事实证明你的单一产品行不通。
贵公司的产品已经使用了5-10年，无法维修，任何意义上的维修都不能让它可靠。
你必须保持你的公司稳定，直到一个更大的傻瓜把你捞出来。
软件欺诈模式，我们在不同阶段已经多次看到。
就像，这是一个非常具有欺骗性的模式。模型中的“面向非技术用户的技术产品特性”不可靠。 “你需要数据库吗？你需要使用数据库吗！不要担心我们的错或不信守承诺。您可以随时购买咨询和支持服务来弥补功能上的不足。对于数据丢失，lol ，我们只能（毫无歉意地）说对不起。”
发现软件欺诈的一个简单方法是查看它是否“被夸大了”：当营销始终是优先产品时，欺骗总是优先于创造更好的产品。
软件欺诈分析
一方面，经营一家欺诈性软件公司很容易：雇佣 22 岁的年轻人来构建复杂的系统，而无需相互交流。这样一来，您就拥有了一大堆永远无法运行且无法修复的软件，而您仍然有 30 个单独的非集成软件包，您可以将它们放在捆绑的价目表上，并作为“解决方案”出售给客户。
如果您担心客户可能会发现您缺乏专业知识（比如您自己编造的术语和非标准的技术堆栈），并试图锁定平台，您可以在一年内建立独立法律费用“开源基金会”并容纳您的代码片段。这样您就可以告诉您的客户，这里没有技术锁定，因为技术/代码属于开源基金会。
您可以告诉您的客户这是一个很大的优势：您的软件具有“开放核心”以及专有插件和托管服务的组合。
投资者青睐具有“开放核心”模式的公司，因为它们给人一种“客户自由”的错觉（以及没有“版权锁定”的错觉）。您可以这样欺骗您的客户：这是一个免费软件示例，您可以围绕它来建立公司的业务。哦，你需要修改一下吗？您需要安全更新吗？我们不为我们软件的“开放核心”提供支持。但我们很高兴根据年度许可向您出售我们的完整产品。如果您有兴趣，请参加此网络研讨会...
客户想要从您的付费版本切换回免费的“开放核心”版本，因为您声称您的软件在技术上没有被锁定，他们很快就会后悔。您的客户当然可以只使用“开放核心”，毕竟您没有任何技术锁定。或者，根本没有锁定任何东西。但是您会告诉您的客户：除了这个“开放核心”之外大数据培训是骗局，您的客户不会有安全更新、用户界面、季度功能更新（抱歉，“开放核心”版本只有每两年更新一次功能）和访问权限在发生任何故障时提供支持。祝运行您专有平台的“开放核心”版本的客户好运！我们“最有价值”的客户！
例如，他们通过使用“懦夫许可证”来模拟开放的外观。您当然可以查看源代码，但是任何与源代码公开或私下交互的东西，无论您是否发布，都必须向公众发布。拥有运作良好的法律团队的企业根本不会触及 AGPL 代码，因为根据其不受欢迎的有毒许可条款，所有内部商业机密都会公开。
——不过没关系。只要 VC 对你的营销、虚荣指标和不当的市场行为保持浓厚的兴趣，其他一切都不重要。
接下来，我们来分解一下大型软件欺诈的一些细节。
最低要求
每个软件都有最低要求。然而，你不能靠一个软件赚钱，你需要一个互联的“意大利面条”架构平台。
请记住，您必须是一个平台，而不是单个软件的一组要求（例如 4 核和 4GB 层）。您的平台需要在后台运行 20 个庞大而复杂的服务，每个服务需要 3 个虚拟机，每个虚拟机需要 32 GB RAM。您的平台是企业级的。谁在乎浪费 2TB 内存运行空闲平台？请记住：花钱是进步的标志。
隐藏的货币成本
作为一个真实的例子，运行一个闲置的企业级云平台（一个开源 PaaS 云平台）每年花费 50,000 到 200,000 美元，用于闲置系统（即使没有运行用户应用程序）“按次付费-”托管费用。你的平台很“重要”，因为它浪费了很多资源。
这些钱不包括在实际的系统许可、合同、咨询等成本中。一个闲置的 Cloud Cloud PaaS 平台需要至少 20 多个具有 40 多个 IP 地址的虚拟机 (VM)，而这只是用于为新的云平台部署一个空的管理界面。
但这还不是全部：如果您想运行该应用程序，您需要更多的许可证。请致电销售部门并安排一次网络会议，他们将为您支付每个应用程序实例（或每个“Tiles”、“Cells”或“BBS”或“Cell Rep”或“”或“Stem Cells”的经常性年费,”或引用其他两打没有人理解的虚构术语）。除了您已经购买的实际上不起作用的东西之外，您还可以获得“超值优惠”，以支付额外费用来启动和运行您自己的应用程序。
市场增长高于基线现实的愿望很容易想象。您应该以每月 399 美元的价格推广超级豪华健身房会员，而不是更实惠的每周 3 小时 4.99 美元的会员资格。
始终让客户相信，您的软件是他们数字化转型为敏捷、多云和面向未来的公司的唯一途径。
幸运的是，您的平台是建立在“按实例定期订阅许可”之上的，还幸运的是，您的平台相信“微服务”是未来的发展方向，让您可以轻松大幅增加执行任务所需的实例数量最琐碎的任务。多么伟大的协同作用！您对计算未来的愿景可以通过您首选的商业模式获得极大的利润。赚钱的好机会！
显然，您的客户想要创建的每项服务都需要 100 个单独的“微服务”，每个“微服务”都需要自己的实例许可证。您现在唯一的任务是说服客户让他们的整个公司在您的平台上运行他们的所有系统。您希望客户相信他们将获得无与伦比的迭代速度，并且到下个季度末，他们可以部署 2000 个业务价值服务项（每个服务项有 100 个微服务依赖项），这要归功于他们新的按次付费使用，定期获得许可的硅谷心态。
在支付 6 到 8 位数的许可费之前，听说仅一个闲置的系统每年的托管成本就可能高达 200,000 美元，这让客户头脑清醒。任何清醒的客户都会将销售人员踢出会议室，并将您的公司永远列入黑名单。如果闲置的系统效率如此之低，即使是您能想象到的最慷慨的客户也不会相信部署到生产环境中的系统在现实世界中会高效、可靠或稳定。他们一定认为这个产品是他们进化的死胡同。
作为开发欺诈性软件的人，您剩下的唯一方法就是在“串通垄断”上加倍努力。做出什么选择）这个把戏。如果客户不了解他们在购买什么，他们必须信任您。信任是您赚钱的方式，信任是您为客户和投资者获得优势的方式。
您可以使用他们的 PCF 工具查看定价示例。启用高可用性是可选的（什么？！），但如果您确实需要冗余，则必须运行所需服务的三个或更多副本，因此只需将所有实例计数及其相关的每小时费用乘以三倍。
但是，在构思不当的系统上启用高可用性会降低整体可靠性。您想添加冗余，但每个组件在其 ()/()/高可用性 (HA) 系统中都有不同的未经测试的故障场景。 Cloud由16+个基础服务组件组成，每个组件都有自己独立的HA机制。
实际上，我们可以证明，围绕“只需添加另一个依赖项”这一理念构建的管理架构毫无用处。
因为，每个组件对以下方面都有独特的要求：
故障转移模型
故障转移启动时间
故障转移恢复时间
分布式模型
状态维护模型
持久性要求
可靠性保证
每个相互关联的组件都有独特的要求，这意味着客户必须在其生产平台的每个相关组件中保留一些专业知识。这些相互依赖的组件并不是相互独立的，而且由于它们相互关联并且在任何无害的网络故障期间都容易发生灾难性的共同故障，因此将它们组合在一起可能会降低整个系统的可靠性。
将许多不同的“故障转移”模型作为系统的依赖组件运行可能会使系统不可靠且难以理解。你无法预测系统的当前状态，更不用说它未来的任何状态，所以当发生故障时，你只能重启所有组件。
享受您的停机时间。 （您可以“安慰”自己或客户）这只是一次错误。 （直到明天）它不会再发生了。
恭喜：您创建了一个系统来销售您无法理解的东西，但这也意味着您的客户也无法理解它。你的客户会认为你在掌控之中，而事实上你和他们一样迷失方向。不过不用担心，您可以在这个烂摊子中钓鱼多年，并继续尝试签署一些大额合同，直到客户发现您的欺诈行为。
也许有人会在一切崩溃之前收购你的公司，对吧？因为你在高层交了很多有钱的朋友。当然，不要考虑任何 IPO，因为你必须在上市之前暴露太多不可持续的财务状况。
隐藏的时间成本
当您进行软件诈骗时，您希望将大量隐藏成本转嫁给您的客户，但您无法让他们一开始就意识到这一点。
例如，一个没有经验的公司暑期实习生可能会在公司的生产环境中部署一个新的内部应用程序，安装一个随机包，然后使用它。实习生走了，但服务还在。该服务不可靠，因为它只是一种幻觉，即公司失去了在创建服务时负责照顾服务的实习生。因此，现在您可以聘请提供咨询/支持服务来维护这个没有时间重写的内部应用程序。系统正常！
借助 Cloud 平台，整个系统作为一个完整且随时可用的平台出售，但您必须花费六个月的时间来培训您的员工如何使用它。另外，因为现实世界中没有人真正使用这些东西，所以你永远不能雇佣有实际经验的人。如果您忽略了阻止您每天遇到错误和重复停机的逻辑并继续使用这个错误的系统，那么您必须让每位员工接受 6 个月的错误跟踪培训，然后他们才知道如何才能不破坏您的惊人，可无限扩展的平台，每秒不能处理超过 4 个请求。
然后，在您的员工完成六个月的培训后（在“结对编程”的原始合同中增加双倍的时薪），他们会发现系统根本无法工作。尽管整个系统（包括销售人员和向您出售该系统的整个公司）声称它可以执行 X、Y、Z，但当您使用这些功能时，系统会失败并且不会执行任何功能。您最终会发现，除了您的公司在平台上浪费了 6 到 18 个月，您什么也得不到。
在进行软件欺诈时，您必须希望客户公司不够聪明，无法在证明无效时将其丢弃。公司通常不愿意承认他们被欺骗以高得离谱的价格从这些供应商那里购买软件和服务。将自己视为公司数字化转型唯一真正主人的 CTO 不得不承认，他们被欺骗选择了不可靠的供应商，这将打击他们的个人信心。
许多公司宁愿忽略在软件许可、培训、员工时间和服务器硬件上花费数百万美元被销售驱动的软件平台欺骗所带来的负面投资回报率，也不愿承认他们执行决策的能力差。
组件
为了继续进行软件欺诈，您需要构建一个尽可能难以理解的平台。使用“故障总是由某些依赖项的一次性问题引起”的借口使您的公司免于承担故障责任。这样你就需要很多组件，包括很多功能目的相反的组件。
以 Cloud 为例，查看启动所需的所有组件及其所需的实例数（每个都在自己的 VM 中），甚至启动 Cloud HA 系统。
重复的组件
你可能还会问，为什么你需要两个和 etcd 组件？嗯，原因很简单。在真正的“如何构建软件使其永远无法工作”的软件欺诈风格中，您不希望内部团队进行协调。让他们分成两个团队，强迫每个团队从头开始学习和重新发现一切，永远不要让他们在同一任务上工作超过一两天。
这样，团队 A 决定使用组件作为特性，团队 B 决定使用 etcd 组件作为特性，所以你有两个系统（每个系统都有 3+ 个独立的 VM 和故障场景），你需要照顾每一个都是为了保持系统的可靠性。
要求相似但不相同的依赖项（组件）是构建软件欺诈即服务公司的好策略。每一个新的依赖（组件）都会增加客户端的困惑，为“一次性失败”增加一个借口，让你更容易隐藏内在架构崩溃的真相。
不应使用的组件
除了复制组件之外，您还希望以不应该的方式重用现有软件。
您想监控服务吗？使用监控！虽然 monit 有自己的故障条件，但它根本不是进程监控系统的良好替代品。但这没什么大不了的，当 monit 与进程失去联系时，只需重新启动整个平台即可。毕竟，没有人在生产中运行这些。作为客户，您需要为有类似问题的其他客户充当免费分布式 QA 团队的特权而支付大量费用。
添加错误的抽象层 (JALA)
构建欺诈软件的最后一个技巧：要求所有东西都提供基于您自己错误抽象的接口。这样，您可以将故障归咎于客户软件和主机平台之间的错误抽象，而不是平台上运行的软件或平台本身。
以 Cloud 为例，发生了一些神奇的错误，但你不能责怪它，因为错误可以归咎于错误的 Tiles 抽象。
为什么要使用“瓷砖”？没有流行的软件会重写自己以兼容“云”规范，因此 Tiles 成为软件和平台之间的桥梁。磁贴告知如何设置软件实例（如果软件是 HA，则包括多个实例）、自动备份、监控软件、故障转移等。
创建一个可工作的磁贴界面通常与底层软件本身一样复杂，这违背了平台对客户“零干预、无经验”的承诺。
创建可行的磁贴需要对软件、系统、分发、故障转移、备份和磁贴磁盘模式等领域有深入的了解。但是，作为欺诈性软件提供商，您不愿意相信这些“经验”，或者愿意相信这需要比任何一次性兼职工作、结对编程、制作待办事项或复制答案更复杂的工作来自谷歌，所以你复杂抽象接口的可靠性很低。
你相信这些结果吗？当然不是。
客户购买您的欺诈平台是为了复杂操作的高可靠性，但结果恰恰相反，他们只是从您那里获得所有操作的低可靠性。但这有什么关系。客户已支付并签署多年期合同，这样您的公司至少可以再生存几年，然后再实施客户需要的功能。
您要部署高可用性 (HA) 数据库集群吗？抱歉，此数据库磁贴仅支持在您平台上的一台服务器上作为单一部署。
您想自动备份您的数据库吗？很好的主意！但是 Tile 只能在未加密的情况下运行并通过网络传输结果，您可以忽略它。您一定不要关心您的数据或 PCI 或 HIPA，对吗？您的竞争对手以前从未在网络上安装过这些软件。您也无需考虑加密您的网络连接，因为我们所有的网络都是完全安全的。
与多个相互冲突的依赖项一样，Tile 之所以“好”，有一个原因：每个抽象的 Tile 接口都增加了平台的复杂性，并降低了您对正在运行的系统状态进行判断的能力。平台提供者可以通过轻描淡写的“哦，另一个一次性错误”一遍又一遍地忽略抽象故障转移错误。毕竟这么复杂，怎么会有人预测到你正在经历的错误？
您不会放弃您的 CTO 购买的这个七位数系统，是吗？相信我，下一个错误修复“绝对”是最后一个。
教育客户
像所有“好”公司一样，您希望根据与 CEO 的社交网络的个人关系和友谊来做出招聘和晋升决定。
用 80% 的低级程序员填补您的公司也有助于让您落后于“我们认为这些失败是不可能的，我们的无能是无可非议的！”盾！ "
作为一名员工，当您听到老板讨论分布式工程时，您会认为自己身处一个疯狂的世界。你可能会听到这样的说法：“只要没有网络分区，我们就是高可用的”，或者“我们只支持单数据中心部署大数据培训是骗局，因为你不能在一个数据中心有多个网络分区”，或者“我们不支持不需要加密，因为我们只支持一个数据中心。”
当您的产品负责人决定选择不稳定或无用的架构时，您的产品还有什么希望？
如果您浏览 Cloud 的 HA 文档，您会注意到这是一个自言自语的架构。整个系统的前提是网络始终是低延迟的，永远不会出现故障和性能下降的时候。您的平台必须在 Web 永远不会失败的前提下进行设计。文档指出您可以将其部署在高可用区（多可用区）中，但您是否有足够的勇气尝试在多个数据中心或区域中部署这种混乱的架构！如果网络的任何部分出现故障，则必须重新启动整个平台，以便所有底层组件重新同步到一致的状态。
您可以让专门从事低价值/高红利 Rails CRUD 咨询服务的“敏捷结对编程”爱好者构建您的关键系统，这样您就可以构建一个可证明不稳定的系统，同时保持对故障的合理否认。最后，您会发现这与合并上面复制/粘贴的数十个答案的效果完全相同。
总结
销售欺诈软件的最简单方法：从一开始就建立软件的历史时间表。
客户倾向于认为软件存在的时间越长，它就越稳定，因此，如果您无法在第一年以您想要的速度销售您的软件，请稍等片刻。在接下来的几年里，继续销售“软件存在的证据”作为产品质量和客户价值的体现。客户自然会认为，既然你的公司还在，你应该值得信赖。
例如，Cloud 有 6-10 年的历史，它最初是创建的，然后移交给一家新公司，它的可靠性只有 6 个月大，仍然是 beta 测试阶段的系统预期然而，这似乎并没有阻止全球范围内的客户被欺骗购买一个无法正常工作并在四分之一时间内破坏其内部系统架构的平台。
让您的客户乐于在他们期望使用的平台上玩“在生产中部署 QA 系统”游戏。如果你幸运的话，他们不会有胆量怀疑这是一场彻头彻尾的软件欺诈。
原文：
【结束】