NTT DATA TECH
😱

非機能要求グレードの歩き方 Vol.9 C3障害時運用

Junichiroh Hirose
に公開
金融
障害
運用
非機能
tech

30年以上にわたり金融IT基盤に携わる中で得た経験と知識をもとに、「やらかしがちな」技術的課題について、IPA[1]の非機能要求グレード[2]に沿って解説します。
※筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。

全体構成

「非機能要求グレードの歩き方」シリーズ全体の構成は、「非機能要求グレードの歩き方 Index」を参照ください。
本記事(vol.9)では、「C.3 障害時運用」に焦点を当てて解説します。

C.3 障害時運用

中項目「C.3 障害時運用」では、システム障害に関する運用要件を定義します。
本項目の要件は、以下の定義に基づいて決まります。

  • A.1.2 業務継続性（特に A.1.2.2　サービス切替時間）
  • A.1.3 目標復旧水準（業務停止時）（特に A.1.3.2 RTO（目標復旧時間））

これらの要件は、システム構成策定に必要なものではなく、設計前提として確認すべき項目であるため、「〇: 重要項目」の指定はありません。
ただし、サポート費用など、ベンダに支払う維持保守コストに大きな影響を及ぼす可能性があるため、ベンダ選定時には、事前に十分な確認を行うことが重要です。

下表は、大項目「C 運用・保守性」-中項目「C.3 障害時運用」を抜粋したものです。

表: 「C.3 障害時運用」の小項目とメトリクス（折りたたんでいます）
大項目 中項目 小項目 メトリクス(〇: 重要項目)
C 運用
・保守性		 C.3 障害時運用 C.3.1 復旧作業 C.3.1.1 　 復旧作業
C.3.1.2 　 代替業務運用の範囲
〃 〃 C.3.2 障害復旧自動化の範囲 C.3.2.1 　 障害復旧自動化の範囲
〃 〃 C.3.3 システム異常検知時の対応 C.3.3.1 　 対応可能時間
C.3.3.2 　 駆けつけ到着時間
C.3.3.3 　 SE到着平均時間
〃 〃 C.3.4 交換用部材の確保 C.3.4.1 　 保守部品確保レベル
C.3.4.2 　 予備機の有無

以降、小項目ごとに解説します。

C.3.1 復旧作業

小項目 メトリクス(〇: 重要項目)
C.3.1 復旧作業
業務停止を伴う障害が発生した際の復旧作業に必要な労力。
 C.3.1.1 　 復旧作業
C.3.1.2 　 代替業務運用の範囲
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.3.1.1
　
復旧作業		 0: 復旧不要
1: 復旧用製品は使用しない手作業の復旧
2: 復旧用製品による復旧
3: 復旧用製品＋業務アプリケーションによる復旧

【重複項目】
A.4.1.1。復旧作業は、可用性の復旧目標（RTO/RPO）を検討するうえで必要な項目であるため、可用性と運用・保守性の両方に含まれている。
【メトリクス】
選定したレベルに応じて、ユーザ側・ベンダ側それぞれの体制や権限の整理を実施する必要がある。
【レベル】
自作ツールを利用するケースは手作業に含む。 復旧用製品とは、バックアップ・リカバリを行う製品を指す。復旧用製品による復旧を行う場合、どこまで自動化するか（自動リカバリー機能充足率など）を定義するケースもあるが、可用性としては、復旧用製品を使用するかしないかでギャップが発生するため、この観点でレベルを検討する。
C.3.1.2
　
代替業務運用の範囲		 0: 無し
1: 一部の業務について代替業務運用が必要
2: 全部の業務について代替業務運用が必要

【重複項目】
A.4.1.2。代替業務運用の範囲は、可用性の復旧目標（RTO/RPO）を検討するうえで必要な項目でもあるため、可用性と運用・保守性の両方に含まれている。
【メトリクス】
代替業務運用とは、障害によりシステムが復旧不可能となった場合に、代替業務でカバーすることが可能な運用手段（代替機あるいは人手による運用）を指す。

