前段時間公司定制系統在調用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權限帶來的數據風險，但我相信他們絕對不會。
