Zenn
NTT DATA TECH
😱

非機能要求グレードの歩き方 Vol.7 C2保守運用(前半)

Junichiroh Hirose
に公開
金融
保守
運用
非機能
idea

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

全体構成

「非機能要求グレードの歩き方」シリーズ全体の構成は、「非機能要求グレードの歩き方 Index」を参照ください。
本記事(vol.7)では、Vol.8と併せて「C.2 保守運用」に焦点を当てて解説します。
四半期ごとパッチ数

C.2 保守運用

中項目「C.2 保守運用」では、システムを維持するために必要な保守作業の要件を定義します。

📌現状の運用方法も要件の一部

現状の運用方法は、 既存の手法を踏襲する場合はもちろん、改善や抜本的な見直しを行う際にも、重要な基準となります。
特に、新たな発注先を検討する際には、要件として運用引継ぎに必要な資料の提示が不可欠です。

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

表: 「C.2 保守運用」の小項目とメトリクス（折りたたんでいます）
大項目 中項目 小項目 メトリクス(〇: 重要項目)
C 運用・保守性 C.2 保守運用 C.2.1 計画停止 C.2.1.1 ○ 計画停止の有無
C.2.1.2 　 計画停止の事前アナウンス
〃 〃 C.2.2 運用負荷削減 C.2.2.1 ○ 保守作業自動化の範囲
C.2.2.2 　 サーバソフトウェア更新作業の自動化
C.2.2.3 　 端末ソフトウェア更新作業の自動化
〃 〃 C.2.3 パッチ適用ポリシー C.2.3.1 　 パッチリリース情報の提供
C.2.3.2 　 パッチ適用方針
C.2.3.3 　 パッチ適用タイミング
C.2.3.4 　 パッチ検証の実施有無
〃 〃 C.2.4 活性保守 C.2.4.1 　 ハードウェア活性保守の範囲
C.2.4.2 　 ソフトウェア活性保守の範囲
〃 〃 C.2.5 定期保守頻度 C.2.5.1 　 定期保守頻度
C.2.6.1 　 予防保守レベル
〃 〃 C.2.6 予防保守レベル C.2.6.1 　 予防保守レベル

以降、小項目ごとに解説します。
なお、中項目「C.2 保守運用」で1万文字を大幅に超えるため、2つの記事に分割しました。
後半の小項目「C.2.4」「C.2.5」「C.2.6」については、Vol.8を参照ください。

C.2.1計画停止

小項目 メトリクス(〇: 重要項目)
C.2.1 計画停止
点検作業や領域拡張、デフラグ、マスターデータのメンテナンス等、システムの保守作業の実施を目的とした、事前計画済みのサービス停止に関する項目。		 C.2.1.1 ○ 計画停止の有無
C.2.1.2 　 計画停止の事前アナウンス
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
C.2.1.1
○
計画停止の有無		 0: 計画停止有り（運用スケジュールの変更可）
1: 計画停止有り（運用スケジュールの変更不可）
2: 計画停止無し

【重複項目】A.1.1.3。
計画停止の有無は、システムの可用性の実現レベルを表す項目でもあるため、重複項目となっている。
【運用コストへの影響】
計画停止有りの場合、事前のバックアップや、システム構成に応じた手順準備など、運用時のコストがかさむ。
C.2.1.2
　
計画停止の事前アナウンス		 0: 計画停止が存在しない
1: 計画停止は年間計画によって確定する
2: 1ヶ月前に通知
3: 1週間前に通知
4: 前日に通知

【運用コストへの影響】
計画停止が存在する場合、利用者への通知や運用スケジュールの変更など、イレギュラーな対応が発生する。それらを短時間で実現しなければならないほど、システムの例外処理に対する作り込みを慎重に実施する必要があると考えられ、導入コストが増大すると考えられる。
一方、運用コストに関してはその作り込みによって例外処理に対する運用が簡略化されるため減少すると考えられる。

運用スケジュール[A.1.1]に記述

  • 本項「計画停止」では、計画停止の事前アナウンスを含む、計画停止を実施する際の運用要件について整理します。
  • 但し、「C.2.1.1 計画停止の有無」のメトリクスは「A.1.1 運用スケジュール」と重複しているため、計画停止の有無や頻度については小項目「運用スケジュール[A.1.1]」に記述し、本項ではその参照にとどめることを推奨します。

C.2.2 運用負荷削減

小項目 メトリクス(〇: 重要項目)
C.2.2 運用負荷削減
保守運用に関する作業負荷を削減するための設計に関する項目。
 C.2.2.1 ○ 保守作業自動化の範囲
