別紙でポート収容表を用意します。, 機器間のケーブル媒体、規格、色、タグの書式を定義します。  基盤面 :ディスクバックアップ、アクセスログ取得等, ・情報(データ)や情報システムへのアクセスを制限するために、利用者IDの管理(パスワードの管理など)を行う。, ・インターネット接続に関わる不正アクセス対策(ファイアウォール機能、パケットフィルタリング、ISP サービス 等)を行う。, ・ソフトウェアの選定や購入、情報システムの開発や保守に際して、情報セキュリティを前提とした管理を行う。, 出典:IPA『中小企業における組織的な情報セキュリティ対策ガイドライン』,pp.7-8, 単体テスト・結合テスト・総合テスト・運用テストといった各テスト工程について、プロジェクトの特性に応じて、下記のような観点を記載する。, システム機能だけでなく、データ移行や新業務への移行等、プロジェクトの特性に応じて移行方法を記載する。, 要件定義では、定常運用・臨時運用・障害時運用における要件を記載したが、基本設計段階では、各要件を実現するに当たっての運用保守業務設計、および必要な環境や機能の設計を行う。, 運用保守業務に入る本番移行前〜フォロー期間にて詳細な内容を検討し、運用保守契約を締結することとなる。, 最初に述べたように、作成する成果物やテンプレートや書き方は、企業の標準としてまとめられている場合もあるので確認してほしい。, @IT『システム間連携のアーキテクチャ、4つの基本パターンと正しい適用のポイント徹底解説』.  3-2.帳票設計 基本設計=外部設計、What(何を作る)詳細設計=内部設計、How(どのように作る) 基本設計書の目次例。 1. また、時刻同期先のNTPサーバの情報を記載します。, 機器のOS、アプリケーションが出力するログの一覧を記載します。   3-2-4.帳票出力項目一覧 機能要件2. ※改善箇所があれば、コメントをもらえると嬉しいです!, ドキュメントリリース後の更新履歴を表で記載します。 また、セキュリティパッチの適用方針有無、対象についても一覧で記載します。, 機器に設定するアカウントの一覧とその役割を記載します。 ログローテーション周期、圧縮有無、保存世代数も記載します。, 監視運用のため、SNMPポーリングを許可するアクセス元IPアドレス、コミュニティ名を記載します。 HAクラスタを組む場合は、データ同期方式について記載します。, 機器の部品(電源、ファン、ディスクなど)について、冗長化する箇所を記載します。   3-4-2.テーブル・ファイル一覧   3-2-5.帳票編集定義  3-3.バッチ設計 以下の内容も整理しておくと良いでしょう。, 対象機器、データについて定義します。  4-1.性能設計 情報システムの画面や帳票、バッチ処理などの作るべき機能を全て洗い出す 2.   3-1-5.画面アクション定義 QoS分類について、トラフィック種別、プロトコル、ポート番号を一覧で定義します。 また、SNMP Trapを使用する場合は送信先SNMPマネージャも記載します。  1-3.システム化業務一覧   3-5-1.外部システム関連図 企業のシステムは通常、データセンタや企業内のサーバルームに設置されますが、その際に「効率良くハードウェアを設置できるように」と規格化された収納製品のことです。通常は大型冷蔵庫のような大きさがあり、設置したい機器を支柱などに固定して収納していきます(図3は弊社の研修室に設置されたラック。研修用のサーバが整然と収納されている)。, こうして見るとあっさりしていますが、さらに要素分解すると実際には多くの種類のソフトウェアがあります。OSであれば「Windows Server」や「Red Hat Linux」や「Ubuntu」などのLinux、「HP-UX」や「AIX」などのUNIX、ミドルウェアであればアプリケーションサーバ製品やデータベース製品などがあります。ミドルウェアの場合は「WebLogic」や「Oracle Database」といった製品名を聞いた方がピンとくるかもしれません。, ここまで解説した内容をまとめると、インフラとは多くの要素で成り立っていることが分かります(図4)。改めて“インフラ”という領域の広さと奥深さを実感すると思います。これらの要素は技術革新により日々バージョンアップされ、また要素自体が追加されたり減少したりするため、インフラエンジニアは常に世の中にアンテナを張り巡らして勉強し続けています。, 今回は各要素や専門用語等について細部まで解説しませんでしたが、次回以降は下記の予定で詳しく解説していきます。, 第2回:サーバ第3回:ネットワーク第4回:仮想化、クラウド第5回:ミドルウェア(Web、AP、DB)第6回:ミドルウェア(システム運用)第7回:構築とテスト第8回:インフラエンジニアの仕事, 本コラムでは、連載を通してインフラエンジニアが関わる「プロジェクト」に注目して、さまざまな側面から解説していきます。, システムを作ることが決まると「プロジェクト」が発足されます。このプロジェクトの進め方にはいくつか方法がありますが、日本における大規模システムでは「ウォーターフォール型」を採用しているプロジェクトが多数派を占めます。2017年現在で弊社が携わるプロジェクトもほとんどこの型です。, ウォーターフォール型開発とは、誤解を恐れずに書けば「計画をしっかり立てて1回で完成品を作ろう」とするやり方です。カレー作りに例えると、食べる人達の食材や味付けの好みをしっかりとヒアリングし、材料や作業を漏れなく設計して作っていくやり方です。メリットはカレーを提供できる時間やコストを事前に把握できることですが、デメリットは材料が足りなかったり作業が遅れたりした時に弱いことです。, ユーザー企業からすると事前に予算やコストが分かるので、上司や役員に報告しやすく都合が良いという側面があるのもメリットと言えるでしょう。, しかし、1人で作るカレーなら漏れなく計画できそうですが、何千人も関わって作る大規模なシステムならどうでしょうか。実際にプロジェクトの終盤になって「必要な作業が計画されていなかった」とか「この日数では作りきれない」、「できると宣言したけどできなかった」といったことが起きています。, これらのメリットやデメリットをどのように捉えるかで、ウォーターフォール型に批判的な考えもあります。できるインフラエンジニアはこのようなことが少なくなるように知識や経験を積んだり、普段から色々なプロジェクトの情報を仕入れたり、自分で事前に検証したりしています。, ここまで、インフラについて大まかに理解できたのではと思います。ここからは実際のシステム構成を見ながら、もう少しイメージを膨らませていきましょう。, 図5は、企業における一般的なシステム構成です。様々なコンピュータがそれぞれの役割を担いながら、相互に接続することで1つのシステムが成り立っています。, まず特筆すべきは、「クライアント」と「サーバ」に役割が分かれている点です。システム利用者が使うコンピュータであるクライアントと、サービスを提供するコンピュータであるサーバに分けて、相互にネットワークで接続する形をとっています。このような構成を「クライアント・サーバシステム」と呼びます。皆さんがこれから関わるシステム構成もこの形が多いのではと思います。, クライアント・サーバシステムの中でも、最近ではさらにクライアント側のソフトウェアとして「Webブラウザ」を使用するシステムが主流となっています。一昔前まではクライアント側に専用のクライアントアプリケーションをインストールして、サーバ側のアプリケーションと通信するといったシステムが主流でした。インターネットの普及とともにWebブラウザの汎用性や画面表示能力が上がってきたため、クライアントソフトウェアとしてWebブラウザを使用するシステムが選択されるようになってきています。, 私がまだ新人の頃に某銀行のシステム更改に携わったことがありますが、行員が使用する数千台のパソコン(クライアント端末)に専用のクライアントソフトウェアをインストールして設定し、サーバとの通信を確認するという単純作業を休日3日返上で実施したことがあります。現在ではWebブラウザがデフォルトでインストールされているので、このような作業は不要になりました。, 「Web3層構造」とはWebシステムの典型的な構成であり、下記の3つの役割のサーバから成り立っています。, システムによってはWebサーバとAPサーバを1台に統合したり、Webサーバがなかったりなどしますが、基本的には上記の3層でクライアントからの処理に対応する構成をとります。, 弊社が行っているLinuxでWeb3層システムを構築する研修では、実際に3台のサーバと1台のストレージを使用しています。各サーバの役割は受講者が決めることができるので、OSをインストールする際は図6のように付箋で目印をつける人もいます。実際にはデータセンタに置かれているサーバにはテプラを使用したきれいな識別テープを貼るのですが、テープをインフラエンジニアが作成することもあり、普段の頭を使う仕事から離れて妙に単純作業に没頭してしまうといった話はインフラエンジニアあるあるかもしれません。, 上記の3つのサーバを中心に、さらにユーザー認証が必要なシステムであれば「認証サーバ」や監視・ジョブ管理などを行う「運用関連サーバ」などが周辺を固めていきます。また、それぞれのサーバを接続したり、アクセスを制御したりするために各種のネットワーク機器やセキュリティ機器が配置されていきます。, このように、インフラエンジニアは上記のハードウェアやソフトウェアの設計・構築を行い、アプリケーションが動く“インフラ“を提供しています。, 今回は、第1回として“インフラ全般”をテーマに全体を広く浅く解説しました。今回の内容を読んで、インフラが扱う領域の広さに期待と不安が入り混じった感情をおぼえたのではと思います。本連載を通じて現場の状況等も加味しながら、そのような不安を少しでも解消できるように分かりやすく解説していきます。, 次回は、インフラエンジニアにとって切っても切り離せない”サーバ”をテーマに解説します。併せてストレージやOSについても解説しますので、楽しみにしていてください!, 「OSSfm」は“オープンソース技術の実践活用メディア”であるThink ITがお届けするポッドキャストです。, 某SIerを経て株式会社BFTの設立に関わり、現在は取締役エンジニア部門長。大学在学中にネットワーク技術に魅せられてIT業界へ入るも、新人時代には障害解析のためApacheのソースコードを永遠と読まされ、危うくITが嫌いになりかける。Apple製品の元コレクターでもあり、実家には40台近いAppleII,AppleIII,Macなどが転がっている。趣味はスカッシュだが、大会では0勝。.   3-3-3.バッチ処理定義 詳細設計以降に具体的な手順を作成するので、この段階では概要レベルでよいです。. 運用をMSP企業にアウトソースする場合、保守運用設計はインプットとなる情報なので、重要な設計項目です。, システムが動作し続けるために実施する必要のある業務の一覧を記載します。  1-4.新業務フロー インフラシステムの提供機能が多い場合、この章は別ドキュメントで個別の基本設計書にしてもよいでしょう。 マーキングについて、トラフィック種別、プロトコル、DCSP種別を一覧で定義します。, 帯域制御を実施する目的、対象通信種別、対象機器について記載します。  2-1.ハードウェア構成図 また、筐体の冗長化について、対象範囲、使用する機能やプロトコルを記載します。 ファイウォールやロードバランサといったL4〜L7の通信を扱う機器では、セッション同期、コネクション同期の方式について記載します。, 機器の部品(電源、ファン、ディスクなど)について、冗長化する箇所を記載します。 UPSの設置有無もこの項目に記載します。, 機器のポートをどういった順番で使用するか収容規則について定義します。 また、筐体の冗長化について、対象範囲、使用する機能やプロトコルを記載します。 インフラシステム(ネットワーク及びサーバ)の構築を目的としたプロジェクトで、基本設計書を作成する機会がありました。自分への備忘録も兼ねて、どのような内容を書けばよいか本ページに記載します。 オブジェクトに付与する命名規則を定義します。, ウイルスチェックを適用する通信プロトコルの一覧とそれに対するアクションの一覧を記載します。, Web機能を提供する機器、および社内/社外のクライアント端末を俯瞰した図を記載します。, 閲覧可能ネットワーク、ホスティングするWebコンテンツ種別、URL、通信プロトコルを記載します。, 外部から内部へ配送を行うメールについて、通信フロー、プロトコル、対象ドメインを記載します。, 内部から外部へ配送を行うメールについて、通信フロー、プロトコル、対象ドメインを記載します。, 送信元、宛先のネットワークアドレスやドメインに制限やルーティングを行う条件を記載します。 サーバ機器は監視ソフト付属のエージェントをインストールすることが望ましいですが、システム要件などで制約がある場合はひとまずSNMPで最低限の監視をします。, 保守運用設計では、リリース後にシステムを運転し続けるために必要な項目を記載します。 ©Copyright2020 若手プロマネの羅針盤.All Rights Reserved. 基本設計書と詳細設計書で、どちらに何をどこまで書くか、みたいなことです。 必要以上に細かく書きすぎると、メンテナンスが追いつかなくなり、結果として誰も設計書を見なくなります。 章立ての記載方法を合わせておく.  ・非機能要件設計, 要件定義書と同じく、企業によっては記載内容やテンプレートを整備している企業もあるので、まずは自社のルールを確認することをお勧めする。, ※当サイトでは、情報処理推進機構(以下、IPA)や行政機関の資料を参考に記載している。, 上記の中でも、IPAの資料は、具体的な書き方や検討のコツも紹介されているので、特に参考になると思う。, 1.業務設計 An Impress Group Company.   3-2-1.帳票一覧 大規模システムのインフラ詳細設計書は、 構造化して作らないといけない ネーミングルールを決めて、 詳細設計書(パラメータシート)は、複数のサーバに関しても、 コア部分(共通部分)を一つの設計書として作成し、 サーバごとの機能部分をそれぞれ別の詳細設計書として起こす。 コア  Oracle、DB2、SQL Server、MySQL、PostgreSQL等, ・アプリケーションサーバ  WAS、Tomcat、WebLogic、JBoss、Interstage等, 要件定義のざっくりとした内容を元に、システムを実装できるレベルまで具体的に記載しよう。, なお、入力項目でも、プルダウン(コンボボックス)のような選択項目の場合は、どこから値をセットするのか検討が必要となる。, 基本設計では、ユーザーがどのようなアクションをしたときに、システムがどのようなアクションを返すのかを具体的に記載する必要がある。, 例えば、上記サンプルでは、ログインボタンが押下されたときに「UsernameとPasswordの入力チェック」とだけ書いているが、どのようなチェックをするかまで具体的に書く必要がある。, ちなみに、入力チェックをクライアント側に実装するのか、それともサーバー側で実装するのかは、次の工程である「詳細設計(内部設計とも言う)」にて検討する。, 画面の出力項目と同じく、どのテーブルの、どの項目から値をセットするかまで記載が必要だ。, シンプルな帳票は「帳票出力項目一覧」で十分だが、複雑な編集方法を持つ帳票については、当資料を作成する。, 業務部門の利用者にとっては理解しづらい資料であるものの、画面や帳票との関係が深いため、基本設計でまとめておくべき資料である。, この資料も業務部門の利用者にとっては理解しづらい資料であるものの、基本設計で検討しておく資料だ。, 要件定義では業務上の主要なテーブルのER図を作成するが、基本設計では、システムを実現する上で必要なテーブルを全て書き出す。, 要件定義書に記載したテーブルはもちろんのこと、バッチ処理内で一時的に利用するテーブル(ワークテーブル)等の記載も書き出そう。, 前述のER図に記載したテーブルを一覧にまとめるだけでなく、機能の入出力で用いるファイル(txtやcsv等)についても記載する。, 上記図は、「テーブルと機能のCRUD図」だが、下記図のように「テーブル項目と機能とのCRUD図」を作成する場合もある。, >> @IT『システム間連携のアーキテクチャ、4つの基本パターンと正しい適用のポイント徹底解説』, 非機能要件設計の各資料には方針や考え方を記載し、具体的な設計内容は、アプリケーション機能や基盤設計の各資料に反映することとなる。, ・完全性 例:○○アプリケーションを動作させる基盤、社内メール基盤、お客様Webサーバを収容するDMZ環境…etc, システムがどのようなコンポーネントで構成されているか記載します。 「○○は△△する」という記述をするときの○○は必ず用語の定義の中に記載されるようにします。△△は、システム特有の動作を示す動詞の場合、これも用語の定義を行うようにします。, プロジェクトの構築体制図を記載します。図の中で、顧客側の体制(PM/PL/担当者)、社内体制(PM/担当営業/PL/担当者)がわかるようにします。 ホストごとの詳細なアサイン表は、別紙で用意します。, 通信種別、対象機器、NAT種別について一覧で定義します。 それぞれの機能が、ど …  ・システム方式設計 Powered by WordPress with Lightning Theme & VK All in One Expansion Unit by Vektor,Inc. 仮想機能を使用して物理的な機器に複数の機能を持たせている場合は、論理機器単位で図示します。, セグメント名、用途、VLAN IDを定義します。 正常時は、通信種別ごとにどのような経路を通るか図示します。 大規模プロジェクトで、サーバ担当、ネットワーク担当などチームが分かれている場合は、体制図をチームごとに分け、作成する基本設計書はどのチームが作成するものなのかを記載します。, 設計範囲について、図および表で記載します。既存システムとの接続要件や、他社ベンダが構築に絡む場合は、具体的な相互接続点の責任区分についても述べます。  1-1.システム化の背景・目的  4-6.移行方針   3-4-5.CRUD図   3-1-3.画面レイアウト  ・業務設計  1-5.システム化業務説明, 2.システム方式設計  3-4.テーブル・ファイル設計  2-2.ソフトウェア構成図  4-5.テスト方針 また、接続を許可するリモートアクセス元の環境についても記載します。, 機器に設定するタイムゾーンについて、UTCまたはJSTのどちらかを記載します。 この章では、インフラシステムの提供機能について、どのように動作するか記載します。 インフラシステムの提供機能が多い場合、この章は別ドキュメントで個別の基本設計書にしてもよいでしょう。 また、サーバ機器とネットワーク機器の括りで基本設計書のドキュメントを分ける場合もありますが、近年では専用アプライアンスの普及により区別が曖昧になってきています。本記事ではサーバ、ネットワークを一纏めにして、L4以上の分野は「インフラ機能」として定義します。   3-4-3.テーブル定義 パスワードは設計書に載せず、別の手段で運用担当者へ共有したほうがよいでしょう。, 機器ごとのログイン方式(SSHやWebUI)について記載します。  2-3.ネットワーク構成図  「データの欠損や不整合がないこと」の指標。 対象データは、OSイメージ、DBデータ、ログデータなどがあります。, 対象データごとに、フルバックアップ、差分バックアップ、増分バックアップなど方式を記載します。   3-1-4.画面入出力項目一覧   3-1-1.画面一覧 ポートのSpeed/Duplex、ネゴシエーション設定方針もここに記載します。 あくまでも一例ですが、 保守(システムをあるべき姿に保つために変更を加える作業)と、運用(システムを動かし続けるために必要な作業や確認)は厳密に異なりますが、それぞれが連携する業務が多いので、システム運用を行う組織内で保守を兼任する場合が多いです。 要件定義は、システム化構想の結果を受けて、「どんな業務にしたいのか検討し、その業務を実現するために必要なシステムを整理する」工程である。 ゆえに、要件定義書には「業務要件」と「システム要件(機能と非機能)」の2つを書けばよく、具体的な記載内容は決められていない。 とはいえ、担当者の能力で記載内容が変わるようでは、システム品質に差が出てしまうことから、記載内容やテンプレートを整備している企業も多い。 まずは自社ルールを確認してみる良いだろう。 ※当サイトでは、 … また、サーバ機器とネットワーク機器の括りで基本設計書のドキュメントを分ける場合もありますが、近年では専用アプライアンスの普及により区別が曖昧になってきています。本記事ではサーバ、ネットワークを一纏めにして、L4以上の分野は「インフラ機能」として定義します。, ポリシーで使用するオブジェクトを定義します。(アドレス、アドレスグループ、サービス、サービスグループ) エイリアスやメッセージサイズ上限、同時接続数といった項目も方針があれば記載します。, DNS機能を提供する機器、及び名前解決要求の送信元、転送先を俯瞰した図を記載します。, 管理対象ドメイン、マスター/スレーブの種別、ゾーン転送元/転送先について記載します。, システム全体の稼働時間(夜間や休日の停止を許容するのか)、後述の各要素の可用性設計を行うことによる目標稼働率について記載します。, 機器の部品(電源、ファン、ディスクなど)について、冗長化する箇所を記載します。 また、ロードバランサやUTMについては、同時セッション数も合わせて記載します。, この章では、将来的にリソース需要が増加した場合に、どの設計項目をどのように拡張できるか方針を示します。, 外部からの脆弱性を突いた攻撃をどのように防御するか方針を記載します。 technology.  4-4.情報セキュリティ設計 Copyright © 2004-2020 Impress Corporation. 版数は、0.01からはじめ、システムリリース時に1.00としてFIXさせます。 どの箇所でクロス/ストレートケーブルを使用するかも定義しておきます。, AWSやAzureなどのクラウド環境では、物理環境の代わりにクラウド環境の設計を行います。  機器の破損への対策、ログの取得など、定性的な書き方となることが多い。, ・完全性 異常時は、機器、ケーブルの障害ポイントごとに、どのような迂回経路をとるか図示します。, この章では、インフラシステムの提供機能について、どのように動作するか記載します。 版数管理のルールもここに記載します。   3-2-3.帳票レイアウト この道路の例のように、個々にフォーカスしていくとイメージしやすくなるため、下記のように単語を組み合わせて使うことも多いと思います。, ”インフラ”と単体で言うと抽象的で性質上捉えどころがないイメージですが、上記のように単語を組み合わせて使用することである程度範囲が限定されてイメージがしやすくなります。, 本連載で解説するのは上記で言うITインフラですが、それでは“システムにおけるインフラ”、ITインフラとは何を指すのでしょうか。「分けることは、分かること」とはよく言いますが、ここでインフラの構成要素を少し分解しながら見ていきたいと思います。, システムを要素分解すると第2階層、「アプリケーション」と「インフラ」に分けることができます(図1)。道路のくだりを思い出してほしいのですが、この場合はアプリケーションを車、インフラを道路にたとえることができます。アプリケーションを動作させるための下部構造をインフラが提供しているのです。, ここで、本筋からはズレますがアプリケーションについて補足します。例えば、八百屋の販売業務をシステム化する際には、まず野菜を販売する人が行っていることを理解する必要があります。領収書が必要と言われて発行する時もあれば、買物客の献立を聞いておすすめ(レコメンド)することもあるでしょう。そのようなすべての起こりうる業務や処理をJavaなどのプログラム言語を使用して事前に作りこんだものがアプリケーションです。通常は業務ごとにカスタマイズして作りますが、世の中の様々なありふれた業務はすでにパッケージ(製品)が提供されていることもあります。, もともとアプリケーションは「アプリケーションソフトウェア(応用ソフトウェア)」の略でソフトウェアの一種ですが、ここでは「業務やサービスに合わせて個別に作るもの」というイメージで理解しておいていただければ良いと思います。, まだ分かりにくいと思いますので、もう少し要素分解していきます。さらにインフラを要素分解すると第3階層、「ハードウェア」と「ソフトウェア(システムソフトウェア)」に分けることができます(図2)。本連載を読んでいるインフラエンジニアを目指す皆さんは、この両方をしっかり理解することが求められます。, 余談ですが、弊社が関わる大規模システムは10~30人くらいのインフラエンジニアで作っていくことが平均的ですが、この規模になるとサーバ系に強い人はサーバエンジニアとしてサーバを担当し、ネットワークに強い人はネットワークエンジニアとしてネットワークを担当する、といった分業制になることが多くなります。, また、上記以外にもハードウェアを設置するための「ラック」や電源まわりに関する話題を扱うこともあります。電源や荷重などの機器仕様を考えながらラックへの搭載位置を設計したり、機器の搬出入や各種工事を調整したりなど、大きなプロジェクトになると専任で複数名が必要になるくらいの仕事量になります。この作業に当たるエンジニアはインフラエンジニアの中でも特に「ファシリティエンジニア」と呼ばれたりします。, ラックとは   3-4-1.テーブル関連図   3-4-4.ファイル定義   3-1-2.画面遷移図 以下の内容について記載します。, どの機器が、どの論理的なネットワークで接続されているか記載します。 廃熱のための空きユニットスペース、ケーブルの整線方針もここで示しておきます。, 機器ごとの最大消費電力一覧と、収容するラック内の電源設備を一覧で記載します。  4-3.拡張性設計 インフラ案件であれば、システム基盤(ネットワーク及びサーバ)の外部的な動作の仕様を示す基本設計書である旨を記載します。, 基本設計書の位置づけを記載します。プロジェクト全体フェーズを図で示し、基本設計書を作成するためのインプット情報(要件定義書)、基本設計書をアウトプットとした後続フェーズの資料(詳細設計書)について定義します。, ドキュメントの中で使用する用語を定義する。