運用の基本／ PolicyとCondition

通知チャネルとエスカレーション

NinjaOneで検知した事象を適切な相手に届ける設計を説明します。受け手ごとのチャネル設計、重要度との対応、時間帯による切り替え、エスカレーションの段階設計について解説します。

検知した事象を、適切な相手に適切な手段で届けます。チャネルの作成手順は通知先（メール・SMS・ウェブフック）の設定で扱っているので、ここでは設計と運用を説明します。

通知先の設計

チャネルは受け手ごとに作ります。「誰に届けるか」で選べる状態にしておくと、Conditionの設定が簡潔になります。

個人宛てのチャネルは作らないでください。担当者が変わるたびに設定変更が必要になります。

アラート設計のベストプラクティスで決めた3段階を、チャネルに対応させます。

この対応表を先に作ってから個別のConditionを設定すると、判断がぶれません。

夜間や休日は、通知先を変えるのが一般的です。

考え方は次の通りです。

2番目の「緊急のものだけ」の切り分けが重要です。夜間に呼び出す基準を明文化しておかないと、当番担当者の判断に委ねられ、負担が偏ります。

【運用のポイント】夜間に呼び出す条件は、書面で合意してください。「基幹サーバーの停止」「複数拠点にまたがる障害」のように具体的に定義します。定義がないと、呼び出されなかったことが後で問題になるか、逆に不要な呼び出しで当番が疲弊します。

一次受けの担当者で対応できない場合の手順を決めます。

段階を分ける目的は、対応の遅れを防ぐことです。一次担当が抱え込んだまま時間が過ぎる状況を、時間で区切ることで防ぎます。

NinjaOneの機能だけでエスカレーションを完全に自動化するのは難しいため、次のように組み合わせるのが現実的です。

チケットのSLA設定はBoard・ステータス・SLAの設定で扱います。

通知だけでは、対応したかどうかが記録に残りません。対応の記録を残したい事象は、チケットを自動起票する設定にしてください。

設定方法は自動化トリガーの設定を参照してください。

通知が来ないという状況では、次の順で切り分けます。

4番目は見落とされがちです。連携先の仕様変更やトークンの失効で、チャネルが静かに止まっていることがあります。

【注意】通知チャネルは、設定した直後は動いていても後から止まることがあります。月に一度テスト通知を送り、全チャネルが機能していることを確認してください。障害発生時に「通知が来なかった」と気付くのでは手遅れです。