UD Day 21 機能外要件

運用・保守要件などの機能外要件として何があるか、それぞれどのような考えをしたかについて述べます。

  1. 運用・保守要件
運用・保守においてありえる作業

以下は実際の要件定義書からの抜粋です。

(1) SW保守 

6〜10年程度のライフサイクルを想定する。    
利用するコンポーネントに応じて異なるが、GCEの場合にはOSアップ、GCSの場合にはMWアップ、GAEの場合にはアプリに対して、問題の検知と解決のための保守を実施する。
問題の経路としては主に以下を想定する
・ アプリケーション起因のバグ
・ ユーザーからのインシデント報告
・ 監視によって検知したエラー
別途PM計画書で規定する課題管理プロセスに従って、起票(検知)〜クローズまでを実施する。(問題 => 課題 => Action *)
*) 問題(インシデント:単なる事象)の検知 => 問題の分析により課題を浮かび上がらせる => 課題の解決のためのアクションを設定するの流れ。

(2) バックアップ

バックアップ
(3) サービスデスク    
アプリの設定項目より、ユーザーが改善、要望、クレームを送ることができる機能を設定し、運用者が通知を受けれるようにする。(もしくはメールで送信されるような形)
(4) IT運用    
自動化できない作業をオペレーション運用作業として特定して、運用上の実施項目として定義する。現時点で明示的に必要なものを以下に記載する。
・ 不正ユーザー報告があった場合には、対象ユーザーを利用不可とするなどのことを実施する
・ バッチの再実行などの手動対応
・ パターン化された特定障害に対しての手動対応
(・ バックアップ、ログファイル退避などの作業は自動化、オペレーション対応は不要)
(5) 資産管理    
SW資産を購入する場合には、年次で棚卸を実施する。

尚、計画停止については、初期の段階では月次を想定し、お知らせやコメントの吹き出し形式などで計画停止の通知をすることを想定しました。

2. キャパシティ・パフォーマンス要件

 a. キャパシティ要件
  UD Day 20のような形でキャパシティを想定
 b. キャパシティ拡張基準
  スケールアップ、スケールアウトについての基準を策定する。
  ・ スケールアップ
    トランザクション量の増加に伴って、スケールアップをまず行うこととする。
    別途記載のリソース監視時の規定容量に基づいて、超過時にインスタンスタイプの変更を行う。
  ・ スケールアウト
    スケールアップによる限界もしくはスケールアウトによるコストメリットが確認できる場合には、スケールアウトを行う。
    Web/APについては、Auto Scalingの設定を行い、自動拡張の設定を行う。
    DBについては、データのDB分割(Sharding。データを異なるDBに保存する)を行う事によるスケールアウトを検討する。
 c. パフォーマンス要件
  ・読み込み時にかかる時間
  ・書き込み時にかかる時間

3. リリース方法
要件定義では詳細化はせず、GithubもしくはGitlabを用いるということだけを決めました。実際にどのようにやるかは構成が決まり次第、ものを作る中で簡単にできるためです。

4. 監視
GCP及びそのツールでモニタリングが可能なもののうちどれを採用するかという判断を行いました。最終的には、ツールとしてはStackdriverのLogging/Monitoringを採用しています。

他にもNWのセキュリティやデータの暗号化について検討しました。これらについての詳細への言及はここでは控えます。(続く)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です