書籍情報
書籍名: 運用設計の教科書【改訂新版】 〜現場でもっと困らないITサービスマネジメントの実践ノウハウ〜
著者: 近藤 誠司
著者について
株式会社K-model代表。オンプレからクラウドまで幅広いシステム導入プロジェクトに運用設計担当として参画。運用設計・運用改善コンサルティングを専門とする。趣味は小説を書くことで、第47回埼玉文学賞にて正賞を受賞。
著者の他の著作
著者リンク
学んだこと
1. ジョブ/スクリプト運用の概要（p218）
最近のシステムのほとんどは、対応の速さや省力化のためになるべく自動的に回るように設計・構築されている。
システムを自動的に回す仕組みの中心がジョブとスクリプトです。（p.218より）
システムの外側から定期的に行わなければならない作業についても、ジョブ管理システムやスクリプトを作成して自動化することで運用効率を上げることができる。
2. ジョブとは（p219）
ジョブとは、簡単に言うと人の代わりにシステムに対する命令（コマンド）を実行するものである。（p.219より）
このジョブをつなげて依存関係を明確にしたものをジョブネットと呼ぶ。
3. スクリプトとは（p220）
スクリプトとは、一連の作業を即時実行可能な言語（スクリプト言語）で記載した簡易なプログラム。（p.220より）
代表的なものにはシェルスクリプト・バッチファイル・VBS・PowerShellなどがある。作成目的は「高頻度・大量データへの同一処理を一括実行するバッチ処理（高速化）」と「判断分岐が多い処理を運用担当者がインタラクティブに実行する処理（精度向上）」の2つに分類される。
4. スクリプトを作成するかどうかの判断（p221）
手順書の中で毎回同じコマンド実行が続く箇所にスクリプトを作成すると、作業工数の削減・スキルばらつきの抑制・ログ精度の安定化といったメリットがある。一方で、スクリプト作成自体にも相応の工数が必要となる。
一見、悪いことがないように見えるスクリプトの作成にはそれなりの工数がかかる。このため、短納期のプロジェクトではすべての作業でスクリプトを作成することはコストとして難しい面がある。（p.221より）
5. 自動化している処理を一覧化する（p223）
自動実行されている処理は、正常時は運用担当者が意識することがない。しかしひとたびジョブが止まると、何も把握していなければ障害の影響範囲さえ調べられない。
運用担当者はシステムで自動実行している処理を把握しておく必要がある。（p.223より）
6. バックアップ/リストア運用（p227）
運用中には障害・オペレーションミスなどでデータ不整合やデータ損失が起きる場合がある。そのような場面でバックアップから正しくリストアできれば、システムの安心感は格段に増す。
バックアップ/リストアは非機能要件の可用性と深く結びついている。アプリケーション担当・基盤構築担当との連携が必須。
バックアップとリストアは必ずペアで考えなければなりません。（p.227より）
どのタイミングで取得したバックアップを、どのタイミングでリストアする可能性があるのかを常に意識した設計が求められる。
7. バックアップ/リストア運用の成果物（p239）
バックアップ/リストア運用の設計では、方針・対象一覧・手順書の3点をセットで整備することが求められる。
バックアップ方針・バックアップ対象一覧・バックアップ/リストア手順書の3点をセットで整備する。（p.239より）
「バックアップ方針」は基本設計書または運用設計書に反映し、「バックアップ対象一覧」では定期・手動・リストアタイミングをまとめ、「手順書」には実際の取得方法とリストア方法を記載する。
感想
ジョブ/スクリプト・バックアップのどちらも、どのプロジェクトでも必ず発生する普遍性の高い項目だと感じた。特に自動化処理の一覧表は作成コストが低い割に効果が高く、絶対に整備しておくべきだと思う。障害が発生したときに「どんな処理が自動で動いているか」を把握していなければ、影響範囲の調査さえ始められない。一覧がある・ないの差は想像以上に大きい。
バックアップ/リストア運用は現場で軽視されている印象がある。現職ではGUIツールからのCSVエクスポート・インポート機能を多用しているケースが多く、バックアップポリシーが不明瞭になっていることが多い。レコード数の多さや対象範囲の複雑さなど様々な要因が重なり、「どこまでをバックアップ対象にするか」の判断が難しい場面をよく見てきた。「とりあえず全部バックアップしておけばいい」という発想では、保管コストと管理負荷が際限なく膨らんでしまう。
そういった状況こそ、フローチャートで方針を明文化する必要があると思った。「どのデータを・いつ・どの手段で・どのタイミングでリストアするか」をフローにまとめることで、属人的な判断を減らせる。また、リストア手順を実際に試す「リストアテスト」まで設計に含める視点は、実運用の現場ではなかなか徹底されていない部分だと思う。バックアップを「取ること」に満足せず、「戻せること」を確認するまでを運用設計の範囲とするべきだと改めて認識できた。
実践できること
- 個人開発で自動実行している処理（cronジョブ、CI/CDのスクリプトなど）を一覧化してみる
- バックアップ対象一覧を作成し、取得タイミングとリストア手順をセットで整理する
- 手順書の中で繰り返しコマンドが続く箇所を洗い出し、スクリプト化できるか判断する
- 個人開発のAWSインフラ（アプリケーション・DB）のバックアップ方法とリストア手順をドキュメント化する
- バックアップを取得するだけでなく、実際にリストアできるかを検証するリストアテストも実施してみる
- スクリプト作成の費用対効果を判断する基準（繰り返し回数・ミスリスクの高さ）を自分なりに整理しておく
定量評価（1年後に記入）
注意: このセクションは読書直後ではなく、1年後など実際の効果が見えてから記入してください。
記入日: YYYY-MM-DD
スキル・知識の評価
| 評価項目 | 評価 | コメント |
|---|---|---|
| 長期的な有用性 | ⭐⭐⭐⭐☆ (4/5) | |
| 実践のしやすさ | ⭐⭐⭐☆☆ (3/5) | |
| 汎用性 | ⭐⭐⭐⭐☆ (4/5) |
スキルスコア: /15点
経済的インパクト
投資コスト
| 項目 | 数値 | 根拠・計算 |
|---|---|---|
| 書籍価格 | ¥X,XXX | |
| 読書時間 | XX時間 | |
| 読書時間コスト | ¥XX,XXX | |
| 総投資額 | ¥XX,XXX |
リターン
| 項目 | 数値 | 根拠・計算 |
|---|---|---|
| 時間削減効果 | XX時間/月 | |
| 時間削減の金額換算 | ¥XXX,000/月 | |
| コスト削減効果 | ¥XXX,000/年 | |
| 年間経済効果 | ¥XXX,XXX |