前段時間公司定製系統在呼叫SAP RFC介面的時候報錯了，看錯誤訊息一時半會兒也不知道是哪裡引數資料錯誤，就想著進到SAP系統裡面對這個介面做遠端Debuger，跟蹤一下引數變數的變化，結果發現根本就沒有這個許可權。
我記得當初入職的時候是有申請過這個許可權的，包括IT總裁及公司老闆在內的都同意了該申請，到SAP系統管理員那邊的時候也照申請的許可權更新了角色，但過了一段時間之後這個許可權還是被收回了。聯絡系統管理員被告知：SAP生產機不能開放Debuger許可權，哪怕是公司老闆同意了也沒用，原則上就是不能開放。
他口中的“原則”無非就是SAP生產機畢竟是企業生產真實的資料，許可權把控要比較嚴格。如果一個賬號有了Debuger許可權，那就等於很大程度擁有了SAP系統很多許可權，從審計以及IT管控上來說是不合理的。從他的角度上來說或許是對的，但站在IT業務和開發顧問的角度來看，如果遇到了非常規未知的錯誤，就必須通過Debuger來跟蹤解決，甚至要跟蹤到系統深層次的標準邏輯。那些妄想通過資料複製到測試機來讓問題復現的做法都是愚蠢者的行為。
不僅如此，我還問過其他業務顧問，比如SD模組的業務顧問，他們的賬號連SD模組很多許可權都不具備（如VA02等），甚至連自開自發的報表許可權都沒有。有時候使用者打電話發郵件過來反饋異常，常常讓他們感到難堪，因為許可權問題他們看不到這個異常。
算起來我混SAP界也是有一些年頭了，一直都是用的sap_all，遇到什麼問題解決從來不會為許可權煩惱，也不會有人來稽核我IT賬號的許可權，而這麼多年來我也從來沒有因為許可權過大而發生過什麼誤操作。
所以開放Debuger許可權是一定有的，不管是不是SAP生產機，否則很多問題根本就沒法解決。唯一要卡控的是誰能擁有這個許可權。一般來說資深的開發顧問以及資歷較深的SAP顧問應該擁有這個許可權。這就看企業SAP系統管理員的規劃了，如果只是偷懶而禁用這個許可權，那我只能說像這種把SAP系統當菩薩供著的做法特別不專業和沒水準。
文章的最後，再說一句：其實SAP系統是可以管理到一個賬號可以用Debuger許可權，但不允許修改任何變數的值。如此可以在一定程度上消除Debuger許可權帶來的資料風險，但我相信他們絕對不會。
