InfoQ:由中行IBM大型机宕机谈银行系统运维

12月15日中行IBM大型机宕机，系统没有第一事件切换到热备或者异地容灾上，直接影响中行的信用卡支付相关业务，直到4小时之后才恢复服务。由于银行业务的特殊性，对于系统的可用性要求极高，就此事件，我们采访了兴业银行系统分析师周伟然、支付宝应用运维架构师陆惟凯（花名：近南），请他们谈一下对于银行系统运维的一些看法。

InfoQ：作为一名银行金融行业的IT技术专家，您认为本次中行IBM大型机宕机的体现出哪些问题和教训？

**陆惟凯：**主要的问题是灾备或大型故障的演练与决策，对于硬件或者机房故障的大型故障，需要有经过验证演练的切换方案来保证切换风险可控。对于故障决策来说是否启动灾备切换是个艰难的决定，不过确实也要能够下决策去切换。其实一切的根源还是在切换方案是否足够可靠、是否经过演练。只要切换风险可控，切换得决策其实不会太纠结。 **周伟然：**对于本次中行事件，具体原因不了解得情况下不好直接评论。但所谓相关金融系统的运维是一个复杂的系统功能，不能单纯的从main frame的稳定性一概而论。设备运行的稳定性也只是整体系统稳定性的很小部分。除了环境保障中包含的网络环境、硬件资源、存储设备、操作系统数据库等基础软件环境以外，应用运行、系统间互操作等事件都可能产生重大影响。而风险是无法完全避免的，这才显示的出灾难备份和应急预案的重要性，最大程度降低风险暴露后的影响是验证应急体系有效性的重要指标。

InfoQ：ITIL流程是否在您所在的组织中使用？对于类似事故，ITIL流程的处理应该是什么样子？

**陆惟凯：**使用，不过不是标准的ITIL流程。我们有一个应急响应的Team在处理相关决策以及应急事务。对于特别重大的问题会在应急响应TEAM内进行决策。 **周伟然：**我行使用ITIL。无论是ITIL还是各级监管机构，乃是内部风险机构，对于银行应急处理的流程均有严格的要求，基本上是系统分类，根据不同等级重要性提出不同的风险要求。对于重要系统，需要建设完备的灾备体系，建立完善的应急预案 并且需要确保灾备和应急预案的有效性。对此，监管和内部审计通过演练进行确认。 所谓的演练非模拟实际环境的演练，而是在实际的生产环境进行的模拟灾难，各机构对演练的频度和内容均有严格的要求，并且重大演练时，监管官员将进行现场检查 通过各银行每年发出的停业公告可以看到这些演练信息。

InfoQ：在你们的系统中，“桌面模拟演练”和“Call Tree演练”是如何进行的？

**陆惟凯：**模拟演练比较少吧。方案定了之后模拟其实都是没问题的，定期的review是需要的。演练相关主要是定期组织运维的容灾演练与应急演练以及网购节（双11大促）之前的演练。 **周伟然：**据我所知，在股份制银行或规模以上银行，重要系统演练多以实际生产系统的方式进行，模拟演练主要用于系统正式上线之前的验证，在实际生产运行时并不采用也不符合监管要求。所有实际生产系统，即实际生产后台、实际渠道系统，但限定范围，例如，在演练时，可能关闭网银入口，使用户无法直接登录，控制演练本身造成的二次风险。

InfoQ： 相对互联网行业来说，银行金融行业的IT运维人员的素质和技能具体有哪些不同？

**陆惟凯：**个人感觉是比较接近的。可能是我在支付宝工作的缘故，IT相关企业的运维人员根据企业的性质不同（门户，电商，游戏，SNS）等会有一些各自有特色的容灾以及流控方案。所以需要相关的运维人员更多的了解前端业务，能够根据不同的故障情况进行不同的处理。（例进行功能的删减控制，流量开关，流量切换等）。另外IT企业运维人员遇到的外部故障会更多一些比方外部攻击，或运营商，或应用异常出现的故障。。另外传统IT业的系统更新频率会比金融业快上很多。相关应用发布带来的一些故障处理也会对运维人员提出更高的需求。传统金融行业的容灾方案相对来说就比较单纯一些。在数据备份方面IT企业根据企业特性不同，数据备份的重要性也会不同。金融行业对可用率以及数据备份的要求会更高。 **周伟然**：由于不太了解互联网的运维素质所以不好比较。但对于金融行业运维，制度性准确性和规范性是很重要的。由于银行设计大量资金和重要隐私，在制度规范上有着较为严格的规定，例如业务、研发人员与生产系统严格分离、生产数据完全无法接触的到、需要检查分析时需要通过严格的审批流程。在研发软件下发生产也必须严格进行内容审查和审批，操作步骤必须清晰描写，而对于运维把控的是对于审批结果的执行，精确执行审批结果而不能自行改动丁点，而且执行过程被记录，可被审计 在风险发生时，则应依照预案进行各项操作。运维人员对于应急预案的制定的维护，需要基于大量运维经验，并且通过不断优化验证的。

