本周上海出差中，公司的研发同事临时请假，所以估计要呆到下周二回北京了。正好开题报告写的差不多了，整理一下近几个月来的工作笔记，虽然不是什么秘籍宝典，但是也算自己平时的一些积累，多记点东西，以后有时间可以在翻看一下，或许还会碰到之前正好遇见的问题。
 
  
       就按照时间顺序倒着往前写吧，内容比较杂乱。
 
  
 
 
  
      1.问题：在上海贝尔的测试现场支持公司AS彩铃业务流程测试，任务是加载新版本，但是现场一直加载失败
 
  
                    替换了关键字还是有问题，原本很简单的update操作一直搞到下午3点。
 
  
         思路：因为考虑到时测试环境，并且自信对etc目录下的service.bin还是比较了解的，所以在备份原先的bin                    文件之后，没有update，为了简便直接删除了原来的业务加载新版本，然后出现问题导致一度怀疑                      自己对SCF是否了解，所以一直关注 SCF不识别可能是因为配置文件的错误，或者是本身进程环境                      等，根本没有往文件损坏的方向去想。
 
  
         原因：由于在FTP上传业务bin文件到服务器的时候，没有设置binary传输模式，导致文件损坏所以一直无                      法加载。
 
  
         解决方法：1.在FTP传输是设置ftp>bin   
 
  
                           2.现场编译源文件代码，直接生成对应的bin文件在服务器上
 
  
                            最后使用方案2解决。
 
  
         知识点：FTP的传输分为两种模式
 
  
            1.FTP在传送文件时分为ASCII和BIN两种，一般文本文件例如html使用ASCII，其他的通通使用                   BIN（例如图像文件，压缩文件，可执行文件等）；
 
  
                      2.ASCII文件可以使用BIN模式传输，但是反过来BIN文件不能使用ASCII模式，因为文件会遭到破                           坏。
 
  
 3.当不确定使用什么模式的时候，最好使用BIN模式，因为BIN模式没有检查文件和转换行结束符的  操作，不会破坏文件 的内容。
 
  
         经验感想：其实这个问题在西藏测试的时候遇到过，只不过当时是处理Apache文件的拷贝时，没有先及时停掉Web服务，直接对文件夹进行tar包,导致解压到服务器上之后，重新启动时好多配置文件不全服务异常。而设置BIN模式FTP上传只是在其中的一个小步骤，所以印象不是很深。这次又碰到了也是好久才想起来对于问题的定位思维要发散，可能的原因有很多个，如果开始的想法不能解决，要尝试从其他方面去想，可能会有意想不到的收获。
 
  
 
 
  
     2.问题：西藏彩铃平台北向接口上KPI指标采集不全，出现问题已经连续两周。
 
  
        思路：最常见的可能就是文件不存在，但是现场回复说文件是存在的（这里有问题），因为是之前比我大6届的一位学姐使用新语法写的代码，流程很简单就是分支处理，代码量也只有300多行，非常精简也符合业务发布版本的要求；但是对Debug来说缺少必要的信息，于是我在代码中加入了一些print消息（向第一代Unix程序员致敬，在如今各种IDE横行的年代我还是用最原始的调试方法），发到现场后加载测试；原本是自动执行，因为已经处理问题很久，所以工程同事就直接手动加载了，结果神奇的事情发生了，手动执行结果正常（这里也有问题）。
 
  
        原因：1.采集指标的业务在B机器上，程序执行需要获取的文件名是Path+Time格式构造，其中Time是机器                      A封装在消息里面发给B，B解析之后加上Path，然后对其查找。
 
  
                  2.关键在于机器A和B的时间不同步，A比B快了将近30分钟，也就是说在B寻找对应的文件时，B机器                      上还没有符合A当前时间点的文件出现，所以报错返回错误码。
 
  
                  3.刚好这个相差的时间过去之后，B机器上有了对应的文件，这时候如果程序执行，一部分指标是存                        在的，所以问题表现为指标不全而不是全部缺失
 
  
        解决方法：1.同步机器时间，但是可能会影响机器上加载的其他业务。
 
  
                          2.代码流程没有问题，在代码中修改时间为B的时间一次获得可以找得到的文件名
 
  
                        （ 方案2是饮鸩止渴，因为机器之间时间不同步，暂时的修改只能适应一段时间，以后二者的时                              间差异肯定还会逐步扩大，所以解决不了根本问题。）
 
  
        经验感想：1.对比Trace分析的时候要仔细，不能只关注文件名，目录名。因为文件不存在可能是物理上不存在，也可能是文件名不符合规范，还有可能是系统的时间点上没有文件生成，所以思维还是要开阔。想法多一种就意味着增加一种解决问题的可能。
 
  
                         2.服务器需要定期做时间同步，对于一些涉及到计费，话单生成等类似的业务，时间很重要。目前随意登录公司的两台服务器二者已经相差一个小时，汗。。。
 
  
                         3.有问题要及时沟通，不要拖延，要主动，很多事情没有想象的那么复杂。
 
   3.问题：Shell脚本执行报错，一个简单的文本处理的脚本，各种执行不通过，代码如下： 
 
  
 
  
  1. #! /bin/sh   
  2. #--common condiction.   
  3. awk 'BEGIN{FS="|"}$1 == "'$2'" {print $2}' $1  
 
  

 
  
 调用：在新语法中实现调用的语句：esultStr=systemcall(sprintf('System %s %s monthcruser',scriptName,fileName_user)); 报错/bin/bash^M: bad interpreter: No such file or directory
                    
 
  
 思路：从提示信息上看是shell不识别，一开始以为是awk不能区分开本身的$1和shell里面的$1,因为处理语句中               前面的$1是文本的第一列，而最后的$1是文件名，但是后来经过单独执行发现awk是可以区分开的
 
  
 
 
  
 原因：1.表面上看是^M它本身不是shift+6和字母M，而是一个字符，它的ASCII码是0X0D，生成它是先Ctrl+V,然             后在回车，这样导致shell无法识别， 因为shell是解释性语言，它认为这是一个错误的解释器。
 
  
           2.这一种报错的原因一般有两种，一是在Windows下面用文本编辑器修改过，但是保存时没有注意编码格            式； 还有一种是在VI中修改过，在第一行的末尾按到了ctrl + V然后回车，表面上看的话是看不出来的
 
  
           3.实际的原因是2中的两种都占了，我真是太佩服我自己了。
 
  
 
 
  
           解决方法：1.用VI打开文件，在命令模式下输入:set ff?  确认文件是否是dos格式，如果是则执行:set ff =                                unix（这里的ff应该是file format的意思，set就不用说了吧）
 
  
                             2.执行dos2unix命令转换编码         dos2unix   XXX.sh
 
  
                             3.使用sed命令      sed  's/^M//'  filename > tmp_filename
 
  
                                                          mv tmp_file  filename (其实就是把这个M去掉)
 
  
           经验感想：以后保存文件的时候以及执行程序出错的时候，可以关注一下代码的编码格式