プロフィール
管理者:しらせ(HN)
とあるIT企業のインフラエンジニア。プライベートでは開発もちょっとやります。
※本ブログの内容はすべて個人の見解であり、所属する企業とは関連ありません。
カテゴリ別
内部リンク
[PR]
Twitter
来訪
257132 [合計]
96 [今日]
152 [昨日]
Powered by
Powered by AWS Cloud Computing

ByProduct - FukuSanButsu Blog

ふくさんぶつBlog

開発系インフラエンジニア

インフラを学ぶ学生や企業のIT担当者のために



【第3回】社内インフラエンジニアのために(企画~リリース③)

Date:2020/05/24 14:24:37
Category:インフラ


前回:【第2回】社内インフラエンジニアのために(企画~リリース②)
お疲れ様です。
しらせです。

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

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

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


もくじ

  1. 計画:企画書
  2. 要件定義:要件定義書
  3. システム構成検討
  4. 設計:基本設計・運用設計、詳細設計
  5. 構築:構築手順書、運用手順書
  6. テスト:テスト仕様書・結果報告書 ★今回
  7. 展開計画 ★今回
  8. リリース ★今回


テスト(テスト仕様書・結果報告書)

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

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

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

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

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

書式例

テスト種別テスト項目テスト内容想定結果実際結果受け入れ可否担当者実施日
1.正常系テスト1.xx機能動作テスト操作xxを行うxxが動作するxxが動作したAさん2020/x/x
2.yy機能動作テスト操作yyを行うyyが動作するyyが動作しない不可(1回目)Aさん2020/x/x
yyが動作した可(2回目)Aさん2020/x/x

項目例

  1. 正常系テスト
    1. xx機能動作テスト
    2. yy機能動作テスト
  2. 準正常系テスト
    1. <xx障害時>
      1. xx機能動作テスト
      2. yy機能動作テスト
    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か月程度はモニタリングを続けて不測の事態に備えます。



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


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



以上
お疲れ様でした。



Views:107 この記事をツイート!