はじめに
タイトルの通りですが、運用って意外に難しいですよね。
仕事でも個人でもサービスを作りあげる事は何度もあるのに、
それでもこんな事ありませんか?
- 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...?
- ローンチしちゃったから走りながら設定変える辛い...いや無理かも..
- ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ... サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば
システムの運用を事前に設計するのって難しいなーと思っていたところで
この本を見かけて読んでみたので、自分用に整理したメモです。
読んだ本
もくじ
- 要件定義フェーズ
- 2.1.要件定義とは
- 2.2.機能要件/非機能要件
「書籍のメモ」をつづっていきますが
「自分の感想」には「※ hogehoge」という形で記載しています。
読んだ感想
この章では要件定義での機能要件と非機能要件、
非機能要件という位置づけの運用設計という形で説明されています。
個人的には、運用設計としての検討項目が体系的にまとめられているので
今後プロジェクトを進める上でとても参考になるなーと思いました。
「運用で検討する事をまとめといて」みたいなときって慣れてないと何を考えたら良いんだろう...となりますよねw
2.1.要件定義とは
要件定義では、以下のような事を行う
- 達成しなければならないものや、システムの全体像を明らかにする
- 必要なサービスを提供するためにどのような実現方法があるかを件とうする
- 費用や全体スケジュール、実現方法を鑑みながら決める
要件定義の注意点
- 要件は常に変わる
- システムの全体像が見えてくるとあれもこれも欲しい気持ちになる
- 要件定義段階はできる限りの可能性を検討しておく事が望ましい
- 顧客とのギャップ
- 顧客は大枠のシステムの実現性や必要な要件を知りたい
- エンジニアはどうやって実現するかになりがち
- 求められているものは「システム設計」ではなく「検討漏れのない要件定義書」
- 何かなければ議論は始まらない
- 顧客は正解をもっていない
- 要件を理解してこちらから提案する
- これはきっと大丈夫だろうは、どこかで出戻りが発生する
- 「違っている」や「関係ない」も含めて細かく合意していく
- 特定の製品を指定する場合
- 刷新するだけでなく「使い慣れている製品」も重要なファクター
- 運用担当者への引き継ぎ稼働の削減が見込める
- 現行踏襲に気をつける
- 現行踏襲のメリ・デメは検討する
- メリット
- 移行がスムーズ
- 基本設計や運用フローがそのまま使えるので設計コスト削減
- すでに全社的に統一されたフローなどは現行踏襲がうまくいく場合が多い
- デメリット
- 新システムとマッチしない
- 最新機能を導入する機会を失う
- 負の遺産(やりにくい部分)も引き継いでしまう
- 現行運用が属人化、高運用スキル者によってギリギリ回っているだけの場合失敗しやすい
2.2.機能要件/非機能要件
書籍では実製品として「洗濯機」を例にあげている
- 機能要件
- 洗い
- すすぎ
- 脱水
- その他の機能要件
- タイマー機能
- 脱水+乾燥
- 非機能要件
- 何年使えるか
- 騒音はどれくらい抑えられるか
- 海外でも使えるか
製品だとわかりやすいが、システムで非機能要件を洗い出すのは難しい
IPAでの非機能要件グレードについて資料的には以下のように定められている
- 基本的な非機能要件に対する考え方は以下の6点
- 可用性
- 必要なときにどれだけ使えるか
- 性能/拡張性
- どこまで性能が発揮できるか、拡張できるか
- 運用/保守性
- 運用や保守についての取り決め
- 移行性
- 現行データをどのように移行するか
- セキュリティ
- セキュリティ対策
- システム環境/エコロジー
- 電源設備、耐震免震性
運用設計は非機能要件
あらためて洗濯機の例で表すと
- 物理的な設計: アプリでいう
インフラ設計
- 設置場所
- 電源やホースのつなぎ
- 排水
- 機能的な設計: アプリでいう
アプリ設計
- 洗い
- すすぎ
- 脱水/乾燥
- タイマー
- 運用設計: アプリでも同じく
実際に使う人の動きを設計
- 洗濯を開始するにはどうするか
- 乾燥が終わったら取り出す&たたむにはどうするか
要件定義時に検討しておいたほうが良い運用項目
※ 結構多いけど要件定義時〜基本設計あたりで一緒に検討しないと何度も困った経験がある... ※ それこそローンチ後、あれ?これどうするんだっけ?はここで生まれてる気がしますね
- 運用体制
- 現在誰がどのようにシステムを運用していて、今回導入するシステムはどのような体制で運用されるのか
- 責任分解点を決めるためにも欠かせない
- サービスデスクの場所や運用担当者の作業場所、データセンターの運用体制
- 運用開始後のイメージを作成する
- ユーザアカウント管理
- ユーザー改廃
- アクセス権設定方法
- 特殊なユーザアカウント
- ヒアリング項目例
- 新入社員時の大量アカウント作成時の対応方法
- 一次貸し出しなどの特殊アカウントの有無
- 昇格による権限の付与
- 人事異動による権限変更
- セキュリティ対策
- 全社のセキュリティポリシーとの照らし合わせ
- 例
- 脆弱性対策
- ウイルス対策
- パスワードルール
- セキュリティパッチ適用運用
- ジョブ/スクリプト運用
- 自動化項目
- バックアップ/リストア運用
- バックアップ
- バックアップの概要(RPO)
- リストア
- リストアのトリガー
- 申請によるリストアが必要か
- 申請によるリストアが定常ならその運用設計
- 監視運用
- 要件定義フェーズは
- 「誰が」「どこで」「どのように」「どれくらい」監視するかを決定
- 「何を」「どれくらいの周期で」「どのレベルまで」監視するかは次工程
- ログ管理運用
- 障害検知用
- 短くても良い
- 監査用
- 長期間保存する必要がある
- 稼働統計運用
- 定期報告書の有
- システム稼働状況
- インシデント件数
- 顧客がなんのために必要とするかの合意
- SLAのため
- 安定運用の確認のため
- ライセンス棚卸しのため
- 安定運用の確認のため
- 移行(ユーザ教育含む)
- 検討する項目
- 人
- データ
- ドキュメント
- スキル
- 例
- 運用メンバーへの運用作業引き継ぎ方法
- 新システムへのデータ移行
- 新システムのユーザ説明会の実施
- システム切り替え時期と事前周知
BCP/DR
BCP/DRについての運用設計は次工程でも良い。
要件定義の時に検討はする。
BCP
- Business continuity plan(事業継続計画)
- 主眼は事業
- 災害時に限られた資源でどのように事業を継続していくか
- システムが被災しても紙運用で事業が止まらなければ問題ない
DR
- Disaster Recovery(災害復旧)
- 主眼はIT
- 災害時にどのような体制で、どのようにシステムを復旧するか
- システム被災から復旧までの進め方
DR対策
- バックアップ
- 最も安価
- 安全な遠隔地に保存
- 復旧に時間がかかる
- コールドサイト
- 遠隔地に最低限のインフラだけを確保
- 復旧にハイスペックな要因が必要
- ウォームサイト
- 遠隔地に同じシステムを構築し、非稼働状態で待機
- コールドサイトほどはハイスペック要因でなくていい
- ホットサイト
- 遠隔地に同じシステムを構築し、常時データレプリケーションも行い稼働させておく
- サービス停止時間がもっとも短い
- コストは一番かかる
おわりに
要件定義時に検討しておいたほうが良い運用項目
が非常に参考になりました!
冒頭でも書きましたが、
「運用で検討する事をまとめといて」みたいなときって何を考えたら良いんだろう...となりがち。
慣れなのかもしれないですが、まだまだ勉強と経験が必要だなと思いました\(^o^)/