また、時刻同期先のNTPサーバの情報を記載します。, 機器のOS、アプリケーションが出力するログの一覧を記載します。 運用をMSP企業にアウトソースする場合、保守運用設計はインプットとなる情報なので、重要な設計項目です。, システムが動作し続けるために実施する必要のある業務の一覧を記載します。

機能要件2. 例:版数はx.xzで管理する。xはシステム新規構築、リプレース時に増加させる。yはサブシステムの追加、削除、変更時に増加させる。zは、サブシステム内の軽微なパラメータ修正時に増加させる。, 作成するドキュメントが、何のプロジェクトの、どの部分の基本設計書なのか記載します。   3-5-3.外部インターフェース項目定義 全体構成図および構成一覧表(提供するシステムの機能、それに紐付く機器やソフトウェア)を記載します。, サービス名、帯域、インターフェース、アクセス回線種別、Act/Stb系を一覧で記載します。, サーバ種別ごとに、インストールするソフトウェア名、バージョン、用途を記載します。  3-1.画面設計 また、セキュリティパッチの適用方針有無、対象についても一覧で記載します。, 機器に設定するアカウントの一覧とその役割を記載します。

別紙でNAT/NAPTアドレス対応表を用意します。, 優先制御を実施する目的、対象通信種別、対象機器について記載します。

 4-3.拡張性設計

マーキングについて、トラフィック種別、プロトコル、DCSP種別を一覧で定義します。, 帯域制御を実施する目的、対象通信種別、対象機器について記載します。 また、サーバ機器とネットワーク機器の括りで基本設計書のドキュメントを分ける場合もありますが、近年では専用アプライアンスの普及により区別が曖昧になってきています。本記事ではサーバ、ネットワークを一纏めにして、L4以上の分野は「インフラ機能」として定義します。, ポリシーで使用するオブジェクトを定義します。(アドレス、アドレスグループ、サービス、サービスグループ)   3-2-1.帳票一覧   3-3-1.バッチ処理フロー

 2-2.ソフトウェア構成図 All rights reserved. 「○○は△△する」という記述をするときの○○は必ず用語の定義の中に記載されるようにします。△△は、システム特有の動作を示す動詞の場合、これも用語の定義を行うようにします。, プロジェクトの構築体制図を記載します。図の中で、顧客側の体制(PM/PL/担当者)、社内体制(PM/担当営業/PL/担当者)がわかるようにします。   3-5-2.外部インターフェース一覧  3-5.外部インターフェース設計  3-2.帳票設計 以下の内容も整理しておくと良いでしょう。, 対象機器、データについて定義します。  ・アプリケーション機能設計

また、筐体の冗長化について、対象範囲、使用する機能やプロトコルを記載します。

 1-2.システム化の対象範囲 本連載では、これからIT業界(特にインフラエンジニア)に踏み出そう、または踏み出したいと思っている方向けにインフラの基礎知識を解説していきます。 「インフラ」は大学の情報学科でもなかなか教えていない分野で認知度も低く、特に新卒採用では仕事内容を理解してもらうところに最も力を入れます。私たちはインフラエンジニア250名を擁する会社として数々のシステムに携わってきましたが、その経験を基に現場の状 … また、接続を許可するリモートアクセス元の環境についても記載します。, 機器に設定するタイムゾーンについて、UTCまたはJSTのどちらかを記載します。

 1-3.システム化業務一覧 あくまでも一例ですが、 異常時は、機器、ケーブルの障害ポイントごとに、どのような迂回経路をとるか図示します。, この章では、インフラシステムの提供機能について、どのように動作するか記載します。 大規模プロジェクトで、サーバ担当、ネットワーク担当などチームが分かれている場合は、体制図をチームごとに分け、作成する基本設計書はどのチームが作成するものなのかを記載します。, 設計範囲について、図および表で記載します。既存システムとの接続要件や、他社ベンダが構築に絡む場合は、具体的な相互接続点の責任区分についても述べます。   3-1-1.画面一覧 日次、週次、月次などバックアップスケジュールも記載します。, データ保全を優先させるのか、サービス復旧を優先させるのかなど、対応の基本方針を記載します。  1-1.システム化の背景・目的

ファイウォールやロードバランサといったL4〜L7の通信を扱う機器では、セッション同期、コネクション同期の方式について記載します。, 機器の部品(電源、ファン、ディスクなど)について、冗長化する箇所を記載します。 Copyright © 2004-2020 Impress Corporation.   3-3-3.バッチ処理定義

 3-4.テーブル・ファイル設計 保守(システムをあるべき姿に保つために変更を加える作業)と、運用(システムを動かし続けるために必要な作業や確認)は厳密に異なりますが、それぞれが連携する業務が多いので、システム運用を行う組織内で保守を兼任する場合が多いです。   3-4-5.CRUD図

基本設計は、情報システムを実現するために何をどう作ればいいのかを決める作業です。情報システムを作る作業の中では、要件定義の次にある作業です。 基本設計では以下のようなことを行います。 1.

正常時は、通信種別ごとにどのような経路を通るか図示します。  4-6.移行方針 WANルータの回線側インターフェースで回線帯域へ通信速度を合わせるためによくこの機能が使われます。, 正常時と異常時それぞれにおける、パケットの通信経路を記載します。   3-1-5.画面アクション定義  Oracle、DB2、SQL Server、MySQL、PostgreSQL等, ・アプリケーションサーバ インフラ案件であれば、システム基盤(ネットワーク及びサーバ)の外部的な動作の仕様を示す基本設計書である旨を記載します。, 基本設計書の位置づけを記載します。プロジェクト全体フェーズを図で示し、基本設計書を作成するためのインプット情報(要件定義書)、基本設計書をアウトプットとした後続フェーズの資料(詳細設計書)について定義します。, ドキュメントの中で使用する用語を定義する。  「データの欠損や不整合がないこと」の指標。

