【第２回】社内インフラエンジニアのために（企画～リリース②）

前回：【第１回】社内インフラエンジニアのために（企画～リリース①）

お疲れ様です。
しらせです。

『社内インフラエンジニアのために』
「企画～リリース」のフェーズ②です。

要件やシステム化の検討結果をもとにしてシステム全体の設計を行います。
基本的にインフラの設計では外部設計や内部設計はありません。※ある場合もあります。

ここでは基本設計・運用設計と詳細設計を通して実際のシステム構築と手順書の作成を進めていきます。

もくじ

設計（基本設計・運用設計）

基本設計では、構築するシステムについて「何を使って」「どうやって」などの実装のHowやルールを中心に記載していきます。

インフラは読んで字のごとく基本的に停止しないものとして見られるのが普通ですが、どうしても停止or縮退させないといけなメンテナンスは発生します。
その際は何曜日の何時から作業をすることで業務への影響を最小化できるのかもあらかじめ検討します。
またその場合、何日前までにどのように周知するかも合わせて考慮出来ていると混乱を少なくすることができます。

どんな内容を台帳として記録する必要があるか？
システムの変更は誰の承認のもとでどのように記録するか？
手順書は何を使ってどんな書体で残すか？
などなど、管理者の視点でもあらかじめ定義できるものは整理してまとめておきます。

ベースとなるような項目を中心に記載していますが、構築するシステムによっても内容は異なりますので必要に応じて適宜追加・削除してよく検討します。

1. 初めに
   
   1. 本書の目的
   2. 用語
   3. 別紙
2. 基盤システム設計
   
   1. 機器構成
   2. OS設計（利用OS、ホスト名ルール）
   3. ソフトウェア/ミドルウェア
   4. クラウドサービス
3. 物理拠点設計
   
   1. 利用拠点
   2. フロア・ラック
   3. 機器設置場所
4. ストレージ設計
   
   1. 記憶域設計
   2. 耐障害設計
5. ネットワーク設計
   
   1. ネットワーク構成
   2. 接続スイッチ・ポート
   3. 利用セグメント
   4. ネットワーク冗長化・負荷分散
6. バックアップ設計
   
   1. バックアップ対象
   2. バックアップ方法
   3. リストア方法
7. 災害対策
   
   1. 拠点災害対策
   2. 遠隔地データ保護
   3. システム切り替え
8. サービス設計
   
   1. 提供機能
   2. 提供方法
9. サービス運用設計
   
   1. メンテナンスウィンドウ
   2. メンテナンス周知方法
   3. 障害時周知方法
10. システム運用設計
    
    1. 管理者の定義
    2. 権限管理
    3. 台帳管理
    4. 変更管理
    5. フォーマット仕様（手順書、図）
11. システム監視設計
    
    1. 監視対象
    2. 監視項目
    3. 監視方法
12. セキュリティ設計
    
    1. マルウェア対策
    2. 脆弱性対策
    3. 監査ログ保管
    4. モニタリング
13. 廃棄
    
    1. 機器廃棄
14. テスト
    
    1. テスト対象
    2. テスト方法

その他、個人的に「電算星組」さんの以下のサイトがとても参考になります。

インフラ構築案件で作成する基本設計書記載内容
https://densan-hoshigumi.com/nw/infra-basic-design

設計（詳細設計）

基本設計に続いて詳細設計を進めます。
インフラにおける詳細設計は主に機器やソフトウェアに対して設定を入れるためのパラメタシートを指します。

パラメタシートは、既定値からの変更点が分かるように落とし込みます。
これは、デフォルト値がセットされて変更が可能な項目については、バージョンアップや修正パッチの適用やオペミスで意図せず変わってしまうことがあるためで、設定するしないに関わらずすべて列挙してまとめるのがベターです。

特にパラメタシートは次の構築手順書とリンクさせて利用することが多いため、項目名や項番は統一した書式にしておくとわかりやすくなります。

リリースして運用が始まってしまうとこの一覧の管理はかなり厳しいものになるので、このような場合でも構成管理ツール(後述)を使うことで運用負荷は軽減できます。

＜例＞

その他、システム全体図、ネットワーク通信図などの細かい仕様も基本設計のフォーマットに基づいてすべてドキュメントに落とし込みます。

1. パラメタシート（基本設計における仕様すべてに関する）
2. システム全体図
3. ネットワーク通信図

構築（構築手順書）

構築手順書には大きく2つの意味があります。

①システムに対して手を入れた個所とその変更方法をまとめる
②同一環境を再度作る際の二度手間防止

最近ではChef,Ansible,Pupet,DSCなどの構成管理ツールの利用も盛んで、GUI/CLIを操作して手動で変更をすることが少なくなってきているかと思います。

構成管理ツールを利用する場合でも、ツール自体をどのように操作をすることで環境が作れるのかを構築時の手順として残しておくことで、引継ぎや担当者の入れ替わりの際にも有効です。

また構築手順書には、どんな画面でどのような操作をしたのかを視覚的にわかるように操作のキャプチャ画像を添えておくと見やすくなります。

個人的な意見ですが、Chefはとっかかりが難しいですが分かってしまえば便利ですね。
DSCはMicrosoft標準で使えるため、余計なパッケージを入れなくていいという点がメリットではありますが、操作できる範囲が限られていてまだ微妙なところもあります。
※DSCはまたどこかでまとめてみます。

参考

構成管理ツール「Chef」の概要とインストール手順 - Codezine
Puppetが開発した新たな構成管理ツール「Bolt」を使ってみる - さくらのナレッジ
Windows 用 Desired State Configuration (DSC) の概要 - Microsoft

構築（運用手順書）

運用手順書はシステム管理者向けのマニュアルです。

運用手順書はいつ作ってもよいのですが、システムの構築と合わせて作ると後戻りもなくスムーズです。
構築手順書の作成時に撮りためたキャプチャやソフトウェアの操作方法などをベースにするとより楽になります。

この時に、基本設計書に沿ってシステムを操作できる管理者はどんな条件が必要でどんな権限・端末・ソフトウェアが必要なのかを明示しておくと後で困りません。

1. 初めに
   
   1. 本書の目的
   2. 用語
   3. 別紙
2. 管理者概要
   
   1. 管理者条件
   2. 必要権限
   3. 必要端末
   4. 必要ソフトウェア
3. 定常運用
   
   1. システム起動・停止手順
   2. ｘｘ運用
   3. ｙｙ運用
   4. ｚｚ依頼対応
4. 非定常運用
   
   1. ｘｘ障害対応
   2. ｘｘアラート対応
   3. ｘｘ切り替え対応

今回は設計から構築までを通してまとめました。
次回はテストからリリースに進みます。

以上
お疲れ様でした。