監視ツールの障害アラートと社内の対応メモから、顧客向けの障害のお知らせ（発生・調査中・復旧）の文面を段階ごとに下書きする

処理の起点を決める

起点は2つあります。 1つは Datadog のアラート、もう1つは対応チャンネルに当番が書く続報のメモです。

1つ目は、監視の通知を Webhook で受けたときです。 顧客向けの告知の対象にする監視だけに、メッセージへ @webhook-zapier-notice を書きます。すべての監視に書かないのは、ディスクの使用率のような社内だけの監視で下書きが作られないようにするためです。 さらに、対象の監視には notice:customer のタグを付け、Zap の側でもタグを確かめます。二重に絞ります。

通知の種類は $ALERT_TRANSITION で分けます。 Triggered なら初報、Recovered なら復旧の下書きを作ります。Renotify（再通知）では何もしません。 同じ障害の初報が何度も作られるのを防ぎます。

2つ目は、対応チャンネルに「#続報」で始まるメッセージが書かれたときです。 Zapier の Slack の New Message Posted to Channel は、選んだチャンネルに新しいメッセージが投稿されたときにすぐ動きます。書き出しで絞るのは、対応チャンネルには調査のやり取りが大量に流れるからです。 すべてに反応させると、Zap のタスクを使い切ります。

ボットの投稿では動きません。 Slack の連携の説明では、ボットやスラッシュコマンドなどによる添付付きのメッセージは Zap を起こせないとされています。続報のメモは、当番が自分のアカウントで書きます。

入力データを集める

質を決めるのは、監視と症状の対応表です。 api-gw-latency-p95 という監視が「打刻の画面の表示が遅くなる」ことに当たると書いてあれば、AIはその言葉で書けます。表が無ければ、AIは監視の名前から症状を推し量ることになります。 それは当番の頭の中にある知識を、AIに当てずっぽうで再現させることです。

お詫びの文は型に固定します。 AIに毎回書かせると、障害の大きさに関係なく言い回しが変わります。お詫びの程度を決めるのは会社で、文面の生成ではありません。

データの取得方法を決める

続報のメモから障害を特定する方法を決めておきます。 対応チャンネルで同時に2つの障害を追うことは多くありませんが、ゼロではありません。「#続報 INC-0412」のように、メモの書き出しに台帳の障害番号を書く決まりにします。 番号は初報の承認依頼に載せておき、当番がそれを写します。

Datadog の本文は、送る側で JSON の形を決めておきます。 変数を並べた JSON を Webhooks インテグレーションの本文に書けば、Catch Hook の側で欄ごとに分かれて届きます。

AIへ渡す前に整形する

1. 告知の対象かの確認 … $TAGS に notice:customer が含まれないものは止めます
2. 通知の種類で分ける … Paths で Triggered・Recovered・それ以外の3本に分けます。それ以外（Renotify など）は止めます
3. 重複の確認 … 同じ監視のIDで状態が「対応中」の障害が台帳にあれば、初報を作らず、当番に「同じ監視の障害が対応中」と知らせます
4. 時刻の変換 … $DATE はエポックミリ秒なので、日本時間の「10月8日 14:05」の形にします
5. 対応表の引き当て … 監視のIDで対応表を引きます。見つからなければ下書きを作らず、当番に知らせます
6. 社内の用語の洗い出し … 対応表に登録した社内の用語（監視の名前、サーバーの役割の略称、チーム名）が続報のメモに含まれていれば、その一覧を指示に渡します

5番目で下書きを作らないのは、対応表に無い監視は症状の言葉が無いからです。 作らせると、AIは監視の名前を顧客向けの言葉に「訳し」ます。その訳が合っているかを、障害の最中に当番が確かめる余裕はありません。

6番目は、AIに言い換えを任せるための準備です。 社内の用語を消すのはAIの仕事ですが、何が社内の用語かを決めるのは表です。

AIに処理させる

させるのは、決まった型の各項目を、渡した材料の範囲で埋めることだけです。

右端の列が、この構成でいちばん大事な決まりです。 材料が無いところは、型の既定の言い回しで埋めるか、空にします。 AIの推測で埋めることはしません。

1行目がいちばん起きやすい失敗です。 メモに「DBの接続数が上限に張り付いている」と書かれていると、AIは「データベースの不具合により」と原因として書きます。張り付いているのは症状の1つで、原因とは限りません。

指示内容を固定する

あなたは法人向けSaaSの障害のお知らせの下書きを書く担当です。
読み手は契約企業の人事・総務の担当者で、技術の専門家ではありません。
下の【材料】だけを使い、【型】のとおりに書いてください。書かれていないことを推測しないでください。

【段階】{phase}（initial = 発生・調査中 / update = 続報 / resolved = 復旧）

【型】
題名: 【障害】{機能の名前}がご利用しづらい状態について（resolved は【復旧】）
本文の順: 発生日時 → 影響を受ける機能 → 症状 → 現在の状況 → 次の更新の予定
お詫びの文: 「ご迷惑をおかけしており、申し訳ございません。」（この文のまま使う）

