质疑浙江农行的柜台异地转帐费用不合理

在中国农业银行杭州的一个营业网点做了一回比较糟糕的上帝。

具体的需求场景:我有一张在吉林省办理的的农行金穗卡,在杭州要给杭州一家公司的账户转一笔款。

办理的过程遇到种种不快,尽量忍了。先说拿到的回执是”银行卡取款业务回单”,上面的交易类型是”现金取款“。手续费扣了 100 元人民币。这个 100 块还是超过我的预料的,这毕竟是同行异地转帐而已嘛,这个 100 元怎么产生的,为什么交易类型是”现金取款”呢?

先是咨询了农行的一个业务人员,她第一次告诉我收费标准是按照 1% 来收,封顶是 300 元人民币。可这样无论如何收 100 元是不对的,然后让我去找值班经理。值班经理爱搭不理的给我打印了一份收费标准的文件看,上面是 2003 年的收费办法 ,写着异地取款的标准,而且告诉我这个情况就是属于异地取款,可是那个文件上写着收费是按照 1% 的,而且没有封顶。

你们收费是严格按照这个标准执行的? 对呀!说这个文档我可以拿走么? 该经理立刻变了脸色,不是都给你解释了么? 这是我们的内部文件,保密的,你不可以带走。只是个收费标准有什么好保密的? 那好,我拍几张照片总可以的吧? 用手机把关键的那一页拍了下来。

我回来上网查询了一下农行借记卡的收费标准,发现至少 2005 年与 2007 年各有一次费用调整。而我这个业务,我的理解应该属于”异地卡柜台转账支出”,而不是”异地卡柜台现金取款”(只有这个费用才对得上)。同事告诉我说,假设农行”定义”这个”转帐” 只限于卡与卡之间,你也没辙。

我第二次回到农行,要问个清楚。还是找到那个值班经理。对方见我有备而来,似乎也感觉有些难缠。我直接问她我的需求是不是应该属于”异地卡柜台转账支出”呢? 对方答”是”,我说那为什么柜台人员不给我选择这个业务类型,而选择费用更高的呢? 对方答不出,于是说现在现在可以给我重新办理。我说那是不是银行操作员开始的时候操作类型是选择错的?甚至是有意错的? 这时候给我办理转帐的业务员冲她喊了一句:”是对公的转帐”。然后这个值班经理立刻就改口了,说刚才给我办理的方式就是正确的,农行统一都是这么办的。要先把我的钱取出来,然后再汇款,所以有个”现金取款”的业务操作。”你确定? 刚才的谈话我录音了啊…” 旁边有个更刁的营业员插话,”录音非法,咱告他”,那值班经理想了想,”你还是和我们的主任说吧”。

主任也是个女的,相比之下态度还算不错,问了半天到底是怎么回事,最后告诉我农行借记卡的转帐就是卡与卡之间的转,如果是个人对公,就不是所谓的转帐,然后就给我解释什么银行内部是怎样的,各省之间又是怎么回事,什么总行上面的规定之类的,我算是”补习”了一下财务知识,可是这和我有什么关系?

我问如果办理一张本地卡先把钱转过来,然后把钱转到该对公账户上,费用也不超过 100 (办卡的费用加上转款的50块而已)? 这之间的成本差异跑那里去了呢? 而且,既然存在这样成本更低的途径为什么柜台人员收费的时候也不询问一下用户的意见,收费之前为什么不告诉客户? 客户直到最后才知道被扣了 100 元; 再者说来,收了 100 元,出示发票总是天经地义的吧? 请提供发票。

最后银行”让步”说,可以按照我说的方式办理,不过要先把这笔交易撤回,撤回方法呢,根据农行的业务规则,要收款方出示支票才可以…今天还有 15 分钟,如果你找收款方要支票,今天重新办理这笔业务来得及…说了一大通,可这不同样是不可能的任务么? 我要确定的是这个收费依据是根据什么来的,是不是正确的收费途径,又不是非要省这个几十块钱。简言之,我的这个需求就是”转帐”嘛! 那里有明文规定这不是”转帐” ? 给出标准即可。

