TROCCOワークフロージョブのエラー対応の効率化を考えてみた

## 0. 想定読者

本記事は、以下のような方を想定しています。

- **TROCCOを普段利用している方**
- **TROCCOの大量のエラー通知に困っている方**
- **工数を抑えてエラー対応を効率化したい方**

エラー対応の**属人化**や**見落とし**に課題を感じている方にとって、本記事の内容が役立つかもしれません。

---

## 1. はじめに

突然ですが、TROCCOのワークフローを活用していますか？  

私自身、データ転送や加工を定期実行する際にTROCCOをよく利用しています。特に、**実行結果の分かりやすさやエラー通知の柔軟性**が魅力的と感じます。ただ、ワークフロージョブのエラーが増えると、**「特定の担当者の対応工数の増加」や「対応見落としのリスク」** が課題に感じることがあります。

そこで本記事では、**TROCCOとBigQueryを活用したデータ分析基盤を想定し、エラー対応の効率化**について考えてみました。

※ こちらの記事は、#TROCCOシェアチャレ キャンペーン参加記事として作成しています。

---

## 2. ワークフローのエラー対応に関する課題

エラー対応には、以下2つの課題が発生しやすいと考えています。

### **(1) 属人化：エラー対応の判断が個人に依存しやすい**  
ワークフローが多数ある場合、エラーメッセージから原因を推測することは可能ですが、**事前に把握していないと判断が難しく、調査に時間がかかること**が予想されます。その結果、**特定の有識者に依存したり、他のメンバーが時間をかけて対応せざるを得なくなる**状況が生じやすくなります。

### **(2) 見落とし：大量のエラー通知による対応漏れ**  
データ活用が進むにつれ、**ワークフローの数が増える分、エラー発生頻度も上がる**ことが予想されます。特に、長期休暇など対応できない期間があると、その間に発生したエラーが蓄積し、対応漏れのリスクが高まる可能性があります。また、エラー通知機能を有効活用することも重要ですが、**通知が多すぎると埋もれてしまい、結果的に対応が遅れるリスク**もあります。

---

## 3. エラー対応の効率化のための3つのアイディア

TROCCOのエラー対応を効率化するために、以下の3つのアイディアを考えてみました。

### **(1) エラー未対応状況の一覧化**

**目的**：見落とし防止  

**方法**：
- ワークフローのジョブ実行履歴をBigQueryに転送し、データ加工することで、エラー発生後に正常終了できていないジョブを未対応とした一覧を作成します。具体的な方法は以下の通りです。

**1. TROCCOワークフローのジョブ実行履歴をBigQueryに転送**
    TROCCOでは、転送設定の「転送元 TROCCO（※）」を使用することで、ワークフローのジョブ実行履歴をBigQuery等のDWHに転送することが可能です。転送設定で「転送元TROCCO」を指定し、対象：ワークフロー定義、データタイプ：ジョブ実行履歴、取得対象期間を指定し、転送先（今回はBigQuery）の設定を行うと転送できます。
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7502/b7254924-1083-40bb-b0aa-fb213ebdaa3c.png)

※【マニュアル】転送元：TROCCO
 https://documents.trocco.io/docs/data-source-trocco

また、ワークフロージョブ実行履歴のテーブルには、以下3種類のIDカラムがあり、それぞれ①、②、③の画面の黄色枠の数字に対応しています。なお、③→②→①の順でIDの粒度は細かくなります。詳細は【マニュアル】転送元：TROCCOをご参照ください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7502/e54fed3b-4066-4c97-b936-15a4b120fef0.png)

①(画面上の確認方法不明)
（画面上からの確認方法は不明だが、後述の②のジョブの初回、再実行をするタイミングで少なくとも採番されていることをデータ上で確認済み）

②ワークフロージョブ画面のワークフロージョブ番号
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7502/f517d3af-3f00-4799-b807-fb02f738d852.png)

③ワークフロー画面上のID
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7502/bec214af-9bc0-4873-a6ba-aa216498254d.png)


**2.エラー発生ジョブの特定**
    1.で出力したテーブルのデータを `status = 'error' -- 実行完了(エラー)`で絞込み、エラー発生ジョブを特定します。（以降、エラージョブリストと記載します。）
    
**3.成功ジョブの特定**
    1.で出力したテーブルのデータを `status = 'succeeded' -- 実行完了(成功`で絞込み、成功ジョブを特定します。（以降、成功ジョブリストと記載します。）
    
**4.未対応ジョブの特定**
2.のエラージョブリストと3.の成功ジョブリストをワークフロージョブID（pipeline_definition_id）で紐づけ、以下2つの対応状況に分類をする。

- 未対応：エラージョブに紐づく、成功ジョブが `存在しない` 場合
- 完了：エラージョブに紐づく、成功ジョブが `存在する` 場合

なお、2～4の手順をBigQueryのSQLでまとめると以下の通りです。