【厳守事項】
- 原因は書かないでください。メモに「原因：」で始まる行がある場合だけ、その行の内容を書いてください。
  「〜のため」「〜により」で原因のように読める書き方もしないでください。
- 復旧の見込みの時刻を書かないでください。
- データの消失や漏えいについて、あるともないとも書かないでください。
- 影響する会社の数や社名を書かないでください。
- 【社内の用語】にある語を本文に出さないでください。対応表の言い換えを使ってください。
- 現在の状況にメモから書くことが無い場合は「原因を調査しています」とだけ書いてください。
- 次の更新の予定がメモに無い場合は「1時間以内に続報をお知らせします」と書いてください。
- 続報では【これまでの版】の症状の書き方を変えないでください。変わった点だけを足してください。
- resolved の場合も「復旧しました」とは書かず、復旧日時の欄は空のままにしてください。
- 書けなかった項目と、材料のどこにも根拠が無い文が無いかを、それぞれの欄に書き出してください。

【材料】
アラート: {alert}
対応表: 機能={component} / 症状の書き方={symptom} / 言い換え={glossary}
続報のメモ: {memo}
これまでの版: {past_versions}
【社内の用語】{internal_terms}

「〜のため」「〜により」を名指しで禁じないと、原因が忍び込みます。 「原因は書かない」とだけ書くと、AIは原因の欄は空にしても、症状の文に「サーバーの負荷の高まりにより」と書き足します。禁じるのは、原因として読める書き方そのものです。

resolved でも「復旧しました」と書かせないのは、宣言を人に残すためです。 下書きに書いてあると、承認の画面で読み流されたまま出ます。空欄なら、当番は時刻を入れるときに必ず確かめます。

出力形式を固定する

AI by Zapier の出力の項目として、次の形で受け取ります。

{
  "phase": "initial | update | resolved",
  "title": "",
  "body": "",
  "affected_components": [""],
  "next_update": "",
  "missing_items": [""],
  "internal_terms_found": [""],
  "unsupported_sentences": [""]
}

1つ目の理由は、承認の画面に項目ごとに並べられることです。 Human in the Loop の承認依頼では、レビューする内容を名前と値の組で並べます。題名・本文・次の更新の予定を別の行にすると、当番は直す場所をすぐに見つけられます。

2つ目は、missing_items と unsupported_sentences を承認の画面の先頭に出せることです。 「影響を受ける機能が確認中」「根拠の無い文が1つ」と最初に見えれば、当番は本文を読む前に確かめる場所が分かります。

3つ目は、internal_terms_found で社内の用語の残りを機械的に止められることです。

システムへ連携する

ステータスページには書き込みません。 掲載担当が貼る手間は残りますが、誤った文面が一瞬でも公開される経路を作らないためです。 承認から掲載までは数分の差で、初報が遅れていた理由はそこではありません。

承認依頼は Slack で当番の責任者に届けます。 承認の依頼はメールでも届けられますが、障害の最中に当番が見ているのは Slack です。 依頼に書く説明欄には、障害番号と Datadog のイベントのURLを入れます。

人が確認する

下書きはすべて、当番の責任者が承認してから出ます。 目標は、1版あたり10分です。

1. 先頭の注意を読む … 社内の用語の残り、根拠の無い文、書けなかった項目
2. 症状と影響を受ける機能を確かめる … 今わかっている状況と合っているか
3. 次の更新の予定を確かめる … 守れる時刻か。守れないなら延ばします
4. 復旧の版では、顧客の画面で直ったことを確かめてから時刻を入れる
5. 直して承認する … 却下したら、手で書いて掲載担当に渡します

承認の待ち時間を決めておきます。 Request Approval では、待つ長さと、時間内に応答が無いときにそのまま続けるか、実行を終えるかを選べます。ここでは必ず「実行を終える」にします。 続ける設定にすると、誰も読んでいない文面が掲載担当に渡ります。待つ長さは15分にし、催促の通知を5分後に出します。

承認できる人を決めておきます。 Professional のプランでは承認の依頼を自分にしか送れないとされているので、当番の交代がある運用では Team 以上のプランが要ります。レビューする人は Zapier のアカウントを持ち、その Zap を共有されている必要があります。

例外に対処する

「Zapier に届かない」の行と最後の行は、自動化が止まったときの話です。 障害の最中に Zap が動かなくても、手で書く今の手順に戻れば告知は出せます。 自動化を前提に今の手順を捨てないでください。

Datadog の再送は、こちらが5XXを返したときと内部のエラーのときだけです。 1回の要求は15秒で時間切れになり、つながらなかった要求は5回まで再送されるとされています。Zapier 側が受けた後に Zap の中で失敗した場合、Datadog は再送しません。

記録を残す

• アラートの本文（JSON）と受けた時刻
• 段階ごとのAIの出力（body、missing_items、internal_terms_found、unsupported_sentences）
• 承認の結果と、当番が直した後の文面（直す前と後の両方）
• 承認した人と時刻、却下・時間切れの記録
• 掲載担当が掲載した時刻
• 続報のメモの本文と、それを書いた人

3つ目で直す前と後の両方を残すのは、指示と対応表を直す材料にするためです。 同じ直しが続くなら、それは対応表の症状の書き方か、型が合っていないということです。