インフラ構築のプロジェクトで実施していること

## 0. プロジェクト準備
### ツールを整備する
#### ドキュメント管理ツールを整備する
* 目次を作成する
```
00_プロジェクト管理
  PJ概要
  スケジュール概要
  WBS
  確認事項一覧
  会議体
  勤怠ルール
  アカウント管理台帳
01_要件定義・基本設計
  非機能要件
  全体システム俯瞰
  アーキテクチャ構成
  ソフトウェア構成
  処理方式概要
  インフラコスト見積もり
02_詳細設計
  共通
    命名規則
    ジョブ一覧
  クラウド環境
  サーバ環境
  踏み台
  デプロイ
  監視
  バックアップ・リストア・改廃
  セキュリティ
03_開発
  開発規約
04_テスト
  テスト計画
  インフラ単体テスト
  インフラ結合テスト
  障害テスト  
  性能テスト
  セキュリティテスト
  運用テスト
05_運用
  運用体制
  接続先一覧
  アラート
  問い合わせ
  変更管理
  定型作業
20_議事録
```

#### チケット管理ツールを整備する
* ビューを作成する
    * Board: タスクステータス別（カンバン）
        * Open -> ToDo -> Doing -> Review -> Closed
        * 人別にも確認
    * Milestone: フェーズ・マイルストーン・スプリント別（1,2wごとなど）
    * Priority: 優先度別
        * 緊急で必須/必須/必須でない
    * Archived: 過去振り返り用
        * スプリント別人別の実績評価→次のスプリントの計画のインプットに
* 工数・ストーリーポイントはフィボナッチ数を設定する
* 割り込みタスクのコントロール
* 要件定義・設計チケットが残りがち。ドキュメント作成は開発チケットで実施するか
* Backlogは増えがち。期限だけは厳密に管理する（なので期限がないチケットは空欄で良いとする）

#### ソース管理ツールを整備する
* プロジェクトを作成する
* リポジトリを作成する
    * Protected Branches設定
    * デフォルトブランチ設定
    * 更新通知設定
    * 権限設定
        * インフラチーム以外もPR送れるようにするか
    * ルール決め
        * Squash and merge かとか
* インフラはmainブランチのみでいいのでは。検討する

### プロジェクト管理ドキュメント作成
* 「00_プロジェクト管理」のドキュメントを作成する
* 特に、マイルストーンを合意しておく。他システム・アプリと整合性の取れたスケジュールを作成する
* テストフェーズの環境利用計画も早めに決めておく
* 振り返りシートは初めから用意しておく

## 1. 要件定義・基本設計
* 「01_要件定義・基本設計」のドキュメントを作成する
* まずアーキテクチャ構成図作成→インフラコスト見積もり→（必要に応じて）経費申請など
* 非機能要件は[非機能要求グレード](https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html)を参考に

```
* 可用性
    * 運用スケジュール: 運用時間、計画停止、サービス切り替え時間
    * サポート時間
    * 目標復旧水準: RPO（目標復旧地点）、RTO（目標復旧時間）、RLO（目標復旧レベル）
    * 稼働率
    * 災害対策
* 性能・拡張性
    * 通常時の業務量
        * 利用者数、アクセス数、ピークタイム、データ量など
    * 業務量増大度
    * 保管期間
    * 性能目標値
        * レスポンスタイム、バッチウィンドウ
* 運用・保守性
* 移行性
* セキュリティ
    * ガイドライン
    * 監査対応
    * データ暗号化
    * 個人情報
* システム環境・エコロジー
```

