银行前置机“跪式服务”
01 PART
引子
银行前置机一直是个很烦的业务，技术含量不高但是特消耗精力，投入产出比又低导致从业者待遇极低。从业这15年里，印象中遇到过三次以上的银行前置机故障，每次都令人及其痛苦。讲两个大家常见的现实案例：
案例1：某公司内部银行前置机多（百八十台且都是五年以上的老破过保机器）且归属及责任不清（有银行提供的，有自己采购的；历史遗留的 摊子，没有明确哪些工作由那个团队负责），每次前置机故障财务同事紧急催内部运维（理由：我们XX时间要打款，如打不出去后果XX）。运维人员：“这事也不归我管啊，你们财务部自己管找我们干啥“。财务人员：”不找你们找谁，公司就一个运维部，我们又不懂技术。我不管，反正你给我修好“。然后财务老大和运维老大一合计，运维最后还的被迫协助和背锅连夜搞。
案例2：某公司卖给客户一套私有云平台，客户想把银行前置机放到云平台上。可悲的是云平台不支持usb直通导致虚拟机不识别银行usb-key。客户死缠烂打，销售中间和稀泥，公司架构和研发不支持或者反馈后续版本增加这个功能(后续遥遥无期，客户又觉得你公司不靠谱)；迫不得已运维强上背后通过命令行手工绑定临时解决。过几天插usb-key的物理机故障了，银行前置机虚拟机飘到其他宿主机上了，客户又是各种电话和case紧急骚扰，搞的你精疲力尽且客户体验也很糟糕。
今天还有一个同事，同事要把银行前置机放到虚拟机上并做usb直通。聊了半天，反馈：测试环境当前有没有物理机资源，先临时用虚拟机跑起来。最后和同事沟通的结果：技术上可以做，但是运维人员不背锅不担责。
回顾和反思了这些年遇到的前置机问题，总觉得需要做点什么，一劳永逸的解决银行前置机这个烦人的问题；由此引出了这篇技术文章。
02 PART
前期准备工作
A
前置机特点
1）操作系统：清一色windows
2）硬件配置：要求很低（CPU：4core 内存：8-16G 硬盘：100G）
B
相关部门需求分析
1）财务人员的需求：银行前置机7*24可用
2）运维人员的需求：业务及基础设施高可用+降低故障紧急度(故障后无业务催或者有非常大的缓冲时间)
3）公司的需求：降成本提效率
03 PART
解决思路
A
多赢
多赢其实就是相关部门利益的协调和满足。银行前置机涉及到公司、财务、运维多方的利益。充分协调和调度相关部门及领导的支持和配合才是项目成功的关键。
B
运维部门的担当
运维部门的担当其实就是尽最大可能提供优秀的技术方案选型，满足财务需求同时还要满足公司降本增效，另外还要降低自身压力和工作量。
C
财务部门的担当
财务部门的担当其实就是在项目预算上不能太抠，对运维部门给出的优秀的方案要给与支持和敢于支持。
D
客户教育及明确责任
技术部门需要和财务部门充分沟通并明确相关责任，而不是屈服或者跪式服务。告知财务部门当前现状及存在的问题及对应的解决思路和相关责任方，同时提供改进和优化的方案及相关收益。
04 PART
银行前置机相关方案
A
传统物理机方案
点评：成本支出高昂且效率低下，业务、运维、公司三方都无受益且体验极差；此方案为最传统方案。
B
虚拟化方案
点评：成本支出适中且效率高，最大受益公司成本降低；业务受益效率提升；运维不仅无受益还面临技术复杂和运维压力极大的困境；此方案几乎很难推广(运维抗雷背锅)。
C
虚拟化+usbanywhere方案
点评：成本支出最低且效率高，业务、运维、公司三方受益；应该是目前最好的方案。
usbanywhere推荐产品：http://www.remoteusb.com/此产品相对冷门，大部分人应该不清楚（备注：非广告）。
05 PART
额外知识补充（kvm直通usb挂载）
A
定位usb-key路径
usb-key插入前后图片对比
B
vm绑定usb-key配置文件
C
vm绑定usb-key命令及验证
备注：29为vm的id，通过virsh list --all获取
