一转眼到了传统的忙碌的年末，以往这个时候都是人力最紧张的时候，今年也不例外。 唯一有变化的就是今年是新成立的北京分公司。虽然是新成立的分公司，但是技术人员的管理的组织结构主要是从以前未拆分前的组织结构继承而来。从一年的来看运作情况来看，这个继承而来的重型结构有时候会影响到资源利用率。显然招聘更多的人是最简单的方案，但从目前的情况来看，如何提高资源利用率才是唯一可行的方案。
想到这里，我就不得不想起今年发生的另外一件事情。大概九月份的时候吧～，一天快下班的时候有个销售同事反馈说某个客户希望了解应用安全方面的内容，而且第二天就要去客户那边交流。得到这个消息的时候已经下班，至于谁会听，客户具体的要求，销售同事和他的直接联系人都不能讲清楚。只好制作了一个比较通用的关于应用安全的 PPT ，希望通过这个 PPT 将全部内容过一遍，然后再根据他们感兴趣的内容展开。交流很顺利，关于应用方面安全方面的内容都讲清楚了，但客户似乎一直把关注放在 DDoS 上面，一问才知道原来是客户前几天遭受到了 DDoS，虽然一通手忙脚乱，但是最终还是防护住了。在庆幸之余，客户想到了我们，希望听听我们专业安全解决方案的意见和建议。
客户关心的重点在于他们应该采取什么样的 DDoS 策略？他们提出的方案是拓宽网络总容量，加强出口处对 DDoS 的防护能力。但是他们的领导提出了另外一个方案，就是建立多套独立的系统分别为来自不同运营商的客户提供服务。客户领导提出的方案的好处在于当遭受到来自于某个运营商网络的 DDoS 流量时， DDoS 将仅仅影响这个运营商的用户。而当时客户的工作是要对这两个方案进行评估并给出实施的步骤和费用。我当时就给他打了一个比方：
这两种方案如果用一个简单的方法来对比，就是我们都做过修池子的算术题。两个方案一个是修一个大池子，另外一个是修多个等容量的池子。如果以同样的速度放水，那肯定是放空大池子需要的时间最长。多个小池子的方案很容易导致某个小池子彻底的被放空，虽然此时其他的池子可能还有水。
对于 DDoS 防御来说也是一样，解决方案的一部分就是提供更高容量的资源池。如果我们人为的把资源划分到各个单独的系统，当 DDoS 发生的时候很容易造成某个系统资源耗尽，而此时其他系统可能还有大量的限制资源。如果我们用一个资源池来响应所有的请求，在遭受 DDoS 的时候，可能所有的系统都会受影响，但仅仅都只是性能方面的影响。如果攻击者要想让系统彻底不能提供服务，他需要的攻击流量将是所有单个系统的总容量的和。各个系统的总容量的和显然比单个系统的容量高，因此这样的方案在防护能力上来说显然是更高的。
其实，我觉得我们遇到的问题和这个 DDoS 防护策略选择比较类似，我们就是希望在同等的资源支持情况下获得更高的服务能力。从前面的类比我们很容易得到一个结论：如果可能的情况，将多个小的资源池进行整合，能够提高整体对外服务的能力上限。我觉得将一些隔阂打开将资源进行整合是一个提高资源使用率的选项。
BTW：要说的话题太散了，总得找个主线穿起来。想来想去还是找个比较合适 —— Pool 这个比较合适～