* ポイント
    * アーキテクチャ設計
        * マルチテナントの場合は注意。どこを共通化するか
            * 後から乗ってくる場合に、すでに乗っているシステムも含めてテストが必要etc
    * 運用の優秀性、セキュリティ、可用性、性能、コスト
    * 関連する既存システムの構成・通信プロトコル
    * 製品・技術要素の指定があるか
        * 構成管理ツール
        * クラウドサービス
        * OS
        * デプロイツール
        * 監視ツール
        * バックアップ・リストア・改廃ツール
        * セキュリティツール
    * クラウド・ライセンスの契約
    * 外部サービスの利用制限
    * インフラコストの目処感の合意
    * NWアクセス経路のフィジビリティ確認（プロトコルも合わせて）
    * レスポンスタイム、バッチウィンドウの制約
    * 拡張方針
    * BCPの要否
    * セキュリティポリシーの有無
    * 運用保守ベンダの指定、関連ベンダ、役割分担
        * 特にマルチテナントの場合。インフラ担当を各チームで抱えるかetc
    * クラウドのサポート契約
    * 環境利用計画
        * Production環境、リリース前の試験環境、再現試験環境、etc

## 2. 詳細設計
* 「02_詳細設計」のドキュメントを作成する
* 設定はコードを見れば分かる。経緯を残す
* 監視は死活・リソース・ログ
    * 監視設定の工数を少なめに見積もらないこと
    * 監査ログと保存期間
    * ダッシュボード作成
* ポイント
    * IPレンジ設計
    * ロードバランサ設定: スティッキーセッション、タイムアウト、sorryページへの振り分け、ALB/CLB/ELBの選定（クライアント認証など）
    * 証明書、ドメイン
    * OS設定: su,sudoコマンド制限、パスワードログイン禁止、時刻同期、swap
    * DBメンテナンスウィンドウ、バックアップウィンドウ
    * デプロイ方式。瞬断が許されるか。
    * サーバーレスは起動時間、ウォームアップ時間に注意する
    * バッチ処理は[こちら](https://noko-htn.hatenadiary.com/entry/2020/02/02/011615)に記載されているような内容に注意する
    * ストリーミング処理はイベントの遅延・部分的な出力・障害時の状態の回復・読み取りや書き込みの分散処理に注意する
    * インフラのテスト環境も用意しておく（アプリチームの利用、本番運用が始まった後を見据えて）

## 3. 開発
* 「03_開発」のドキュメントを作成する+コーディング・構築作業を実施する
* ポイント
    * 権限付与の経緯・履歴は残す
    * 権限確認のため、インフラテスト用アカウントを作成しておく
    * 運用フェーズとかは、緊急で権限が必要になったりするから付与のフローを整備しておく
    * CICD: 初めにインフラのCI/CDを作っておく（必ずmainと一致させる、自動化で時間短縮。ブランチ、PRが溜まらないように）
        * Prdだけ、デプロイ前に人のチェックをいれる？
        * GigHub release使うか
        * 自動デプロイの時間を決めるか
        * CICDのためと、アプリチームに強い権限を渡し過ぎていないか

## 4. テスト
* 「04_テスト」のドキュメントを作成する・テストを実施する
    * 開始基準、完了基準、シナリオ、データ、環境、監視、体制
    * 障害一覧を作成して障害を管理する
* 結合テスト
    * 処理方式概要と対応
    * 業務処理・運用処理
* 障害テスト
    * 機能×障害発生箇所
    * 処理継続性、データ整合性、リカバリ方法、監視
* 性能テスト
    * 負荷・限界・耐久、ボリューム・実行時間・実行数
    * 機能追加の時は、既存システムと合わせて同時実行数に問題がないかなど
    * 性能目標・役割分担（誰が準備・実施・確認するか）を明確にしておく
    * 単体性能テスト・結合性能テスト・他領域含めた性能テスト
    * やり直しを想定してスケジュールを組んでおく
    * インフラチームがダッシュボードを事前に用意し、アプリチームに引き継ぎしておく

## 5. 運用
* 「05_運用」のドキュメントを作成する・運用引き継ぎを実施する
* 定型作業は、アカウント管理・キャパシティ管理・システムメンテナンス・システム監視・データ抽出・バックアップリストア、など
* 運用手順は確認手順まで記載する
* 運用引き継ぎの計画をたてておく。工数を見ておくこと