「常時稼働・即時対応」の顧客の要求と期待の高まりに応えるため、デジタルオペレーションは人々の仕事の仕方を変えつつあります。 また、最も興味深いマクロなトレンドの１つは、IT運用チームと開発チームだけでなく、ビジネス全体がどのように顧客への対応力をレベルアップさせるよう注力しているかを見ています。 良いにつけ悪いにつけインシデント対応は、時間の制約のある中での組織全体の取り組み（カスタマーサポート、エグゼクティブ、コミュニケーション/マーケティング、セールスなどを含む）で効果的な対応を策定するための非常に良い例になります。重大インシデントはビジネス上の問題であり、製品上の問題ではありません。 現代のインシデント対応には、優れたコミュニケーションとコラボレーションが不可欠です。
Atlassianはこの現実解を与えてくれます。 当社が既に用意しているJIRA、HipChat、およびStatusPageとの深い統合に加えて、 PagerDutyのStride向けエクステンションの一般向けの提供開始をここに発表します。 Strideは完全なチームコミュニケーションソリューションで、何かPagerDutyでのインシデントが発生したときにチーム全体の可視性を向上させるのに最適です。 しかし、最も重要なことは、Strideが、重大インシデントのような危機の時に組織を調整するのに役立つということです。 特に、効果的なインシデント対応を推進するために、Incident Commanders、Deputies、Scribesの優れた機能を提供します。 （Incident Commandに精通していない場合は、 https://response.pagerduty.com/を参照してください ）。
Incident CommandのStride機能をご紹介します。
PagerDutyのStrideサイドバーの使い方
PagerDutyはChatOps（GitHubの商標です）の初めに関連していることを誇りに思っていますが、ChatOpsの悪い応用例の１つは、対応中のインシデントの詳細を理解させるために新しいレスポンダーにチャットログ全体を読み上げるよう強制することです。それに対してStrideのサイドバーは、インシデントに関して関連性が一番高い情報のスナップショットを提示しておく場を提供します。インシデントに関連する冗長な会話はルームで行われ、一方でサイドバーのアクティブなインシデントの表示には、インパクト、イベント、重要な決定事項、および実行されたアクションの要約が含まれます。
このタイプの情報はまさにScribeがキャプチャし続ける必要があるものであり、リアルタイムでキャッチアップするためにも、後でタイムラインを編集するためにも最適です。 共通の基礎情報はコミュニケーションの重要な概念であり、インシデント対応にとって特に重要です。インシデント・コマンダーは、共通の基礎情報を維持するために、これらの種類の要約を定期的に（音声でのコールでは口頭で）行うように訓練されています。 スピードを上げるために人々に「チャットログを読め」と強制しないでください！ （興味があれば、ExomiteのDan Slimmon氏はVelocity Santa Clara 2016で素晴らしい話をしています。ご覧ください。）
Stride Decisions
効果的なインシデント対応の重要な原則の１つは、すべての意思決定権限がインシデント・コマンダーに与えられることです。 これは、リスクの高い決定が顧客の影響を緩和するために必須な重大インシデントでは特に重要です。 トレーニングで使用する1つの例を示しましょう。ダウンタイムが発生すると同時に全Webサーバーを再起動するのは一般的ではありませんが、既に他の方法ですべての顧客が影響を受けている場合は、再起動が正しい選択かもしれません。
Stride Desicionsは、そのハード・ディシジョンをレスポンスが記述されているときにインラインで簡単に記録できます。 この種の意思決定ポイントの記載は、あなたの対応チームの共通の基礎情報を更新する素晴らしい方法です。 ただ覚えておいてください：あなたは決定を下す権限を持っていますが、あなたは常にあなたの Subject Matter Experts（SMEs）の専門知識を活用すべきです。 あなたは自分の意思決定について承認する必要はありませんが、実行する前に「何か強い反対意見」を求めておくのは、事後の偏った見方を防ぐために常に良い考え方です。
Stride Action
インシデントコマンドが有効な間に、統制のとれた状態を保つのが難しいことがあります。 決定が下されると、いろいろな行動がしばしば続きます。Stride Actionsは、さまざまな調査や実験を追跡し、それによって幅広い顧客への影響を理解し、それが顕在化するまえに緩和する方法を知るために最適です。
この種の機敏を要するアクションについては、次の３つを強く推奨します。
- Assign them（担当に割り当てる)、つまり個人名（ “Dave Cliffe”）または機能（ “Network on-call”）で指定すること。
- Time-box them（締め切りを示す)、担当者はより多くの情報を得る余裕がどのくらいあるかを知ることができます（これは緊急性を意識させるためにも役立ちます）。
- Receive acknowledgement （誰かが受任したという通知を受け取る)、インシデント・コマンダーは彼らがタスクを理解していることを知っています。
事後検証をないがしろにしないこと
混乱が収まり、顧客への影響が少なくなったとき、インシデント・コマンダーがすべき最後の1つは、事後検証をさせることです。 すべてのインシデントは、学習の機会であることを覚えておいてください。 システムの技術的側面だけでなく、チームのコミュニケーションの仕方を理解することで、今後の対応がさらにうまくいくようになります。だからインシデント対応プロセスを定期的に確認してください。 PagerDutyとJIRAの統合は、レスポンスチームが特定したアクション項目をフォローアップするための素晴らしい方法を提供します。
モダンなインシデント対応には、反復と学習を通じて向上する正確で自動化された共同のレスポンスを可能にしながら、分散型のオーナーシップを取り入れる新しいアプローチが必要です。 PagerDuty StrideエクステンションをJIRAとStatusPageの統合と連携させることで、PagerDutyとAtlassianは効果的なオペレーションのための優れたプラットフォームを提供します。 ぜひ試してみて、あなたの考えをお聞かせください！
その他のリソース：
本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです
カテゴリー ：インテグレーション＆ガイド
