上周突发怪例,    情况如下：
Linux版本：AS4 update2
postgresql版本：8.1.0
rpm包安装后，postgresql的Service无论如何都启动不来。第一次失败，查看Log，空；第二次重试，报错：无法创建目录‘/var/lib/pgsql/data/pg_log’: 文件已存在。删除该文件夹，启动，失败。

在另一台机器上重试，重新安装操作系统（系统相同），安装时将系统自带的Postgres7.4安装。服务可以启动，配置文件时很郁闷，8比7果然是一个较大的飞跃。于是卸载掉7,安装8,启动服务成功。

对比第三台机器，操作系统centos，kernel为2.6，和AS4相同。未安装系统自带的Postgres7,直接安装Postgres8，直接安装无异常。


问题的根源与解决办法：SELinux（Security Enhanced Linux）是4的新安全机制，是在内核之上增加了一层访问控制。
SELinux：Security-Enhanced Linux。由NSA搞的（不是NASA）,是national security agency搞的咚咚。
http://www.nsa.gov/selinux/
SELinux极大的增强了Linxu的安全性。在SELinux下，即使root要不是为所欲为。这样万一WebServer被攻陷了，攻击者的收获也可能仅限与此，无法对其他系统进行破坏。
当然也狠狠的郁闷了我这个菜鸟一把。

回想起来，其实安装时，都问过是否启用SELinux的选项。（大概是在防火墙设置）centos3,AS4，ES4都提示了，只不过一直没在意。

简单的解决办法：
将/etc/selinux/config中的SELINUX=enforcing 改成SELINUX=Disabled，将SELinux停止。
还找到了一个配置文件/etc/sysconfig/selinux，不过该文件只是指向了上面文件，改哪个都一样。

当然这种办法一棍子打死了NSA的辛苦心血，失去了B1级别的安全性。喝杯凉水，还是可以慢慢配置的。
上次由于时间紧张，急了就把SELinux全部停掉了，罪过罪过。
配置：/etc/selinux/targeted/booleans，就可以发现我们需要的配置都在这里，以0和1表示布尔值。
如果觉得麻烦，在“系统设置”“安全级别”中同样也可以配置SELinux。

最后，教训是，以后如果一些服务出了古怪的问题，那么不妨执行sestatus，看看是否被SELinux给屏蔽掉了。

几几歪歪写了一堆，没有好好干活，罪过罪过。

  
 

中国人与欧美人的思维习惯存在较大的差异。当一件事情做砸了后，中国人一般倾向于去反思个人犯了什么错误，并往往得出结论，如果换另外一个水平高一点的人，应该就不会搞砸了；而换作是欧美人的话，则会去反思做事情的方法存在什么问题和不足，他们的结论正好相反，如果做事情的步骤不对，换其他水平再高的人，同样很有可能搞砸。欧美人总是希望找到一种方法，能够让普通智力的人就可以将事情做好。
分析上述这个在国内很常见的典型案例，我们可以发现，案例中的项目经理首先想到的是依靠能人或高手来成功完成这个项目，这应当出自于其以往的项目经验，这种心理本身并没有错；然而，项目经理显然缺乏足够的工程素养，他没有认真地去分析项目的性质、并思考项目到底该如何去做，而这家软件企业也没有建立相应的机制，将以往成功项目的经验传递给项目经理；于是这个项目完全是凭借项目组成员自发的想象来推进。
项目经理的开发思路是：大家从学校所学到的软件工程知识，能够记得的好像就是需求、设计、测试什么的，而设计从来就没做过，大部分人最拿手的还是编码；而项目的工作量摆在那儿，肯定要靠大伙儿共同来分担，这样就必须划分任务；架构设计虽然做不了，需求中的功能模块还是能分出来的，于是按模块分配任务就是自然而然的事儿了。纯粹依据功能模块来划分开发任务，在业界早已被证明是种不好的开发模式，经过这么多年的努力，业界已诞生了更为合理与有效的开发过程。另外，案例中后期出现的需求变更直接导致了项目的失败，这完全是可以避免的；当代企业应用的软件开发过程规定，在做需求之前还有业务建模的环节，如果开发组与客户先认真地就业务达成一直认识的话，遗漏一些对业务非常重要的功能是不大可能发生的。不幸的是，项目组没有采用这些正确的软件过程与方法，或者他们压根就不知道应当这样去做项目。
总而言之，这个案例中的项目执行与书中所列的软件项目执行步骤是背道而驰的。

    应用系统经常受到中文问题的困挠，J2EE环境下的中文问题更是常见。目前缺乏对此问题的全景分析，更有一些不合理的解决方案流传在网络。本文目的在于： 


    分析中文问题的存在根源，解析完整的中文处理过程。 

    中文问题涉及面很广，因为篇幅的所限，这里不会罗列各种现象的处理办法，而是就问题产生的原因进行探讨。 

  

   1. 中文乱码问题的根源
 

    在J2EE系统的开发过程中，稀奇古怪的中文问题很多，一些运行好好的系统，修改了一个文件，或者迁移了一个平台，换了一个服务器，就变得面目全非了。为什么只有中文问题？没有英文问题？要解决中文问题，就应该从解答这个问题开始。 


    1． 中文有多种编码。一个中文字符，在不同的环境下，有不同的二进制值 

    2． 某些应用系统，会把字符串转换成其他的字符串进行传递或保存 

    3． 在一个完整的软件中，各种编码形式存在很多的转换 

    4． 每个转换过程都需要一些参数，比如“数据到底是Unicode还是GB2312的” 

    5． 程序员往往会忘记设置这些参数，或者错误设置 

    6． 不同的应用服务器或者api，其提供的设置方式经常不一样，甚至本身就是错误 

    7． 另外，中文问题的泛滥还得益于一种有趣的现象：当程序中有两处出现编码错误的时候，错误可以相互抵消，产生看上去似乎正确的结果，从而成为随时可能爆发的定时**
