開發時間省三倍：用 Ragic 自建 app 錯誤回報系統

開始開發 app 以來，後續維護方面一直有個困擾，就是有時候因為線索不足，很難直接透過用戶口頭、文字或圖片說明的錯誤回報內容找到問題源頭來解 bug，所以一直在找能幫我更快解決問題的自動化回報機制。

其實，我們現階段採用的 Flutter 已能支援 Firebase report 來自動取得錯誤回報資訊。但是，通常看到錯誤回報的統計後，下一步就是要想辦法確認問題、改善問題、避免問題再次出現。而 Firebase report 這樣的第三方套件畢竟不是為我們「量身打造」的，實際上很多問題發生時，不見得能從 Firebase report 取得對應的 log。此時經常又得回到原始、人工的「使用者回報」流程，依靠使用者的描述猜測是哪裡出錯，這樣仍然無法有效抓出問題根源。

日前就遇到一個這樣的例子：使用者回報 app 一直無法順利取得資料庫的資料，但該台電腦又可以正常使用我們的網頁版本。從我們手邊既有的 log 資訊、使用者起初提供的資訊，一直找不到問題的原因。後來經過多次猜測、邀請使用者配合安裝測試版本的 app ，才抓出問題所在：原來是該使用者公司的網路環境不小心將我們其中一台伺服器 IP 封鎖掉了。

像這樣的問題雖然最終解決了，但來來回回也耗掉好幾天的時間，也因為如此，我們決定乾脆自行開發專屬的問題回報系統。這個回報機制最好讓開發團隊看到問題回報就知道哪一段 code 出問題，最好還能把使用者是在什麼操作情況下產生問題的資訊帶入，以達成比第三方套件更精確、更快解決問題的目的。

考量開發的時間成本、管理介面友善度等因素，我們採用 Ragic 作為存放 log 的資料庫，Ragic 現成的工具介面和 API 大幅節省了開發時間，讓我在 7 個小時內就建好系統，比原本預估時間省了將近三倍，很推薦有類似開發需求的朋友參考。以下就分享我們構思此系統的幾個步驟，供大家參考。

1. Log 存放

要做問題回報的系統，第一個問題就是：log 資料要放在哪邊，用什麼格式存放？

一開始的構想是寫入到伺服器某一個 log 文字檔案，或者使用 SQL 伺服器存放，但不管是哪一個方案，似乎都還要花不少時間去處理純文字資料的呈現方式，畢竟我們希望可以更直覺地看到 log 內容所表達的問題，但前提是我們又不想花太多時間在視覺處理上面。

參考很多現成方案之後，我們決定直接採用 Ragic 來當成回報資料的存放方案，考量的原因包括下列幾點：

(1) 可將回報資料直接無痛支援 Ragic 26 種欄位的呈現方式。舉例來說，Log Type 就可以是從選單選擇欄位，而 Record Time 直接可以是 Ragic 的日期欄位（可對照下方採用 Ragic 當管理介面的圖）。

(2) 可以直接使用 Ragic 寫好的工具介面，包含轉檔，大量修改、報表、通知......等功能。

(3) 資料串接的部分也可以直接使用 Ragic 提供的 API，也省去了自行開發 API 的時間。

另外，相較於純文字介面，直接使用 Ragic 來管理查詢 app 回報的 log 變成一件很輕鬆的事情，Ragic 介面將純文字的 log 變成了一個漂亮整齊的資料瀏覽畫面，提供更迅速直觀資料的預覽方式，直接內建了文字篩選與排序等資料庫功能，在這些功能上面省去了不少開發時間。

下面兩張圖分別為「直接採用 Ragic 當成問題回報管理系統前端畫面」與「傳統純文字資料」的差異。

採用 Ragic 當作管理介面：

傳統文字 log：

2019/08/15, NoSuchMethodError: The method '[]' was called on null.
2019/08/15, RangeError (length): Invalid value: Not in range 0..5
2019/08/15, moveToAddress camera update NoSuchMethodError..

2. Log 上傳方式

存放方式解決之後，接下來要處理的就是讓 app 呼叫的 API ，傳統做法就是自己要開始寫伺服器端的 API 來處理 app 的呼叫，但因為我們把 log 存放在 Ragic，所以直接使用 Ragic 寫好現成的 API 即可，Ragic 有完整的 REST API，開發者可以從官網 API查詢並直接呼叫使用即可，這部分也是省下不少的開發時間啊！

3. Log 分析

我們前幾年包含現在的 app 除錯流程如下：

如果繼續走這個流程，單純分析 log 的話，Ragic 內建的圖形化報表分析工具已經很夠用。Ragic 內建的報表包括以下工具：

資料儀表板、排行報表、樞紐分析、分群報表、看板（任務板）、圓餅圖、曲線圖、行事曆、甘特圖