InfoQ：能否介绍下：在您所在的组织中，关键业务系统的备份是怎么做的？

**陆惟凯：**同城容灾加异地灾备吧..同城容灾包括机房内单点容灾（备份）以及机房间的相互备份。 **周伟然：**备份方式对于重要系统均需多方面考虑，例如某关键系统，首先在运行时就使用应用集群的方式确保可用性，通讯接入采用端口和地址复用进行多重备份。运行体系基本需要确保无单点故障，即单一功能点在2个或以上并行运行的节点。其他设备采用热备或冷备方式。该数据库备份基于数据库引擎和高端引擎进行远程灾备同步的功能，为单数据源热备份，数据的保存备份对于非监管要求数据，根据内部管理规定制定备份保存时间，备份至专用数据平台、对于监管要求的数据，在一定时间内在线保存至数据平台，长时间后转磁带长期保存。

InfoQ：在网友评论中看到一句话：“最关键的是一般都是只有设备容灾，没有人员组织架构的容灾。”请问您觉得“人员组织架构的容灾”应该如何理解？

**陆惟凯：**人员组织架构的容灾分两部分来看，一部分是操作以及一线的处理人员的备份，这块要保证相关的运维的操作技能与权限到位，在第一联系人没有联系到的情况下可以联系第二联系人来进行处理。 第二是决策人员的备份对于决策的人员存在联系不上的情况下，可以联系备份决策人员来进行决策。 当然这里的人员组织架构容灾基本还没有考虑到一个异地或者其他的成分，如果遇到毁天灭地型的地震或者更极端的灾难的时候，可能会缺乏异地的人手来处理问题。。 **周伟然：**人员组织的架构在银行来说有着明确的规定。首先对于每个系统对应的负责人员需要报送管理，并且做到A、B角等多角定义，在系统故障和重大事件保障时均遵循流程对应具体人员。日常工作时，大家对ab角等也有一定的注意，例如某集体全体不宜同一趟飞机出行等来降低风险。

InfoQ：能否介绍一些国外银行金融企业对类似问题和事故的处理经验？

**陆惟凯：**没有相关的经验。 **周伟然：**处理经验其实之上各题中均有提到，即功夫在平时。好的应急预案和备份需要大量前期工作和定期优化维护，并且验证，每次处理之后通过仔细的分析、审计、故障报告等方式探讨不足，不断地优化和改进。

清理 zabbix 的历史数据

zabbix收集的信息非常多，导致运行一段时间后，做数据备份或者迁移的时候，非常的慢，数据库占用空间也很大，可以先做一部分清理工作，主要涉及到下面的表：

 use zabbix;
 truncate table history;
 optimize table history;
 truncate table history_str;
 optimize table history_str;
 truncate table history_uint;
 optimize table history_uint;
 truncate table trends;
 optimize table trends;
 truncate table trends_uint;
 optimize table trends_uint;
 truncate table events;
 optimize table events;

<!-- more -->当zabbix使用一段时间后，里面的数据库太大，想备份里面的数据库时，要浪费大量的时间，zabbix里面最大的表就是历史记录的表了，网上很多人都是写全部清空这些表的数据，其实我们可以按时间来删除里面的历史记录；（做之前建议停掉zabbix server,optimize table 这个命令不能缩减innodb文件的大小，不知是什么问题。)

里面最大的表是 “history” 和 “history_uint”两个表；

zabbix里面的时间是用的时间戳方式记录，我们可以转换一下，然后根据时间戳来删除；

比如要删除2012年的1月31号以前的数据

1、先将标准时间转换为时间戳

# date +%s -d "Jan 31, 2012 00:00:01"
1327939201

然后mysql执行

mysql> DELETE FROM `history_uint` WHERE `clock` < 1327939201;
mysql> optimize table history_uint;

清楚10天前的数据.