「A.4.1 復旧作業」に記述

  • 本項目「C.3.1 復旧作業」（「C 運用・保守性 > C.3 障害時運用」の小項目）は、
    「A.4.1 復旧作業」（「A 可用性 > A.4 回復性」の小項目）と重複項目です。
    運用保守フェーズにおける対応事項ですが、要件としては信頼性要件の方が明確であるため、本項目で具体的に記述せず、「A.4.1 復旧作業」参照と記載することを推奨します。

メトリクスの対応

  • C.3.1.1 復旧作業（A.4.1.1 復旧作業）
    システム障害により、最悪の場合システムやデータが失われたケースを想定し、
    システム復旧に必要となる作業の全体像を定義します。
    BCPと対比してSystem Continuity Plan（SCP）ということもあります。
  • C.3.1.2 代替業務運用の範囲（A.4.1.2 代替業務運用の範囲）
    いわゆる、Business Continuity Plan（BCP）に相当する、
    障害によりシステムが復旧不可能となった場合の業務運用を定義します。

📌高信頼ならベーシックリカバリ(BR)が必要

「A.1.3.2 RTO（目標復旧時間）」を厳守することが求められる高信頼なシステムは、ベーシックリカバリの整備が望まれます。
ベーシックリカバリ[3]は、以下の２つの方法論からなります。

  • ベーシックリカバリ手順:
    故障原因が特定・確定できない状況下で、被疑箇所を初期化することにより、原因を除去し復旧を試みる手順です。
    要するに、再起動やフェイルオーバーを試すことで復旧を図る方法ですが、二次障害を防ぐために、あらかじめ確実かつ安全な初期化手順を準備しておくことが重要です。（参考: あったら怖い本当の話）

    • 再起動時の注意点
      特に、DBサーバや共有ストレージなどの永続データの原本を扱う機器は、障害発生時に不用意に再起動すると、データ破損や仕掛中電文の喪失などの二次障害を招く恐れがあります。
      安全に再起動するためには、喪失してはならないキャッシュデータを確実に永続化したうえで、再起動する必要があります。
    • 冗長化構成を持つ機器の対応
      冗長化構成をとっているAPサーバやNW機器が半死に状態（起動しているが機能していない状態）の場合、片系ずつの再起動では悪循環構造から抜け出せずに復旧しないことがあります。
      確実に復旧するベーシックリカバリ手順としては、両系の停止＆起動に加え、接続先が保持する接続状態の復旧を含む手順が必要となります。

  • ベーシックリカバリ運用:
    故障原因が特定・確定できない状況下で「A.1.3.2 RTO（目標復旧時間）」を遵守するために、残された時間とオペレーションにかかる時間を考慮し、実施するオペレーションを判断する運用手法です。

    • 障害発生時の判断フロー
    1. 故障原因にあたりがつけば、即座に原因を排除し、システム復旧作業に着手します。
    2. 原因不明の状態が続く場合、以下の基準で「ベーシックリカバリ手順」の発動を判断します。
      1. 復旧時限確認：業務影響度を把握し、障害レベルを判断
        → 障害対応に必要な体制（エスカレーションレベル）を決定
      2. 被疑箇所特定：被疑箇所を特定するオペレーションを実施
        → 半死に状態（起動はしているが機能していない）で、エラーログやリソース不足が見当たらない場合でも、稼働機能と不具合が発生している機能の関係性を確認し、被疑箇所を特定する手順が必要
      3. BR発動判断：RTOとベーシックリカバリ手順にかかる時間を考慮し、リスクを加味して発動判断
        → ベーシックリカバリ手順の発動は、最終段階に位置付けられる

C.3.2 障害復旧自動化の範囲

