Managed Service Column ＜システム運用コラム＞第４回：システム運用方針のまとめ方と、運用体制構築に必要なこと

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

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

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

はじめに

「運用体制」というと24時間365日の監視体制 や ヘルプデスク というものが想像されると思います。たしかに、運用しているシステムに何事も起こらなければ、監視だけ行い、問合せがあれば都度対応する、で良いかもしれません。

運用設計の目的は、システムが「あるべき機能／サービス」を提供し続けること、すなわち「そのシステムが正常に稼働し続ける」こととはどのような状態を指すのかを正確に理解し、そのための指針を決定し、それを遂行する運用体制を構築することです。

サービス提供基盤の多くは24時間365日の稼働を必須条件として構成されており、この条件を満たすために基盤の冗長構成ならびに故障時のリカバリ体制を整えるとともに、発生した問題について都度原因を分析し、再発防止策の検討と対策を行っていかなければなりません。

システム運用体制を整えるには、平常時の監視体制以外にも、障害や災害などの不測の事態が発生した場合の対応体制、再発を防止するための策を検討し実運用に載せる体制、機能追加や改修が必要となった場合の実装・リリース体制が必要となります。

本連載では、組織（企業）や規模によって変わるであろうツールや人員配置などの運用体制を詳説するのではなく、どのような規模の運用体制でも変わらない、運用体制構築にあたって前提となる「システム運用方針をどう決めるのか」 ということに主眼をおいて説明します。また「これらの方針をどのような体制や仕組みで実行・管理しているか」という取り組み例を、当社事例でご紹介します。

システム運用方針を決める

前回のコラムでは、運用対象をどういう視点で管理していくのか＝「可用性要件、完全性要件、機密性要件から運用管理項目を洗い出す視点」をご紹介しました。

今回は、「洗い出した運用管理項目をどういうプロセスで管理していくのか」という運用管理プロセスの定義のしかたについてお話しします。実際に体制を構築するためには、「何を、どのような視点で、どう管理していくのか」という運用方針（これが運用手順に落ちていきます）が決まっている必要があるからです。

ITILのサービス・デザインのプロセスから考える

ITIL（Information Technology Infrastructure Library）とは、ITサービスの運用管理のベストプラクティスを体系化したもので、英国政府商務省によって作成され、国際的なスタンダードになっています。1989年に初期バージョンがリリースされた後、V2、V3とアップデートされ、2019年V4（英語版）がリリースされました。V3が、IT組織がITサービスを企業内に配備する方法やITサービスを効率的に配備するためのプロセスに重点を置いて作成されたのに対し、V4では、IT環境におけるサービスマネジメントの課題に対処し、アジャイル開発やクラウドといった新しい技術を生かすためのガイダンスを提供することに焦点を当てています。

本コラムでは、運用設計プロセスの解説を趣旨としていますので、V3をベースにお話ししていきます。

ITIL(V3)のサービス・デザインには、運用管理という側面からITサービスを設計するのに以下の7つのプロセスがあると記載されています。（サービス・デザインとは、ITサービスの戦略やビジネス要件をもとに、ITサービスを設計するプロセスをいいます）

1. サービスレベル管理
2. 可用性管理
3. ITサービス継続性管理
4. サービスカタログ管理
5. キャパシティ管理
6. 情報セキュリティ管理
7. サプライヤー管理

この管理プロセスについて

• 何を意図して定義されたものか（目的は何か）
• 何を行うのか
• 取り組み事例（当社の場合）

をお話しします。

なお、「サービスカタログ管理（稼働中のITサービスや、ITサービスに関する情報を管理するプロセス）」と「サプライヤー管理（サードパティ・サプライヤーとの契約管理）」については、今回の連載では割愛します。

以下の５つのプロセスについて、考え方や取り組み事例（当社の場合）を説明していきます。

サービスレベル管理

サービスレベル管理の目的は、システムが達成すべきサービスレベルを、サービス提供側とサービス利用側とで事前に定義・合意し、常にサービスレベルを満たすことを目的とします。（→詳しく見る）

可用性管理

可用性とは、情報を使いたいときに使える状態にしておくことです。可用性管理の目的は、合意済みのサービスレベル目標値を満たすように、ITサービスの可用性を最適化、改善していくことになります。（→詳しく見る）

ITサービス継続性管理

可用性管理が日常の障害に備える管理プロセスであるのに対し、ITサービス継続管理は、天災、テロなどの災害によってサービスが停止に追い込まれた際、サービス利用者と合意した、もしくは自社で定義した時間内にサービスを普及させ、ビジネスインパクトを最小限度に抑えるためのプロセスです。（→詳しく見る）

キャパシティ管理

キャパシティ管理は、サービスを供給するために必要なITキャパシティを予測して、適切なタイミングで提供できる準備を整えるプロセスです。（→詳しく見る）

情報セキュリティ管理

情報セキュリティ管理とは、情報漏洩やマルウェア感染といったセキュリティリスクに対して組織がどのように取り組むか方針をまとめ、組織の資産、情報、データやITサービスの機密性、完全性、可用性を管理することで、情報セキュリティを確保するプロセスです。（→詳しく見る）

