【授業レポート】システム開発入門 第30週｜Runbook、変更履歴、監視で改善を定着させる

第30週は、第29週で実装し、効果を確かめた改善を、継続して運用できる形に整える授業でした。

班ごとにRunbook、変更履歴、監視項目、インシデント初動の手順を作成し、担当者が変わっても作業の目的と判断の根拠を追える状態を目指しました。

改善を一度やるだけで終わらせないために、手順を書き、担当を決め、効果を測る仕組みを作ることが重要です。今日作るのは「未来の自分」や「次に入る人」のための設計図です。
田中先生（授業内）

今回の到達点

1. 改善作業を再現するためのRunbookを作る。
2. 変更の目的と結果をたどれる変更履歴を整える。
3. KPIとSLOを決め、監視画面に載せる項目を考える。
4. 問題発生時の初動を並べた簡易プレイブックを作る。

4つの文書は何を残すのか

似た文書に見えても、記録する対象は異なります。授業で扱った役割を整理すると、次のようになります。

改善を継続するために作成した文書と役割

文書	残す内容	使う場面
Runbook	前提条件、実行手順、確認方法、巻き戻し手順	変更を安全に実施するとき
変更履歴	いつ、誰が、何を、なぜ変え、どう確認したか	変更の経緯や問題の原因をたどるとき
監視画面	KPI、SLO、しきい値、時間による変化	変更後の状態を継続して確かめるとき
初動プレイブック	検知、影響確認、一時対応、記録、連絡、振り返り	インシデント発生直後に対応するとき

実習1：Runbookで作業を再現できるようにする

Runbookは、運用作業の条件、手順、確認方法を一つにまとめた手順書です。手順だけでなく、失敗したときに元へ戻す方法まで書くことで、実行者が途中で判断に迷いにくくなります。

各班は、キャッシュTTLの延長、入力のサニタイズ（入力値を検査し、安全に扱える形へ整える処理）、フォールバックの調整といった改善を題材に、次の項目を記録しました。キャッシュTTLとは、取得したデータをキャッシュとして再利用する有効期間のことです。

• 目的：何を改善したいのか。
• 適用環境：テスト、ステージ、本番のどこで行うのか。
• 前提条件：必要な権限、環境変数、依存サービスは何か。
• 実行手順：どの設定を、どの順番で変更するのか。
• 確認方法：どのKPIやログを見て成否を判断するのか。
• 巻き戻し手順：問題が起きた場合に、どう元へ戻すのか。
• 記録欄：実行者、承認者、実施日時をどこに残すのか。

キャッシュTTL変更の記入例

次の値とコマンドは、授業で使った記入例です。実際の環境へそのまま適用する基準ではありません。

目的：キャッシュTTLを300から900へ変更し、ピーク時の応答改善を図る
前提：config/cache_config.pyへの書き込み権限
手順：
  1. ステージ環境でTTLを300から900へ変更する
  2. サービスを再起動する：systemctl restart myapp
  3. 10分間の負荷テストを実行する
確認：
  - 平均応答時間が前回の測定より改善していること
  - エラー率が上昇していないこと
ロールバック：
  - TTLを300へ戻し、サービスを再起動する

実習2：変更履歴に判断の根拠を残す

変更履歴は、変更した事実だけでなく、その目的、影響範囲、確認結果を後から追えるようにする記録です。Runbookが「どう作業するか」を示すのに対し、変更履歴は「実際に何を行い、どうなったか」を残します。

授業では、日付、変更者、変更概要、目的、影響範囲、実施環境、結果、関連するRunbookへの参照を一つの記入単位にしました。結果欄には期待した効果ではなく、負荷テストや運用確認で得た内容を書く形にしています。

実習3：KPIとSLOで改善後の状態を追う

変更が終わっても、効果が続いているかは監視しなければ分かりません。授業では、第28週で学んだ運用テストとログ解析を踏まえ、監視する指標としきい値を班ごとに決めました。

• KPI：改善の効果を追うための指標。今回は平均応答時間、成功率、フォールバック発生率、再生成要求率などを候補にしました。
• SLO：サービス品質についてチームが目標として置く水準。
• p95応答時間：応答時間を短い順に並べたとき、95％の測定値が収まる位置。平均値だけでは見えにくい遅い応答を確認する助けになります。

アラート条件には「p95が2,000ミリ秒を超えた状態が5分間続く」「成功率が95％を下回る」といった授業用の例を置きました。ダッシュボード案には、現在値を示す表と時間による変化を示すグラフを組み合わせています。

実習4：インシデント初動の順序を決める

インシデント初動プレイブックは、問題を検知した直後に行う確認と連絡の順序をまとめた文書です。初動では原因を早合点せず、影響を把握して一時対応を行い、調査に必要なログを残します。

1. 事象を検知する：監視アラートを受け取る。
2. 影響範囲を確認する：対象の機能と利用者を調べる。
3. 一時対応を行う：トラフィックを切り分けるか、フォールバックを有効にする。
4. ログを収集する：該当する時間帯の記録を確保する。
5. エスカレーションする：担当者へ連絡し、必要に応じて先生を介して運用側へ報告する。
6. 復旧後に振り返る：原因を分析し、結果を変更履歴へ残す。

ロールバックとフォールバックの違い

• ロールバック：変更した設定や状態を、変更前へ戻すこと。
• フォールバック：本来の処理が使えないときに、別の処理へ一時的に切り替えること。

二つは目的が異なります。Runbookと初動プレイブックでは、それぞれの条件と手順を混同しないように書き分けます。

ドキュメントを更新され続けるものにする

授業の最後には、文書を作った後の運用ルールを話し合いました。記録を残すだけではなく、誰が、どの変更をきっかけに、どの文書を更新するのかまで決めます。

• 更新の流れと責任者を決める。
• 変更内容を変更履歴へ残し、対応するRunbookから参照できるようにする。
• Runbookは、次の実行者が再現できる粒度で書く。
• 文書の名前と保存場所を統一する。

誰が次に見るかを想像して書くと、丁寧になるね！
授業内で共有された生徒の気づき

第30週の振り返り

第30週では、改善を実装する作業から、その効果を追い、問題に備え、次の担当者へ引き継ぐ作業までを一つの流れとして扱いました。コードと一緒に手順、変更理由、確認結果を残すことで、「作る」から「運用して伝える」へ学習範囲が広がりました。

次週は学期の総まとめへ

次週は、振り返りシートとポートフォリオを整理し、UML、データベース設計、アーキテクチャといった次の学習領域へ進みます。続きはシステム開発入門の第31週で紹介しています。

この記事に関連する株式会社greedenの取り組み

改善を一度で終わらせず、手順と記録を運用に組み込むことが、担当者が変わっても続けられる仕組みにつながります。株式会社greedenは、Webシステム開発を企画から保守や改善まで一気通貫で支援しています。