『究竟』软件欺诈的骗局揭露：“替罪羊”究竟是如何构建的？( 五 )
不该使用的组件
除了重复组件之外，你还希望以本来就不该有的方式重新使用现有软件。
你想监控一个服务吗？使用monit吧！虽然monit有自己的故障条件，并且它根本就不是进程监控系统的一个好用的替代品。不过那也没有大不了的，当monit与进程失去联系时，重新启动整个平台就好了。毕竟，没有人在生产环境中运行这些。作为一个客户，你付了一大笔钱，获得的只是为其他有类似问题的客户充当一个免费的分布式QA团队的特权而已。
添加错误的抽象层
构建欺诈性软件的最后一记妙招：要求所有东西根据你自己的错误抽象提供一个接口。这样，你可以将失败归咎于客户机软件和主机平台之间错误的抽象，而不是平台上运行的软件，或平台本身。
拿Cloud Foundry为例，一些神奇的错误发生了，但是你无法指责它，因为错误可以归咎于错误的Tiles抽象。
为什么要用“Tiles”呢？任何流行的软件都不会将自己重写为兼容规范“Cloud Foundry”，因此Tiles就成了软件和平台之间的桥梁。Tiles通知如何设置软件实例、自动备份、监视软件、故障转移等等。
创建一个可行的Tile接口通常和底层软件本身一样的复杂，这违背了平台承诺给客户的“零介入和无须任何经验”的承诺。
创建一个可行的Tile需要对软件、系统、分发、故障转移、备份和tiled磁盘模式等领域知识相通精通。但是，作为一个欺诈性软件提供商，你不愿意相信这些“经验”或愿意相信这需要比任何一次性兼职、结对编程、列出任务清单、或从谷歌上复制答案更加复杂的工作，这样你的复杂抽象接口的可靠性就非常低了。
你相信那些结果吗？当然不。
客户购买你的欺诈性平台是为了实现复杂操作的高可靠性，但结果恰恰相反，他们只是从你那里获得了所有操作的低可靠性。但这又有什么关系呢。客户已经支付并签署了多年的定期合同，这样你的公司至少在实现客户需要的功能前，可以再苟延残喘几年。
你想要部署一个高可用性数据库群集吗？很抱歉，该数据库的Tile仅支持在你的平台上的一台服务器上作为一个单独的部署。
你想要自动备份数据库吗？这个主意很棒！但是Tile仅能够在未加密的netcat上运行mysqldump并将结果通过网络传输， 这一点对你来说可以忽略。你一定不在乎你的数据或PCI或HIPA，是吧？你的竞争对手以前从未在网络中安装过这些软件。你也不需要考虑加密网络连接，因为我们所有的网络都是完全安全的。
与多个相互冲突的依赖项一样，Tile之所以“出色”，有一个原因：每个抽象的Tile接口都增加了平台的复杂性，降低了你对运行系统状态进行判断的能力。平台提供者可以在一次又一次地发生抽象故障转移错误时，轻描淡显地用一句“哦，又是一个一次性的错误”打发过去。毕竟事情太复杂了，怎么会有人预测到你所经历的那些错误呢？
你一定不会放弃你们的CTO买的这个七位数的系统吧？相信我吧，下一个bug修复序“肯定”是最后一个。
教育客户
和所有“好”的公司一样，你希望根据个人关系和CEO社交网络的友谊度来决定招聘和晋升。
用80%的low-information程序员来填满你的公司，也有助于让你躲在“我们不认为这些失败是可能的，我们的无能是无可指责的！”的盾牌后面！”
作为一名员工，当你听到负责人讨论分布式工程时，你认为你来到了疯狂世界。你可能会听到诸如这样的言论：“只要不发生网络隔断，我们就高度可用”，或者“我们只支持单个数据中心部署，因为你不能在一个数据中心中有多个网络分区”，或者“我们不需要加密，因为我们只支持一个数据中心”。
当你的产品负责人做出决策选择一个不稳定或毫无用处的架构时，你的产品还能有什么希望？
如果你浏览Cloud Foundry的HA文档，你会注意到这是一个自说自话的架构。整个系统的前提是网络总是低延迟，从不出现故障也不会有性能降低的时候。你的平台必须基于这样的设计前提：网络永远不会失败。这个文档宣称你可以把它部署在高可用区，但是你够胆尝试在多个数据中心或区域部署这种混乱的架构吗！如果你的网络的任何部分出现故障，则必须重新启动整个平台，以便所有底层组件重新同步到一致状态。
推荐阅读
- 大学再有三个月就结束了，没学到知识，参加一个软件测试培训机构好吗
- 一同选车|全球销冠！比亚迪的插电混动技术究竟有多强？
- 大部分黑客或安全研究员读的是啥「大学专业 」
- 软件公司为啥频繁地在培训机构批量招人
- 最近有啥样的交友软件比较好玩呢
- 能和 Google Calender 方便双向同步的 iOS 日程管理软件有哪些最好也支持iPad
- 电子信息工程考研有啥偏软件类的专业可以报考
- 作为软件工程大二的学生，学习一般，编程一般，毕业后能干些啥
- 一个刚起步的互联网公司究竟需要哪些职位
- 如果做好一个手机股票软件