ルールの使い方とスコープのリセットタイミング
回答済み
お世話になっております。
２点教えてください。
１．ルールの使い方
例えば２００台のサーバ担当が１グループだったとします。
２００台のサーバ名と合致していれば、１コールフローに架電します。
その場合、enterprise を使わない最も簡易的な設定は、スコープ毎のルールの処理フローで「件名がサーバ名を包含する」の条件を指定したスコープを２００個作成することになりますか？
仕様情報では、ルールのオペレーション登録可能数は「上限なし」でした。
これはスコープ数も同じでしょうか？
またこの場合、深刻度を監視する必要がなければ、イベントの設定は不要でしょうか？
また、前にも少し伺ったのですが、電話担当が１グループであったとしても、その曜日やひにちによってコールフローは変わる場合があります。
数種類のコールフローがあったとして、systemdate と絡めた判別を、excelファイルとの親和性のあるEnterprise で対応可能ということでしたが、間違いないでしょうか？
２．イベントの深刻度名の値、警戒判定閾値、障害判定閾値がリセットされるタイミングはいつでしょうか？
深刻度自動復旧は無効のままの条件です。
Kompiraシリーズのポリシーとして、受信スロットに入った情報が解決済とするのは
・アクションの正常終了
・スコープが正常にもどること
でしょうか？
スコープが正常に戻るのは、深刻度自動復旧を設定するしかないのでしょうか？
長くなり申し訳ありません。
よろしくお願いします。
-
正式なコメント
ご質問ありがとうございます。回答させていただきます。
例えば２００台のサーバ担当が１グループだったとします。
２００台のサーバ名と合致していれば、１コールフローに架電します。
その場合、enterprise を使わない最も簡易的な設定は、スコープ毎のルールの処理フローで「件名がサーバ名を包含する」の条件を指定したスコープを２００個作成することになりますか？サーバー名を完全にホワイトリスト形式で判定するとなると、ルールを200個作ることは避け難いと考えます。ただし、イベント発行先のスコープに関しては1つにまとめられる可能性がございます。
例えば架電に使用するコールフロー・ガイダンスが1種類だけで済む場合は1つのアクションで表現が可能です。このときガイダンスが完全に固定文面ならばスコープ・トリガーの設定は1つにまとめて問題ございません。
また読み上げ内容にサーバー名を含める場合など、ガイダンスへ情報の埋め込みを行う場合、トリガーの「パラメーター加工フロー」により正規表現等で情報の抽出が可能であれば、スコープ・トリガー自体は1つで表現することができます。
仕様情報では、ルールのオペレーション登録可能数は「上限なし」でした。
これはスコープ数も同じでしょうか？スコープ数に関して、登録数に上限はございません。
こちら、仕様情報の方にも記載するよう社内調整させていただきます。深刻度を監視する必要がなければ、イベントの設定は不要でしょうか？
「イベントの設定」が何を指しているかによりますが、ルールの「イベント」の設定であれば、こちらがないとスコープに対してイベント発行が行われず、結果としてトリガー判定が発生しない場合アクションが実行されません。なので、こちらは必須となります。
深刻度自体を変化させる必要がないようであれば、「深刻度を0にする」イベントを発行するのが良いかと存じます。またトリガーの「実行条件」の設定を指すのであれば、こちらは設定しなくともアクションが実行されます。その場合「イベントが発生すると必ずアクションが実行される」という動作となります。
電話担当が１グループであったとしても、その曜日やひにちによってコールフローは変わる場合があります。
数種類のコールフローがあったとして、systemdate と絡めた判別を、excelファイルとの親和性のあるEnterprise で対応可能ということでしたが、間違いないでしょうか？Enterpriseを利用する場合、曜日・日付等のルールと呼び出すコールフローの対応表を元に、然るべきリクエスト内容でPigeonのAPI呼び出しを行う、という形でご要望の内容を実現可能です。
その対応表はExcel形式やCSV形式などファイルの内容を元に生成することも出来ますし、Enterpriseの画面上から直接設定する形を取ることも可能です。
イベントの深刻度名の値、警戒判定閾値、障害判定閾値がリセットされるタイミングはいつでしょうか？
深刻度自動復旧は無効のままの条件です。深刻度自動復旧の設定を行わない場合、自動的にステータスが正常に戻ることはございません。
Kompiraシリーズのポリシーとして、受信スロットに入った情報が解決済とするのは
・アクションの正常終了
・スコープが正常にもどること
でしょうか？
スコープが正常に戻るのは、深刻度自動復旧を設定するしかないのでしょうか？深刻度自動復旧を使用せずにスコープステータスを正常に戻すには、例えば復旧メールを送ることができるならばこれを受信したとき「深刻度を0にする」（もしくは「深刻度をN減らす」）といったイベント発行を行うようにルール設定を行います。
もしくはWebhookアクション経由で「イベントの手動呼び出し」APIを用いて深刻度を0にすることも可能ですが、トリガー設定をうまく行わないとイベント発行が無限に行われ続けてしまう可能性もあり、上級者向けと言えます。
基本的には復旧用のアラートを送信していただくか、自動復旧を利用することをお勧めいたします。
コメントアクション -
お世話になっております。
ご回答いただいてから、長く間が空きまして申し訳ありませんでした。
第1段階の運用仕様が決まったので、念のためお尋ねしたいと思います。
質問【20210825_1】
・コールフロー：架電＝１：１の関係であり、コールフローは必ずUNIQUE に存在する・ガイダンスはパラメータ加工フローを使い、全架電共通ガイダンスとする（受信スロットを分ける場合は別作成）
・ルール一致条件において UNIQUE であるコールフローの表示名をメール本文内の文字列と一致させる
といった環境の場合は、ガイダンス以外は全てコールフロー毎の作成が必要 という認識でいます。これ以外の手法がもしありましたらご教示ください。
scope - rule - (event：深刻度"0" のまま)
- trigger -action -callflow
-guidance （共通）
-
ご提示の対応関係にてPigeonアクションを用いて連絡を行う場合、おっしゃる通りガイダンス以外は個別に用意する必要があるかと思います。
なお、別途いただいたいるご質問「 Kompira シリーズ間での架電情報の引き渡しについて 」で回答させていただいた、WebhookアクションのパラメーターとしてコールフローIDを指定する方法を用いる方式であれば、メール本文内にコールフローIDを含め、それをトリガーの「パラメーター加工フロー」で抽出して使用することでルール・スコープを1つにまとめることができる可能性がございます。
該当質問の最後に設定例を挙げておりますので、そちらをご参考に採用可能かご検討いただくのがよいかと思います。
よろしくお願いいたします。
サインインしてコメントを残してください。
コメント
3件のコメント