如果對 JavaScript 很熟的朋友，還可以直接使用 Ragic 提供的 Workflow 功能開發。

但既然現在 app 已經具有搜集問題的能力，接下來就會希望更進一步，除了上述維護方式之外，增加自動分析問題的能力，期望的模式如下：

要做到上述功能，就會需要自動分析每天的所有 log，其實每日 log 數量也不小，每天都有好幾萬筆資料，要分析的層面包含每個版本產生的 bug 分類、分析 bug 在新版本上是否有效降低產生次數、相同問題的使用者回報數量......等等，資料處理需求較大，所以我們選擇透過另外一台伺服器來抓取 Ragic 上面的 log 資料並分析，需要撰寫額外的程式來處理這部分。

如果像我們一樣，功能需要比較複雜或者有比較大量運算量的統計，建議這部分也另外建立一台伺服器處理。下面我們就介紹如何透過 PHP 的方式來存取目前我們在 Ragic 上面的資料。

Ragic PHP SDK

Ragic API目前有提供 PHP SDK，有需要的人可以直接透過以下連結下載使用：

https://github.com/ragic/public/tree/master/HTTP%20API%20Sample/PHP-Sample

(1) SDK初始方式

require_once(RagicSDK/Ragic.php");
$RagicSDK = new RagicSDK();

(2) Get 呼叫方式

基本使用方式

$RagicSDK = new RagicSDK();
$RagicSDK->SetAPIKey("Your APIKey");
$Parameter = [];
$Parameter["api"] = true;
$RagicSDK->Get("表單路徑", $Parameter);

伺服器會回應範例

{
  "12": {
    "_ragicId": 12,
    "_star": false,
    "姓名": "test guest",
    "_index_title_": "test guest",
    "pic": "k81cktVS1M@截圖 2020-04-13 下午3.07.54.png",
    "file": "wBAK5UZp26@分機表.pdf",
    "note": "",
    "_index_": "",
    "_seq": 1
  }
}

(3) 資料排序與篩選

Ragic API 資料排序的說明見此連結；Ragic API 資料篩選的說明見此連結。

$RagicSDK = new RagicSDK();
$RagicSDK->SetAPIKey("Your APIKey");
$Parameter = [];
$Parameter["api"] = true;
$Filter = ["1000002,eq,Error"];
$Sort = array(
    "1000003" => "DESC"
);
 
$RagicSDK->Get("表單路徑", $Parameter, $Filter, $Sort);

(4) Ragic登入呼叫範例

API說明

$RagicSDK = new RagicSDK();
$LoginParameter = [];
$LoginParameter["u"] = $_GET["u"];
$LoginParameter["p"] = $_GET["p"];
$RagicSDK->Get("/AUTH", $LoginParameter);

(5) Post 呼叫方式

新增一筆資料

$RagicSDK = new RagicSDK();
$RagicSDK->SetAPIKey("Your APIKey");
$PostParameter = [];
$PostParameter["1001183"] = "Test";
$PostParameter["1001184"] = "1234";
$PostParameter["api"] = "";
$RagicSDK->Post("表單路徑", $PostParameter);

(6) Post 上傳檔案範例

require_once(RagicSDK/Ragic.php");
$RagicSDK = new RagicSDK();
$RagicSDK->SetAPIKey("Your APIKey");
$PostParameter = [];
$PostParameter["api"] = "";
$file = realpath("test.jpg");
$mime = "image/jpg";  
$file_name_onserver = "sample.jpg";  // use on server side
$cfile = curl_file_create($file, $mime, $file_name_onserver);
$PostParameter["1001228"] = $cfile;
$RagicSDK->Post("/zen4641/ios-test/18", $PostParameter);

(7) Delete 呼叫方式

$RagicSDK = new RagicSDK();
$RagicSDK->SetAPIKey("Your APIKey");
$RagicSDK->Delete("表單路徑")

4.總結

當初規劃自建問題回報系統的目標有下面幾項:

(1) 能提供比採用第三方套件更精準的回報資訊

(2) 用最少的時間成本達成

(3) 介面友善

實際上這些目標確實都達到了，整套系統不包含 log 分析的部分，開發下來時間大概約 5-7 小時，比當初預估的時間省了將近三倍，原因是很多資料處理的部分，都直接透過 Ragic 處理掉了，實際運作下來也大幅度降低跟客戶來回往返要資料與測試資料的時間。

最後，額外發現一個當初沒預估到的優勢：因為 Ragic提供的介面很容易上手，所以第一線客服人員就算不具備工程師的能力，一樣可以查詢看懂客戶出現的回報問題，所以很多簡易的問題或者非 app 錯誤的問題，就直接被解決掉，而不用再回報到工程師這邊再測試。所以這邊真的很推薦有相同開發需求的朋友，直接採用 Ragic 當作問題回報方案的資料庫。