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

前回：【第２回】社内インフラエンジニアのために（企画～リリース②）
お疲れ様です。
しらせです。

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

設計から構築までがひと段落し、本番リリースに向けて着々と進めていくフェーズになります。
作ったシステムが想定通り動作しているか？従業員の利用開始に向けたサポートの準備はできているか？

ここではテストから実際のリリースまでを行います。

もくじ

テスト（テスト仕様書・結果報告書）

構築が一通り終わった後は、要件定義や基本設計でまとめた内容が充足されているかを確認するためにテストを実施します。

要件に沿ってテスト項目を作成し、想定した動作と、実際の動作をまとめてテスト仕様書とします。
システムが正常に動作している時の要件に沿ったテストを正常系テスト、システムに問題が生じた際の正常動作を準正常動作、それ以外の動作を異常系テストとします。

システム開発のようにバグを埋め込むようなテストもなく、構築したインフラ機器が想定した通りに動くことを確認することが目的です。
以下の項目は結合テストですが、サーバやネットワーク機器のドライブ故障や電源障害などの単体テストも必要です。

なお、テスト結果のまとめ方は以下のような項目で構成しています。
他にも「ダブルチェックの担当者は？」「承認者は？」など詰めていけば切りがないですが、大事なのは問題発生時に「ちゃんとテストされていたのか？」と言われて「少なくともテスト時には動いていた」が分かるようになっていることだと思います。

インフラと言えどもテストなくしてリリースはできません。

書式例

項目例

1. 正常系テスト
   
   1. ｘｘ機能動作テスト
   2. ｙｙ機能動作テスト
2. 準正常系テスト
   
   1. ＜ｘｘ障害時＞
      
      1. ｘｘ機能動作テスト
      2. ｙｙ機能動作テスト
   2. ＜性能テスト＞
      
      1. 負荷テスト
      2. 切り替えテスト
3. 異常系テスト
   
   1. サーバ障害テスト
   2. ネットワーク障害テスト
   3. 監視アラートテスト
   4. 復旧テスト

展開計画

テストが無事完了すると本番リリースに向けて進みます。

当初の計画に従って無理のない範囲で安全にリリースができるように計画を立てていきます。
いきなり本番リリースをするのではなく、関係者などの限られた範囲から徐々に広げていき、テストで見えてこなかった不具合や課題をつぶしながら進めるのが一般的です。
インフラ版のカナリアリリースという感じでしょうか？

サポートデスクが専用である場合は、事前にスケジュールやマニュアル類の読み合わせをするとスムーズです。

例

1. リリースの概要
   
   1. スケジュール
   2. リリース可否判断基準
2. リリースのフェーズ
   
   1. スモールスタート（一部）
   2. プレリリース（狭範囲）
   3. 本番リリース
3. 周知方法の検討
   
   1. メール、イントラ、チャット、張り紙etc
4. 利用マニュアルの整備
   
   1. 利用マニュアル＆FAQ
   2. 問い合わせ方法
   3. 受付業務手順
5. サポートデスクへの連絡

リリース

展開計画に従って無事リリースがなされると晴れてプロジェクトが一旦の完了を迎えます。
リリース後はシステムの安定性や負荷の予測がつかない事も多く、数週間から長くて1か月程度はモニタリングを続けて不測の事態に備えます。

すべての作業に抜けや漏れがないかを確認し、必要な成果物が揃っていることをチェックします。
プロジェクトの締めくくりには振り返りを実施して、上手くいった点や改善が必要な点を関係者全員で出し合って次回に繋げる工夫などもおすすめです。

以上で「計画～リリース」のフェーズはおわりです。
次回から「安定化」のフェーズに入ります。

以上
お疲れ様でした。