，同时也使得程序员对错误做法产生错误的信心。 

    8．最后，由于J2EE平台的开放性，各种工具和服务器来源广泛，而这些提供者对中文的处理办法往往不尽相同，有些厂家自己都不知道中文怎么回事（他们不是中国人）。JDK和Servlet本身也不得不因为双字节字符问题而修改。这给J2EE环境下的中文问题处理又增加了难度。 


    2. 字符编码
 

    这个字符串变量的值是什么？ABC，还是“中文”？实际上，计算机里面无法保存“中文”这个方块字，同样也无法保存ABC这样的字符，只能保存二进制的数据。  

    因此计算机必须有办法用一个二进制的编码来代表字符，由此产生了ISO8859-1编码（和ASCII码相似），用一个二进制字节来代表英文字母及其他常见的字符。  

    2.1. 中文的编码
 

    遗憾的是，早期的计算机设计者并没有考虑到计算机将应用到全世界的各个领域，正如他们设计的日期只能到1999年为止一样。当计算机在我国应用的时候，问题就出现了。ISO8859-1并不包括中文，而且成千上万的汉字显然无法用一个字节来表示。 

    其解决办法是双字节的GB2312码。因为要跟ISO8859-1码兼容，所以GB码一般以一种变长的EUC模式处理，即字符a的编码仍然和ISO8859-1一致，而汉字的编码，则用两个字节来表示。 


    很麻烦吗？如果只有这么麻烦的话，恐怕就不会有那么多中文问题了。 

首先，由于GB2312收录的字符有限，甚至连总理的名字都无法表示，因此又出现了GBK和GB18030编码（需要注意的是GBK并非国家标准）另外一些繁体字地区使用的BIG5编码，尽管原理类似，但是编码却不同，使得沟通非常困难。世界上其他地方，也有自己的双字节编码，字符编码成了“万马奔腾”的结局。如果大家各自用各自的，也就罢了，但是显然计算机专家不能容忍这种局面，于是，新的囊括几乎所以字符的双字节编码Unicode诞生了（其收录的字符仍然在增加中）。 


    Unicode？那UTF-8又是什么东东呢？因为Unicode的编码，和ISO8859-1并不兼容，a的ISO8859-1编码为0x41，而 Unicode为 0x00 0x41。这样一来，那些长久以来积累的英文txt文件岂不是无法使用？而UTF-8是一种变长的编码，字母的编码和ISO8859-1完全一样，中文的编码，则用三个字节表示。 


    通常在文本文件中使用的都是UTF-8编码，而jdk内部的String对象，才是Unicode编码。Java从设计之初，就明确了其所有的String对象，必然是Unicode编码。而字符串写到文件之中，或者供网络传输使用的时候，总之不是JVM的String对象的时候，则可能是UTF-8或者GB2312编码。 


    所以汉字编码，有Unicode，GB2312和BIG5等形式。一个中文字符，在不同的软件不同的环境下，有不同的二进制值。虽然java String对象总是Unicode，但是J2EE是一个需要和很多应用系统打交道的环境，比如说，用户提交的数据，并不是java的String，而是浏览器提交的几个字节，配置文件的内容，是文件系统中的几个字节。 


    然而即使如此，故事仍远未结束。 

    2.2. 另一个故事：把任意数据编码成其他ISO8859-1字符串
 

   

    如果某协议只能使用可打印的ISO8859-1字符串（编码为0-127的字符，即字母，数字等），而现在需要处理图片数据，或中文数据，那怎么办？比如原本的邮件传输协议，就是如此。 


    这就出现了BASE64编码，简单的说，它总是把3个字节的数据，转换成4个字节来表示，而这每个字节，都是一个“可打印”的ISO8859-1字符。 BASE64只使用64个字符，即字母，数字和加号，斜杠。根据使用的字符数量的不同，还有BASE85等编码。类似的情况，在别的应用领域还有其他编码。 


    这些协议中最常见的，正是我们最“喜欢”的http。因为原本的http协议只能传递ISO8859-1字符串，所有的中文，不管是何种编码，都无法传递，其他任何双字节编码也一样。 


    因此，http的url参数使用如下的形式： 

    www.site.com/index.jsp?name=a&age=1&q=ÖÐÎÄ
 