从最开始的给客户出示陈旧的收费规则,不敢让人把收费标准拿走,到最后暗示类似的业务有更为优惠的操作方法,甚至答应用户可以重新业务操作……我个人严重怀疑农业银行的对类似业务的收费方式存在猫腻。服务不规范暂且不说,对于具体业务的定义绝对存在歧义,偷换概念,什么是店大欺客?

算算每个类似的操作多收 40 元,每天全省有多少类似的操作,加起来来要多收多少钱呢?

以前看到不少朋友发一些所谓的通过银行的”省钱”手段,好像沾了银行多大便宜似的。作为用户,有权利享受更低的费用政策,而银行这种给用户添加操作障碍、黑箱操作敛财的方式和吸费电话本质区别在哪里?

EOF

为 MySQL 选择更合适的硬件

MySQL 爱好者关注的 2008 MySQL Conference & Expo 落幕后,很多文档都能看到了。今天读了一下这篇 Scaling Out MySQL: Hardware Today and Tomorrow。感兴趣的朋友也不防下载下来研究一下。

用什么样的硬件做 MySQL ,真不是三言两语能说清楚的。不过该讲座中还是能总结出来几点关键点的。

CPU 选择

首先如有可能就选择 64 位CPU,这样才可以安装 64 位操作系统,有了 64 位操作系统才能利用好更大的内存。如果非要抬杠的话,不是 64 位芯片也可以安装 64 位操作系统,也就是 Intel 的 EM64T 的解决方案(这也是文档中没提及的) 。

我个人倒是比较喜欢 AMD 64 位 CPU 的,物美价廉,性能也不错。

注意: MySQL 在多核上的 Bug 问题。

内存,来者不拒

第二点是尽可能配置比较大的内存,当然,只配置内存如果 MySQL 参数配置有问题,还是摆设,如何设置各个引擎的 Cache 相关参数,够写一本书的了。

现在市场上内存是越来越便宜了。我个人的感觉内存降价的程度比 CPU 和硬盘都夸张很多。所以,考虑到人力越来越贵,内存越来越便宜,配置服务器的时候就别太吝啬了。

硬盘–唯快不破

国内用 MySQL ,绝大多数都是直接仍在本机磁盘上的。这个磁盘的选择要慎重一点点。尽量选择 15K 而不要 10K 慢速磁盘,大多数数据库的磁盘问题都在速度上,如果只在磁盘上多花费 30%的钱而能得到总体性能的 30%收益,那么还是值得的,而容量多数情况下不会出现问题,现在的硬盘容量就是一个大。

至于选择什么类型的磁盘,SCSI 与 SAS 都可选,SATA 倒是够便宜,特定的应用再考虑吧。

这三板斧看是简单活,但是实际的应用场景下可未必就能做出更优的选择。最简单的东西也有人不知道不是?

EOF

Sun 下的 MySQL 蒙上了阴影

热热闹闹的 The 2008 MySQL Conference & Expo 还没落幕,一个不那么和谐的小道消息传了出来并被最终确定:Sun 计划对 MySQL 进行”选择性开源”,某些企业级的新特性源代码将不再开放。

谁知道 Sun 葫芦里卖的什么药,看家宝 Java 都开源了,在 MySQL 上还保留什么呢? 能否成为更受人尊敬的公司,还要看气度。这点上,Sun 始终扭扭捏捏。

一心要做 Web 2.0 中的这个 Dot 的 Sun,看来又要做活雷锋了,不过这次似乎是要帮助一下竞争对手 PostgreSQL。

EOF

用 Oracle EM 管理 MySQL

一个很有意思的技术嫁接。Pythian 发布了一个 MySQL 插件,通过该插件,Oracle 10g 的 Enterprise Manager Grid Control 能够用来管理 MySQL 。

在 Oracle 10g 刚发布那会儿,EM 的地位在整个链条中倒是挺重要的,几年下来,似乎并没有占领多少市场。我个人觉得这个工具挺”重”的,倒是很少看到有 DBA 用这个工具。

尽管这个 MySQL 插件应用场景可能不多,但这还是第一次看到第三方给 Oracle EM 带来扩展能力。

比较关注即将召开的 The 2008 MySQL Conference & Expo,Sun 收购 MySQL 之后第一次大规模亮相,能带来什么? 新版本的特性基本了解了,还有呢?

Updated: InnoDB Plugin 1.0 for MySQL 5.1 也需要关注一下。

EOF