Zabbix 5.2 インストール手順(CentOS8 / Apache2.4 / PHP7.2 / MySQL8.0), 【Ansible】CentOSのISOファイルからパッケージをオフラインインストール, Tomcat 9.0のインストール・設定・Webアプリケーションデプロイ (CentOS 8).

基本設計書と詳細設計書で、どちらに何をどこまで書くか、みたいなことです。 必要以上に細かく書きすぎると、メンテナンスが追いつかなくなり、結果として誰も設計書を見なくなります。 章立ての記載方法を合わせておく. インフラシステムの提供機能が多い場合、この章は別ドキュメントで個別の基本設計書にしてもよいでしょう。 パスワードは設計書に載せず、別の手段で運用担当者へ共有したほうがよいでしょう。, 機器ごとのログイン方式(SSHやWebUI)について記載します。 HAクラスタを組む場合は、データ同期方式について記載します。, 機器の部品(電源、ファン、ディスクなど)について、冗長化する箇所を記載します。 エイリアスやメッセージサイズ上限、同時接続数といった項目も方針があれば記載します。, DNS機能を提供する機器、及び名前解決要求の送信元、転送先を俯瞰した図を記載します。, 管理対象ドメイン、マスター/スレーブの種別、ゾーン転送元/転送先について記載します。, システム全体の稼働時間(夜間や休日の停止を許容するのか)、後述の各要素の可用性設計を行うことによる目標稼働率について記載します。, 機器の部品(電源、ファン、ディスクなど)について、冗長化する箇所を記載します。

インフラシステム(ネットワーク及びサーバ)の構築を目的としたプロジェクトで、基本設計書を作成する機会がありました。自分への備忘録も兼ねて、どのような内容を書けばよいか本ページに記載します。 An Impress Group Company.  2-1.ハードウェア構成図

サーバ機器は監視ソフト付属のエージェントをインストールすることが望ましいですが、システム要件などで制約がある場合はひとまずSNMPで最低限の監視をします。, 保守運用設計では、リリース後にシステムを運転し続けるために必要な項目を記載します。 版数は、0.01からはじめ、システムリリース時に1.00としてFIXさせます。   3-4-3.テーブル定義 また、SNMP Trapを使用する場合は送信先SNMPマネージャも記載します。   3-5-4.外部インターフェース処理概要, 4.非機能要件設計 ポートのSpeed/Duplex、ネゴシエーション設定方針もここに記載します。

この道路の例のように、個々にフォーカスしていくとイメージしやすくなるため、下記のように単語を組み合わせて使うことも多いと思います。, ”インフラ”と単体で言うと抽象的で性質上捉えどころがないイメージですが、上記のように単語を組み合わせて使用することである程度範囲が限定されてイメージがしやすくなります。, 本連載で解説するのは上記で言うITインフラですが、それでは“システムにおけるインフラ”、ITインフラとは何を指すのでしょうか。「分けることは、分かること」とはよく言いますが、ここでインフラの構成要素を少し分解しながら見ていきたいと思います。, システムを要素分解すると第2階層、「アプリケーション」と「インフラ」に分けることができます(図1)。道路のくだりを思い出してほしいのですが、この場合はアプリケーションを車、インフラを道路にたとえることができます。アプリケーションを動作させるための下部構造をインフラが提供しているのです。, ここで、本筋からはズレますがアプリケーションについて補足します。例えば、八百屋の販売業務をシステム化する際には、まず野菜を販売する人が行っていることを理解する必要があります。領収書が必要と言われて発行する時もあれば、買物客の献立を聞いておすすめ(レコメンド)することもあるでしょう。そのようなすべての起こりうる業務や処理をJavaなどのプログラム言語を使用して事前に作りこんだものがアプリケーションです。通常は業務ごとにカスタマイズして作りますが、世の中の様々なありふれた業務はすでにパッケージ(製品)が提供されていることもあります。, もともとアプリケーションは「アプリケーションソフトウェア(応用ソフトウェア)」の略でソフトウェアの一種ですが、ここでは「業務やサービスに合わせて個別に作るもの」というイメージで理解しておいていただければ良いと思います。, まだ分かりにくいと思いますので、もう少し要素分解していきます。さらにインフラを要素分解すると第3階層、「ハードウェア」と「ソフトウェア(システムソフトウェア)」に分けることができます(図2)。本連載を読んでいるインフラエンジニアを目指す皆さんは、この両方をしっかり理解することが求められます。, 余談ですが、弊社が関わる大規模システムは10~30人くらいのインフラエンジニアで作っていくことが平均的ですが、この規模になるとサーバ系に強い人はサーバエンジニアとしてサーバを担当し、ネットワークに強い人はネットワークエンジニアとしてネットワークを担当する、といった分業制になることが多くなります。, また、上記以外にもハードウェアを設置するための「ラック」や電源まわりに関する話題を扱うこともあります。電源や荷重などの機器仕様を考えながらラックへの搭載位置を設計したり、機器の搬出入や各種工事を調整したりなど、大きなプロジェクトになると専任で複数名が必要になるくらいの仕事量になります。この作業に当たるエンジニアはインフラエンジニアの中でも特に「ファシリティエンジニア」と呼ばれたりします。, ラックとは