Managed Service Column ＜システム運用コラム＞第１回：運用設計を行うべき理由と運用設計のアプローチ

はじめに

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

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

ここでは、なぜ運用設計が重要なのか、運用設計するために何を把握する必要があるのかを、改めて考えていきます。
全12回の連載となります。

なぜ運用設計が重要なのか？

システム運用の最終目的は、ターゲットとなるシステムを定常的に安定稼働させ、エンドユーザーにとって不可欠なインフラとしての「機能／サービス」を提供し続けることです。「問題なく稼働して当たり前」と思われがちなシステムですが、当然システムトラブルといった問題は起きますし、日頃のメンテナンスも必要です。
システムの安定稼働を支えるためには、障害発生といった不測の事態への対応や、日常の運用業務をスムーズに進めるためのルールやプロセス、体制を予め定義しておくこと（＝運用設計）が、非常に重要になります。

「運用設計とは？サービスを安定稼働させるための項目定義」では、あらかじめ定義しておくべき運用設計項目を洗い出しましたが、本記事では、「項目を定義する際の考え方」にフォーカスして解説します。

考え方として、ボトムアップ式にシステムを構成する各機器の役割・機構にフォーカスして項目を洗い出していくという方法もありますが、本コラムでは、トップダウン式に運用設計を行っていく方法をとります。

つまり、システムが稼働する目的から、

• 必要な運用要件は何か（可用性要件、機密性要件、完全性要件、性能要件）
• 運用管理対象は何で、どう管理するのか（管理項目は何か、運用・保守の仕組みや体制をどうつくっていくのか）

に、落とし込んでいく考え方を説明します。

運用設計を行う際に把握すべきこと

システムの安定稼働を支えるためには、まず「何が正常な状態なのか」を知る必要があります。ですが、「システムが正常に機能／サービスを提供し続ける」と言っても、その意味するところはシステムによって異なってきます。

運用設計を行う上でまず初めに把握すべきことは、「そのシステムは何を目的に稼働しているのか」、「対象システムの役割は何か？」「どういう状態が正常なのか」であり、さらにそれをブレイクダウンしていきます。
いくつかの例を挙げて考えてみましょう。

システムの果たすべき役割の例：

• 検索サービスやSNSサービス: 世界中にサービス提供しているWebサービスで、24時間365日稼働し続けることが当たり前
• Eコマースサービス: サービス停止はもとより、サイトの表示速度が遅くなるなどサービス品質の低下がビジネスチャンスの喪失を意味する
• 社内人事システムや経理システム:業務時間（＋α）だけサービスを提供できれば良い
• 確定申告に代表される納税関連やキャンペーンサイト:ある特定の期間限定で稼働すればよい

上記4例は、それぞれシステムを利用するユーザーが異なります。 また、求められる機能や性能も変わってきます。
すなわち、「システム」を知るためには、大きく「A：システムの目的とステークホルダー」、「B：システム環境」、「C:保守運用環境」の観点を押さえる必要があります。

A：システムの役割とステークホルダー

システムの役割とステークホルダーについて把握すべきこと。

• どんな機能（役割）を提供しているシステムなのか
• 利用ユーザーはだれか
• ビジネスオーナーはだれか
• システムの持ち主はだれか（自社、顧客、パートナー、ホスティング事業者、クラウドベンダー・・・）
• システムが停止した場合のマイナスインパクトは何か、またどのくらいのインパクトがあるのか（社会的に影響、売上や利益に影響、業務遂行に影響、敏感に反応する影響は無い・・・etc）

B:システム環境や運用要件

システム環境や運用要件について把握すべきこと。

• システムが稼働している環境（オンプレミス、クラウド、・・・）は何か
• システムはどのような構成要素により成り立っているか（WebサーバーやDBサーバーといったサーバー、ファイアーウォールやスイッチといったネットワーク機器等々）
• システムが稼働するうえで求められる運用要件は何か（可用性要件、機密性要件、完全性要件、性能要件）
• 現行システムの稼働開始時期 や 更改予定時期はいつか

C:サービスを維持するための体制

サービス提供体制について把握すべきこと。

• システムの運用体制（異常発生時の迅速な対応含め、システムが安全に稼働するための取組み）はどうなっているか
• システムの保守体制（システムが不測の事態に陥らないための日々の取組み）はどうなっているか

運用設計のアプローチ

上記の A、B、C を以下のように階層化して考えてみましょう。

A には、「システムが果たすべき役割」「システムが停止した場合の影響」「システムに関わるステークホルダーの情報」が入ります。

B には、Aの目的を達成するのに必要な「システム環境」「システムが稼働するうえで求められる運用要件（可用性要件、機密性要件、完全性要件、性能性要件）」「運用管理の項目」が入ります。

C には、Aの目的を果たすために稼働するBを維持するのに必要な「運用の仕組み」「システム運用体制」「システム保守体制」が入ります。

例えば、サービス停止そのものがビジネスに直接インパクトを与えるシステム（A）の場合は、まず「無停止」を前提としたシステムである必要があり（B）、仮に停止した場合でも影響を最小限に抑える仕組みやルール、体制を整える必要があります（C）。
当然、そのシステムを構成する資産が自社のものか、レンタルか、クラウドか（B） によって体制作り（C）も大きく変わってきます。　 このように、（A）→（B）→（C）とブレイクダウンして考えていきます。

「システムのあるべき姿」を把握したあとのステップ

システムが果たすべき役割を把握したら、あるべき姿を維持するための監視設計と、システム障害など不測の事態を想定した対応フロー、体制の設計を行います（他にも、システムの機能変更・追加がある場合に、サービスレベルを落とさずに済むような仕組みづくり等も必要です）。

例えば、サービス停止そのものがビジネスに直接インパクトを与えるシステムの場合は、「無停止」を前提とした運用の仕組みや体制を整えることを行います。

このように、運用管理対象（システムを構成する要素を細分化したもの）と 運用要件（可用性、機密性、完全性）から 運用設計 に落とし込んでいきます。

Step1とStep2を限りなく漏れなく行うことによって、システムの目的を達成する（＝システムを安定稼働させる）ために必要な監視ポイントが決まります。そのポイントに応じた運用設計を行うことで、システムに何らかのトラブルが発生した場合、アプリケーションやネットワーク、場合によってはハードウェアなど、「階層」の視点を変えて原因を追及することで早期の解決を図ることができます。

全ての階層をまたいだ運用設計はIT技術の総合力ともいうべきものであり、特定の何らかの技術があれば良い というものではありません。

まとめ

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

では、何を管理対象としてルールやプロセスを設計していくのでしょうか？　
次回は 「運用管理対象をどういう視点で洗い出していくか？」というお話をします。

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

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

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

Tag： 運用設計

• 

  Dockerとは？代表的な管理システム Kubernetesとの違いもわかりやすく解説

• 

  第２回：運用設計の考え方―何を管理するのか？運用管理対象の洗い出し方