C.2.2.2 　 サーバソフトウェア更新作業の自動化
C.2.2.3 　 端末ソフトウェア更新作業の自動化
メトリクス内容（折りたたんでいます）
項番
メトリクス		 備考の【メトリクス】の抜粋、レベル
C.2.2.1
○
保守作業自動化の範囲		 0: 保守作業は全て手動で実施する
1: 一部の保守作業を自動で実行する
2: 全ての保守作業を自動で実行する

【メトリクス】
保守作業とは、保守運用に伴うシステム基盤を維持管理するための作業を指し、点検作業やパッチ適用等のアップデート作業、領域拡張、デフラグ、ログローテート等を想定している。障害対応や復旧作業などは含まない。
【運用コストへの影響】
システム基盤の保守運用作業を自動化するためには、特別な運用管理ツールを導入したり、さまざまな作り込みを実施する必要がある。
そのため導入コストは増大するが、ユーザが実施すべき保守運用作業が簡略化あるいはなくなると考えられるので、運用コストは減少する。
C.2.2.2
　
サーバソフトウェア更新作業の自動化		 0: サーバへの更新ファイル配布機能を実装しない
1: サーバへの更新ファイル配布機能を実装し、手動にて配布と更新処理を実行する
2: サーバへの更新ファイル配布機能を実装し、自動で配布したのち、更新処理を手動で実行する
3: サーバへの更新ファイル配布機能を実装し、配布と更新処理を自動で実行する

【メトリクス】
サーバソフトウェアとは、サーバ機器のOSやストレージのファームウェア、サーバ機器上で動作するミドルウェアやアプリケーションを指す。
【運用コストへの影響】
サーバへの更新ファイルの配布や更新処理を自動化するためには、特別なツールを導入したり作り込みを実施する必要があるため導入コストは増大する。
一方、サーバソフトウェアの更新作業が自動化されることでユーザが運用中に実施すべき作業がなくなり、運用コストは減少する。
C.2.2.3
　
端末ソフトウェア更新作業の自動化		 0: 端末への更新ファイル配布機能を実装しない
1: 端末への更新ファイル配布機能を実装し、手動にて配布と更新処理を実行する
2: 端末への更新ファイル配布機能を実装し、自動で配布したのち、更新処理を手動で実行する
3: 端末への更新ファイル配布機能を実装し、配布と更新処理を自動で実行する

【メトリクス】
端末ソフトウェアとは、クライアント端末のOSやネットワーク機器のファームウェア、クライアント端末上で動作するアプリケーションを指す。
【運用コストへの影響】
端末への更新ファイルの配布や更新処理を自動化するためには、特別なツールを導入したり作り込みを実施する必要があるため導入コストは増大する。
一方、端末の更新作業が自動化されることでユーザが運用中に実施すべき作業がなくなり、運用コストは減少する。

📌CI/CD、DevOps、IaC、SREなど

  • 本項「運用負荷削減」では、自動化など保守運用の効率化に関する要件について整理します。
  • また、既存の統合基盤の利用要件に加え、近年普及している以下のような保守運用に関連する技術やアプローチを適用する場合の要件についても、本項に記載します。
    • CI/CD（Continuous Integration / Continuous Delivery）
      継続的インテグレーションとデリバリーで、手作業を削減し、迅速なリリースを実現
      テストの自動化や環境の統一により、開発と運用の負担を軽減
    • DevOps（Development（開発） と Operations（運用）を組み合わせた造語）
      開発と運用の連携を強化し、スムーズなデプロイを実現
      CI/CDやIaCと密接に関連し、継続的な改善と効率化を促進する。組織変革を含む概念
    • IaC（Infrastructure as Code）
      インフラ構成をコード化し、バージョン管理や自動適用を可能にする
      CI/CDに組み込むことでインフラの保守運用を効率化
    • SRE（Site Reliability Engineering）
      Googleが提唱したシステム運用の手法
      DevOpsの実践方法の一つ、システムの信頼性向上に重点

C.2.3 パッチ適用ポリシー

小項目 メトリクス(〇: 重要項目)
C.2.3 パッチ適用ポリシー
パッチ情報の展開とパッチ適用のポリシー
に関する項目。
 C.2.3.1 　 パッチリリース情報の提供
C.2.3.2 　 パッチ適用方針
C.2.3.3 　 パッチ適用タイミング
C.2.3.4 　 パッチ検証の実施有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 備考の【メトリクス】の抜粋、レベル
C.2.3.1
　
パッチリリース情報の提供		 0: ユーザの要求に応じてベンダが受動的にパッチリリース情報を提供する
1: ベンダが定期的にユーザへパッチリリース情報を提供する
2: ベンダがリアルタイムに（パッチリリースと同時に）ユーザへパッチリリース情報を提供する
C.2.3.2
　
パッチ適用方針		 0: パッチを適用しない
1: 推奨されるパッチのみを適用する
2: 全てのパッチを適用する

