はじめに
タイトルの通りですが、運用って意外に難しいですよね。
仕事でも個人でもサービスを作りあげる事は何度もあるのに、
それでもこんな事ありませんか？
- 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...？
- ローンチしちゃったから走りながら設定変える辛い...いや無理かも..
- ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ... サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば
システムの運用を事前に設計するのって難しいなーと思っていたところで
この本を見かけて読んでみたので、自分用に整理したメモです。
読んだ本
もくじ
- 運用と運用設計
- 1.1.運用とは
- 1.2.運用設計とは
- 1.3.運用設計担当者としてのプロジェクト参加
「書籍のメモ」をつづっていきますが
「自分の感想」には「※ hogehoge」という形で記載しています。
読んだ感想
この章では運用や運用設計がどのようなものか、というのをわかりやすく解説されています。
個人的には1章を読むだけでも全体像がつかめて価値があるなと思いました。
1.1.運用とは
運用設計の必要性
利用者に安定性してサービスを提供するために、システムを安定して稼働させる、そのために運用設計をする必要がある
運用はローンチしてから始まる（当たり前だが作ってる人は意識しずらい）
運用担当者へ必要なフローや手順書などが渡される
運用に登場する人物
システム運用に登場する人物は以下の3人
- 運用担当者
- 監視オペレータ
- 保守担当者
それぞれが連携しあって行うのが運用であり、
現在のシステムでは、運用がITコストの大半を占める。
運用担当者
- 利用者からの問い合わせを行う「サービスデスク」
- 手順書を元に日時や週次で行う「提携作業」
- 依頼を元にアカウント作成、パッチ適用、ログ取得を行う「非定型型作業」
- インシデントが集まるシングルポイントになることが多い
- 運用全体を把握する、システムにとって非常に重要な役割
監視オペレータ
- 不具合の監視
- 不具合時の一次切り分け
- 運用担当者へエスカレーション
- 不具合時の一次対応
- 不正アクセスなどのセキュリティ監視
保守担当者
- 障害発生時の部品交換
- 定期メンテナンス
1.2.運用設計とは
運用設計がなぜ必要？
- システムが複雑化しているので運用担当者もすべてを把握するのは不可能
- 運用設計書は新たな運用担当者への指南書にもなる
- 運用担当者に必要な情報がまとめられている事でまよわない運用ができる
運用設計をする意味
障害が発生したときになにをすべきか事前に決めておく事で安定性が増す。
※ 障害発生時に都度考えるのはやばい
構築設計と運用設計の際
※ 個人的にはここが非常にわかりやすかったです。 ※ 書籍では「火災報知器」を例に差異をあげています。
構築設計
- 設計する項目
- 製品機能
- スペック
- 設置場所
- 具体例
- サイズはどのようなものか
- 設置場所はどこになるか
- 色はどのようにするか
- 音はどの大きさで鳴らすか
- ボタンを押したらサイレンが鳴る事
- ボタンを押したらランプがヒカル事
運用設計
- 設計する項目
- 誰が
- どんな時に
- 何をするのか
- 具体例
- 誰がサイレンを解除するのか
- 誰が解除の承認をするのか
- 解除の手順はどのようなものか
- ※ システム的なものではなく運用フローに近い
- ※ 例えば、上長にメールを送る > 上長はメールをみて解除する、など
- 作動した場合の連絡先はどのようなものか
- 連絡を受けた担当者はどのような行動をするか
- 誰が定期的に動作を点検するか
1.3.運用設計担当者としてのプロジェクト参加
プロジェクト進行
プロジェクト進行は以下のような流れで行われる
- システム基本計画
- 提案対応
- 要件定義
- 基本設計
- 詳細設計
- テスト
- 移行
運用担当者は3. 要件定義以降から関わる事が多い
プロジェクト進行に対する成果物
※ 各フェーズ名 > 成果物 > 運用設計に関わる説明 というフォーマットで記載します
- 要件定義
- 要件定義書
- システムに「何が」必要かをまとめた資料
- 非機能要件も記載する
- 性能/信頼性/拡張性/運用性/セキュリティ
- 「どのように」は基本設計で検討する
- 要件検討資料
- RFP
- 議事録
- 基本設計/運用設計
- 基本設計書
- 要件を「どのように」実現するかをまとめた資料
- 構成、画面・帳票、データの概要、システム連携などの基本方針を記載する
- パラメータやプログラム設計は詳細設計にて行う
- 運用設計書
- 「どのように」運用していくかをまとめた資料
- 基本設計書の一部になることもある
- ※ ユースケースに近いイメージ
- 運用開始後に運用担当者がシステムを理解できるために必要なドキュメント
- 詳細設計
- 詳細設計書
- 基本設計書を実現する方法や設定値を記載する
- 運用設計的には「運用フロー」「運用手順書」「台帳/一覧」なども該当する
- パラメータシート
- 運用フロー
- 運用手順書
- 台帳、一覧表
- テスト
- テスト仕様書
- テスト計画書
- テスト結果報告書
- 問題管理票
- 移行
- 移行計画書
- 決められた時間での移行情報をまとめた資料
- 利用者や運用担当者の教育計画も記載する
- 他の成果物と関連性が低いため後半フェーズで作成する事が多い
- 運用受け入れチェックリスト
プロジェクトの登場人物
- エンドユーザ（利用者）
- プロジェクトオーナー（顧客）
- プロジェクトマネージャー（PM）
- インフラ構築担当（インフラチーム）
- アプリケーション開発担当者（アプリチーム）
- 運用設計担当者（運用設計チーム）
※ SIer型と自社サービス型でも結構違うないう印象 * 自分は後者で働いているため、プロダクトオーナーやデザイナーの役割も重要ですよね
プロジェクト会議体
- キックオフ
- 全体進捗会議
- 分科会
- 内部進捗会
- 内部資料レビュー会
- 打ち上げ
おわりに
運用や運用設計ってサービスが走り出してから考えてしまう事が多かったですが、
振り返るとやっぱり同じ数だけ失敗することが多いなーという感じでした。
自分の失敗 x 体系的に勉強すると、運用や運用設計の目的、大事さも改めてわかりますね。
火災報知器売ってからどう使うものか考えても遅いわけですねw
運用も設計が大事だなーと改めて通貫です＼(＾o＾)／
紹介