```SQL

--- エラー発生ワークフロー
WITH error_wf_list AS (
  SELECT
    *
  FROM
    `[1.で出力したワークフロージョブ実行履歴テーブル]`
  WHERE
    status = 'error'　-- 実行完了（エラー）
   -- 実行期間の指定
   -- 今回は、2月分のワークフローエラーを対象とする
    AND DATE_TRUNC(DATE(created_at,'Asia/Tokyo'),month) IN('2025-02-01')
)
, success_wf_list AS (
  SELECT DISTINCT
      pipeline_job_id,
  FROM
    `[1.で出力したワークフロージョブ実行履歴テーブル]`
  WHERE
    status = 'succeeded' -- 実行完了（成功）
    -- 実行期間の指定
    -- エラー確認対象期間（2025/2）以降～現在(2025/3)を対象期間とする。
    AND DATE_TRUNC(DATE(created_at,'Asia/Tokyo'),month) IN('2025-02-01','2025-03-01')
)
SELECT
  ew.*,
  CASE WHEN sw.pipeline_job_id IS NULL THEN '未対応' ELSE '完了' END `対応ステータス`
FROM
  error_wf_list ew -- エラージョブリスト
LEFT JOIN
  success_wf_list sw -- 成功ジョブリスト
ON ew.pipeline_job_id = sw.pipeline_job_id
```
また、上記SQLを抽出した結果をスプレッドシートに反映すると以下の通りです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7502/fb68e6fb-9821-4e9f-a75b-957e15356b4c.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7502/da89595a-0308-4c54-ad01-0f037ecf6fd4.png)

**期待する効果**：  
- **正常終了したジョブを除外し、未対応ジョブを明確化** 
- **対応漏れのリスクを軽減**  

### **(2) エラー分類情報の付加**
**目的**：属人化の軽減  
**方法**：
1. ワークフロー定義単位でエラー分類を付加した内容を、エラー未対応一覧の別シートに追加する。
**＜エラー分類＞**
      - **主なエラー発生原因**
          - 対象のワークフローで発生する主なエラー原因を記載。
              - 例：外部データ起因、設定ミス
      - **対応優先度**
          - エラー発生時、何日以内に対応かを基準に対応優先度（高・中・低）を定義し、
      　定義した優先度を（１）の一覧に追加する。

 　  　    ＜優先度設定イメージ＞
   　  　  　高：当日中対応、中：1週間以内対応、低：1カ月以内、または、対応不要

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7502/9c60ca9f-6b15-4157-b772-cbda1163e232.png)
        
2.1.のエラー分類を、(1)のジョブ単位のエラー未対応一覧に紐づけ、エラー対応の方針を明確化。ワークフロー定義ID（pipeline_definition_id）でエラー分類と紐づける。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7502/bf10e220-595a-4942-b34c-1fd8372beb3a.png)

**期待する効果**：  
- **エラー対応時のポイントと優先度を明確化し、属人化を防ぐ** 

### **(3) 優先度ごとのスプレッドシート作成とSlack通知頻度の制御**
**目的**：見落とし防止
**方法**：
- 未対応エラー一覧を優先度別にフィルタリングし、スプレッドシートに整理 
- Slack通知を優先度に応じて最適化
  - 優先度高 
      - 発生都度：TROCCOワークフローのエラー通知機能で通知  
      - 日次：スプレッドシートをSlackのリマインド機能で通知（朝）  
  - 優先度中・低 
      - 日次：それぞれのスプレッドシートをSlackのリマインド機能で通知（朝）  

**期待する効果**：  
- **通知の量を最適化し、重要なエラーに気づきやすくする**  
- **ワークフローごとの優先度を明確化し、対応の優先順位を統一**  

---
## 4. さらなる効率化のために

「3. エラー対応の効率化のための3つのアイディア」により、属人化や対応漏れの改善が期待できますが、さらに以下の2つの観点で改善の余地があります。

### **(1) マート定義・転送設定単位のエラー発生状況の可視化**
今回はワークフロー単位でエラー状況を可視化しましたが、ワークフロー内のマート定義や転送設定の実行状況も可視化することで、エラー原因をより特定しやすくなる可能性があります。特にTROCCOでは、マート定義や転送設定の実行履歴をBigQueryにエクスポート可能なため、導入はしやすそうです。

### **(2) エラー分類情報の付加自動化**
TROCCO APIを活用することで、ワークフローのラベルを取得することが可能です。今回は手入力でエラー分類を行う想定ですが、ワークフローのラベルにエラー分類を事前設定し、TROCCO APIを使ってラベル情報を取得・分類することで、エラー分類作業の自動化と工数削減を見込めそうです。

---

## 5. まとめ

本記事では、「属人化」と「見落とし」の観点から、TROCCOワークフロージョブのエラー対応の効率化について考え、以下アイディアを紹介しました。

- **エラー未対応状況を可視化し、対応漏れを防ぐ**  
- **エラー分類情報の付加により、誰でも対応しやすくする**  
- **対応優先度ごとのスプレッドシート作成と通知頻度の制御により、対応漏れを防ぐ**  

TROCCOを活用したエラー対応を少しでも楽にするヒントになれば幸いです。
なお、本記事の内容は、TROCCOのフリープランの内容にて試せる範囲のため、よろしければ試してみてください。

- TROCCO製品ページ：https://primenumber.com/trocco
- フリープラン申込みページ：https://primenumber.com/trocco/contact/free-plan