本週上海出差中，公司的研發同事臨時請假，所以估計要呆到下週二回北京了。正好開題報告寫的差不多了，整理一下近幾個月來的工作筆記，雖然不是什麼祕籍寶典，但是也算自己平時的一些積累，多記點東西，以後有時間可以在翻看一下，或許還會碰到之前正好遇見的問題。
就按照時間順序倒着往前寫吧，內容比較雜亂。
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腳本執行報錯，一個簡單的文本處理的腳本，各種執行不通過，代碼如下：
- #! /bin/sh
- #--common condiction.
- 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去掉)
經驗感想：以後保存文件的時候以及執行程序出錯的時候，可以關注一下代碼的編碼格式