はじめに
システム障害対応の教科書という書籍の中で「ShiftとLift」という用語が紹介されていたのでそこの抜粋と、同書で触れられているトラブル発生時に必要な役割である「インシデントコマンダー」のについても整理しました。
- 作者:木村 誠明
- 発売日: 2020/03/21
- メディア: 単行本（ソフトカバー）
LyftとShiftの違い
言葉の定義は以下。
オンプレミスのシステム構造のままIaaSを中心にクラウド化することをLift、その後クラウドネイティブを前提にしたアーキテクチャ変更を行うことをShiftと呼ぶ。
本来はShiftを実施すべきシステムが、Liftで止まったりそもそも塩漬けにされることでシステム障害が発生した際に有識者がいなくなってしまうという意見が述べられています。そして、Shiftまで進まない背景は以下で説明されていました。
- ビジネスロジックの再構築や再テストを行う費用を捻出できない
- アプライアンス機器があるためクラウド化できない/ソフトウェアライセンスが不利になる
確かにアプリケーションをコンテナ化することができれば、移行も用意になりますしいわゆるクラウドネイティブな設計に落とし込めます。
クラウドネイティブとは「迅速な変更が行える基盤、スケール化させやすい設計、頻発する障害を見越した回復力」を採用しているアーキテクチャのこと。
以下はShiftできないことで起きうる障害発生時のポイント部分で参考になった箇所。
インシデントコマンダーの役割
作業者の上に立ち、お客様との窓口になる役割がインシデントコマンダー。同ポジションはトラブル発生時に作業者とは別に用意すべきポジションであると説明されています。
インシデントコマンダーに必要なスキルは以下
全体の方向性や透明性を確保するコミュニケーション能力（≠技術力）
インシデントコマンダーが報告を受ける際のポイントは以下。
- 報告者からの報告を受ける
- 実際に行った作業と結果の事実を確認
- 報告者が判断した部分があれば根拠を確認する
- 同情報をチーム内で共有する
この手の情報を正しく取り扱うのはPD思考として重要。
そして、インシデントコマンダーに報告する側も以下を意識するといいという話。
- 何が？（一意に特定できるような情報）
- 異常な状態とは？
- 発生時刻と現在な状況は？
- どこから持たされた情報か？
- すでに試した対応はあるか？
上記を聞いた上で、インシデントコマンダーは再現性と緊急性を確認していく流れになります。
終わりに
本書では障害検知～原因調査～業務影響調査～復旧対応と章を分けて解説しています。
現場ごとにこの手のフローは整備されていますが、それを見直すうえでも参考になる書籍でした。
