按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
「这个吗，也不是办不到喔。只要使用『Equalcost multipath routing（注：等价多路径路由）』或者『MHSRP』等技术的话。不过，Active/Active本身相当麻烦喔。通讯品质会被较差的那一方拖累，也很难锁定某流量会经过哪条线路。另外，更麻烦的地方就在于CapacityPlanning（注：容量规划）。」
「Capacity……什么东西？」
「Capacity Planning，就是规划网路上某一点可处理多少的流量。若是Active/standby的话，就非常简单了对吧。倘若Active和Standby同样使用100M的线路，无论流量跑到哪里，传输上限都是100M。」
「应该是吧。」
「不过Active/Active昵？因为要使用两条100M的线路做负载平衡，所以最高可以处理到200M的总流量。而一旦发生障碍的话——」
啊啊。
原来如此，我懂了。
「一条100M的线路，根本无法处理高达200M的流量吧。」
「没错，会导致阻塞。有些业者会坚称那是一种降速机制……但我不喜欢这种说法呢。发生障碍的时候，根本无法立刻去判断哪些流量比较重要吧？要是因为网路缓慢或封包重送而影响到客户业务的执行，那么备援架构就没有存在的意义了。所以我坚持采用Active/Standby架构。」
中心思想可以理解，但用户是否能够接受，就是另一个问题了。如今需要加强这方面论述，以抵御Almada的质问。
「我知道了。那么，我会淮备相关的回答，以应付针对这方面的攻击。请你提供一下必要的关键字，之后由我来拟稿。」
「等等，我自己也试着统整一下。」
室见从包包中取出笔电，解除休眠后开始敲击键盘。没办法，来整理其他的提问项目好了。就是刚才所提到的运用课题，由于成本限制而导致的非蓄意业者本位假象。
唉……应该是在障碍处理流程图吧。
工兵翻动着文件，一边陷入沉思。
究竟该怎么回答才好呢？倘若只是回答「因为费用上的限制」，Almada很可能会反驳「不，按照那种价位，正常来说都能做得到吧」。然后接下来就是「办得到」和「办不到」各执一词，让用户留下最坏的印象。
要是能拿出某种数字性的证据就好了。抱着一丝希望，工兵不断地翻找资料，试图找出足以证明我方估价的恰当性和请款依据一类的东西。
……喔。
工兵停下手指。
运用编制图中夹杂了几张表格。标题为「十一月处理纪录」，上面整理了业平产业通报过的警示和委托项目。
工兵查看表格的内容。发生时间、处理者、处理内容、结案时间……喔喔，很不错嘛。只要将摘要整理起来，就能精淮地查出每个月的工时为多少，以作为请款的依据。先抄在别张纸上，做个统计好了……
写了好一会，工兵忽然停下动作。
嗯？
目光不自觉地被表格所吸引。这个数字是怎么回事？他急忙确认其他资料，查询记载的意义为何。随着对内容的理解愈来愈深入，工兵的脸色逐渐发青。
（这个……会不会太糟糕了？）
「？怎么啦，樱坂？」
室见一脸疑惑地问道。工兵摇摇头，递出手中的处理纪录：
「这是骏河系统去年的运用工时清单。藉由统计实际的工时，向客户表明我们的估价是合理正常的。」
「这样很好啊。有什么问题吗？」
「你看依照委托内容分类的摘要部分。每月平均都在数件内，唯独某处的件数很不寻常对吧？」
「十一月……十二件？十二月也有十八件，这是什么东西啊？」
室见眯细双眼，目光落在「交换埠设定变更委托」的字样上。
「是伺服器收容交换器的设定变更喔。接获客户『我想把这台伺服器连到指定的网路上』的委托时，就将实体连接埠和VLAN做关连……分配一种类似网路ID的东西，就能使用了。」
「这我都知道啦……」
但真有这么多件吗——室见露出这么询问的表情。这也难怪，毕竟自己也是这样怀疑的。
「客户扩充系统的速度，可能比我们想像中的还要快喔。唔……其中还包括了关闭连接埠的委托，所以算是有增也有减。总而言之，由于客户频繁发生交换器的设定变更，所以委托的件数也跟着增多。」
「……的确出乎我们的预料呢。不过有什么问题吗？这就代表我们发生了额外的工时，而且还是收取同样的月费。客户高兴都来不及，又岂会迁怒于我们。」
「按常理来说，的确是这样没错。」
工兵拿起一旁的运用需求定义书，迫不及待地直接翻开中间部分：
「看这个。关于伺服器收容交换器的运用。『本系统的责任分界点至边缘交换器的连接埠，不负责管理各连接埠的设定及连线状况。连接埠的组态资讯由客户自行维护，变更设定时的资料更新，也由客户自行实施』。」
「…………」
室见皱起眉头。她一脸凝重地接过需求定义书并详加确认，呼吸顿时变得急促起来：
「换句话说，这十二次和十八次里，客户也同时更新了这么多次的管理资料？」
「是的，而且我们既然不负责组态的管理，对客户的申请也就未加确认，直接拿来设定了。其结果就是，由于申请内容的错误或疏漏，使得连线障碍频繁发生……平均每一次的申请，后绩都要伴随三、四封修正申请的往来。」
客户说什么，我方就照做。申请内容有无问题，都是客户必须负责的，骏河系统完全不加以干涉……就某层面来说，这是相当简洁的运用。毕竟有了控制成本这个名义，再加上双方事前都已经敲定：相信应该没有人会抱怨才对。但实际上，客户所承受的压力确实不小。倘若Almada要发动攻击，这势必为一个理想的目标。
工兵猛然回忆起痛苦的往事。
江古田建设的败因。据点资讯的管理方法。
当初认为据点的整合与废除会很频繁，因此骏河系统才委托客户自行管理组态。相较之下，Almada却是提案使用一套系统，透过专用的网页来做据点的即时管理。至于最终的结果如何，就不用再多说了。假如敌人这一次也采用相同的手段——
工兵全身冒出一股寒意。
就仿佛走夜路的时候，前方居然出现一个大洞。幸亏身上刚好带有手电筒，才能及时发现。但若未能察觉而继续前进的话，就会摔得遍体鳞伤。
工兵急忙拿出手机：在电话簿里寻找人名。
「等……等一下，你要打给什么人？」
室见狐疑地问道。
「那还用说，当然是和梢商量一下了。请她想办法，看能不能在当前的成本下，改善交换埠设定的运用——」
「笨蛋。」
她一把抢过手机，表情僵硬地看向这边：
「你冷静一点，原价维持不变，却还要单方面加重作业，你想把这个案子搞成钱坑专案吗？况且只有这个部分不寻常降价，你要怎么顾及和其他估价项目的整合性？工时单价的说明会变得乱七八糟喔。」
「话是这么说没错……」
但若不设法解决这个问题，必定会导致失败的局面。一旦发现任何的突破口，Almada势必就会全力抢攻吧。既然得知弱点所在，就不能放任不管。
「啊，不然就说我在做prcsales如何？因为这位客户后绩可望会发包其他案件，所以我们先实施一些运用支援，当作是提案活动的一部分。」
工兵满怀希望地这么建议，却立刻遭到室见摇头否定。
「名义上说得再好听，一样要消耗我们员工的工时吧？到头来，还是要有人无偿提供支援。这可是做生意的旁门左道，属于犯规的喔。」
「不然——」
工兵的思考停止。没有其他的备案了。无论怎么想，脑中依旧是一片空白。
「……难道真的没有办法了吗？」
室见毫无回应。她像一块石头般沉默不语，薄薄的双唇扭曲成へ字形。
工兵紧咬牙根。
混帐，就算已经知道敌人会从哪里下手，若不能采取防范策略的话，就等于徒劳无功。只要待在骏河系统这家公司里，难道就永远无法胜过Almada吗？
「要是我们公司有制作运用工具的编制……」
听工兵咬牙切地这么喃喃自语，室见忽然抬起脸来：
「什么？运用……什么东西？」
「就是运用工具啊。像Almada在江古田提案的那样，要是有一个能够自动受理连接埠设定变更的系统，问题就迎刃而解了。不仅运用起来省时方便，也不会影响到工时。」
「…………」
室见陷入沉默。她沉思了好一段时间后，投来试探性的目光：
「什么样的系统可以解决这个问题，你再跟我说得详细一点。」
「跟你说……这不过是我的一种想像罢了。」
「无妨。」
工兵叹了一口气，开始描绘出脑中的想像图。先是首页画面，上面有登入帐号和密码的输入栏位。
「……选单页有各台交换器的清单。然后，只要点击欲变更设定的交换器，就会跳出该机器的正面图，连接埠像这样排成一列。」
他在画面中央绘出许多方格，每个连接埠就用一个○来代表。
「然后，这些连接埠都可以点选。选择后，会出现目前的设定为何。包括速度、所属VLAN还有description………注解之类的。就是这方面的资讯。」
他接着画出下一个画面。
「凡是显示出来的资讯，都能进行变更。操作者可以在下拉式选单里改变VLAN和速度，然后点选【变更】键。如此一来，相关的资讯就会传送到该交换器，完成设定的变更。当然了。整个系统本身的管理资讯也会自动更新。设定和管理同时进行，简直就是一种理想的工具。」
工兵停下手中的笔，下意识叹了口气：
「不过，理想终归还是理想吧。我根本不知道怎么制作，而且应该也要花不少钱才对。」
他自嘲般地这么说道。但室见却保持沉默，一脸为难地盯着纸面。
工兵的一颗心不禁活跃起来，意识中闪现一丝希望。
咦，这莫非是——
「那个……室见，难道你会写这种系统？」
「不。」
立刻失速。满心的期待一口气消退。什么啊，害我白高兴一场。
他失望地垂下双肩之际，室见忽然翻过纸张背面，将刚才的草图拿到工兵面前。
「我做不出来……不过，我知道有人办得到。」
「咦？」
工兵盯着这张纸，错愕地猛眨眼睛。意想不刭的一句话。室见露出一副相当不愉快的表情。
「咦，是谁？藤崎先生？」
室见摇摇头。
「不然是……梢？」
「不对。」
嗯嗯嗯？
那么会是谁？难道是公司外面的人？她认识那种不收钱，却愿意出手帮忙的好心人吗？唔，可是她看起来为何会这么不高兴？就彷佛要向某个杀父仇人求援一般——
「你……该不会忘记了吧？」
面对沉默的工兵，室见用不带感情的声音这么告知，表情还是一样灰暗且忧郁。
「我们公司里，有个叫软体开发部门（SD）的地方。」
Software Development Division——简称SD部门。他们是负责应用程式以及网页服务开发的团队，由一群程式设计师和网页设计师所组成，拥有包括江古田建设在内的众多客户……似乎是这个样子。之所以如此不确定，主要是因为自己和他们之间至今几乎没有业务上的往来。记忆中和SD部门的接触，就只有刚进公司的第二天，把那里当成SE部门的办公室而误闯进去罢了。当时SD部门的成员们，个个都像冷冻鲔鱼一样毫无反应。自己如今依然能回忆起来，弥漫在室内的沉重气氛，土黄色的脸和嘴角上的白沫。由于这一幕惨