はじめに
システム開発のプロジェクトに参画していると、運用設計漏れや誤りを原因とするトラブルに遭遇することが多くあります。運用設計漏れや誤りはシステムの重大エラー見逃しにもつながり、システムを提供するお客様の社会的価値の損失になりかねません。それほど重要な設計要素であるにも関わらず、運用設計が多くのプロジェクトで軽視されている現実を見てきました。
なぜ、軽視されてきたのでしょうか。100のシステムがあれば100通りのシステム運用があり、運用設計の内容はプロジェクトごとに異なります。運用設計に関する検討項目が標準化されておらず、フレームワークが存在しないことも一因でしょう。運用要件は非機能要件であることに加えて、システムの個別要素が多く、定形運用に集約されるわけでもないことから見える化しずらい要素であるといえます。
一方、運用設計書として検討すべき項目は最大公約数的に考えることで共通化できると考えています。今回はシステム基盤から見た運用設計を中心に、共通化可能な検討項目について、設計書に盛り込むべき運用設計項目の目次サンプルを示し設計ポイントを解説したいと思います。
実際にあったトラブル
まずは運用設計漏れにより発生したトラブル例を見てみましょう。
syslogファイルをローテーションさせず、syslogファイルにログが出力され続ける状況のサーバーがありました。そのまま運用すると、syslogファイルはパーティション容量一杯まで拡張し続け、ついにはログ出力ができなくなります。それが「/」領域だった場合は、何が起こるでしょうか。OSがフリーズしログインができなくなる可能性もあり、何より正常な運用を続けることはできないでしょう。ディスクの空き容量を監視していれば未然に防げなくもないですが、そういう話ではありません。ログ管理設計の不備によるトラブルと言えるでしょう。ログ管理設計を運用設計項目として定義し、必要な設計をしていれば避けられたトラブルです。
このような、一見検討していて当然と思われる内容ですら、運用設計として検討すべき内容であることを理解していないプロジェクトが多いのです。
一般的なシステム開発プロセス
運用設計の検討プロセスを理解するには、一般的なシステム開発プロセスの理解が必要です。まずは教科書的なシステム開発プロセスを確認します。
ウォーターフォールモデルにおけるシステム開発プロセスは上段に示す「要件定義～保守・運用」までの流れで説明されることが多いと思います。しかし、このモデルは工程の最終段階に「保守・運用」が示されているため「保守・運用」に関する検討を最終プロセスで行うものと誤解を与える原因となっています。運用設計が「設計」工程に含まれていることを理解せず、必要な設計がされていないためサービス開始直前に運用に対する必要な検討が大幅に不足しているといった事態になったプロジェクトを数多く見てきました。
運用設計プロセスの重要性
多くのエンジニア、プロジェクトで曖昧とされている運用設計プロセス明確化のために、以下に示す緑色の「運用設計」を意識した開発プロセスを定義する必要があるでしょう。
そして、設計と運用設計の内容には、次の例で示すような相関関係となるものが多く存在します。
ログ管理設計の例で見てみましょう。
ログ管理設計ではログがどのように「運用」されるのかを設計します。設計要素の一例に「ログローテーション間隔」や「保持期限」があります。一方「これを実現するため」の設計をしなければなりません（システム開発では処理方式設計と呼びます）。仮にLinuxを採用するのであれば、Linuxの処理方式設計で検討する必要があり、Linuxの設計に対する入力となります。逆もまた然りで、通常、Linuxの各種ログはバックアップを取得すると思いますので、対象となるsyslogのバックアップフォルダを運用設計担当者へ伝えなければなりません。
依頼やヒアリングの関係が運用設計と処理方式どちらから行うかは状況次第ですが、運用設計者と処理方式設計者でウォークスルーを通して、双方で設計内容に対する認識齟齬をなくすことが重要です。
運用スクリプトの洗い出し
ここで大切なポイントがあります。運用設計側に伝えられたバックアップ要件の詳細はどのように実現するのでしょう。一例としては、ジョブネットに組み込み、日次ジョブとして夜間に実行するケースが考えられます。
※バックアップ製品のスケジューラーで実装する場合もあるかと思いますが、今回はジョブネットを利用するケースで考えます。
ジョブネットに登録されている個別のジョブを実行するにはスクリプトが必要となります。この例であれば、バックアップの個別ジョブの実行スクリプトに「/xx/xx/script/AB001backup.sh」のようなフルパスでスクリプト名を指定することになるでしょう。つまり、登録するジョブの数分だけ、スクリプトが必要になるということです。
運用スクリプト洗い出しには、運用設計自身から導かれるものと、この例で見るLinux製品における処理方式設計から入力を受けるものとに分かれます。システム開発を多く見てきた経験から、運用スクリプトの洗い出しは運用設計で行うべきと考えます。システム開発プロセスにおけるテスト工程までにスクリプトの単体テストまで完了できれば、その後も本番環境と利用したテスト工程で段階的（結合テスト／システムテスト／運用テスト）に品質を積み上げていくことで可能となるからです。
このプロセスで考えられていないプロジェクトが多く、サービス直前になってスクリプトが不足しているだとかジョブネットが動かないなどが発覚し「想定通り」トラブルとなるシステムがあとを絶ちません。運用スクリプト作成まで見込んで、運用設計を計画する必要があります。
運用設計の全体像
システム運用とは「システムの利用者へ、提供しているサービスを停止することがないように、システムを維持管理していくこと」と言えるでしょう。
実現するための設計が運用設計となりますが、まずは運用設計の全体像を確認します。次に示す3つの区分に分けて考えると理解しやすいでしょう。
| 区分 | 検討項目／設計例 | 留意事項 |
| 業務運用設計 | ・オンライン処理、バッチ処理エラー時の対処方針（異常終了発生時の復旧方針） ・外部連携データ取込対応方針（連携データが存在しない場合や取り込みエラーの処理方針） ・運用で必要となるスクリプトを洗い出す | エラー時の対処内容によっては運転スケジュール、ジョブネットへ影響（例 バッチ処理再実行によるジョブネット延伸時の運転スケジュール調整、修正など）がある。システム基盤メンバーとのウォークスルーによって意識あわせをすること。 |
| システム基盤運用設計 | ・オンライン処理時間、夜間バッチ処理時間、運用日付変更タイミングを考慮しシステム運転スケジュール、ジョブネット ・システム運用で必要となる全作業項目の運用項目抽出および方針、運用フローの確定 ・運用で必要となるスクリプトを洗い出す | 「システム基盤運用設計」で確定したシステム運転スケジュール、ジョブネットを入力として「業務運用設計」が実施されることも多く、業務G、基盤G双方において入力となる内容を意識あわせすること。 |
| 全体運用設計※ | ・運用作業項目ごとの効率的な手順書、必要なスクリプト一覧 ・SLAに対する運用状況報告の仕方、対象、運用改善方針 ・障害発生時の報告ルート、連絡体制、承認フロー | 運用手順書、スクリプトは製品導入後の環境構築、テストと並行して作成することも多い。設計段階で必要な手順書類はすべて洗い出す必要がある。 |
業務運用設計は、システム基盤運用設計と比較して機能や実際の運用で行われる作業であり個別のプロジェクトにおいてもノウハウがあると思います。一方、システム基盤運用設計における項目は機能と直接結びつかないものも多く、システム個別要素が強いため標準化しずらいことは解説したとおりです。
１点補足しておくと、関連する工程に「運用テスト」があります。運用テストは「業務運用設計」、「システム基盤運用設計」、「全体運用設計」で検討した運用フロー、承認フローの妥当性を検証するものですが、運用設計の品質が悪いと「運用テスト」が成立しないこともあります。サービス開始後に、お客様からの問い合わせ方法、ベンダーへの質問方法が決まってないといったことにならないようにしてください。運用テストを含むシステム開発におけるテストに関しては以下で解説しています。
次の章では、「システム基盤運用設計」における具体的な項目と検討内容を確認したいと思います。
※全体運用設計はITILで検討する内容として広く知られているため、ここでの解説からは除きます。
システム基盤における運用設計書目次サンプル
一番知りたいのは、運用設計書で検討すべき「項目」だと思います。以下の表に、「システム基盤運用設計書」として設計すべき項目を目次サンプルとしてまとめました。
これらは非機能要求グレードの運用・保守性の小項目を、良くある運用作業「項目」に改めたものです。表の「項目」は運用設計書の目次そのものです。非機能要求グレードの小項目をそのまま運用設計書の入力にすると使いずらいため、プロジェクト参画経験から運用作業の「項目」を観点にすることで漏れなく設計できると考えています。また、各項目で発生する「運用フロー」も必ずまとめます。
実際に設計を行う場合は、要件定義内容をどこにマッピングすればよいのか確認してください。
| 項目 | 設計内容 | 留意事項 |
|---|---|---|
| システム運転スケジュール | システムのオンライン時間帯、バッチ時間帯、バックアップ取得など個々のシステム運用スケジュールを確定する。 | スケジュールは日次、週次、月次、年次、特定日運用を意識して検討する。 |
| ジョブ管理 | システム運用スケジュールをジョブとジョブネットに落とし込む。 | ジョブ実行エラー時の動作を考慮し、システム運転スケジュールが遅延しないようにする。 |
| システム監視※ | 死活監視、SNMPトラップ監視、リソース閾値監視、ログ監視、プロセス監視の対象を確定する。 | リソースであれば、CPU、メモリ、ディスクなどが対象となる。 |
| ログ管理 | ログ出力、退避、転送、圧縮、保管、削除方法を確定する。 | ログレベル、種類、出力仕様を調査し、パーティション事に必要な容量も算出する。 |
| バックアップ管理 | バックアップ対象、リカバリポイント、バックアップ世代を確定する。 | 業務データだけでなく、システムバックアップについても考慮する。 |
| ユーザ管理 | ユーザー情報の属性、受領方法、ドメイン管理方法、認証方式を確定する。 | システムのセキュリティポリシーやSSOの採用可否により検討する。 |
| アクセス管理 | ルートユーザ、リモートログインアクセス管理、データアクセス管理、ネットワークアクセス管理、改ざん検知のルールを確定する。 | データベースであれば、アプリケーション経由および特定端末の特定アカウントからしかアクセスさせないなど考慮する。 |
| セキュリティパッチ管理 | パッチファイルの入手、転送、適用方法を確定する。 | リポジトリサーバー構築の可否、適用方針（CVSSレベルで定義するなど）も検討する。 |
| ウイルス対策管理 | ウイルスパターンファイルの入手、配布、ウイルス検知、隔離・駆除方法を確定する。 | スキャンは時間のかかる処理であるため、システム運転スケジュールに収まるか考慮する。 |
| 時刻同期 | OS毎の実施タイミング、同期先、同期エラー時の対応を確定する。 | NTPサーバーへのアクセスルートを考慮する必要がある。 |
| 起動停止 | システム全体を通したサーバーの起動停止、順序を確定する。 | OS、ミドルウェアの相互依存関係が起動停止順序に影響がある。 |
| アプリケーション配布 | アプリケーション凍結、リリース方法、リリース後動作確認、配布環境、デグレ時の復旧方法を確定する。 | システム開発段階からライブラリ管理チームを立ててテスト構成が滞りなく実施できる体制、リリース方式とする必要がある。 |
| キャパシティ管理 | システム稼働情報の取得、参照、評価方法を確定する。 | 日次、週次、特定日の情報で評価するのか時間帯など含む含めた評価対象のメトリックスを考慮する。 |
これらは、一般的なシステムにおける最大公約数として抽出してるため、システムによってはこれら以外の項目も存在するでしょう。例えば「サーバー証明書」を利用しているシステムでは「サーバー証明書」に関する項目が追加になります。システム運用として必要となる作業を洗い出し、項目として適宜追加してください。
「サーバー証明書」の設計であれば、更新頻度、入手先、ダウンロードなのか媒体渡しなのか、失効／期限切れしている場合の対応方法など、文字通り運用に応じた設計が必要となります。
システム運用作業をする人は誰？
最終的には想定通りシステムが運用されてプロジェクトが終了となりますが、そのシステムの運用作業をする人は誰なのでしょうか。以下にシステム運用担当者をまとめました。
運用設計で示した項目に対して、関係者の誰が実施するのかもあわせて検討することが大切です。作業効率を考えてジョブネットによる自動化を検討すべきなのか、年１回の作業なので運用手順を用意しておいてシステム運用者の随時作業とするのかなど、運用設計の重要なポイントでもあります。
| 関係者 | 概要 |
| システム利用者（エンドユーザー） | ・システムの機能を利用する人 用意された画面や処理を利用し業務を行う。ショッピングモールのようなコンシューマーが利用することを想定している場合と、社内システムのような特定部門、メンバーが利用する場合など、様々 |
| システム開発者 | ・システム開発受託した業者 システムにトラブルが発生した場合、システム運用者から連絡を受け、必要な対応を実施する。 例：IBM、富士通、NEC、日立、NTTデータ |
| システム運用者 | ・システム運用を受託した業者 システム開発者から提供されたシステム監視機能や各種の運用手順に従ってシステムを運用する。 例：〇〇システムサービス、〇〇マネージメントシステム |
| システム管理者 | ・システム開発を発注した業者 システム開発に最終的な責任を負う。システム開発者とシステム運用者へ発注を行い、指示、命令を行う。 例：官公庁、地方自治体、〇〇銀行、〇〇証券、〇〇電力 |
まとめ
結局のところ、表に示す４者がストレスなく安定稼働させるシステムを運用することが目的であり、極端な話、自動化もスクリプト作成もせず、全て手動作業で計画時間内でミスなく完了できるのであれば運用設計稼働は相当削減できるでしょう。一方多くの場合、そのようなわけに行かないため知恵を絞りジョブネットによる運用自動化を図り、運用手順書を用意し誰でもミスなくシステム運用できるように整備するのです。
運用設計の優先順位が低く見積もられてきた背景には、運用設計はシステム開発中に直接の影響を受けずらいということがあります。運用設計の真価が問われるのはサービス開始後である一方、システム開発業者がその責任を逃れやすいという構造的な問題があります。長い目で見た場合、そういった業者は市場から退場を迫られると思いますが「あとはシステム運用者がうまくやるでしょ」というベンダーもありました。
みずほ銀行やKDDIのシステム障害からも明らかなように、ひとたびシステム障害を発生させれば社会問題となる時代であり、それは運用設計の品質と非常に大きな関係があります。正しいプロセスで運用設計を行えるエンジニアが一人でも増えることを願ってやみません。
コメント