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

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_要件定義・基本設計」のドキュメントを作成する
まずアーキテクチャ構成図作成→インフラコスト見積もり→（必要に応じて）経費申請など
非機能要件は非機能要求グレードを参考に

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

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

2. 詳細設計

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

3. 開発

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

4. テスト

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

5. 運用

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