【メトリクス】
リリースされるパッチが個別パッチであるか、集合パッチであるかによって選択レベルが変わる場合は、個別に合意する必要がある。
セキュリティパッチについては、セキュリティの項目でも検討すること（E.4.3.2）。
C.2.3.3
　
パッチ適用タイミング		 0: パッチを適用しない
1: 障害発生時にパッチ適用を行う
2: 定期保守時にパッチ適用を行う
3: 新規のパッチがリリースされるたびに適用を行う

【メトリクス】
リリースされるパッチが個別パッチであるか、集合パッチであるかによって選択レベルが変わる場合は、個別に合意する必要がある。
セキュリティパッチについては、セキュリティの項目でも検討すること（E.4.3.3）。
C.2.3.4
　
パッチ検証の実施有無		 0: パッチ検証を実施しない
1: 障害パッチのみパッチ検証を実施する
2: 障害パッチとセキュリティパッチの両方でパッチ検証を実施する

パッチの種類ごとに頻度を含む適用方針を定める

  • 本項「パッチ適用ポリシー」では、メトリクスにあるパッチのリリース通知[C.2.3.1]、適用方針[C.2.3.2]、適用タイミング[C.2.3.3]、受入検証[C.2.3.4]を含むパッチ関する運用要件全般について記述します。
  • パッチの提供方式は製品ごとに異なるため、要件としては、以下のパッチの種類ごとに統一的なパッチ適用ポリシーを定め、設計段階で製品や環境に応じた具体的な運用方針を定めます。

パッチの種類

パッチは主に以下の3種類に分類されます。
セキュリティパッチ 脆弱性修正によるシステム保護を目的としたパッチ
バグフィックス 不具合修正を目的としたパッチ
機能改善パッチ 既存機能の強化や最適化を目的としたパッチ

また、大きく以下の２つの提供単位があります
個別パッチ 特定のインシデントに対応したパッチ
通常、インシデント対応を優先して提供するため、一定デグレードリスクが残っている
包括パッチ 複数の個別パッチをまとめたパッチセット
通常、包括的リグレッション試験を経て製品出荷レベルの品質が確保されている

パッチの提供方法

パッチの提供方法は製品ごとに異なります。特に以下の観点の違いに留意する必要があります。
1.セキュリティパッチの条件 バグフィックスや機能改善パッチと分けて提供されるか
2.バグフィックスの条件 個別のバグフィックスを提供するか、包括パッチを提供するか
3.包括パッチの条件 提供頻度、包括的リグレッション試験の有無（パッチの品質）
4.詳細情報の提供 重要度が示されるか、バグなどパッチが必要となった理由や
対応内容の詳細情報が提供されるか
5.個別対応の有無 重要パッチの通知サービスの提供など、サポートの充実度

📌非常に高い信頼性を求める場合

非常に高い信頼性を求めるシステムでは、パッチ適用に伴うデグレードリスク対策が不可欠です。
これを確実に実施するには、利用する製品やサービスに対して以下の要件を満たすことが望まれます。

  1. セキュリティパッチの独立提供

    • セキュリティパッチに機能変更を含まず、包括的リグレッション試験なしで速やかに適用可能なこと。
    • 注意点
      認証などのセキュリティ対策機能に対するセキュリティパッチは、機能変更を伴うことを避けられないことがあります。
      このため、リグレッション試験を局所化できるよう、ユーザインタフェースや業務処理など他の機能からセキュリティ対策機能を独立した構成とすることが望まれます。

  2. 障害対応のための個別バグフィックス提供

    • バグによる重大インシデントが発生した際、個別バグフィックスを提供できること。
    • 個別バグフィックスを提供するプロセスとして、以下の運用に対応すること：
      1. インシデント内容を踏まえた暫定版バグフィックスを提供
      2. システム側で受入れ試験を実施し、改修の有効性とデグレードリスクを評価
      3. 課題があった場合1.に戻る。問題なければ確定版の個別パッチとして提供する

  3. 予防保守のための包括パッチ提供

    • 定期的に、製品出荷レベルの試験に合格した包括パッチを提供すること。
      （複数製品のリグレッション試験を計画するには、包括パッチの提供時期を事前に把握しておくこ必要があります。）
    • 受け入れシステム側のリグレッション試験で問題が発生した場合を考慮した、以下の運用に対応すること：
      • 包括パッチに対する、個別バグフィックス作成に対応すること。
      • 包括パッチ適用を複数回見送りできること。

  4. パッチの内容（重要度や詳細情報）の提示
    利用者が適用要否を判断できるよう、以下の情報を提示すること：

    • システム側で対応要否を容易に判断できるよう参考情報として、包括パッチに含まれる個々のパッチの重要度を提示すること。
    • システム側で対応要否を判断できるよう、全てのパッチについて、対応した問題の概要、および影響範囲を提示すること。
    • システム側で対応要と判断したパッチに対して、ワークアラウンド（回避策）を策定できるよう指定したパッチについて、詳細な問題の発生条件、および改修内容を提示すること。

  5. 利用システムに即した重要パッチの選定と通知サービス

    • 製品ベンダからの迅速な通知:
      ・影響のあるシステムを判定するには、製品ベンダ側で各システムが使用している機能を予め把握しておくことが必要。
      ・重要なパッチが作成された際、システム側で速やかに対応できるよう、重要な個別パッチ作成段階で通知を行う。（包括パッチ適用時では間に合わない可能性があるため。）
    • 通知には重要度と使用機能との関係を含める:
      ・製品内部仕様を理解していないシステム利用者でも迅速に対応の必要性を判断できるよう通知に重要度が必要。
      ・システム側では、当該機能についてパッチが影響する使い方をしているか、およびパッチが対応した問題が顕在化した際の影響に基づき、対応要否を判断し対処する。