ÖÐÎÄ “中”的GB2312码为十六进制的D6 D0，但是这两个字节根本无法放到http的协议中去，因此计算机用一个字符串来保存这些数据。把这两个字节用6个字符来表示：ÖÐ。接受方首先根据这个字符串还原字节数组D6 D0，加上知道使用的是GB2312码，就可以知道这6个字符代表的意思。 


    又如，xml是纯粹的字符串文档，有很多符号都被语法本身所保留，如& 

因此在xml文本中，一些字符需要用特殊的方式来表示，如&用&来代替。而更统一的方法，是用以下的形式 

中文 表示“中文” 

中文 同样表示“中文”，注意20013=x4e2d 


    又如，JDK的native2ascii的运行结果（在java的properties文件中使用） 

\u4e2d\u6587 表示“中文” 


    让事情更糟的是，这些编码方式和前面的汉字编码并非相加的关系，而是相乘的关系，也就是说，可以用来编码GB2312的字符串，同样也可以用来编码Unicode的字符串。 

    前面所列出的一些例子，分别是（文字都是“中文”）： 

    q=ÖÐÎÄ  

   “中文”的GB2312码  

    中文 

   “中文”的Unicode码 0x4e 0x2d 0x65 0x87 

    显然并没有谁规定这些方式只能编码Unicode或者UTF-8的数据，当然还可以是GB2312或者BIG5或者其他什么东西  

    2.3. 简单应用系统中的中文编码
 

    也许读者会问，这些跟我的中文问题有什么关系？我从来没有让我的程序使用过UTF-8或者那些古怪的字符串编码。 

遗憾的是，每个程序员确实需要关心这些东西。不管你愿意不愿意，一个简单的java应用，已经在你并没有注意地情况下，使用了以上的很多编码。而这些编码过程在程序的处理过程中，就必须要经过很多次的转换，任何一个转换的错误，都可能是中文问题的根源！ 

     一个玩具性质的JSP应用，就已经使用了GB2312，Unicode，UTF-8，还有这些字符串所转换出来的各种形式。一个普通的J2EE应用，涉及的编码更是繁多。 


    让我们来看一下在一个最简单的JSP页面中，“中文”两个字的各种表现形式。必须要说明一点的是，只有在应用程序完全按照tomcat的推荐方法设置的时候，以下的字符才会是这种形式，任何一个参数的不同，都将造成结果的不同。 
    3. 字符转换过程
 

    我们已经看到，在一个过于简单的系统中，已经有3种以上的中文编码，繁多的字符串编码模式，组合出各种奇怪的数据。 


    而所有这些在程序中运转的时候，都会涉及很多转换的过程。 

    举简单的例子（以下的编码只是举例，并不是说在这个环节不能使用其他的编码）： 

    1. 用户的输入是GB2312，java需要读取成Unicode的字符串 

    2. 如果在java代码中写了中文，java编译的类文件会用UTF-8来保存 

    3. 配置文件使用了java的编码模式（\ u4e2d） 

    4. 数据序列化XML的形式时，会把字符串转换成XML的字符编码（中）  

    读取的时候当然是相反的过程。  

    3.1. 一个真实的转换过程
 

    经常听到某人说“我这个String是GB2312的”，实际上，String对象永远是Unicode。JVM要处理这些数据，首先从外部的IO流读取字节数据，然后将其还原为String对象。 


    举例来说，用户用http表单提交的数据中的“中”字，会用六个ISO8859-1字符表示：%D6%D0。注意这里的D6是两个字符，而不是十六进制的数字！他们的作用正是要代表D6 和 D0两个十六进制的数字。 

