運用設計書 テンプレート。 PM初心者でも出来る?プロジェクト計画書の作り方~無料サンプル付き!~

【設計】みんなが知っておくべき運用設計のノウハウ を読んだメモ

運用設計書 テンプレート

Contents• はじめに この章では、ドキュメントに関する決め事を記載します。 更新履歴 ドキュメントリリース後の更新履歴を表で記載します。 版数は、0. 01からはじめ、システムリリース時に1. 00としてFIXさせます。 版数管理のルールもここに記載します。 例:版数はx. xzで管理する。 xはシステム新規構築、リプレース時に増加させる。 yはサブシステムの追加、削除、変更時に増加させる。 zは、サブシステム内の軽微なパラメータ修正時に増加させる。 本書の目的 作成するドキュメントが、何のプロジェクトの、どの部分の基本設計書なのか記載します。 インフラ案件であれば、システム基盤 ネットワーク及びサーバ の外部的な動作の仕様を示す基本設計書である旨を記載します。 ドキュメント体系 基本設計書の位置づけを記載します。 プロジェクト全体フェーズを図で示し、基本設計書を作成するためのインプット情報 要件定義書 、基本設計書をアウトプットとした後続フェーズの資料 詳細設計書 について定義します。 用語の定義 ドキュメントの中で使用する用語を定義する。 プロジェクト体制 プロジェクトの構築体制図を記載します。 大規模プロジェクトで、サーバ担当、ネットワーク担当などチームが分かれている場合は、体制図をチームごとに分け、作成する基本設計書はどのチームが作成するものなのかを記載します。 基本設計範囲 設計範囲について、図および表で記載します。 既存システムとの接続要件や、他社ベンダが構築に絡む場合は、具体的な相互接続点の責任区分についても述べます。 ネットワーク設計であれば、外部システムへ接続するケーブルは範囲に含むかどうかを明記します。 サーバ設計であれば、ミドルウェア、アプリケーションをどこまで含むかを明記します。 システム設計 この章では、基本設計を実施するインフラシステムの全体方針を記載します。 システム概要 設計するシステムの概要を記載します。 全体構成図および構成一覧表 提供するシステムの機能、それに紐付く機器やソフトウェア を記載します。 機器一覧 機器用途、機器型番、選定理由を記載します。 機器緒元 別紙で機器緒元一覧を用意します。 ソフトウェア一覧 サーバ種別ごとに、インストールするソフトウェア名、バージョン、用途を記載します。 バージョンの選定方針も記載します。 物理設計 この章では、物理的な機器や配線に関する決め事を記載します。 クラウド環境のみの場合はこの章は不要です。 物理構成図 WAN WAN網を中心に置き、通信を行うデータセンタやオフィス拠点を記載します。 物理構成図 LAN 拠点内に設置する機器間の配線図を記載します。 接続するケーブル種別やポート番号も記載します。 フロア図 機器を設置する場所がフロア内のどのラックなのか図示します。 ラック収容設計 ラック内のどのユニット番号の位置に機器が設置されるか図示します。 機器の電源を接続する電源ユニットもラック収容図の中で表します。 廃熱のための空きユニットスペース、ケーブルの整線方針もここで示しておきます。 電源収容設計 機器ごとの最大消費電力一覧と、収容するラック内の電源設備を一覧で記載します。 UPSの設置有無もこの項目に記載します。 ポート収容設計 機器のポートをどういった順番で使用するか収容規則について定義します。 別紙でポート収容表を用意します。 インターフェース設計 機器間のインターフェース規格は何を使うのか記載します。 ケーブル設計 機器間のケーブル媒体、規格、色、タグの書式を定義します。 クラウド環境設計 AWSやAzureなどのクラウド環境では、物理環境の代わりにクラウド環境の設計を行います。 以下の内容について記載します。 使用サービス• プラン• 用途 仮想ネットワーク設計 仮想ロードバランサ設定 仮想サーバインスタンス設計 仮想ストレージ設計 論理設計 この章では、機器の論理的構成について記載します。 ネットワーク設計 ホスト名設計 機器ホスト名の命名規則を定義します。 論理構成図 どの機器が、どの論理的なネットワークで接続されているか記載します。 仮想機能を使用して物理的な機器に複数の機能を持たせている場合は、論理機器単位で図示します。 VLAN設計 セグメント名、用途、VLAN IDを定義します。 ネットワークの規模に応じて、百の位、十の位でフロアや用途を分けたり、IPアドレスの第3オクテットを使用するルールを決めると運用時に便利です。 IPアドレス設計 採番方針、セグメント名、ネットワークアドレス、対応するVLAN ID、用途を定義します。 ホストごとの詳細なアサイン表は、別紙で用意します。 プライベートIPアドレス• グローバルIPアドレス ルーティング設計 機器別の使用ルーティングプロトコル一覧、各プロトコルの方針を記載します。 WANルータ• 拠点L3SW• 全体構成図にアドレス変換ポイントを記載した図を用意します。 トラフィック制御設計 優先制御 優先制御を実施する目的、対象通信種別、対象機器について記載します。 QoS分類について、トラフィック種別、プロトコル、ポート番号を一覧で定義します。 マーキングについて、トラフィック種別、プロトコル、DCSP種別を一覧で定義します。 帯域制御 帯域制御を実施する目的、対象通信種別、対象機器について記載します。 WANルータの回線側インターフェースで回線帯域へ通信速度を合わせるためによくこの機能が使われます。 トラフィックフロー設計 正常時と異常時それぞれにおける、パケットの通信経路を記載します。 正常時は、通信種別ごとにどのような経路を通るか図示します。 異常時は、機器、ケーブルの障害ポイントごとに、どのような迂回経路をとるか図示します。 トラフィックフロー 正常時• トラフィックフロー 異常時 サーバ設計 Windows 時刻と言語 使用する時刻 タイムゾーン と言語を記載します。 ディスク構成 RAID利用有無について記載します。 パーティション構成 パーティションのフォーマット、パス、サイズ、役割を記載します。 役割と機能 Windows Serverで使用する役割と機能について記載します。 RHEL 時刻と言語 使用する時刻 タイムゾーン と言語を記載します。 ディスク構成 RAID利用有無について記載します。 パーティション構成 パーティションのフォーマット、パス、サイズ、役割を記載します。 パッケージ インストールするパッケージ グループ を記載します。 インフラ機能設計 この章では、インフラシステムの提供機能について、どのように動作するか記載します。 インフラシステムの提供機能が多い場合、この章は別ドキュメントで個別の基本設計書にしてもよいでしょう。 また、サーバ機器とネットワーク機器の括りで基本設計書のドキュメントを分ける場合もありますが、近年では専用アプライアンスの普及により区別が曖昧になってきています。 本記事ではサーバ、ネットワークを一纏めにして、L4以上の分野は「インフラ機能」として定義します。 ロードバランサ設計 機能概要 ロードバランサがどのような機能を提供するのか記載します。 対象機器一覧 ロードバランサ機能を提供する機器の一覧を記載します。 負荷分散対象 負荷分散対象となる機能、機器一覧を記載します。 負荷分散方式 負荷分散方式の方針および対応一覧を記載します。 ヘルスチェック方式 ヘルスチェックの方針を記載します。 パーシステンス方式 セッション維持のためにどのような通信にパーシステンスを適用するのか記載します。 UTM設計 機能概要 UTMがどのような機能を提供するのか記載します。 ゾーン設計 ゾーン名、用途、適用インターフェースを定義します。 オブジェクト設計 オブジェクト一覧 ポリシーで使用するオブジェクトを定義します。 アドレス、アドレスグループ、サービス、サービスグループ オブジェクトに付与する命名規則を定義します。 アンチウイルス設計 ウイルスチェックを適用する通信プロトコルの一覧とそれに対するアクションの一覧を記載します。 スパイウェア設計 適用プロトコルの一覧とそれに対するアクションの一覧を記載する。 ファイルブロッキング設計 適用プロトコルの一覧とそれに対するアクションの一覧を記載する。 公開Web設計 閲覧可能ネットワーク、ホスティングするWebコンテンツ種別、URL、通信プロトコルを記載します。 内部Web設計 閲覧可能ネットワーク、ホスティングするWebコンテンツ種別、URL、通信プロトコルを記載します。 SMTP設計 機能概要 SMTP機能を提供する機器、及びメールの転送元、転送先を俯瞰した図を記載します。 外部SMTP 外部から内部へ配送を行うメールについて、通信フロー、プロトコル、対象ドメインを記載します。 内部SMTP 内部から外部へ配送を行うメールについて、通信フロー、プロトコル、対象ドメインを記載します。 メール配送制御 送信元、宛先のネットワークアドレスやドメインに制限やルーティングを行う条件を記載します。 エイリアスやメッセージサイズ上限、同時接続数といった項目も方針があれば記載します。 DNS設計 機能概要 DNS機能を提供する機器、及び名前解決要求の送信元、転送先を俯瞰した図を記載します。 キャッシュDNS 名前解決要求を受け付ける送信元、名前解決要求の転送先を記載します。 可用性設計 この章では、システムの可用性について記載します。 基本方針 システム全体の稼働時間 夜間や休日の停止を許容するのか 、後述の各要素の可用性設計を行うことによる目標稼働率について記載します。 ネットワーク機器 機器の部品 電源、ファン、ディスクなど について、冗長化する箇所を記載します。 また、筐体の冗長化について、対象範囲、使用する機能やプロトコルを記載します。 ファイウォールやロードバランサといったL4〜L7の通信を扱う機器では、セッション同期、コネクション同期の方式について記載します。 サーバ機器 機器の部品 電源、ファン、ディスクなど について、冗長化する箇所を記載します。 また、筐体の冗長化について、対象範囲、使用する機能やプロトコルを記載します。 HAクラスタを組む場合は、データ同期方式について記載します。 ストレージ機器 機器の部品 電源、ファン、ディスクなど について、冗長化する箇所を記載します。 また、筐体の冗長化について、対象範囲、使用する機能やプロトコルを記載します。 ネットワーク 以下の事項について、どの機器でどのような機能やプロトコルによって実現させるか記載します。 回線冗長化• 経路冗長化• リンク冗長化 性能設計 この章では、システムの性能について記載します。 ネットワーク機器 スループット bps や応答値 ms について性能目標を記載します。 また、ロードバランサやUTMについては、同時セッション数も合わせて記載します。 サーバ機器 サーバが提供するインフラ機能について、単位時間あたりの処理数を記載します。 物理拡張性 物理的な回線帯域や、機器のスケールアップ、スケールアウトの可否を記載します。 回線帯域 WANルータ 拠点L3SW サーバ 論理拡張性 論理的な構成要素について、拡張可否、拡張時の方針を記載します。 VLAN IPアドレス セキュリティ設計 脆弱性対策 外部からの脆弱性を突いた攻撃をどのように防御するか方針を記載します。 また、セキュリティパッチの適用方針有無、対象についても一覧で記載します。 マルウェア対策 マルウェア対策を行うサーバ、導入するアンチウイルスソフトを一覧で記載します。 アクセス制御 各システムコンポーネントに対して、アクセス制御の方式と条件を記載します。 データ暗号化 通信データ、ストレージデータについて、暗号化対象と方式を定義します。 管理機能設計 アカウント設計 機器に設定するアカウントの一覧とその役割を記載します。 パスワードは設計書に載せず、別の手段で運用担当者へ共有したほうがよいでしょう。 リモートアクセス設計 機器ごとのログイン方式 SSHやWebUI について記載します。 また、接続を許可するリモートアクセス元の環境についても記載します。 時刻同期設計 機器に設定するタイムゾーンについて、UTCまたはJSTのどちらかを記載します。 また、時刻同期先のNTPサーバの情報を記載します。 名前解決設計 各機器の名前解決利用有無、方式、名前解決先を記載します。 ログ設計 機器のOS、アプリケーションが出力するログの一覧を記載します。 ログローテーション周期、圧縮有無、保存世代数も記載します。 SNMP設計 監視運用のため、SNMPポーリングを許可するアクセス元IPアドレス、コミュニティ名を記載します。 また、SNMP Trapを使用する場合は送信先SNMPマネージャも記載します。 サーバ機器は監視ソフト付属のエージェントをインストールすることが望ましいですが、システム要件などで制約がある場合はひとまずSNMPで最低限の監視をします。 保守運用設計 保守運用設計では、リリース後にシステムを運転し続けるために必要な項目を記載します。 保守 システムをあるべき姿に保つために変更を加える作業 と、運用 システムを動かし続けるために必要な作業や確認 は厳密に異なりますが、それぞれが連携する業務が多いので、システム運用を行う組織内で保守を兼任する場合が多いです。 運用をMSP企業にアウトソースする場合、保守運用設計はインプットとなる情報なので、重要な設計項目です。 保守運用業務一覧 システムが動作し続けるために実施する必要のある業務の一覧を記載します。 以下の内容も整理しておくと良いでしょう。 保守と運用の区分 担当部署が分かれている場合• 誰が行うか 人 or 自動化• いつ行うか 定常 or 非定常 定常業務 以下のように定期的に発生する業務について、実施周期と作業概要を記載します。 [保守]• セキュリティパッチ適用 計画• SSL証明書更新 [運用]• バックアップ• ログローテーション• ジョブ実行• 製品EoL情報管理• ベンダ保守契約情報管理• 定期レポート作成 非定常業務 以下のように都度発生する業務について、実施の契機と作業概要を記載します。 [保守]• セキュリティパッチ適用 緊急• 障害対応 復旧作業• ソフトウェアバージョンアップ• 機器増設 拡張性設計に準拠した内容• 機器設定変更 [運用]• 障害対応 アラート切り分け、正常性確認• 監視対象 監視対象の機器一覧、監視項目、監視監視プロトコルを記載します。 監視項目 以下のような監視項目ごとに、値取得間隔、閾値を定義します。 死活監視• トラフィック監視• プロセス監視• ポート監視• ログ監視• HW状態監視• サービス応答監視 バックアップ・リストア設計 基本方針 バックアップの目的、対象機器、データ種別、バックアップ手段の概要を記載します。 バックアップ バックアップ対象 対象機器、データについて定義します。 対象データは、OSイメージ、DBデータ、ログデータなどがあります。 バックアップ方式 どのような方式でバックアップし、どのストレージに保存するか記載します。 バックアップポリシー 対象データごとに、フルバックアップ、差分バックアップ、増分バックアップなど方式を記載します。 日次、週次、月次などバックアップスケジュールも記載します。 リストア リストア基本方針 バックアップ対象について、どういった場合にリストアを行うのか記載します。 リストア方式 バックアップ対象を、どのデータでどういった手段でリストアするのか記載します。 障害対応設計 基本方針 データ保全を優先させるのか、サービス復旧を優先させるのかなど、対応の基本方針を記載します。 詳細設計以降に具体的な手順を作成するので、この段階では概要レベルでよいです。 対応契機 障害対応を開始する契機を記載します。 例: 監視検知、ユーザ申告 切り分け 複数機器で異常を検知した場合、どのような切り分けをするか記載します。 ネットワーク: Ping試験、トラフィックグラフの確認• ハードウェア: リモート管理ボードの異常表示有無の確認• OS: CPU、メモリ、ディスクに関するリソース異常有無の確認• ミドルウェア: サービス起動状態、ポートリッスン状態の確認 対応内容 障害の原因となっている箇所に応じて、どのような対応をするか記載します。 共通: サービス切り離し、対応完了後のサービス切り戻し• ハードウェア: 筐体交換を保守ベンダへ依頼• OS: バックアップからリストア• ミドルウェア: バックアップからリストア.

