IT系统运维的稳定与安全

  稳定性与安全性是银行IT系统运维最需要保证的两个属性。笔者将以这两方面为切入点，总结银行IT系统的运维技术理念，以抛砖引玉。
一、系统的稳定性
  稳定性是指在生产系统运行过程中，尽量降低故障发生频率，使故障处在可控制、可处理的范围之内，使生产系统的正常运行状态得到最大限度的延续。
  目前，IT电算系统已得到普遍应用，且复杂度日益提升。无论是实际的生产运行经验，还是国内外先进的运维理论，都在告诉我们：想要在相对较长时间内完全避免故障发生几乎是不可能的，转而追求提升单位时间内的系统稳定运行比率。首先要求系统提高自身的容错性，对可能发生的问题有所预见，并提供相应的处理机制，保证一般性问题不会造成系统崩溃等严重错误。在运维工作中，我们所关注的是如何缩短从故障发生到被发现的反应时间；如何减少故障处理的响应时间。因此对系统进行良好的监控是必须的，选择一个优秀的监控软件则会起到事半功倍的效果。
1.常用的监控系统
  常用的监控模式采用称为“agent”的数据采集器，以一定的时间间隔定期在被监控的目标系统中采集必要的数据，并将数据上送到监控主机进行数据分析，得出被监控系统的健康度结论。其好处首先是可利用一个监控主机监控足够多的被监控系统，只要在每个系统内安放一个agent，就会源源不断地得到该系统的各种必要数据；其次只要agent所在的系统环境允许数据采集间隔足够小，监控主机的数据分析正确，一旦故障发生，几乎可同步获知；第三，可通过对监控主界面的定制，利用声、光、电等各种多媒体方式，使运维人员能够一目了然地确定系统是否存在故障。同时，该模式也存在一定的弊端。如agent对被监控系统可能造成系统资源稀缺，以及由于监控主机数据分析的失误而造成系统故障的漏报错报等。
  较为先进的监控软件还可以通过详细的系统拓扑结构，在发现故障点的同时指示出故障可能波及的其他系统或业务流程，请运维人员对故障的发生做出全盘考虑和处理。
  通过先进的技术手段，辅以认真负责的工作态度，相信系统故障的发生可以被系统维护人员及时发现。但故障处理时间的有效缩短则需要通过良好的故障处理机制来实现。
2.故障处理机制
  在国外先进银行的运维经验中，一线运维监控人员往往不需要对系统有丰富的经验和高超的技术水平。当他们接到故障报告或直接发现故障时，第一步是根据故障的表象从系统知识库中获取必要的信息。从知识库中可以基本定位到故障的发生原因，转交相应的二线维护工程师解决。二线维护工程师是对系统有着深入了解的资深人员。对于更为先进的处理机制，基本不需要或只需要极少的二线工程师，一线人员就可以从知识库中查询到大部分故障处理的完整流程，照做即可。
  目前国内银行的系统运维主要依靠一线运维人员的经验来判断系统故障，凭借二线资深人员或开发公司工程师的经验进行故障处理。因此一旦出现人事变动，新进人员很难立刻接手。经验的重新积累势必影响故障处理速度，同时会给运维工作带来巨大隐患。
  知识库机制的建立是一个良好的故障处理流程体制的基础。建立和维护一套完整的知识库体系，需要投入大量的人力物力，但它能够快速及时地处理生产系统运维中的各种问题，并保持运维团队处理故障能力的稳定性。
二、系统的安全性
  这里所说的安全性，指对各种系统访问风险的控制。
1.系统安全隐患分析
  由于银行的生产系统均建设在自己独立的内网环境中，与外网间有数道防火墙和各种网络安全控制做保护，直接从外界入侵相当困难。虽然应用系统，尤其是网络银行系统的不完善可能会给恶意访问遗留后门，但这均可通过更严格的编码限制予以关闭。
  为了日常维护需要，银行技术人员必须或多或少地拥有访问业务主机，甚至登录核心数据库的权限。且不提少数技术人员的犯罪案例，即使普通的误操作，都有可能使重要文件和数据发生篡改或丢失，导致业务系统混乱甚至瘫痪。
  对内部人员的访问限制通常的方式是依据口令的复杂度规范，分级别、分段保管，定期更改。口令是一切的基础，控制住口令，谁都无法随意登录系统。但实际情况往往不能达到这样的理想状况。比如系统间数据交换用到的口令通常不会轻易更改，一旦记下，即可凭其登录；或者互信关系的两台主机之间的相互登录等等。针对这种情况，笔者经与同事探讨，提出了“综合安全管理”模型。
2.综合安全管理模型的引入
  本模型的核心在于用户登录系统后不是进入命令行模式，而是全部操作菜单化。系统给予不同级别用户个性化的菜单界面，屏蔽用户操作权限之外的菜单显示，禁止用户跳出菜单之外进入命令行模式，从根本上杜绝用户越权操作的可能性，降低误操作和蓄意破坏的风险。
模型所引入数据库的基本形态是以应用系统为单位的分布式库表，目的是简化数据库复杂程度，避免因不同系统间用户和菜单的重复问题在数据库级别制造混乱。基于此结构，库表的记录可以以各原子操作菜单为标识。原子菜单在各应用系统内部不会重复。为方便处理，对各原子菜单引入单一的索引编号作为库表主键。数据库架构中将对各原子操作菜单引入“权值”的概念，作为每条记录的一个字段。
  在引入“原子菜单权值”概念前，首先需要对用户进行角色分级，把不同的用户归结到若干个用户角色级别中。角色级别的操作权限逐级递减，其中零级为超级用户级别。一级以下均为各级别的普通用户。
  原子菜单的权值表征各原子菜单可以被展现给哪些级别的用户，设定为拥有其操作权限的最低级用户级别。例如，某原子菜单权值为3，0～3级的用户进入系统后，这个菜单均会显示供用户选择；若其权值为0，则只能被超级用户使用。
  考虑到可能存在原子菜单不希望被多个级别用户同时应用或跨级别应用，设置特殊字符“-”表征，并在表中增添备用字段，在其中用较为复杂的表现手法记录这类原子菜单的具体权限情况。此记录方式的查询与判断代价均较高，仅限于应用在此类特殊原子菜单中，不宜推广为普遍方式。
另设置两个字段，用于子菜单结构。一个字段记录上级菜单索引编号（无上级菜单用“N”标识）；另一个字段作为是否有下级菜单的标志位（1代表有，0代表无）。库表结构见表。
实现此模型的主要工具如下：
  堆栈一个，利用二维数组及数组指针实现。一维部分由数组指针协助实现堆栈功能；二维部分存放各菜单结构的显示要素。数据缓冲池一个，同样利用二位数组实现，完全模拟关系型数据库的二维关联方式，用于存放从数据库中选取出的有用数据。
  上述只是模型的原始结构，要想真正将之可行化还需进行细致的编程工作。同时，被管理系统也要做相应调整，如屏蔽系统中断响应以避免用户跳出菜单结构等等。

  为避免用户直接进入命令行方式或直接进入数据库，代之以菜单方式的好处是屏蔽了用户进入系统后操作的随意性，尽量让每个用户只可以进行自己权限范围内的操作。该模型也许不能完全达到目的，仍留有各种漏洞，但它提供了一种访问控制的手段，供大家参考。