小項目 メトリクス(〇: 重要項目)
C.3.2 障害復旧自動化の範囲
障害復旧に関するオペレーションを自動化する範囲に関する項目。
 C.3.2.1 　 障害復旧自動化の範囲
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.3.2.1
　
障害復旧自動化の範囲		 0: 障害復旧作業は全て手動で実施する
1: 一部の障害復旧作業を自動化する
2: 全ての障害復旧作業を自動化する

【レベル1】
一部の障害復旧作業とは、特定パターン（あるいは部位）の障害復旧作業に関してのみ自動化を行うようなケースを指す。
【運用コストへの影響】
障害復旧作業を自動化するためには、障害のパターン毎に複雑な判断を行うスクリプトを作成する必要があり開発コストが増大する。一方、障害発生時の復旧作業が迅速化され、ミスも少なくなるため運用コストは減少する。

「A.1.2.2 サービス切替時間」から自明

  • 本項目「C.3.2 障害復旧自動化の範囲」は、「A.1.2.2 サービス切替時間」（「A 可用性 > A.1 継続性 > A.1.2 業務継続性」のメトリクス）から自ずと定まります。
    具体的には、機器や処理の種類毎に、サービス切替時間要件に応じた対策を定義します。
    以下に、サービス切替時間のレベルごとに、想定される障害復旧自動化の対策レベルを示します。
    A.1.2.2 サービス切替時間 対策レベル：C.3.2 障害復旧自動化の範囲
    レベル5: 60秒未満 レベル2：冗長化構成（障害検知からサービス切替まで自動化）
    レベル4: 10分未満 レベル2：自動再起動（仮想サーバーやコンテナの実現レベル）
    レベル3: 60分未満 レベル1：自動復旧コマンド入力
    （常駐オペレーターの機械的判断による運用手順）
    レベル2: 2時間未満 〃
    レベル1: 24時間未満 レベル0：予め手順化された手動の復旧作業で対応可能
    レベル0: 24時間以上 レベル0：手動の復旧作業で対応

C.3.3 システム異常検知時の対応

小項目 メトリクス(〇: 重要項目)
C.3.3 システム異常検知時の対応
システムの異常を検知した際のベンダ側対応についての項目。
 C.3.3.1 　 対応可能時間
C.3.3.2 　 駆けつけ到着時間
C.3.3.3 　 SE到着平均時間
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.3.3.1
　
対応可能時間		 0: ベンダの営業時間内（例：9時～17時）で対応を行う
1: ユーザの指定する時間帯（例：18時～24時）で対応を行う
2: 24時間対応を行う

【メトリクス】
システムの異常検知時に保守員が作業対応を行う時間帯。
C.3.3.2
　
駆けつけ到着時間		 0: 保守員の駆けつけ無し
1: 保守員到着が異常検知から数日中
2: 保守員到着が異常検知からユーザの翌営業日中
3: 保守員到着が異常検知からユーザの翌営業開始時まで
4: 保守員到着が異常検知から数時間内
5: 保守員が常駐

【メトリクス】
システムの異常を検出してから、指定された連絡先への通知、保守員が障害連絡を受けて現地へ到着するまでの時間。
C.3.3.3
　
SE到着平均時間		 0: SEの駆けつけ無し
1: SE到着が異常検知から数日中
2: SE到着が異常検知からユーザの翌営業日中
3: SE到着が異常検知からユーザの翌営業開始時まで
4: SE到着が異常検知から数時間内
5: SEが常駐

【メトリクス】
システム異常を検知してからSEが到着するまでの平均時間。

