設計Design
動く前に、決めておく。
ITインフラの設計は、構築に入る前に「何を、どの水準で、どう実現するか」を文書で決めておく工程です。サーバー、ネットワーク、ストレージ、クラウド、セキュリティ、バックアップ、監視のそれぞれについて、要件を構成と設定値に落とし込み、関わる人が同じ完成形を思い描ける状態をつくります。構築と運用は、この段階でつくる設計書をもとに進みます。
要件を整理する要件定義
何のための
業務に必要な機能に加えて、止まってもよい時間、応答の速さ、データを残しておく期間、扱う情報の重要度といった非機能要件を明らかにします。なかでも、稼働率（システムが使える状態にある時間の割合）は数値で決めておきます。1年（365日）あたりに直すと、99.9%で約8.8時間、99.99%で約53分の停止に相当し、9が一つ増えるごとに、許される停止の時間は10分の1になります。障害のとき、どの時点のデータまで戻せればよいのか。止まってから、どれくらいの時間で使える状態に戻すのか。この二つも、目標復旧時点・目標復旧時間（RPO・RTO）として数値の目標にします。こうした数値が、その後の設計で迷ったときの判断のよりどころになります。
非機能要件の整理に役立つ資料に、独立行政法人情報処理推進機構（IPA）が公開した「非機能要求グレード2018」があります。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの六つの大項目に沿って要求を整理し、漏れを防ぐための枠組みです。
全体の構成を決める基本設計
方式と
多くの現場で「基本設計」と呼ばれる段階です。オンプレミスか、クラウドか。どこか一か所が壊れても全体が止まらないよう、単一障害点をどう減らし、機器や経路をどこまで冗長化するか。ネットワークをどう分け、どこで通信を制御するか。利用者数やデータ量とその増え方を見積もり、CPU・メモリ・ストレージ・回線の必要量を出します（サイジング）。少なすぎれば処理が追いつかず、多すぎればコストがかさみます。決めた内容はシステム構成図やネットワーク構成図にまとめ、なぜその構成にしたのかを設計書に残します。
守り方を決めるセキュリティ設計
誰が、
アカウントと権限の分け方、認証の方式、通信と保存データの暗号化、許可する通信と止める通信、ログの取得と保管期間、マルウェア対策、セキュリティパッチの適用方針を決めます。基本は、必要な人に必要な分だけの権限を渡すこと（最小権限）と、外部からつながる入口を、できるだけ少なくすることです。クラウドでは、事業者と利用者の責任の分かれ方が、使うサービスによって変わります。そこで、何を事業者に任せ、何を利用者側で守るのかを、最初に明確にします。
設定値まで落とし込む詳細設計
決めた方式を、
ホスト名、IPアドレス、VLAN、ルーティング、OSやミドルウェアの設定、アカウントと権限、監視のしきい値。こうした値を一つずつ決め、パラメータシート（設定値の一覧）にまとめます。これが構築手順書のもとになります。値を決めることと、その値を設定することを分けておくと、人によって結果が変わりにくくなり、のちの変更や調査も進めやすくなります。
動かし方を先に決める運用設計
つくる前に、
何を監視し、どの値を超えたら誰に知らせるのか。バックアップはいつ、どこに取り、要件で決めた目標復旧時点・目標復旧時間をどう満たすのか。障害が起きたときの連絡と対応の流れ、計画停止やパッチ適用の進め方。運用をシステムができてから考えるのではなく、設計の段階から組み込んでおくことが、安定した稼働への近道だと私たちは考えています。
確かめ方を決める試験計画
何ができたら
設定値の確認、機器どうしの通信、片方が止まったときの切り替わり、負荷をかけたときの性能、バックアップから実際に戻せるか。こうした項目と手順、合格の条件を、構築の前に書き出しておきます。設計書は構築の手引きであるだけでなく、試験で「設計どおりか」を判定する基準にもなります。試験の進め方を考えるうちに、設計のあいまいな点にも早く気づけます。
このページで触れた資料へのリンクは、「用語と資料」の「参照した主な資料」にまとめています。