twg-operational-health

twg-operational-health

ルートの twg スキルと併用してください。正確なコマンド構文は、実行中の twg help または twg help describe <path> で確認してください。

CLI ランチャーのフォールバック

twg <command> を実行してください。シェルで command not found が発生した場合は、$HOME/.local/bin/twg （macOS/Linux）または $env:LOCALAPPDATA\Programs\twg\bin\twg.exe（PowerShell）を使用し、 そのディレクトリを PATH に追加するようユーザーに伝えてください。認証エラーやコマンドエラーを PATH の問題として扱わないでください。

使用する場面

• 「オンコールを引き継ぎます」
• 「信頼性、インシデント、SEV、またはインシデント後レビューの報告」
• 「進行中のインシデントを調査し、緩和策を見つける」
• 「根本原因を分析する、またはポストモーテム／PIR の学びやアクション項目を作成する」
• 「未解決のリスク、ブロッカー、過負荷の担当者、運用状況」

最初に行うこと

対象範囲、期間、アンカー、担当者／エスカレーション経路、ステータス、最新性、フォローアップを 確認します。関連する情報源を横断する前に、運用上のアンカーを見つけてください。 --site を付けずに実行してください。TWG はユーザーが Jira/JSM で固定したサイトを引き継ぎます。 ユーザーが別のテナントを明示的に指定した場合にのみ、サイトのオーバーライドを追加してください。 ベンダー内部のインシデントサイトを決めつけないでください。

エビデンスポリシー

• 影響度、緊急度、担当者の明確さ、再発リスク、実行可能性に基づいて順位付けし、 進行中のリスクと過去の言及を分けます。
• インシデント、PIR、フォローアップ、ランブック、担当者、アセット、会議に関するコンパクトな エビデンスを、サービス、テーマ、担当者、最新性ごとにまとめます。リスクの高いクラスターを詳しく調べ、 テーマ、担当者の兆候、確信度が明確になった時点で止めます。
• working theory、confirmed problem、mitigation、root cause を区別します。根本原因の確定には因果メカニズムが必要です。レコードがクローズされているだけでは 不十分です。主張には confirmed、supported、candidate、missing evidence のラベルを付け、 RCA の詳細には参照情報を使用します。
• バックエンド、認証、スキーマの同じエラーを一度修正しても再発する場合は、問題点を報告し、 近くにある別名や広範なインベントリを使うのではなく、残りのエビデンスを使用します。
• ビルドの健全性は、パイプラインごとに pipeline get を実行するのではなく、 bitbucket pipeline query で確認します。ログやテストレポートによってパターン、担当者、 またはアクションが変わる失敗に限り、get を使用します。query が一覧表示するのは最近の実行のみです （--limit のデフォルトは 15）。値を増やし、対象期間を明記してください。順位付けしたセットは 1 回の一括 get で詳しく調べます。

レシピカード

リーダーシップ向け信頼性レビュー／オンコール引き継ぎ

references/reliability-review.md を読み込みます。リーダー、プラットフォーム、期間を確認し、 裏付けのあるテーマをまとめ、原因と緩和策を分け、予防作業を関連付け、リーダーシップ向けのアクションに 優先順位を付けます。引き継ぎの場合は、最初の 1 時間のチェックリストとエスカレーションマップを追加します。

インシデント調査／緩和策

インシデントが進行中、新たに緩和された直後、または PIR 前の場合に使用します。インシデントレコードを アンカーにしてから、対応者、症状、影響、最近のデプロイ／フラグ／設定、トポロジー、アラート／ログ／メトリクスの 参照先、担当者、ランブック、類似インシデントを取得します。チケットのフィールドが少ない場合は、 範囲を限定したフォローアップで 4 つのゴールデンシグナルの系統を調べます。 references/incident-investigation.md を参照してください。 4 シグナルのマトリクス、仮説、確信度、次の確認事項、緩和策の選択肢を出力します。因果メカニズムを 示さずに、緩和策を根本原因と呼ばないでください。

インシデント後の根本原因／学び

緩和／復旧後にポストモーテム／PIR を作成または評価する場合に使用します。インシデントを PIR、 関連ドキュメント、最終コミュニケーション、修正 PR、アクション項目と組み合わせ、確定した緩和策、 因果メカニズム、5 Whys の連鎖、検知／対応のギャップを網羅します。 references/pir-root-cause.md を参照してください。根本原因、寄与要因、緩和策と原因の違い、 優先順位付きアクションを出力します。

アセット／アセットの更新

プロジェクト／目標／Jira／PR／ドキュメント／アクティビティのエビデンスから関係者を特定します。 AQL の前に Assets のスキーマ／タイプのメタデータを調べます。Calculated user など、発見した ユーザーに類する属性を使って人を関連付けます。貢献の中心性とアセットのリスクを組み合わせて順位付けし、 確信度と不足情報を報告します。references/assets.md を参照してください。

キャパシティ／人員配置／ミーティング

人員配置では、プロジェクト／トピック／組織を特定し、関連する業務、 オーナーシップ、レビューへの影響力、ドキュメント、プロジェクト／目標への関与から人員を特定します。 推奨する前に負荷を確認します。ミーティングでは、範囲を絞って録画を検索し、まず文字起こしをプレビューし、 中心的なものだけ全文を取得してから、決定事項、アクションアイテム、情報の不足を要約します。

出力形式

• 重要度、緊急度、または推奨事項を最初に示し、続けてオーナー、ステータス、 最新性、影響、確信度、根拠を記載します。
• 進行中の調査では、4つのシグナルからなる根拠マトリクスと、 確認済みの問題、緩和策、根本原因の状況、再発防止策を含むインシデントから学習までのタイムラインを追加します。
• 成果物全体に見られるパターンをまとめ、推奨オーナーを添えた優先順位付きの次のアクションを提示し、 データの不足（文字起こしの欠落、アセットとの一致なし、更新の古さ、ACL／認証の不足、オーナーシップの不明確さ）を明示します。

アンチパターン

• すべての文字起こしやページ本文を取得したり、インシデントに関するあらゆる言及を進行中のリスクとして扱ったりしないでください。
• 事前 PIR 調査のために方向性を示す仮説を提示する前に、チャット／コメントで RCA のラベル付けが行われるのを待たないでください。
• 確立されたメカニズムがない限り、緩和策を根本原因と呼ばないでください。ワークフローパネル、ボットのコメント、不透明なフィールドを RCA の説明として扱わないでください。
• キーワードの一致だけを組織のオーナーシップの根拠にしないでください。担当者、 サービスオーナー、PIR 参加者、または組織ツリーのメンバーシップと照合してください。
• スキーマ／タイプのフィールドを確認する前に、表示名の推測で Assets を結合したり、活動件数だけをもとに人員配置を推奨したりしないでください。

参考資料

• references/assets.md - スキーマ優先の Assets クエリと人物／デバイスの結合
• references/reliability-review.md - 範囲を絞ったインシデント／PIR のリーダーシップレビュー
• references/incident-investigation.md - 進行中の調査と緩和策
• references/pir-root-cause.md - 緩和後の根本原因分析と PIR ワークフロー