高信頼ほど高コスト

  • 小項目「C.3.3 システム異常検知時の対応」では、システム障害が発生した際の対応要件を記述します。
    非機能要求グレードとしては、メトリクスとしてベンダ保守体制に関する要件を挙げていますが、小項目としては、ベンダだけでなく、ユーザ部門やシステム部門の連携体制も併せて明確にする必要があります。

  • 本項目は2018年版で追加された項目のため、公式なレベル選定の例が存在しないため、以下に2009年版相当の目安を参考として提示します。

    社会的影響が
    殆ど無いシステム    		 社会的影響が
    限定されるシステム    		 社会的影響が
    極めて大きいシステム
    C.3.3.1
    対応可能
    時間    		 0: ベンダの営業時間内
    　（例：9時～17時）
    　で対応を行う    		 1: ユーザの指定する時間帯
    　（例：18時～24時）
    　で対応を行う    		 2: 24時間対応を行う
    　
    .
    C.3.3.2
    駆けつけ
    到着時間    		 保守員到着
    0: 保守員の駆けつけ無し
    1: 数日中    		 2: ユーザの翌営業日中
    3: ユーザの翌営業開始
    　時まで    		 4: 数時間内
    5: 保守員が常駐
    .
    C.3.3.3
    SE到着
    平均時間    		 SE到着
    0: SEの駆けつけ無し
    1: 数日中    		 2: ユーザの翌営業日中
    3: ユーザの翌営業開始
    　時まで    		 4: 数時間内
    5: SEが常駐
    .

    用語定義と補足

    • 保守要員（CE：Customer Engineer）：ハードウェア(HW)やミドルウェア(MW)などの製品レベルの保守サポートを担う。HWはHW部品交換ができる要員。
    • SE（System Engineer）：アプリケーション（AP）やシステム基盤など個々のシステムに精通し、障害時の原因分析や対応判断を行う技術者。
    • 「駆けつけ」の読み替え：本項目を定めた2018年当時は、障害対応には現地への物理的到着が前提でしたが、コロナ禍（2019/12発生）を経て、リモート対応が一般化したため「作業着手までの時間」に読み替えることが適切です。

📌高信頼システムの場合

  • 24/365迅速な有識者対応(万難を排したシステム復旧) を要件とすると、非常に高コストになります。
    たとえば、8時間×3交代制で週休・年休を考慮する場合、最低でも7名以上の有識者体制が必要となります。
  • システムは通常、多数の製品や機能の組み合わせで構成されているため、すべての構成要素に対して24/365の即時対応を求めるのは費用対効果の面で現実的ではありません。
  • そのため、以下のように機能の役割や重要性に応じて、復旧対応レベルにメリハリをつけることが必要となります。
分類 代表例 要求レベル 理由
統制・SE SE 24/365迅速な対応 ・障害対応における適切なオペレーション判断と指示が必要なため
原本データを扱う製品 DB、ストレージ、メッセージングなど 同上 ・暫定復旧しなければシステム復旧しないため
・対応ミスによるデータ破壊などの二次障害を引き起こした際の影響が甚大なため
（製品バグ等による障害の場合、安全なはずのベーシックリカバリ手順でもデータ破損を伴うことがある）
複製データを扱う製品 参照用のDB・ファイルサーバなど 平日日中
数時間で対応開始		 ・SE判断による再起動やデータリストアなどのベーシックリカバリ手順で、暫定復旧できる可能性が高いため
永続データを管理しない製品 NW機器、Webサーバ、APサーバ、OSなど 同上 ・SE判断による再起動などのベーシックリカバリ手順で、暫定復旧できる可能性が高いため

※ベーシックリカバリ手順：「C.3.1 復旧作業」参照

C.3.4 交換用部材の確保

小項目 メトリクス(〇: 重要項目)
C.3.4 交換用部材の確保
障害の発生したコンポーネントに対する交換部材の確保方法。
 C.3.4.1 　 保守部品確保レベル
C.3.4.2 　 予備機の有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.3.4.1
　
保守部品確保レベル		 0: 確保しない
1: 保守契約に基づき、部品を提供するベンダが規定年数の間保守部品を確保する
2: 保守契約に基づき、保守を提供するベンダが当該システム専用として規定年数の間保守部品を確保する

【メトリクス】
当該システムに関する保守部品の確保レベル。
C.3.4.2
　
予備機の有無		 0: 予備機無し
1: 一部、予備機有り
2: 全部、予備機有り

