Unix操作系统自1969年在AT&T的Bell试验室诞生以来，迄今已经有30多年的历史了。因其性能稳定，功能强大，安全性好等特点，Unix系统得到了广泛的应用，特别是在高端解决方案方面，已经成为了主流操作系统。
国内进行Unix的研究和应用也已经有20多年的历史了。初期，Unix系统多应用于银行、电信、邮政、保险、铁道等部门；近期，由于国内计算机技术的普及，行业信息化的进展，以及互联网的飞速发展，Unix系统在多个领域得到广泛应用，成为处理核心业务的支撑软件。可见，了解和掌握一些有关Unix系统的知识对于IT人员而言，很有必要了。
参加工作以后，笔者有幸参加了多个银行综合业务系统的建设。在与客户的交流过程中，大家均感觉到：对于使用Unix作为平台的业务系统，要使其充分可靠地发挥作用，除了开发人员做好系统设计和开发外，更重要地是维护人员要做好系统管理。而由于Unix系统本身博大精深，相关的技术又很多，要精通Unix系统绝非轻易可以做到（尽管有很多所谓"从入门到精通"的书籍）。所以，本着循序渐进的原则，维护人员在初期掌握一些基本的与业务密切相关的系统管理知识非常重要。鉴于此，笔者总结了一些关于银行行业Unix系统管理（后面所讲的Unix系统管理均指银行行业的Unix系统管理）的经验。
笔者认为Unix系统管理总的原则是：了解原理、严守规范、勤于检测、有备无患。所谓"了解原理"是指必须了解Unix系统的基本原理，对于Unix的进程管理模型，文件管理策略，内核结构，安全机制，Shell编程等必须要有理论上的认识。"严守规范"是指必须熟悉所管理的Unix系统的各种操作规范。这里需要注意的是，由于历史的原因，Unix在版本统一方面发展得并不好，不同厂商的Unix系统在操作和管理上有时候有很大的不同。因此，如果管理员没有通过相应Unix厂商的系统管理员专家认证，不应该被允许上岗。"勤于检测"是指管理员应该经常性地检查系统的文件系统使用情况、日志使用情况、业务系统进程运行情况、系统内存运行情况，以保证业务系统正常稳定运作。"有备无患"是指做好系统紧急引导盘，做好各种系统备份等。
下面，笔者从5个方面对此进行详细讨论：
一、启动/终止系统
启动/终止系统也许可以说是最简单的事情。但是，对于很多系统管理新手而言，这却是最不可以掉以轻心的事情。先谈启动系统吧，我觉得应注意以下几个方面：
检查机房环境。现在银行业务系统中使用的往往是Unix小型机（例如IBM RS6000系列、HP 9000系列等）。为了保证机器的稳定性和性能，这些机器对于机房的温度、湿度都是有要求的。因此在决定开机之前必须看一下机房的温度表和湿度表。
检查UPS系统。非正常掉电对Unix服务器的损害是非常大的。为避免这种情况，现在系统中基本都配置了UPS系统。在启动机器之前对UPS系统进行一次常规检查是很有必要的。
严守加电规则。现在的系统通常配备有双机双柜热备份系统，具有多台服务器，多个磁盘阵列柜。有的还具有独立磁带机、光盘塔等设备。这些设备的加电启动过程是有顺序的，要求管理员必须按照操作手册的规定来操作。否则，很有可能造成对系统的损坏。
二、执行安全策略
安全策略一般包含以下部分：网络安全、服务器安全、操作系统安全、数据库安全以及应用系统安全。网络安全和服务器安全还分为硬件安全和软件安全两个方面。由于银行数据的敏感性，其业务系统的安全自然是非常重要的。保障系统安全可以说是系统管理员丝毫马虎不得的任务。不过，对于管理员而言，银行业务系统安全策略的设计和实现并不是最重要的（这通常由系统集成商和系统验收鉴定单位负责）。管理员最重要的应该是严格实施业务系统的安全策略，维护好系统安全。笔者认为这可以从以下几个方面进行考虑：
遵守"最小权力"原则。权力最小原则是安全保密的一条基本常识，可以避免因某个人（特别是管理员）权力太大而带来的安全隐患。也就是说当需要进行操作和使用系统资源时，除必要的身份确认外，需要对用户的权限进行控制，做到用户只能获得或拥有完成基本职工作所需要的最小权力。当然，这样做会给管理员进行系统维护带来种种"不便"。不过，为了安全一点，麻烦一点又何妨呢？
遵守"开发者、使用者、维护者分离"原则。这可以说是系统安全管理的一条基本原则；严格遵守的话，对于减少内部人员作案可以起到较好的作用。不过需要指出的是，在实际工作中系统管理员在领导的"热切"目光中往往很无奈地要完成很多开发者和使用者的事情。要改变这个情况，有关领导不仅仅需要精通银行业务知识，还要牢牢树立"安全管理"意识。
做好机房管理工作。这主要是指做好网络设备、中心服务器、中心打印机、前台主机等设备的硬件安全管理工作。这就要求做好各种防雷、防火、防盗、防静电等工作。
做好网络安全监控。随着业务的发展，许多银行已经开通了电话银行和网上银行（利用国际互联网开展业务的系统）。因此，银行业务系统已经不仅仅运行在内部专用网上，而是运行在Intranet和Internet接合的具有复杂拓扑结构的计算机网络上。而由于这种计算机网络具有联结形式多样性、终端分布不均匀性和网络的开放性、互连性等特征，致使网络易受黑客、怪客、恶意软件和其他不轨的攻击。所以网上信息的安全和保密已经一个至关重要的问题。因应这种情况，系统集成商往往采用了多种技术来保障安全，例如网络设备端口安全控制，网络安全防火墙（软件/硬件），加密技术（DES、RSA等），数字证书等。对于系统管理员而言，一定要掌握好这些技术，利用开发商提供的各种武器对支撑业务系统运行的网络环境进行全面监控。
做好用户管理。用户管理体现的是开发商为系统设计的基于多级安全机制的访问控制策略。要执行好这个策略，系统管理员需要做好下面几件事情：在开发商的帮助下定义好系统角色和用户组，维护好新旧帐号，严格执行密码使用规范。
三、维护系统环境
银行业务系统结构复杂，为了保障业务稳定运行，系统管理员需要维护好系统的运行环境。具体来说，需要注意以下几个方面：
维护系统配置和服务设定。Unix系统在安装以后会自行进行很多系统配置（例如允许的最大进程数，最大可打开的文件数等）和服务设定（ftp服务、 telnet服务等）。管理员需要根据业务系统的要求维护好这些配置。通常，系统管理员需要根据服务器的硬件情况调整允许的最大进程数、最大可打开的文件数，需要关闭ftp、telnet等服务。
维护各种用户进程配置缺省环境。这里需要特别注意的是为了保证业务系统中所有的功能模块都能够正确作用，系统管理员在系统试运行阶段时就需要注意各种用户进程的配置方法（这里涉及的环境是说$HOME、$WORKDIR等环境）。因为尽管开发商都会提供《操作手册》和《技术手册》；但是，考虑到在大多数情况下，开发商在上系统时都存在对代码或多或少的修改。这些修改是很难及时反应到《手册》中的。当然，在进行系统切换时，管理员很有必要备份这些设置。
维护各种日志文件。Unix操作系统、数据库系统、网络监控系统（防火墙）、业务系统等软件都会产生一些日志文件。这些日志文件记录了当前系统的运行状态。管理员需要分析并维护这些文件，定期对其进行备份和清除。
维护中央打印机。为保证客户和内部职能部门及时得到相关报表，银行在中心机房都配备了高速打印设备。这些打印设备往往负责关键打印业务（例如银行对帐单、银行内部业务状况表等）。管理员需要做好这些打印设备的日常维护工作，保证其在需要使用时能够正常工作。
进行作业调度。以前，银行业务系统基本是实时系统。现在为了提高服务器利用效率，有的开发商在系统中引入了作业系统的思路。对于一些耗时长，业务实时性要求不高的工作，采用了后台异步执行的方式。管理员需要对这些作业进行正确调度。
维护软/硬件变更。业务系统基本都面临软/硬件升级的问题。这涉及到各种兼容性测试、系统切换、系统培训等一系列问题。由于影响大，涉及面广，需要考虑的细节问题非常多，限于篇幅关系，这里就不进行具体讨论了。
四、监视系统性能
监控系统性能，提高系统资源利用率，降低交易峰值是管理员日常工作中的重要任务。这可以从以下几个方面来考虑：
监测CPU和内存的利用率。众所周知，CPU的速度和内存的大小对系统的影响是非常大的。管理员需要经常性的查看系统CPU和内存的使用情况，并做记录。管理员还需要根据业务的发展情况及早提出CPU和内存的升级报告。
检测进程运行。管理员需要周期性的对峰值情况下和非峰值情况下的各种进程运行情况进行监测、分析，发现对资源消耗大的进程。并且把观测报告发送给系统集成商，以便其及早做出解决方案。
监测磁盘使用情况。这主要是指监测数据库的容量变化和日志文件的大小变化。
五、备份/恢复
备份可以说是管理员在各种"灾难"面前的最后一道防线，其重要性可谓不言而喻。下面将介绍灾难备份的一些原则和灾难恢复的一般步骤。
灾难备份的基本原则如下：
安全性原则。
为保证备份的安全，从风险分散的原则考虑应建立多套备份（至少有两套）、多种介质，并且异地存放，另外，对备份的保密性、介质的存放条件都要加强管理。
冗余性原则。冗余是备份恢复机制实现的基本原则。为保证系统的安全性，从硬件配置、软件设计、数据存储等各方面都采用冗余换取安全。
可行性原则。包括技术可行性和经济可行性。首先要从技术的角度保证能正确地将数据备份到不同的介质上，而且要保证备份的数据能准确、完整地恢复，其次在制定备份计划时要结合本单位的实际情况和经济承受能力。灾难恢复可按照以下步骤：
检查热备份系统是否已经发生作用。如果发生作用，执行第（4）步。
检查中心机房热备份系统中备份服务器和备份磁盘阵列柜是否可用。如果可以使用，则立即启动备份磁盘阵列柜和备份服务器，利用中心机房备份系统处理银行业务。然后，执行第（4）步。如果不可以使用，而又没有异地冗余系统，则执行第（4）步；否则执行下一步。
启动异地远程系统。利用异地远程机房备份系统处理银行业务。
尝试启动发生灾难的服务器。如果能够成功启动则执行第（6）步。
置换发生故障的硬件/软件模块。重新执行第（4）步。
启动数据库系统。
本地磁盘阵列中数据是否可用。如果可用，则执行第（9）步，否则执行下一步。
在数据库中恢复最新的数据备份。
启动业务系统。如果没有备份系统发生作用，执行第（11）步；否则执行下一步。
进行系统切换。
分析事故原因，填写灾难报告，损失评估。
