网站故障隔离的成本怎么算？

假如创建的架构许可你以面向服务或者面向资源的方法划分代码，那么你就有了关注的天真性，能够给这些服务专门指派工程师了。当你照旧一家小公司时，这样做可能意义不大。但是随着你的公司发展，代码数量、服务器数量和体系的团体复杂度都在增加。要处理这种复杂度的增加，你就必须要集中你的工程师。假如不能让你的员工专注于本身特定的领域，那么就会造成太多的工程师了解太少的整个体系的信息，以致服从低下。

假如你运营的是一个电子商务站点，那么你可能有代码、对象、方式、模块、服务器和数据库，专门用于登出、搜索、对比、欣赏、物流、存货管理等。通过给这些领域专门分配团队，即使这个领域的代码库复杂、有难度而且在赓续扩大，这个团队也会成为该代码库的专家。有了这种专业性，就能更快地开发出新功能，更快地解决已知的或已有的故障和问题。因为这些交付的速度加快了，那么修复bug、故障的解决方案以及新开发的功能的上市时间也就缩短了，此外，开发的隔离以及理想状态下的体系或服务的隔离，会削减单- 体系开发中可能发生的合并冲突。这里，我们采用的术语“单一体系开发”，指的是一个特定产品中的所有函数、对象、过程和方式共享资源。多个工程师都签出统一个复杂体系的代码，可能会在代码合并时增长冲突或出错的可能性。让专门的软件开发团队负责专门的代码，会削减这种冲突。
 
当然，这并不是说代码复用不应该是组织关注的重点，它绝对应该是。你应该开发一个共享的代码库，还应该考虑专门指派一个团队负责开发和监管这个共享代码库。可以用服务到服务、共享的可动态加载的代码库或者在编译产品时加以编译或链接的代码库的情势，来实现这些代码库。我们常用的方式是采用团队专用的共享代码库，假如一个负责不共享代码库的团队开发了一个有效的、能共享的组件，那么应该把这个组件加人团队共享的代码库。
 
因为工程师总是喜好赓续面对挑衅，所以你可能忧虑工程师不会乐意在某个特定领域花费许多时间。这时你可以让工程师轮换地在不同的领域工作，以使他们更好地了解整个体系，久而久之，这样做能发挥他们的才能，帮助他们发展。此外，这样做还会为你培养-位对体系有着广泛熟悉的将来架构师，或者会为你打造一个快速反应的SWAT团队，其中的成员可以敏捷集结，解决故障和问题。
 
故障隔离不仅能缩短 上市时间，基于同样的方法和理由它还能降低成本。对此一个视角是，每个工程师每小时或天天的生产力越高，那么你的单位成本就会降落。例如，在一个复 杂的单一 体系中，假如要生成通俗的故事或用例，通常必须要5个软件开发人日；而在一个用泳道分隔的系本就被削减了10%。统中，生成通俗的故事或用例，则只必须要4.5个软件开发人日。这样软件开发工作的平均单位成交量价值。你可以决定把软件开发人员削减10%，也可以用较低的成本实现等量的产品提开、单位成本降低了，你可以用它来做两件事中的一件，这两件事都会影响净收人， 从而影响此外，你还可以决定保持当前的成本结构不变，而用雷同的成本开发出更多的产品。这里的关键是你要选对产品，选择会增长你收人的产品。假如你成功了，那么你不仅会提升净收人，还会使你的股东变得更富有。
 
你大概会认为额外的站点通常会比-个站点花 费的资本多，而目运营成本也会增长。虽然事实的确如此，但大多数公司照旧盼望本身的产品能经受得住地理上相互隔离的种种灾祸，他们会投资打造各种级别的灾祸恢复方案，以便能够削减这些灾祸带来的影响。假设你具备了精确的故障隔离的架构，运行三个或四个故障隔离的数据中间的资本和花费，可能比运行两个完全-致的数据中间的成本小得多。
 
证实故障隔离有用性的另一个视角是看它对收人的影响。你可以计算在某段时间中失去的机会(失去的收入)。通常可以用成都网站建设体系失去的交易量以及将来比预计要高的客户离开率来衡量失去的收人。比较当前损失的收人与未来损失的收人，可以决定实现故障隔离的架构的成本是否合理。根据我们的经验，通过提升可用性和削减失去的机会，就可以证实故障隔离的架构是有用的。和bug修复。这种成本的降低会提升净收人，但不会增长收人。