以上が、システム運用方針を決める際に考慮すべき項目となります。

システム運用業務を仕組化する

ここまで運用方針を決めるお話をしましたが、実際の運用現場では、ユーザーからの要求管理や、コンポーネントからの異常通知を管理するインシデント管理、問題の根本原因の特定と除去を行う問題管理、資産管理や構成管理など、他にも多くの管理業務があります。
運用設計時には、これらの業務を効率よく行うための方法や体制も検討する必要があります。

では、効率化や高品質化、さらにはコスト削減をしながら、運用を実践していくにはどうしたらよいでしょうか？
「決まりきったオペレーションを、徹底的に仕組化、システム化する」が答えになります。

以下に、運用の現場で行われている作業例を記載します。

• リソース利用状態を目視でグラフから確認
• Windowsのイベントログの確認
• アプリケーションログの確認
• 日々のバッチ処理成否確認
• バックアップ成否のチェック

• 特定ページの表示確認を担当者がブラウザで確認
• 業務システムへのアクセス確認
• ステムチェックのためのダミー業務実施
• 特定のメールを成形して集計、再送付
• 定期的なデータ更新
• 定期的な再起動
• 蓄積したログの整理

以上の作業はいずれもシステム運用には必須の作業です。実際、運用担当者はこれらの作業に多くの時間を割かれているのではないでしょうか。しかし、これらは「自動化が可能な作業」です（「自動化が可能な作業」は、「過去の確認」「現在の確認」「定型的な作業」の3つの類型に分けられます）。

例えば、定期的なプロセス再起動、障害発生時の手順に従った対応がありますが、障害発生時に決まった連絡先にメールや電話で「連絡」「報告」を行うことは定型作業であり、ほぼすべてをシステム化できます。

これらのオペレーションに求められることは、確実性と対応スピードです。特に障害検知時の第一報については、重大な障害であれば、その後の対応を検討し対処方法を決定できる技術者（もしくはサービス担当者）へ、確実に正確な情報が伝わることが重要となります。

確実性と対応スピードが求められる場面では、人的な対応よりもシステム化するほうがよく、「効率化」「高品質化」「コスト削減」の実現への近道になります。いかにオペレーションに人的リソースを使わないかがポイントです。

そして技術者には、問題改善や次期システムの設計へつなげる業務を任せることで、サービスレベル管理、可用性管理、ITサービス継続性管理、キャパシティ管理、情報セキュリティ管理という「運用設計」の分野に頭を使う時間を振り分けて行きましょう。

その他の運用体制構築にあたり必要な準備

最後に、人員配置やツール導入など、運用体制を構築するために必要な要素について簡単にお話しします。これらの要素は、企業規模やシステムの用途・運用要件によって変わってきますので、以下では、24時間365日のシステム運用を自社で実現する場合を想定します。

インフラエンジニアの確保・人事管理ルールの整備

24時間365日のシフトを組む場合は、シフトの数に合わせたインフラエンジニアの確保が必要になります。また、労働基準法に準拠した就業規則や賃金体系の整備や、技術者の工数を管理する仕組みも必要です。

システム運用基盤の構築・運用保守

システム監視基盤、要求管理やインシデント管理、問題管理を行う運用基盤、コミュニケーション基盤が必要になります。
監視基盤については、システム監視ツールを自社で構築・運用保守する方法と、クラウド型監視サービスを利用する方法があります。監視対象がさほど多くない場合、あるいは、監視項目のカスタマイズをしなくてもよい場合は、クラウドサービスを利用するほうがコストパフォーマンスがよいケースもあるでしょう。その際には、クラウドサービスの SLA を確認するなど、「可用性管理」で解説したポイントをチェックするとよいでしょう。
またシステム運用基盤には、セキュリティ対策（不正アクセス防御や適切なアクセス制御等）を講じるべきでしょう。

当社では お客様に24時間365日のシステム運用サービスを提供するため、数十人の技術者でシフト体制を組んでいます。運用技術者を複数の案件に横断的にアサインすることで、ナレッジの蓄積・共有を促進する工夫もしています。
また、システム運用に必要な、システム監視基盤、要求管理やインシデント管理、問題管理を行う運用基盤、コミュニケーション基盤は、自社で構築・運用保守および外部サービスを組み合わせて利用しています。加えて、ISMSに準拠した情報セキュリティ管理を行っています。

まとめ

システム運用体制を構築するためには、運用方針が決まっている必要があること、運用業務は多岐にわたるために業務効率化の仕組みが必須であること、運用体制を構築するためには、インフラエンジニアの確保だけでなく、運用基盤の構築・運用保守・セキュリティの確保、また、管理部門と連携した就業規則等の人事ルールの整備が必要であることを見てきました。

全部を自前で用意するのはハードルが高いと感じる方もいるかもしれません。自社のビジネスやサービス開発に専念するために運用のアウトソースをうまく活用する、というのも有効な選択肢となるでしょう。

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

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

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

Tag： 運用設計

• 

  第３回：運用設計の考え方―運用管理対象をどういう視点で管理するのか？運用要件から落とし込むときのポイント

• 

  第５回：サービスレベル管理とは？―運用体制構築に向けての考え方と取り組み事例（１）