システムライフとサポート期間のギャップ対策を記述

  • 小項目「C.3.4 交換用部材の確保」では、「C.5.3.1 ライフサイクル期間（〇：重要項目）」と、サポート期間のギャップ対策を記述します。
  • メトリクス「C.3.4.1 保守部品確保レベル」は、HW交換部品の確保をイメージさせる表現となっていますが、本項目ではソフトウェアも含むライフサイクル管理全体の要件（サポート期間に関する全般の要件）を記載します。

高信頼業務システムにおける課題

  • 特に、金融機関の基幹系システムなど、大量のAP資産を抱える高信頼業務システムでは、製品のバージョンアップに伴うリグレッション試験のコストが非常に大きいため、同一バージョンの製品（特にミドルウェア）を長期間利用する方針が長年採用されてきました。
  • しかし、近年、クラウドの普及により、製品やサービスのサポート期間が短くなる傾向が強まっており、以下のようなシステムライフ自体の概念を再構成する方針も登場しています。
    • システムライフの途中でバージョンアップする
    • CI/CD（継続的インテグレーション／継続的デリバリー）対応により、定期的にバージョンアップと包括パッチを適用する

あったら怖い本当の話

※　実際に起きたことを、脱色デフォルメしたフィクションにして紹介します。

😱もう少し早く両系再起動を指示していれば…

成功報酬型SLA

  • 4年間にわたり、RTO（目標復旧時間）5時間以内を維持できれば成功報酬が発生するという、SIと運用をセットにした契約でした。

障害原因

対象のサーバは、syslogをリモート保守サイトへ転送することで、迅速なハードウェア保守サポートを提供する高信頼なサーバでした。
しかし、リモート監視回線の障害により、サーバ筐体内のリモート転送領域があふれ、syslog出力が停止していました。
最終的には、電源OFFで転送領域がクリアされ、復旧しました。

敗因

今回、全4回の復旧オペレーションのうち、3回目の時点で最終手段（電源OFF再起動）を判断していれば、SLAを達成できていました。
各オペレーションの判断から結果確認までに約1時間かかることは把握していましたが、緊迫した状況下で段階的な切り分けを優先し、「RTOを意識した判断ができなかった」 ことが、最終的にRTO超過の要因となりました。

再発防止

原因が特定できない状況でも、RTOを遵守できるようベーシックリカバリを整備しました。
復旧優先度や判断のトリガーを事前に明文化し、時間的余裕がない状況でも迷わず行動できるオペレーション基準として活用しています。

まとめ

本記事では、高信頼なシステムにはベーシックリカバリが必要となることを説明しました。

最後に、NTTデータの金融高度技術本部では、ともに金融ITの未来を切り拓く仲間を募集しています。

[募集要領]
https://nttdata-career.jposting.net/u/job.phtml?job_code=1172
[NTTデータ 金融分野の取り組み]
https://www.nttdata.com/jp/ja/industries/finance/

脚注

  1. IPA: 独立行政法人 情報処理推進機構 (Information-technology Promotion Agency, Japan) ↩︎

  2. 非機能要求グレード:
    参照用pdf: 非機能要求グレード2018 改訂情報(PDF:897 KB)
    活用用xls: 非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)の　06‗活用シート.xls
    ↩︎

  3. ベーシックリカバリ:NTT DATAが提唱した長時間停止を防ぐための方法論
    ・PM学会論文: システム故障の早期復旧を目指した「ベーシックリカバリ」の検討
    　-NTTデータにおけるシステム故障長時間化防止への取り組み-
    　Study On ”Basic Recovery” Aiming For Early Recovery Of System Failure
    　-Efforts To Prevent Long-Term System Failure In NTT DATA-
    ・Qiita解説記事: ベーシックリカバリという考え方と実践 ↩︎

NTT DATA TECH
NTT DATA TECH

NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。

設定によりコメント欄が無効化されています