当应用程序用request.getParameter来读取数据的时候，Tomcat处理字符转换大致是这样的原理（实际的处理过程当然决非这么简单，因为tomcat要考虑性能可靠性等因素）
import java.io.UnsupportedEncodingException; 

public class ConvertHttp2String 
 {   
        public static void main(String[] args) throws UnsupportedEncodingException   
        {   
               byte[] input = { 0x25, 0x44, 0x36, 0x25, 0x44, 0x30 };  
               System.out.println("http协议提交的数据为：" + new String(input, "ISO-8859-1"));   
               // 1 转换为16进制数,应该有两个16进制数 
               byte[] code = new byte[2];  
               for (int i = 0; i <= 1; i++)   
               {             
                      String temp = new String(input, i * 3, 3, "ISO-8859-1"); 
                      // 去掉百分号  
                      temp = temp.substring(1, 3); 
                      // 计算字符代表的16进制数   
                      code[i] = (byte) Integer.parseInt(temp, 16);  
                }   
                // 2 创建字符串,第一个参数为数据,第二个参数为编码类型  
                String result = new String(code, "GB2312");  
                System.out.println("代表字符串:" + result);     
         } 
} 

 
    输出结果： 

    http协议提交的数据为：%D6%D0 

    代表字符串:中 

我们讲解决问题的时候应该多问几个为什么，这就可以看做是问题分析的过程，问题定义的目的是搞清楚问题是什么以及我们的期望和现实的差距。而问题分析的重点则在于搞清楚问题是如何产生的，为什么会存在该问题，问题的根源是什么？我们平时往往忽视了问题的分析，则我们解决问题针对的是问题的定义和问题的表象，那么解决方法都是一种应急方法，是治标不治本的方法。而当我们针对问题的根源制定的解决方法，则是一种避免问题重复产生的长远治本的方法，是我们持续改进的必要方法。

跳过分析阶段解决问题没有治本，我们往往采用了一种规避的方法来临时的解决了问题，而没有去探寻问题的根源。比如一条路不好走了我们会换一条路，一种方法不好用了我们会换一种方法，但我们却很少去思考为什么路不好走和方法不好用了？是什么原因导致了我们现在的问题，在问题的背后究竟隐藏着什么？对于这些我们往往很难回答，我们采用的规避问题本身的方法其实质是没有解决问题，因此这种方式也就谈不上对我们分析和解决问题的技能有所提高。

问题分析有结构化分析方法和非结构化的分析方法，结构化分析方法强调的是进行全面的调查研究和分析，了解清楚问题产生的整个流程和问题的逐层分析，这样势必会需要大量的调查研究和分析时间。非结构化方法则强调的是根据我们以往的经验积累，先假设问题可能产生的原因和根源，再收集数据来论证自己的观点，当我们有大量的历史经验积累的时候，这种非结构化的方式往往更加有用和高效。

对于问题的分析，重点就是问题产生的流程分析，另外就是问题本身通过问题树或逻辑树的分解(5W1H分析法)。流程分析有利于我们找到问题的根源，问题分解有利于我们利于2/8原则关注问题的关键改进点。在整个过程中我们还可能借助头脑风暴和鱼骨图发散思维(因果分析法)，通过亲和图对问题进行归类分析(问题归类法)，通过帕累托图找寻我们应该关注的关键点(重点分析法)。这些都是常用的方法，对于问题分析阶段的方法和模式，麦肯锡公司除提出有解决问题七步法外，也提出了整个问题分析基础框架，如下:







整个问题分析框架偏企业战略咨询和流程咨询，但我们仍然可以借鉴这个分析框架和思路。整个问题分析的流程都应该围绕问题是如何产生和是谁的问题而展开，展开的方式可以是通过问题本身的分解，也可以是通过活动和流程分析。这个搞清楚了问题的解决措施和我们的行动计划才是对症下药，才可能既治标也治本。

最好还必须强调的是问题的产生不是一个孤立的事件，而是处于一个动态的环境中产生的，因此系统思维和系统分析法是我们在问题分析中要必须注意的。我们经常出现的就是单纯的孤立片面的看待某一个问题或某一指标，而没有去关注各要素之间的相互影响和作用，这造成了旧问题解决后又导致了其他新问题的产生，或者说从整个大环境和大目标来看并没有得到最满意的解决方案。



分析问题是整个问题管理中最重要的环境，如果一个人仅仅是解决问题能力强，那只能够说能够很好的应对现在。如果分析能力也很强，那就能很好的做好自我持续改进以应对未来。