IT系统管理的终极规章化
摘要：规章化（Regulation）一词按照字面理解，其定义为“权威方发布并维护的规章制度”;不过在工程领域和医疗领域，规章化可以基本等同于“风险控制”。
关键词：IT治理规章化
近日在Standalone Sysadmin博客上看到Matt Simmons的一篇文章，标题叫做“Eventual regulation of system administration?”（系统管理的终极规章化），针对系统管理/IT运维这一行业是否能够像工程领域和医疗领域那样建立统一规章标准一事进行了探讨。标题一眼看去，还以为是与系统管理员的培训体系相关的讨论；但仔细一看，发现Matt所说的“规章化”跟培训、执照什么的并没有多大关系，而且里面的很多观点也十分有意思，所以决定将相关的观点整理一下，与大家分享探讨。
规章化（Regulation）一词按照字面理解，其定义为“权威方发布并维护的规章制度”;不过在工程领域和医疗领域，规章化可以基本等同于“风险控制”.Matt在文中一上来就推荐了《Risk Society》这本书（中文名称叫《风险社会》），这本书在上世纪90年代中期对工程领域的运作规则造成了不小的影响。按照Matt的超级简版介绍，这本书的中心思想就是：“社会太复杂了，工程学的方式不可能将风险完全排除。”
目前看来，很多企业的IT架构已经发展成为非常复杂的系统，以至于它们面临着跟社会一样的风险问题。所谓风险无法规避，背后的根源在于造成失效（Failure）的因素并不单一：磁盘坏了，或者交换机故障了，或者系统漏洞被利用了，或者管理员不小心删除了什么重要的系统文件，或者网线的水晶头坏了，或者扫地的大妈将服务器的电源关了……甚至很多外界的因素（比如空调坏了）都会造成系统失效。
换句话说，你如果把一个IT架构放在那里不管，那么系统失效才是它的默认状态，而工作状态其实是一系列复杂因素“恰到好处”的组合在一起之后的小概率事件。与其问它为什么会失效，倒不如问它为什么没有失效。
系统管理员在其职业生涯中会遇到很多不同原因造成系统失效的情况，如何将这些因素传承下去，则是IT运维规章化的目的。
现在的问题在于，IT是一个过于年轻的领域（C语言之父Dennis Ritchie的去世在一定程度上宣告了这个领域已经脱离了幼年期），虽然我们在大型系统架构方面已经积累了不少经验，但是经验的传承仍是个问题。按照Matt的话来形容，“很多菜鸟系统管理员成长为资深人士的过程，就好象一个特别擅长搭电动合金积木的小孩子被雇佣建造一架人行天桥；如果这架人行天桥没有垮掉，这个小孩子将会负责建造一些跨州大桥。”
在医疗领域和建筑工程领域，由于人命关天，这种事情显然是不可接受的；那么对于IT领域而言，我们难道就不需要有一些统一的规章来减少系统管理员们因为已知的错误而再次造成系统失效的几率吗？
其实是有的。事实上，现在针对IT系统管理的规章倒不是没有，反而倒是太多了。
首先，IT业内人士对下面这两个法案应该都不陌生，这正是目前已经进入实践的一些在非IT领域的IT风险控制规章：
◆萨班斯法案（SOX）
萨班斯法案对公司治理、会计师行业监管和证券市场监管等方面提出了许多严格要求，并设定了问责机制和相应的惩罚措施。凡在美国上市的公司，都必须实践萨班斯法案的标准。萨班斯法案中的第302款、第404款、第409款和第802款条例都对IT操作有直接影响，其中尤其以法案404条款提到的“内控体系”为主。企业内控很大程度上就是IT内控，用于控制IT信息系统停顿、不可用和泄密等问题。
◆巴塞尔协议（Basel）
巴塞尔协议主要针对银行和金融机构，其核心内容就是银行的风险管理。银行IT风险主要分为三部分，即IT环境的风险（包括组织架构、物理环境、外包等方面），IT运行风险（包括IT资产脆弱性、误操作、欺诈、信息泄露、系统中断等方面），以及基于IT的金融产品和服务的风险。
在医疗、航空航天等领域，目前也有一些针对IT人员的强制性规范。
另一方面，在IT行业本身，也出现了不少建议的规范条例：
COBIT
COSO
ITIL
ISO/IEC 17799:2005
FIPS Pub 200
ISO/IEC TR13335
ISO/IEC 15408 2005/Common Criteria/ITSEC
PRINCE2
PMBOK
TickIT
CMMI
TOGAF 8.1
IT Baseline Protection Manual
NIST 800-14
对于企业而言，这样就有两个很重要的问题：
规章是否已落地或正在落地？--执行规章是有成本的，如非强制执行，企业未必能找到充足的理由说服自己执行以上规章。
不同规章各有特点和优缺点，如何选择合适的规章，并与自己企业的审计工作融合？--尤其是可选择的规章多达十数个的时候。
责编：fangli188