はじめに
タイトルの通りですが、運用って意外に難しいですよね。
仕事でも個人でもサービスを作りあげる事は何度もあるのに、
それでもこんな事ありませんか？
- 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...？
- ローンチしちゃったから走りながら設定変える辛い...いや無理かも..
- ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ... サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば
システムの運用を事前に設計するのって難しいなーと思っていたところで
この本を見かけて読んでみたので、自分用に整理したメモです。
読んだ本
もくじ
- テストフェーズ
- 5.1.テストとは
- 5.2.テストの種類と内容
「書籍のメモ」をつづっていきますが
「自分の感想」には「※ hogehoge」という形で記載しています。
読んだ感想
この章ではテストにおける運用テストとはという形で説明されています。
テストの分野は本当におくが深いので
個人的にはいわゆるQA/QC的な意味合いでのテストも別で勉強したいなと思いました。
5.1.テストとは
運用設計としてのテストフェーズは運用テストを行うこと
テスト仕様書
- 項目
- テスト項目番号
- テスト項目名
- 実施内容詳細（手順）
- 合否判定基準
- 実施結果
- 実施年月日
- 実行者
- 課題管理晩冬
- 項目とは別にあると良いもの
- テスト計画書
- テスト実施環境
- テストの目的
- 概要
- 実施前提
- 全体の実施予定
問題の管理方法
ランク付けして管理すると良い
- ランク
- 高
- 問題の対応/回避方法が不明
- 対方方法は明確だが、スケジュールや費用に影響がある
- 中
- 問題の対応/回避方法は明確
- 方法が複雑で他の要素への影響が懸念される
- 低
- 問題の対応/開放法は明確
- 他の要素への影響はなく即時対応可能
5.2.テストの種類と内容
- 構築側のテスト
- 要件定義 = システムテスト（System Test: ST）
- 要件定義書を基に、サービスに問題がないか
- 要件定義書にかかれたユースケースのテスト
- 要件が満たせる性能が発揮できるか、負荷テスト
- 基本設計 = 結合テスト（Integration Testing: IT）
- 基本設計書を基に、インフラのミドルウェア間連携やアプリのモジュール間のデータ連携を検証
- 異常系のテストも実施
- ジョブを途中で止めた場合など
- 詳細設計 = 単体テスト（Unit Test: UT）
- 詳細設計やパラメータシートを基に行う
- 機器やサービスの起動・停止も行う
- 運用テスト（operations test: OT）
- 運用フローの検証
- 実施トリガー
- 申請がトリガーの場合、承認されるルート、内容など
- 監視検知トリガーの場合、適切な担当者が検知するか、適切なメールがくるか
- 担当者間をまたがるデータのやりとり
- 担当をまたがるデータがある場合、その方法と内容を検証
- 分岐、繰り返しの判断基準の正当性
- 実施箇所と判断基準が誤ってないか
- インプットデータ、アウトプットデータの整合性
- 運用手順書の検証
- 運用フローから呼び出される場合は、運用フローテストの項目の１つ
- 運用項目一覧に記載してある作業がすべて実施できれば完了
おわりに
テストする事自体も大事ですが、
その後の対応や管理が雑な現場、プロジェクト、個人（自分も含めて）は多いです。
こういうところもきっちりできるようになっていきたいですね＼(＾o＾)／
紹介
