按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
「是的。」
「再来是这边——监控系统一年三百六十五天，每天二十四小时透过HCMP／SNMPTrap来监控系统的正常与否，发生问题时则以电子邮件通知。」
「是的。」
看不出有任何奇怪的地方。究竟发现了什么不对劲？
「还不懂吗？既然有能力侦测问题所在，就由我们自己来处理就好了，何必要等到用户通知我们呢？」
「啊。」
工兵急忙再次确认资料。确实如室见所言，两者的说明有着微妙的出入。
「真……真的耶。为什么？怎么会开出这样的规格来？」
「为了降低估价时的障碍处理件数。」
室见满不在乎地说道：
「警示的发生原因有停电和网路壅塞等许多种，并不一定就是哪里发生障碍了。所以，首先让用户自行确认，排除问题。当对方无法解决时，才联络我们。这是一种简易的筛选机制喔。」
为何要这么做……工兵心想，却忽然察觉到一点。啊啊，原来如此。
「目的是压低成本？」
「没错。」室见这么点头。
「既要遵守RFP的需求，又要将费用压在客户能够接受的范围，唯有出此下策了。不过在这种规格下，倘若真的发生障碍，我们未接获申告前将无法处理。这会导致系统持续处于罢工的状态喔。为了避免这种情况发生，只能请用户端随时随地都能接收警示。无论是下班时间、假日或者深夜。」
「…………」
未免太不方便了。真亏客户愿意接受这样的处理方式。不过，既然没有发生什么重大障碍，对方或许也就睁只眼闭只眼了吧。
「其他还有『备扰系统类的障碍，在下个营业日处理。以及，不对边缘交换器的连接埠实施监控』等，一大堆迁就业者的规格喔。还有这个『Best Effort模式线路的障碍问题，不在处理的范围之内』。」
「……那么，系统的建构方面又是如何？」
和刚才不同，室见的观点如今变得冷静无比。那么对于自己的工作，她或许也能给予客观性的建议吧。
「这个嘛……」
室见斜倾着纤细的颈部。
「和运用不同，规格上很少有可供置喙的部分。毕竟机器和线路这些东西是一分钱一分货，只要我们不赚得太多，应该不至于被刁难才对。多亏现有的供应商——Regio ，我们能评选出相当紧凑的规格来……只不过——」
「只不过？」
室见戳了戳网路架构图：
「我的备援方案，基本上都是采用Active/standby的架构喔。就是另外设置一组一模一样的系统，当发生障碍时可以切换过去。尽管可靠度很高，但待命的设备就会变成一种多余的呆重。可能会被指为浪费，而叫我们改成Active/Active架构。」
「？所谓Active/Active，就是同时使用两台机器来分担吧。这种事情真的可以做到？」
「这个吗，也不是办不到喔。只要使用『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和速度，然后点选【变更】键。如此一来，相关的资讯就会传送到该交换器，完成设定的变更。当然了。整个系统本身的管理资讯也会自动更新。设定和管理同时进行，简直就是一种理想的工具。」
工兵停下手中的笔，下意识叹了口气：
「不过，理想终归还是理想吧。我根本不知道怎么制作，而且应该也要花不少钱才对。」
他自嘲般地这么说道。但室见却保持沉默，一脸为难地盯着纸面。
工兵的一颗心不禁活跃起来，意识中闪现一丝希望。
咦，这莫非是——
「那个……室见，难道你会写这种系统？」
「不。」
立刻失速。满心的期待一口气消退。什么啊，害我白高兴一场。
他失望地垂下双肩之际，室见忽然翻过纸张背面，将刚才的