はじめに
大手SIerで20年以上、システム基盤SEとしてプロジェクトに参画してきました。その中で繰り返し遭遇してきたのが、運用設計の漏れや、処理方式設計との不整合を原因とするトラブルです。
運用設計とは、本番稼働後に必要となる作業、判断基準、体制を整理し、それをシステムの処理方式や構成と結びつける設計です。
監視対象は定義されているのに、何を異常とみなすのか決まっていない。
ログは出力されているのに、保持期間や削除方法が決まっていない。
バックアップは取得しているのに、必要な時間内にリストアできるか確認されていない。
ジョブネットは作られているのに、実行するスクリプトが存在しない。
こうした設計不備は、重大な障害の見逃しや復旧の遅れにつながります。システムを利用するお客様だけでなく、その先にいる利用者や社会へのサービス提供を損なう事態にもなりかねません。
それほど重要な設計領域であるにもかかわらず、運用設計は多くのプロジェクトで軽視されてきました。
なぜでしょうか。
100のシステムがあれば、運用の形も100通りあります。運用・保守に関する確認観点を整理したフレームワークや標準はありますが、それをそのまま適用すれば運用設計が完成するわけではありません。
サービス時間、業務日付、外部連携、夜間バッチ、監視、バックアップ、障害時の判断、運用体制は、システムごとに具体化する必要があります。
非機能要件だけでなく、業務運用や組織の役割分担にもまたがるため、定型の設計書に集約しにくく、見える化しづらい設計領域だといえます。
もう一つ、情報の偏りという問題もあります。
世の中の技術情報を見渡すと、logrotateの設定方法やクラウドサービスの使い方といった処理方式寄りの解説か、ITILに基づく管理プロセスといった組織・サービス管理寄りの解説か、そのどちらかに偏っています。現場のSEが本当に苦労するのは、その中間にある領域です。
運用要件をどの仕組みで実現し、どの設定値、スクリプト、ジョブ、監視条件に落とし込むのか。ここを扱った情報は、驚くほど少ないのが実情です。
この記事では、システム基盤から見た運用設計を中心に、共通化しやすい検討項目を「運用設計書の目次サンプル」として示します。
あわせて、運用設計が処理方式設計と切り離せない理由と、運用設計が要件定義から始まり、基本設計の段階で骨格が決まることを、現場の経験から整理します。
実際にあった運用設計漏れによるトラブル
まず、運用設計漏れによって発生したトラブルの例を見てみます。
あるサーバでは、syslogファイルをローテーションしないまま、ログが出力され続けていました。
このまま運用を続ければ、syslogファイルはパーティションの空き容量を消費し続けます。それがルート領域であれば、OSやミドルウェアが正常に動作できなくなり、ログインやプロセス起動にも支障が出る可能性があります。
ログ管理設計の漏れがどのように障害へつながるのかを、図にすると次のとおりです。
ディスクの空き容量を監視していれば、容量が枯渇する前に検知できたかもしれません。
ただ、これは監視だけの問題ではありません。空き容量の監視は、容量逼迫という状態を検知する仕組みです。
根本原因は、ログの増加を前提に、保持、退避、圧縮、削除を設計していなかったことにあります。
ログ管理を運用設計項目として定義し、
どのログを管理対象とするのか、
何の目的で保存するのか、
どの期間保持するのか、
即時に参照できる必要があるのか、
いつ外部領域へ退避するのか、
いつ圧縮・削除するのか、
誰が参照できるのか
これらを決めていれば避けられたトラブルです。
その運用設計を入力として、処理方式側では、logrotateを使うのかジョブで退避するのか、どのパーティションへ保存するのか、どれだけの容量が必要なのかを具体化します。
一見すると「検討していて当然」と思われる内容です。それでも、ログ管理を運用設計の対象として認識していないプロジェクトでは、実際に漏れます。
運用設計はいつやるのか｜要件定義から始まり基本設計で骨格が決まる
運用設計のプロセスを理解するには、システム開発全体の中での位置づけを押さえる必要があります。
ウォーターフォール型の開発プロセスは、要件定義、設計、製造、試験、移行、保守・運用という流れで説明されることが多いと思います。
このモデルでは工程の最後に「保守・運用」が置かれているため、運用に関する検討もシステムが完成してから行えばよい、という誤解が生じます。
最後に置かれているのは、完成したシステムを実際に維持管理する運用工程です。そのシステムをどのように運用するのかを決める運用設計は、設計工程の中にあります。
運用設計を設計工程として扱わないプロジェクトでは、サービス開始直前になって検討不足が表面化します。
ログがローテーションされない。
バックアップはあるのに戻せない。
ジョブは定義されているのに実行するスクリプトがない。
監視アラートは出るのに一次対応者が決まっていない。
夜間処理は終了したのに、業務を開始してよいか判断できない。
私はそうした現場を数多く見てきました。
これらは、運用開始後に考える問題ではありません。工程初期から、処理方式とセットで具体化すべき設計事項です。
処理方式設計と運用設計は双方向でつながっている
ここからが、この記事で最も伝えたい内容です。
運用設計で最も重要なのは、処理方式設計との接続です。
運用設計は単独では成立せず、処理方式設計と対になって、初めて本番で運用できる設計になります。
処理方式設計とは、要件をどのような仕組みで実現するかを具体化する設計です。運用設計とは、その仕組みを実際の運用の中でどのように扱うかを具体化する設計です。
この2つは別の設計領域ですが、完全に分けて考えることはできません。
ログ管理を例に考えます。
運用設計側では、管理対象とするログ、利用目的、保持期間、参照要件、退避・削除方針、アクセス権限を決めます。
「syslogを1か月保持する」と運用設計で決めたとします。この決定だけでは、1か月保持は実現できません。
処理方式側で、
日次と週次のどちらでローテーションするのか、
Linuxのlogrotateで実現するのか
ジョブ管理製品で退避するのか、
退避先ディレクトリをどこにするのか、
圧縮するのか、
外部のログ管理基盤へ転送するのか、
必要なディスク容量はいくらか、
容量逼迫をどの条件で検知するのか
これらを設計する必要があります。運用設計の決定が、Linuxや監視製品、ログ管理製品の処理方式設計への入力になるわけです。
逆方向の流れもあります。Linux設計側でログの退避先を決めたなら、その情報は運用設計側へ伝えなければなりません。
ログは、要件に応じてバックアップや外部保管の対象になります。退避先が運用設計側へ伝わっていなければ、バックアップ対象やログ収集対象から漏れる可能性があります。
障害調査に必要なログが残っていない、という事態はこうして生まれます。
運用設計側が「何を、どれくらい、何の目的で管理したいのか」を決める。処理方式設計側が「それをどの仕組みで実現するのか」を決める。運用要件が処理方式に影響し、処理方式の制約が運用設計に戻ってくる。
この関係は一方向の受け渡しではなく、レビューやウォークスルーを通じて、相互に入力とフィードバックを繰り返しながら固めていくものです。
どちらを先に検討するかは状況によって異なりますが、運用設計者と処理方式設計者の間で認識齟齬を残さないことが重要です。
現場では、構築チームと運用準備チームが分かれ、ドキュメントも処理方式設計書と運用設計書に分断されることがあります。
その結果、ログ保持期間を満たすためにどの設定と容量設計が必要なのか、という両者の紐付けが、設計者の頭の中にしか存在しない状態になりがちです。
この紐付けを設計書、課題管理、レビューの仕組みで見える化できるかどうかが、運用設計の品質を左右します。
運用スクリプトは運用設計で横断的に洗い出す
処理方式設計と運用設計の双方向連携を示す例として、運用スクリプトを考えます。
バックアップ要件をジョブネットで実現するとします。
ジョブネットには、
バックアップ取得、
ログ退避、
世代削除、
整合性確認、
後処理
といった個別ジョブが登録されます。それぞれのジョブでは、実行対象となるスクリプト、コマンド、プログラム、製品機能が必要です。
ここで問題になるのが、必要な実行部品を誰が洗い出すのかという点です。
バックアップ方式だけを設計していると、バックアップ製品の設定は完了していても、ジョブから呼び出すスクリプトや終了判定処理が漏れることがあります。
ジョブネットだけを設計していると、ジョブの箱は並んでいるのに、中で何を実行するのか決まっていないことがあります。
運用で必要になるスクリプトや実行処理は、運用設計の中で横断的に洗い出す必要があります。
運用設計で横断的に洗い出すことと、運用設計担当がすべてのスクリプトを作成することは別です。
バックアップスクリプトはバックアップ方式の担当、ログ退避スクリプトはログ管理方式の担当、ジョブ制御スクリプトはジョブ設計の担当、起動停止スクリプトはOS・ミドルウェアの担当というように、実際の設計、製造、単体試験は、その仕組みを設計した担当が行うのが基本です。
運用設計側で行うのは横断管理です。
必要なスクリプトを一覧化し、
用途、
呼び出し元となるジョブ・手順・他スクリプト、
関連する運用作業、
作成担当、
完成時期、
後続テストでの確認方法
それらを明確にします。そして、スクリプトの設計、製造、単体試験、ジョブ登録をWBSへ反映し、結合テスト、システムテスト、運用テストに間に合わせます。
この横断管理がないプロジェクトでは、個別の方式設計は完了しているのに、実際の運用に必要なスクリプトだけが作られていない、という事態が起こります。
サービス開始直前になって発覚するスクリプト不足やジョブネットの実行エラーの多くは、この横断管理が不足した結果です。
運用設計で必要な実行部品を早期に洗い出し、処理方式の担当へ返すことが重要です。
運用設計の全体像
システム運用とは、利用者へ提供しているサービスを安定して継続するために、システムを維持管理していく活動です。その運用を成立させるための設計が、運用設計です。全体像は、次の3つに分けて考えると理解しやすくなります。
業務運用設計は、業務機能や実際の業務作業と結びつく領域です。
システム基盤運用設計は、サーバ、ネットワーク、ストレージ、ジョブ、監視、ログ、バックアップといった、システムを支える仕組みと強く結びつきます。
全体運用設計は、ITILのプラクティスと重なる領域が多く、体制や責任分界、障害・変更管理、サービスレベル管理を扱います。この記事では、主にシステム基盤運用設計を対象とします。
なお、運用手順書一覧、運用スクリプト一覧、ジョブ一覧は、特定の区分だけに属するものではありません。3つの領域で必要になる成果物を横断的に洗い出し、作成担当と期限を管理する必要があります。
関連する工程に、運用テストがあります。
運用テストでは、ここで設計した運用フロー、判断基準、承認フロー、復旧方法が実際に運用可能かを確認します。
運用設計の品質が低ければ、運用テスト自体が成立しません。
障害時の連絡先が分からない、問い合わせの受付方法が決まっていない、誰が業務開始可否を判断するのか分からない。こうした状態を、サービス開始後に残してはいけません。
運用テストを含むテスト工程の考え方は、以下の記事で解説しています。
システム基盤運用設計書の目次サンプル
運用設計について調べている人が最も知りたいのは、運用設計書で検討すべき「項目」ではないでしょうか。以下に、システム基盤運用設計書の目次サンプルを示します。
この目次は、IPAの非機能要求グレードなどの確認観点を参考にしながら、実際のプロジェクトで扱いやすい運用作業単位に整理したものです。
非機能要件の項目をそのまま設計書の章立てにしても、実際の運用作業との対応が見えにくいことがあります。
プロジェクト参画経験から、システム運転、監視、ログ、バックアップ、起動停止といった、実際に発生する運用作業を目次の単位にすることで、検討漏れを減らせると考えています。
表の「項目」は、運用設計書の章や節を組み立てる際のたたき台として使えます。
ただし、設計内容だけを書いて終わりではありません。
各項目について、実施主体、実施契機・頻度、正常・異常の判断条件、承認者・判断者、入出力情報、運用フロー、必要な手順書、必要なスクリプト・ジョブ、処理方式設計への申し送りも、必要に応じて整理します。
要件定義で合意した内容を、どの運用設計項目へ反映するのかを確認しながら進めることが重要です。
ここで挙げた項目は、一般的なシステムにおける最大公約数です。
すべてのシステムに同じ項目を適用すればよいわけではありません。外部公開サービスであれば、DDoS対策やWAF運用が必要になるかもしれません。
クラウドネイティブなシステムであれば、オートスケーリング、マネージドサービスのメンテナンス通知、クラウドコスト管理を追加することもあります。
反対に、小規模なシステムでは、複数の項目を一つの章にまとめることもあります。
重要なのは、テンプレートにシステムを合わせることではありません。システム運用で発生する作業と判断を洗い出し、必要な項目を追加・統合することです。
ここで示した運用設計の項目は、基本設計の段階で方針が決まっていることが前提です。
運転スケジュール、監視、ログ、バックアップ、開局判定の方針を基本設計でどう決めるのか、基盤SEが見ている設計の全体像は、以下の記事で解説しています。
基本設計書の目次と、各章で作成すべき成果物を1つの表で対応させたExcelファイル付きです。運用設計書目次サンプルと2点セットで、設計書の抜け漏れ確認に使えます。
運用設計は誰がやるのか｜4つの役割と責務分界
システムは構築して終わりではありません。
想定した運用を実行できる状態で運用担当へ引き継いで、初めて開発プロジェクトの役割を果たしたといえます。運用設計では、作業内容だけでなく、誰が実施するのかを明確にする必要があります。
役割は契約形態や組織によって異なりますが、一般的には次のように整理できます。
同じ組織や担当者が複数の役割を兼ねる場合もあります。
大切なのは、組織名ではなく責務を明確にすることです。監視アラートが発生したとき、誰が最初に確認するのか。原因調査は誰へ依頼するのか。業務影響は誰が判断するのか。処理を打ち切るかどうかを誰が承認するのか。
ここが曖昧なままでは、連絡先一覧があっても運用は回りません。
また、すべての作業を自動化すればよいわけでもありません。
頻度が低く、計画時間内に安全に実施できる作業であれば、手動運用を選ぶこともあります。
ただし、手動で行う場合でも、実施者、実施時期、必要な権限、作業手順、正常性の確認方法、作業証跡、異常時の対応、承認・報告方法は設計する必要があります。
自動化するか手動で残すかを、頻度、工数、リスク、ミスの影響、開発・保守コストから判断すること自体が、運用設計の重要な役割です。
まとめ｜運用設計は要件定義から始まっている
運用設計の目的は、システム利用者、運用担当、開発・保守担当、システムオーナーが、それぞれの役割を果たしながら、システムを安定して利用・維持できる状態をつくることです。
運用設計は、運用フェーズに入ってから考えるものではありません。要件定義からすでに始まっており、その骨格は基本設計の段階で決まります。
運転スケジュール、ジョブ、監視、ログ、バックアップ・リストア、起動停止、開局・閉塞、運用日付、異常時運用、エスカレーション、運用スクリプト。
これらの方針は、システム構成や処理方式とセットで具体化する必要があります。
運用設計側が、何をどのように運用したいかを決める。
処理方式設計側が、それをどの仕組みで実現するかを決める。処理方式上の制約が分かれば、運用設計側が運用方法や判断基準を見直す。
この双方向の関係を基本設計で押さえていなければ、詳細設計以降でどれだけ頑張っても、本番直前の
「必要なスクリプトがない」
「ジョブネットが動かない」
「バックアップから戻せない」
「アラート発生後の対応者がいない」
「夜間処理後に業務を開始してよいか判断できない」
は防げません。
運用設計は、運用担当へ仕事を押しつけるための設計ではありません。
本番稼働後に発生する作業、判断、障害、変更を想定し、システムの仕組みとプロジェクト計画へ反映する設計であり、処理方式と運用設計をつなぎ、本番で運用できるシステムを設計することです。
関連記事
運用設計は、単独で完結する工程ではありません。要件定義で決めた内容を基本設計・詳細設計へ落とし込み、さらにテストや運用へつなげていく必要があります。
運用設計の前提となる要件の考え方から、要件定義、基本設計、詳細設計、テストまでのつながりを確認したい方は、以下の記事もあわせてご覧ください。
機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う
要件定義で整理する「機能要件」と「非機能要件」の違いを、実務で使える視点から解説しています。
要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務
RFP・質問回答・提案書・見積前提を起点に、認識差を潰しながらスコープと責任分界を確定する要件定義の実務を解説しています。
基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程
要件定義で決めた内容を、システム全体の構成や方式へ落とし込む基本設計について解説しています。
詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程
基本設計で決めた方式を、実際に構築できる設定値や設計内容まで具体化する工程を解説しています。
Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方
要件定義・基本設計・詳細設計の内容が、後工程のテストとどう対応するのかを整理しています。
開発工程全体の流れから確認したい方は、以下の記事も参考にしてください。
システム開発の流れを現場目線で理解する【前編】
シリーズ全体は、noteマガジン「実務で使えるシステム開発方法論」にまとめています。
コメント