運用ビギナーが、設計書でちゃんと見るべき重要な2つの点

システム運用・保守には、手順書通りに実施するだけのオペレーション業務も存在します。その一方で、これまでに経験のないシステムアラートへの対応や、発生したシステム障害が再発しないような恒久的な対処が必要な場合もあります。つまり、プロジェクト全体のシステム構成を理解していることが求められます。

とはいえ、システム運用・保守の経験が浅いエンジニアにとって難しいのは当然です。今回の記事では、そんなビギナー向けに、システム方式設計書からいち早く理解しておきたい、2つのポイントについて解説します。

ポイント1:運用・保守の基本の「キ」、構成を理解せよ!

まずは、方式設計書を最初から最後まで読みましょう。流し読みで構いません。どこにどのようなことが書いてあるのか、大まかに押さえてください。読んでみると、そのシステムの利用者数、ソフトウェアのバージョン、サーバの命名規則などが書かれていることがわかると思います。ざっくりと目を通した後に、『ユーザは何がしたくてそのシステムを導入するのか?』、『そのシステムはどのように動いて目的を成し遂げるのか?』を考えながら、もう一度方式設計書を読んでください。

一括りにシステムといっても、それを動かすためのコンポーネントが複数存在し、それぞれが処理を実行することで、正しく動作することがわかってくるはずです。システムによっては、ログを格納するために別のサーバと連携している場合や、ユーザを認証するためにログイン情報を格納したデータベースと同期している場合もあります。プロジェクトにもよりますが、一つのシステムを理解するためには、複数の方式設計書から構成を読み解く必要もあります。目的が達成されるまでの一連の動作を、ここでしっかりと理解しておきましょう。

ポイント2:サーバダウンは何台までOK?冗長構成を把握せよ!

方式設計書には、システムの耐障害性についても明記されています。絶対に止められないような重大な情報をやり取りするシステムや、システムが止まることで業務に大規模な影響が出る場合は、耐障害性を高めるために、最低限n+1以上の冗長構成にします。

n+1とは、システムを2台のサーバ(メイン)で動かす場合、他に予備として1台のサーバ(サブ)を常時待機させ、メインのサーバが1台停止しても、サブのサーバが代わりに稼働することで、業務影響を出さない(または最小限に食い止める)構成のことです。他の冗長構成として2nや、サブの電源をつけたまま待機させるホットスタンバイ、電源はつけないものの、起動させればすぐに切り替えられるウォームスタンバイ、電源もつけず、切り替えの準備もしないコールドスタンバイなどがあります。

<PR>人材不足はシステム運用の現場が抱える大きな課題。駆け出しエンジニアだって貴重な即戦力になれます。
プロ向けの機能も楽々操作で使えるのは、SaaS型の統合運用管理サービス「UOM」!詳しくはこちら

構成と冗長性を理解したら、再読

この2つのポイントを押さえながら、もう一度、設計書を見てみましょう。複数台のサーバによってシステムが冗長化されていることに気がつくはずです。そして、システム障害発生時に、何台までのサーバダウンが許容され、待機しているサブのサーバは、どのようにしてメインのサーバと動作するのかが分かります。

冗長構成によっては、コールドスタンバイのサーバをメインとして稼働させるために、手動でオペレーションが必要な場合があります。また、サブのサーバをメインとして起動させた場合、業務に影響は出ないものの、普段使用していたシステムの管理画面の一部が使用できなくなることもあります。

例えば、Excelシートで自分なりのまとめを

冗長構成を理解する場合、構成の記載はあっても、起こり得る事象が記載されていないこともあり、方式設計書だけでは読み解くことが難しいこともあります。実際にシステム障害が発生して慌てないためにも、必ず運用手順書も併せて確認するようにしてください。

また、構成を理解するには、例えばExcelシートを活用する方法があります。方式設計書から構成を理解する上で大切だと思う部分を、コピー&ペーストで張り付けていきましょう。管理するサーバが多い場合や冗長構成が複雑な場合、方式設計書上でページをまたがって記載されていることがあります。自分なりに工夫してコンパクトにまとめておくと、構成をスムーズに見直せます。

ただ、Excelはあくまでも表計算ツール。どこの職場にも導入されている手軽さもあり、小規模なシステムであれば使えなくはないとはいえ、遅かれ早かれ限界が来ることも忘れずに。

大まかな構成を説明できるぐらいに把握しよう!

プロジェクトに参画してから一週間程度を目安に、方式設計書を見なくても、大体の構成が口頭で説明できるようにしましょう。構成が理解できていないと、いざシステム障害が起きたときに、指示された内容が理解できず的外れな対応をしてしまったり、障害の再発防止策を考えるときに案が思い浮かばず、苦しむことになります。

運用手順書通りのオペレーション業務なら、誰にでもできます。最低限、自分の担当プロダクトの構成を理解し、イレギュラーな事象にも対応できるスキルを身につけましょう。例えば、ルーチンワークとなっていたExcel作業の代わりに、UOMのような統合型システム運用サービスを使えば、時間的・心理的なゆとりも確保できます。さらにワンランク上の、システム運用・保守エンジニアを目指しましょう。

<PR>設計書をざっと見て、構成を理解して冗長構成を把握する。システム運用の基本とはいえ、重要なスキルです。
そんなビギナーでもカンタンに使えるのが、SaaS型の統合運用管理サービス「UOM」!詳しくはこちら

関連記事

∞∞∞∞∞∞∞ おすすめ記事 ∞∞∞∞∞∞

  1. SREって大規模な組織の話?開発と運用をチームにするメリットとは?

    システム運用に関する話題の中でもたびたび目にする機会が増えてきた「SRE」。これは、「サイトリライア…
  2. 「オブザーバビリティ」を導入すると得られるメリットは?

    前回、「オブザーバビリティ:Observability(o11y)」は「システム内部の様々な情報をデ…
  3. RPAに絶望した人へのソリューション提案:(株)コムスクエア様インタビュー

    RPAに絶望した人へのソリューション提案:(株)コムスクエア様インタビュー

    左からIIJの福原と五十島、(株)コムスクエアの田嶋さんと露木さん 株式会社コムスクエア 執行役…
  4. アウトソーシングの目的は「人減らし」じゃない!:現場のプロに聞いてみた(11)

    イレギュラーが起きてもシステムを止めない!サポートの覚悟:現場のプロに聞いてみた(9)

    あけましておめでとうございます。 本年も「運用ナビ」をどうぞよろしくお願いいたします。この一年が、…
  5. 無駄な手順から見直そう:もう一度システム運用を考える(3)

    一般的には、発生した障害を通知するアラートの多くは、事前に作成された手順書に基づいて対応します。想定…
ページ上部へ戻る