次の

機能一覧

運用設計書 テンプレート

単体テスト 結合テスト 機能テスト システムテスト(負荷テスト、ボリュームテスト、セキュリティテスト etc 受け入れテスト(シナリオテスト) 運用テスト リグレッションテスト 現場によっては、 「開発エンジニア」がテストしたり、また 「QAエンジニア」がテストしたりと異なります。 私の意見としては、 「開発エンジニア」と 「QA担当者」が確認すべきではないかと。 単体テストの実施は、 開発者が担当します。 また、 結合テスト以降のテストは QAエンジニア、もしくはQAテスターが担当する。 単体テストのルールや 網羅性は開発とQAが一緒に考えることが品質を良くする上で大事です。 お互いテストの意義というものを見直すこともできます。 また、仕様を理解している企画や開発者。 テスト設計やテストの種類を知っているテスト担当者が協力しあうことが品質を高めるのではないでしょうか。 特にスタートアップでは、要件機能仕様書も無いので。 コミュニケーションという点では。 テスト仕様書を作成しテストケースを用意する 「テスト計画」、「テスト設計」をし、「テスト仕様書」を作成します。 もちろん、「レビュー」も必要となりますので、見積には追加。 テスト工程は、テスト工程のケースのみチェックする。 何を担保しているテストケースかわからなくなり 工数を増やす要因となる。 各部署との確認を明確化する。 無いからわかりません。 やりませんでしたと無いように、テスト準備段階で確認する。 ・無駄なケースが無いか確認する。 直交表やAllpair法を使用し、必要なケースのみ。 ・前提条件を必ず記載していること。 レビュー者の負担もある。 ・大項目、中項目、小項目、前提条件、操作方法は、わかりやすく。 「単体テスト」、「結合テスト」、「システムテスト」 テスト自動化だけでは難しいので箇所によっては、やはり手動になってしまう。 開発用テストケースです。 設計書の動作だけではなく、設計書に記載していない箇所もテストケースに入れます。 あとは、Webブラウザ単位にテスト。 バージョン単位にテスト。 想定は、WEB系のQAチームになります。 ナレッジはありますが、開発者との距離が離れてしまう懸念もあります。 しかし、開発者では気がつかない不具合を検出するには良いと思います。 テストデータ問題がある。 どれだけ用意したらいいのか。 ここは難しいですね。 どういう方法で作成すれば?? 1. テストデータツールを使用 PICT(Pairwise Independent Combinatorial Testing tool) Excelプラグインツールに「PictMaster」 テスト設計例 テスト仕様書に落とし込むまでの設計作成例です。 テスト仕様書を全てレビュー、例えば数千件のテストケースをレビューするのかというと現実的ではありません。 今回は例として「氏名」・「電話番号」・「住所」の設計となります。 確認項目は、下記の確認項目に紐づけテスト仕様書を作成する形となります。 カラムの追加がある場合は確認。 またテストデータ更新、追加した場合の値の確認。 logに出力。 テスターにわかりやすいように、テスト詳細や、前提条件などを用意。 重要度「高」「中」「低」やテスト区分「正常系」「異常系」も設定します。 テスターは、期待値が実測値とあっているかを確認し、テスト結果をプルダウンから選択 「OK」 「NG」 「PN」を作成。 また、不具合管理票にも記載しましょう。 「OK」は、期待値と実測値が同じである 「NG」は、期待値と実測値が異なっている 「PN」は、テスト環境不備やテストケース自体実行できない場合 4. バグ検出率や、テストケース消化率を算出できるように。 ここはExcel関数を使用して集計を楽にしましょう。 テストデータ 2. テスト環境の確認 DBに接続できる、対象のテーブルがある、phpのバージョンが正しい トップシート ここで各シートの計算を表示しています 1. テストケース件数 2. テスト消化件数 3. バグ検出率 4. テスト消化率 テストシート テスト仕様書のテンプレート化 案件、その都度作成しては、作成工数やレビュー工数が膨れ上がってしまいます。 そのため、全体の機能のテンプレートを進めることにより作成者依存がなくなり、品質の偏りもなくなります。 不具合の記載 テストケースには、テスト結果項目でNGを選択。 再現手順をバグ管理システムに登録する。 一般的には、JiraやRedmineが使われることが多い。 Backlogも。

次の

テスト仕様書

運用設計書 テンプレート

はじめに タイトルの通りですが、運用って意外に難しいですよね。 仕事でも個人でもサービスを作りあげる事は何度もあるのに、 それでもこんな事ありませんか?• 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ... ローンチしちゃったから走りながら設定変える辛い... いや無理かも.. ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ... 読んだ本 もくじ• 基本設計フェーズ• 基本設計とは• 読んだ感想 この章では基本設計における運用設計とはという形で説明されています。 いわゆる基本設計自体はわかりやすいものの 基本設計時に行う運用設計とは?その書き方は?という所がとても参考になりました。 基本設計とは 基本設計は、要件定義を基にシステムの具体的な仕組みを決定する。 運用設計担当としては以下を検討する• 運用に必要な情報の取りまとめ• 運用項目書一覧• 各運用ごとに以下を運用設計書に記載する• 実施タイミング• どこで• なにを• どのように 役割分担を決める インフラ・アプリチームが基本設計、運用設計チームが運用設計書を作るなど分担する。 基本設計• 「どこで」「なにを」「どのように」がメイン• 運用設計• 「いつ」「誰が」「なぜ」がメイン 後続ドキュメントを意識する 運用設計書は、運用担当者が日々使うドキュメントを作成するためのドキュメントとなるようなものを書く。 運用設計書• 登場人物の役割を記載した対製図• 運用フローを作成する上で必要• 運用項目一覧• 何の手順書を作成するかに必要• 運用実施タイミング• 台帳はいつ更新しなければならないのか• 運用担当者が日々確認するドキュメント• 運用フロー• 手順書• 一覧 3. 運用設計書記載項目 大きく分けて以下の3つ• 共通項目• ITILプロセス項目• システム基盤項目 1. 共通項目• はじめに• 本書の目的• 本書の構成• 対象読者• 運用設計方針• システム概要• システム構成図• 運用体制• 運用フロー図や連絡先一覧の作成に必要• 関係者の役割、所属、対応時間、連絡方法、場所など• 作業者、承認者、確認車があればその体制• 業務運用• 人事システム運用• 経理システム運用• Web予約システム運用• 保守運用• システムのライフサイクル• 運用項目書一覧• サービスカタログと混同されがちだが別物• サービスカタログは利用者に提供するサービス一覧• 運用項目書は、サービスを提供するシステム運用の定常作業、臨時作業の一覧• 以下が書かれる• 作業名• 作業概要• 発生頻度• 実施者 2. ITILプロセス項目• インシデント管理• どこか1つに集めるシングルポイントを作ると管理がうまくいく• 各運用ごとにちらばってると分析できない• 問題管理• インシデントの中で解決が必要なものを問題管理として扱う• 費用対効果を基に解決するかどうかを判断する箇所を作る• システムの計画、手順、設計、運用を変更する場合のるs句、作業の正当性を管理する• きちんとやるには高コスト• リリース種別を決めて、種別ごととで管理基準をつける• 構成管理(サービス資産管理)• CI(Configuration Item)とその管理方法について記載• ハードウェア• ネットワーク• ソフトウェア• 問題点は「担当者が気を抜くと更新を忘れる」項目• 鉄の掟を作る• ツールを駆使して更新漏れをなくす• 情報セキュリティ管理• セキュリティ対策など• サービスレベル管理(SLA)• どの程度の品質を保証するかの合意• SLA違反をしたら罰則があるのか、何があるのか、努力目標か、必須達成目標か• 可用性管理• 稼働率• オンライン時間• 定期メンテ時間• 拡張計画• リソース枯渇に対する拡張計画• 報告すべき内容を検討・合意する 3. システム基盤項目 インフラチームと連携して作る運用設計書• ジョブ管理• 自動化している作業の一覧や概要• バックアップ・リスト運用• バックアップ方針、対象、リストアトリガー• ログ管理• 障害調査用、監査用 運用項目一覧を合意する 運用のランニングコストを概算することができる• 定常作業はどのくらいあるか、何時間くらいかかるか• データセンターにかけつける作業はあるか、どのくらいの頻度か•

次の