前兩天處理了乙個筆者不怎麼常見的問題點，特別的在這裡記錄一下，以備之後不小心忘記後的註記。
技能名稱
技能熟練度
技能教程鏈結
模擬電路
了解暫無
當前除錯一塊單板，筆者除錯的模組主要為訊號採集電路。功能為採集輸入的訊號波形並進行引數的輸出。
測試人員在進行功能的驗證過程中，使用外部的輸入的交流訊號進入單板後出現了很大的引數誤差，超出了單板能夠接受的最大誤差，所以就有了下面的分析文章（下圖是波形的示意圖，真實波形與其相差不大）
首先筆者和測試人員溝通後發現測試的方式出現了一定問題，但是當筆者恢復了正常的測試方式之後，原本正常的波形卻消失不見了。
原本測試人員的測試方式中，當前的訊號直接進入測試電路但是測試的電路沒有可靠接地。導致進入的訊號只是單端的輸入，對地沒有參考就造成了波形的失真，索性因為失真導致精度及其下降，所以發現了這個問題。
我改變了正常的測試方式，這個方式可以使當前的測試點測到正常的波形。但是結果卻不盡人意，當前波形直接消失，經過一定的研判之後，我開始認為是因為測試人員將輸入端的訊號線接反，導致當前輸入點和地相接又導致輸入的地和單板相接短路。
但是經過測試人員反覆確認線束的正常之後，我只能從原理圖中查詢問題的原因。
原理圖在原本的測試時，當前的電路使用自身的交流訊號輸出去測量當前的測量電路的精度與驗證。當時的驗證是沒有問題的，所以筆者使用當前電路的抽象模型連線示意圖進行查錯，以期望能夠解決這個問題。
經過仔細的研判，這個電路並沒有什麼邏輯上的錯誤，所以筆者使用了完全複製模型的方式，向當前的電路併入了相關的電器元件。
當我併入了電器元件之後，電路上並沒有什麼大範圍的改變，但當前的交流波形出現了顯著的放大。於是我果斷發現了華點：當前的電路增加了元件後，整體阻抗發生了變化，導致當前對於前端的訊號需求的改變，從而影響了後端波形的輸出。
從而我又加入了一些電器元件，極大的增加了電路的阻抗，訊號直接變成了正常的，說明現在的前端輸出阻抗極高。導致了後端需要很大的輸入阻抗進行阻抗匹配，才能完成訊號的輸出。
後續對於訊號輸出模組的工程師的諮詢表明，當前訊號輸出模組的模型類似於乙個具有若上拉的oc門。就是具有較高的輸入電流能力，部分輸出電壓的能力，無輸出電流的能力。
這種情況下對於外部呈現的就是乙個高阻態的電壓訊號的輸出情況（恒等變換的思維）。在後端的阻抗較小的情況下，這個電路就導致當前沒有輸出訊號出來的現象。
所以需要對當前輸入的電路做一些阻抗變換或單純的增加輸出電流進行處理。這樣就可以一勞永逸的解決這個問題。
因為測試段和輸入端有乙個二極體進行隔離，這個二極體的主要作用是去除當前波形的負半軸，但是因為後端使用的電流很小，導致測試端的輸入必須要併入乙個電阻對當前二極體的電流進行洩放，否則當前的下降波形會出現很大的滯後。
這個波形就會被影響後端的波形整定導致當前波形會在不對應的位置被整定為錯誤的訊號引數，導致了後端的解析電路整個亂掉了。這個軟體必定無法修復因為其本身就是有問題的，這個原因本質上是因為測試方式的錯誤。但是這種問題出現很巧合，排查的過程也很艱辛，為了以後能有參考，筆者將其記錄下來，以作為日後的除錯靈感**。
記一次manila故障
排查過程 1.檢視manila的日誌，api.log scheduler.log share.log,排程日誌最具參考性，但是顯示建立成功 實際狀態為creating 排到share時出現大量報錯 get all share usage failed 2.檢查後端儲存，節點均正常 排查過程 1.關閉...
記週日一次故障意外
記週日一次故障意外 找了waf工程師問，並且我這裡也在同步測試，tcping 網域名稱沒返回，不得不 ctrl c 中斷退出 說解析異常，222這個位址不通，然後給我們明確回覆說 47.91.170.222不是waf的入口 ip，切別的ip是沒用的 因為解析異常之後，我是有叫他切到別的能用的waf ...
記一次Postgres CPU爆滿故障
公司專案測試環境呼叫某些介面的時候，伺服器立即崩潰，並一定時間內無法提供服務。第一反應是伺服器需要公升配啦，花錢解決一切！畢竟測試伺服器配置確實不高，2cpu 4gib，能幹啥？不過問題是今天突然發生的，而且說崩就崩。憑著嚴謹的態度，還是要刨根問底地找下問題。記憶體占用並不大，忘記截圖了，反正看下來...