あったら怖い本当の話

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

要件と実装

  • 保守運用要件（パッチ適用ポリシー）

    • セキュリティパッチ：緊急度の高いものは、リスク評価に基づき速やかに適用する。
    • バグフィックス　　：3ヵ月ごとに重要なパッチの棚卸を実施し、
      　　　　　　　　　　6ヶ月ごとに必要なパッチを適用する。
    • 機能改善パッチ　　：原則、適用しない。

  • パッチ適用運用（厳選した個別パッチを適用）
    基本方針: 包括パッチは、大量の修正を含むため、基本的に適用せず、
    　　　　　厳選した少数の個別パッチを適用する。
    製品ベンダとコンサル契約を締結し、以下の予防保守運用を構築。

    1. 3ヶ月ごとに新たに発表されたバグとパッチを評価し、
      システムの安定運行に支障をきたす可能性のあるものを抽出。
    2. 抽出したパッチの中から、発生リスクの高い個別パッチを特定。
    3. 第1-2四半期の棚卸結果をもとに、第3四半期に試験環境に適用する。
      第3-4四半期も同様に、翌第1四半期に適用する。

  • パッチ適用運用状況
    当該システムで利用しているバージョンの製品からは、四半期ごとに、包括パッチとして
    多数のパッチがコンスタントに提供されていました。
    そのうち、厳選した個別パッチを半期に数件、本番環境に適用していました。

    分類 数 説明
    個別パッチ 数百件 四半期毎の包括パッチに含まれる総数
    重要なパッチ 数十件 個別パッチの中で、システムの安定運行に支障をきたす
    リスクが高いもの
    対応必須パッチ 十件程度 重要なパッチの中で、データ破壊、結果不整合、システム
    再起動不可など致命的問題を起こす可能性があるもの

四半期ごとパッチ数
実際の製品の包括パッチに含まれる個別パッチを仕訳けた結果

😱個別パッチのデグレードで障害

システムは数年安定稼働を続けていました。

敗因

そもそも、パッチを極力少なくできるよう厳選した個別パッチを適用する方針が誤りでした。
予防保守としては品質を確保した包括パッチ適用する方針が適切でした。

  • 受入れ試験不足: パッチで改修したバグの観点のデグレード試験のみを実施し、網羅的な試験を行わなかったため、問題を検出できませんでした。
  • パッチの品質に対する認識不足: 製品ベンダは、緊急対応用として個別パッチを提供し、予防保守用として包括パッチを提供していました。
    そのため、網羅的なデグレード試験は、個別パッチ提供時には実施されず、包括パッチ提供時にのみ行われていました。

再発防止

以下のように予防保守として行うパッチ適用方針を見直し、社内ガイドラインとしました。

  1. パッチの仕訳け
    予防保守として、対応が必要なパッチを適切に分類（従来通りの運用）。
  2. 拙速な適用の回避
    抽出したパッチをすぐに適用せず、まずはワークアラウンドを実施。
  3. 包括パッチの適用
    パッチ適用時は、製品ベンダが製品出荷レベルの品質を確保した「包括パッチ」 を使用。
    受け入れ試験として網羅的なデグレード試験を実施したうえで適用。
  4. 重要なシステムの場合、切戻し手段を確保
    自らインストールした製品は、パッチ適用前のバックアップにロールバックする。
    PaaS (Platform as a Service) など、パッチ適用前にロールバックできない場合は、環境を2面持ち、パッチ適用前の面に切り替え可能な構成とする。

まとめ

本記事では、新システムの要件として、保守運用の要件、特に現状の運用方法を提示することの重要性と、パッチにもデグレードリスクがあることについて説明しました。

最後に、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
    ↩︎

NTT DATA TECH
NTT DATA TECH

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

Discussion