网站故障隔离的成本怎么算？发布者：本站     时间：2019-11-13 16:11:44

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

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