Managed Service Column <システム運用コラム>

運用設計の考え方と取り組み事例

Category: 運用設計編

2021.02.08

システムのクラウド移行が加速する中、「クラウドサービスを活用しているが、クラウド毎に個別に監視・運用をしているため、運用が煩雑化している。どうすればよいか?」「オンプレミスとクラウドを併用することになり、運用管理体制を見直したい」といったお声をいただくことも多くなりました。

システムは構築して終わりではなく、安定稼働するための運用が重要です。そして、システム運用の品質を担保しながら効率を上げていくためには、運用設計が必要となります。

この連載では、運用設計の考え方やの取り組みについて、事例も交えて紹介します(全12回)

はじめに

前回は、システムの安定稼働を支えるためには、システム障害といった不測の事態への対応や、日常の運用業務をスムーズに進めるためのルールやプロセス等を予め定義することが重要だ、というお話でした。

では、運用ルールやプロセスを設計する際の「対象」は何になるのでしょうか?また、この管理対象の「状態」をどういう視点で監視し、その評価に基づく対策をどういう体制で講じていくのでしょうか?

これからの2回のコラムで、「何を(=運用管理対象)」の洗い出し方と、「どう管理するのか(=運用管理項目、管理するために必要な体制、仕組みづくり)」の考え方を説明します。

(あわせて読む:「第3回:運用設計の考え方―運用管理対象をどういう視点で管理するのか?運用要件から落とし込むときのポイント」)

運用管理対象とは

運用管理対象とは、システムを構成する要素であり、システムの目的(あるべき姿)を維持するために監視・管理する対象をいいます。(※対象をどういう視点で管理するか、が運用管理項目となります)

システム運用の対象は、○○系基幹システムや○○系情報システム、○○系Webシステムといった、それぞれ利用目的を持つシステムです。 これらのシステムを

  1. 何のサービスを提供するのか
  2. サービスを提供するために必要な要素は何か
  3. 必要な要素はどう絡み合うのか
という観点でブレイクダウンしていき、運用管理対象を洗い出します。

情報系システムの例:

情報系システムの例

サービスを提供するそれぞれのシステム内には、
「Webサーバー(インスタンス)」「DBサーバー(インスタンス)」「アプリケーションサーバー(インスタンス)」「ファイアウォール」「IPS/IDS」「WAF」「インターネット」「WAN」
といった機器や機能が存在し、

それらがその役割を果たすために、
「ハードウェアやファームウェア」「オペレーティングシステム」「ミドルウェア」「アプリケーション」
等が存在します。

ブレイクダウンのイメージを図で表現するとこのようになります。

サービス提供のために必要な要素
サービス提供のために必要な要素

上記はごくシンプルな例ですが、このような考え方で洗い出された要素のひとつひとつが、運用設計を行う上での管理対象となります。また、個々の要素だけでなく、要素をまとめたグループも運用管理対象となり得ます(例:1台のWebサーバーのパフォーマンスだけでなく、Webサーバー群としてのパフォーマンスも、運用管理対象となりうる)。

このように、運用管理対象を洗い出すということは、システムの構成要素を役割に応じて細分化していくことであり、かつ、どのくらい細分化したかによって、運用設計の精度が変わります。

しかし、やみくもに細分化すればよいというわけでもありません。収集する情報が膨大になり、管理が煩雑になる上に、障害予兆など本当に必要な情報が埋もれてしまうからです。

Webベースの受注管理システムを例に考えてみましょう。

要素をまとめたグループが運用管理対象となる例
要素をまとめたグループが運用管理対象となる例
運用管理対象が「サーバー群の状態」になる例です(Webサーバー群、DBサーバー群のパフォーマンスが管理対象となる)。

このシステムの目的は、「業務時間中、受注管理機能を、ネットワーク経由で、安定的にユーザーに提供すること」です。 このシステムを構成する要素は、図のように、ネットワーク、Webサーバー/DBサーバー、Webサーバーで稼働する Apacheプロセス/DBサーバーで稼働するMySQLプロセスと細分化されます。

このシステムの目的を考えると、個々のWebサーバー/DBサーバーの状態よりも、Webサーバー群/DBサーバー群としてサービス提供できているか、ということが重要となります。

よって、「受注管理機能を正常に提供できること」というシステムの目的を達成・維持するために、「サーバー群としての状態」を運用管理対象として扱います(「個々のサーバーやプロセスの状態」は、障害予兆を把握するための管理対象となります)。

このようにシステムの目的によって、管理すべき対象の粒度が決まります。

まとめ

今回は、システムのあるべき姿を維持する(=システムを安定稼働させる)ために監視・管理が必要なシステム構成要素(運用管理対象)を、「(1) そのシステムは何のサービスを提供するのか」「(2) サービスを提供するために必要な要素は何か」「(3) 必要な要素はどう絡み合うのか」という視点でブレイクダウンして洗い出していく、というお話でした。

それでは、洗い出した「運用管理対象」をどう管理すればよいのでしょうか?
次に、運用管理対象への要求である「運用要件」とは何か、どういう視点で管理項目に落としこんでいけばよいかを考えていきます。

運用設計のポイントを手っ取り早く把握したい方へ

クラウド運用課題を解決する「運用設計の考え方」「運用設計のフレームワーク」のポイントを手っ取り早く把握したい!という方は、以下のホワイトペーパー「運用設計が丸わかり!クラウド運用課題解決への4ステップ(運用設計ガイド)」もあわせてご参照ください。

「クラウド運用の課題と対応策」や「自社で運用設計する際の課題」、「運用設計と継続的な運用改善を継続させるポイント」も記載していますので、参考になさってください。

Free

資料ダウンロード

課題解決に役立つ詳しいサービス資料はこちら

資料ダウンロード
  • 運用設計が丸わかり!クラウド運用課題解決への4ステップ(運用設計ガイド)

    クラウド運用課題を解決する「運用設計の考え方」「運用設計のフレームワーク」のポイントを解説します。

Tag: 運用設計

関連記事

Contactお問い合わせ

お見積もり・ご相談など、お気軽にお問い合わせください。

single.php