はじめに
1/23(木)・24(金) 、インテックス大阪にて開催された Microsoft の大型カンファレンス「Ignite The Tour Osaka」にて「インシデントに対応する」というセッションで登壇しました。
Azure 上で動くシステムでインシデントが発生した場合の対応方法に関して、45分でインシデント対応に関する一般的なお話に加え、Azure や Teams を使ったデモを3つ行うという盛りだくさんのセッションです。
時間が短めの中でかなり速く進めたので、終了後に質問いただいた方や、アンケートでも「デモが短い」「時間が足りない」という声がありましたので、少しフォローアップとして記事を書きます。
しゃべった身としても、せっかくのいろんな要素が詰まった完成度の高いデモの面白さを十分に伝えられていないのはもったいない＆オリジナルの作者様に申し訳がたたないので、なんとか、この記事が届いてくれることを祈ります。
なお、この記事とは別に環境の作り方やハマったところなども続けて記事化する予定です。
セッションの概要と参考リソース
このセッションは「最新の運用プラクティスによる信頼性の向上」というラーニングパスの2番目に位置づけられるものでした。 OPS10 ～ OPS50 までの計5つのセッションを続けて聞くと体系的に理解できるという設計になっています。
ラーニングパスセッションは、アメリカで行われたセッションを「Tour」各地でローカライズして行うもので、オリジナルのスライド・コンテンツの内容は変えずに行うという制約がありました（翻訳はOK）。
各地のスピーカーや、そのセッションを聴いた方が自分でも試してみたい場合に備え、デモ環境作成方法やプレゼンテーション内容・アメリカのオリジナル版のセッション動画などすべて公開されています。
OPS20「インシデントに対応する」に関するリソースは以下です。
セッション動画＆リンク
GitHub リポジトリ
https://github.com/microsoft/ignite-learning-paths-training-ops/tree/master/ops20github.com
なお、環境作成やデモに関してはリポジトリに書いてあるとおりに勧めれば基本的にはいけるのですが、一部ハマりポイント？がありちょっと苦戦したので、そのあたりは別途記事を上げる予定です（＋本家にフィードバック予定）。
日本語スライド
大阪での登壇で使用したセッション資料です。
www.slideshare.net
こちら、今回の大阪のために翻訳しました。
気を付けた点としては、
- スペースが許す限りなるべくオリジナルの英語記述を残した（誤訳怖い）
- 用語の訳し方を一部『入門 監視』に合わせた（特に前半）。
あたりです。
書籍『入門 監視』はセッション内でも紹介しましたが、役割の部分など訳に困った部分で本の前半に非常に似た章があり、助かりました。
セッション構成と内容
オリジナルのリポジトリにも時間配分は書いてありますが、以下のような感じです。
- Section1
- 導入＆インシデント対応の基礎（16分）
- Demo1(7分)
- Section2
- 修復の改善（6分）
- Demo2（5分）
- Section3
- TTR 短縮のためのツール（1分）
- Demo3（7分）
- Section4
- まとめ・クロージング（2分）
いやー、正直時間足りないです…（笑）
説明もパワポのノート欄にびっしり台本が書いてあって、ほんとにこれ時間通りに終わるの？っていう盛りだくさんな内容。
前日までに何度も通しでしゃべって、なんとか切り詰めた…ってかんじです。
では、以下ざっくりと内容です。
Section１：導入＆インシデント対応の基礎
- しゃべったこと：ラーニングパスのひとつ前・OPS10 からのつながりとインシデント対応に関する前提知識。
- デモ：インシデント発生をトリガーとしたかんばんチケット・コミュニケーションチャネル作成の自動化
- 技術要素：Azure Logic Apps, Azure Boards, Azure Table Storage, Microsoft Teams, Adaptive Cards
毎年、「DevOps Research and Assessment」という組織が「State of DevOps」というレポートを出していて、最新の2019年のレポートで紹介された数字について。
1時間以内にサービスの中断を検出、対応、および修正できるチームを「エリート/ハイパフォーマー」として分類。
真ん中のレベルに分類されるチームは、24時間以内にインシデントから回復し、「ローパフォーマー」は、サービスの中断から回復するまでに1週間から1か月かかる。
エリート/ハイパフォーマーは、ローパフォーマーよりも2,600倍以上速くインシデントから回復していて、本番環境へのデプロイも200倍以上多く行っているというデータが出ています。
インシデントとは
今回のセッションはインシデント対応がメインのテーマですが、まずインシデントについて考えてみます。
インシデントが「サービスの中断」であることは問題ないですが、ユーザーが依存しているサービスが止まるとユーザーの仕事や生活に影響してしまいます。
「恐れられ回避される」とは
- 停止の重要性を軽視
- 意図的にラベルを違うものに
- 責任逃れのためサービス中断を報告しない
などがあり、きちんとした体制がない場合こういったことが起こりえますが、最近は DevOps や SRE といった考え方から、こういったことが起こらないよう、インシデントについて改めて考えるようになってきています。
またインシデントは「主観的」なとらえ方をされがちで、さまざまな組織や業界によって、何がインシデントなのかという認識はばらばらです。顧客が影響を受けたときだけなのか、そうではないシステム障害も含むのか。主観的に扱われることは、インシデントの重大度レベルを識別する際にも問題となります。
最後に、エンジニアが行うことのほとんどは計画された仕事ですが、インシデント対応は違います。インシデントに関する作業は予定外です。多くの場合、悪いことと見なされがちですが、ちょっと立ち止まって考えてみると、これはエンドユーザーに価値を提供するための「投資」でもあると捉えられるのかもしれません。
インシデントはシステムの "鼓動"
インシデントは「システムの鼓動・心拍」と考えるとよい、といわれ、心拍たるインシデントは、システムについて多くのことを教えてくれます。
強力な監視基盤がある場合（やシステムで何が起こっているか詳細を知っている場合）には、多くのアラート、インシデント、および対応の機会を生成しますが、そうすると、常にシステムで何が起こっているのかがわかるようになります。
そのすべては、インシデントの最初のフェーズである検知・検出の一部です。
これはひとつ前の OPS10 で詳しく説明があった箇所ですが、このセッションは、アラートを受信したあとの、対応と修復が主題です。
Tailwind Traiders の課題
架空のオンライン小売業者 Tailwind Traders は、Azure 上に構築されたかっこいい EC サイトを持っていますが、インシデントに関して次のような課題に直面しています。
2つ目の原文に「reactionary」とあり、これは訳に迷ったのですが（スライドには直訳を記載）、ニュアンス的には「反射的」とか「ただ反応するだけ」とかの意味になります。
これらは、Tailwind Traders に限らず、私たちもよく直面する課題ではないでしょうか？
インシデント対応の体制・役割・ローテーション
体制と役割
インシデント対応のチームは、必ず複数のエンジニアで構成します。誰かひとりに責任が集中したりしてはいけません。
チームは、以下のような役割のエンジニアで構成します。
プライマリ・レスポンダー
いつでも連絡がとれる、「オンコール」なエンジニア。
セカンダリ・レスポンダー
プライマリ・レスポンダーのバックアップです。
プライマリ・レスポンダーに連絡がつかない場合や、そのサポートを行います。
専門家（SME）
専門家は常に連絡が取れるべきというわけではありませんが、問題の分野ごとに特定しておく必要はあります。
たとえばデータベースの専門家、フロントエンドの専門家など。
プライマリレスポンダーとセカンダリレスポンダーが自分で問題を診断・解決できない場合に連絡できる人がいると安心できます。
現場指揮官（インシデント・コマンダー）
大規模な停止が発生した場合に活躍する統括役。多くの異なるコンポーネント、異なるシステム、チーム間での調整が必要です。 エンジニアが問題解決に集中し、人々がぶつかったり、作業を中断したりしないようにします。 そのためインシデント・コマンダーは何が起こっているのか、誰が何をしているのかを把握しなければなりません。
書記（スクライブ）
会話をできる限り詳細に文書化する役割です。
インシデント対応では、電話やビデオチャットを使用して問題解決のためのコミュニケーションを行うことがありますが、文字に起こさない限り何を言って何をしていたかを詳細に追うことができません（録音でも追いづらいので文書化必須でしょう）。
対応中に振り返ったり、対応後に分析したりすることはインシデント対応において重要です。
コミュニケーション・コーディネーター
インシデント・コマンダーと連携してより多くの情報を共有する人です。インシデント対応を行うエンジニアが持つ以上の情報を、顧客や、カスタマーサポート、販売チーム、マーケティングチームなど外部の人々がもつことがあります。
インシデントやシステムを取り巻く状況や状況を認識するため、コミュニケーションの管理を担当し、他の利害関係者が何が起こっているのか、何が行われているのかを確実に把握できるようにします。
ローテーション
ローテーションは、シフトで管理されます。
エンジニアは、特定の定期的なローテーションに対して「オンコール」の責任を負います。
作成できるシフトにはさまざまな種類があり、「24時間 x 7日間（全曜日）」をローテーションするものや、大きな会社なら "太陽のシフト" に従うローテーションシフトを組めます。これは異なるタイムゾーンでエンジニアが引き継ぐことで、自分の勤務時間だけオンコールであればよくなる、というものです。そうはいっても週末に関しては柔軟性を求められるので、うまくシフトのカスタマイズをすることが必要です。
このあたりは書籍『入門 監視』の前半に詳しいので、あわせて読んでみていただくとよいかと思います。
長くなったので、いったんここで切ります。
次の記事では、Section 1 のデモ（アラートをトリガーとして動く Logic Apps と Teams の連携）について書いていきます。
