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

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