ThinkLink のアラーム運用：発生条件から復旧通知まで確認する

しきい値の前に対処する事象を定義する

温度が高ければ通知する、だけでは納入できる規則になりません。区域、デバイス、単位、継続時間、通知後の行動を決めます。担当者が最初に何を調べるか分かるよう、場所と時刻を含めます。

各規則を受け入れ可能な一文にします。対象範囲で条件を満たしたら発生し、解除条件で復旧し、指定担当者が受信する、という形です。時間、しきい値、頻度は現場固有の値なので、一般例をそのまま本番へコピーしません。

データを受け取る対象へ関連付ける

ThinkLink のトリガーモデルは、関連付け先が上りデータを受信し処理した後に実行されます。保存だけではデバイスに関連付けられません。対象、入力項目、呼び出す RPC の機能を順に確認します。

測定と実行が別デバイスの場合は、資料に従い仮想デバイスやアセットでデータを集約します。実行装置へトリガーを付けても、別センサーの値を自動取得するわけではありません。機器間のデータ関係と制御先の識別を個別に検証します。

発生、継続、復旧を分ける

同じ値を発生と復旧の境界にすると、値の揺れで状態が頻繁に切り替わる場合があります。必要に応じて異なるしきい値と再通知方針を設けます。時間窓や過去状態を使う場合はスクリプトと状態管理が必要で、通知文だけでは実現できません。

オフライン検知は別に設計します。新しい上りデータでのみ動くトリガーは、送信停止だけでは再実行されません。適切なオンライン確認や定期確認を使い、送信周期に合わせて条件を決めます。

通知グループ保存後に受信を確認する

通知グループの資料では email と WeCom WebHook が標準の選択肢です。メールには SMTP 設定も必要で、グループの有効化と連絡先登録も確認します。他のサービスはカスタム RPC や連携手順に従います。名称があるだけで導入済み・利用可能とは判断できません。

テスト用の宛先へ、機器名、場所、時刻、状態、推奨対応を含むメッセージを送ります。トリガー実行、アラーム記録、受信側を別々に確認します。グループ保存は設定の一段階にすぎません。

稼働前に四つの状態を試験する

正常、アラーム発生、異常継続、復旧の順に試験します。各段階のアラーム数、通知数、閲覧者を記録すると、重複発生、復旧漏れ、宛先誤りを見つけられます。

引き渡し時には一時停止方法、しきい値の管理者、調査手順も残します。機器動作を伴う場合は現場状態の読み戻しを追加します。通知送信は実行装置の動作完了を証明しません。

1. 正常データで予期しないアラームが出ないこと。
2. 異常データで指定の事象とテスト通知が発生すること。
3. 異常継続時に所定の再通知方針に従うこと。
4. 復旧時に状態が解除され、必要な復旧通知が届くこと。