#!/bin/bash
#当前时间
t_now=`date +%s`
#10天前的时间
t_ago=`echo 10*24*60*60+$t_now|bc`

mysql -uroot -pxxxxx -e “
use zabbix;
DELETE FROM history WHERE ‘clock’ <$t_ago;
optimize table history;
DELETE FROM history_str WHERE ‘clock’ <$t_ago;
optimize table history_str;
DELETE FROM history_uint WHERE ‘clock’ <$t_ago;
optimize table history_uint;
DELETE FROM  trends WHERE ‘clock’ <$t_ago;
optimize table  trends;
DELETE FROM trends_uint WHERE ‘clock’ <$t_ago;
optimize table trends_uint;
DELETE FROM events WHERE ‘clock’ <$t_ago;
optimize table events;”

这个无风扇服务器很棒!

以色列电脑生产商CampuLab主要生产无风扇的小型桌面电脑。今日该公司向服务器产业发起了挑战，发布了一台uSVR服务器产品。这款产品设计搭载英特尔第三代Ivy Bridge平台的酷睿i7处理器，以及32GB的系统内存。这款产品性能强劲，坚固耐用，并且没有搭载风扇系统，仍能很好的散热工作。这款设备可以使用该公司自定的模组进行拓展。

这款设备可以选择2.5GHz或者1.7GHz的英特尔酷睿i7 CPU，均搭配Intel HD 4000集成显卡，或者可以选择英特尔赛扬1047UE作为处理器，主频则为1.4GHz，搭配英特尔HD 2500集成显卡。这款设备支持最高达32GB的双通道ECC DDR3内存（1600MHz），并且内部有足够的空间能够容纳多达4块2.5英寸500GB或者1TB的硬盘，并支持RAID 0，1，5，10或者JBOD配置。这款设备同样支持最高达480GB的mSATA启动储存，以及一个eSATA接口。这款设备的工作温度可从-20摄氏度到60摄氏度。这款设备可以使用英特尔的主动管理技术远程管理。<!-- more -->

这款设备还搭载有HDMI 1.4a接口，最高支持1920x1200 60Hz的视频输出，以及一个DisplayPort，最高支持2560x1600 60Hz的视频输出，并配有7.1声道的S/PDIF数字信号输入及输入、一个立体声输出以及麦克风输入。这款设备有两个USB 3.0接口以及两个USB 2.0接口，并且可以通过FACE模组增加两个额外的USB 2.0接口。还可以通过另外一个FACE模组选项添加最多达4个千兆级以太网端口，而这款设备默认搭载两个以太网端口。这款设备还搭载有一个六针串行端口以及两个miniPCIe端口。这款设备还可支持蓝牙3.0以及Wi-Fi 802.11b/g/n技术。

这款设备目前已经发售，批量订购起价为556美元。

国服《DOTA2》快来啦！

国内游戏公司完美世界早在2012年10月就与Valve游戏公司达成协议，拿下了后者旗下多人在线联机竞技游戏《DOTA2》的中国内地代理权。在经过漫长的等待之后，完美世界今天终于正式发布了国服《DOTA2》，并公布了具体的上线测试时间。

据此前报道显示，今年3月末，曾有完美内部员工透露称国服《DOTA2》将在今年4月份上线测试。今天，完美国际CEO萧泓在《DOTA2》中国首测暨完美世界与AMD战略合作发布仪式上证实了该消息的真实性，并正式公布《DOTA2》国服的首测时间已经选定在4月28日。

目前，完美国际和Valve双方都还未对国服《DOTA2》未来的运营方式作出具体解释。不过有传言显示，当国服《DOTA 2》正式上线之后，Steam平台或将封禁中国内地IP，以保证完美世界的完全运营权。如果这一传言为真，那么就意味着目前的国内《DOTA 2》玩家将面临失去个人游戏数据的窘境。

甲骨文修复42个Java安全漏洞

甲骨文发布了季度安全补丁更新，总共修复了128个安全漏洞，42个属于Java SE 安全漏洞，其中19个是高危漏洞，39个与Java Web Start插件相关。Java主要应用于服务器端，需要客户端运行Java applet的网站并不多见。甲骨文建议企业和机构尽可能快的应用安全更新。过去几个月，不断有互联网公司报告因为Java（主要是插件）0day漏洞而导致计算机被黑客入侵。安全专家担心，根据新发现Java漏洞的频率，Java在很长时间内将仍然会是一种容易受攻击的软件。