変更要求書を書き、リハーサルで検証する

目標

3つの変更要求の種類を分け、DB再起動の影響範囲を依存の最後までたどり、作業ウィンドウからロールバック時間を逆算して引くことで中止判断時刻を求めます。その数字でJSONの変更要求書を書き、リハーサル記録で計画が楽観的だったかどうかを判定します。

なぜ重要なのか

運用障害の大きな部分は変更から生じます。変更要求書はそのリスクを作業前に紙の上で確認する道具であり、レビュー担当者が差し戻す理由はたいてい同じです。ロールバック基準が「問題が起きたら」の一言だけ、影響一覧が直接の依存だけ、ロールバック時間を計算しておらずウィンドウに余裕があるように見える、といったものです。このラボでは、その3つを数字で埋め、リハーサル記録で計画を検証する習慣を身につけます。

材料は/opt/lab/capacity/change/にあり、採点ツールは期待値を元の材料から計算します。

ステップ

/opt/lab/capacity/change/のファイル5つを/root/chg/へコピーしてください。
要求A・B・Cの種類を、/root/chg/01-type.txtにA=、B=、C=で書いてください(standard・normal・emergency)。
db01の再起動の影響を受けるサービスを依存の最後までたどり、/root/chg/02-impact.txtにimpacted=で書いてください。
/root/chg/03-window.txtにtotal_min=、rollback_min=、nogo_at=、fits=を書いてください。
/root/chg/cr.jsonにid、type、summary、window、impact、precheckを書いてください。
cr.jsonにsteps(S1…S5、それぞれverify)とrollback(trigger・max_min・steps)を加えてください。
リハーサル記録から、/root/chg/04-rehearsal.txtにslowest_step=、over_min=、finished_at=、past_nogo=を書いてください。

参考

依存のたどり方: 影響の集合に加えるものがなくなるまで繰り返します。
時刻の計算: datetime.strptime(s, '%H:%M')、timedelta(minutes=n)。
JSONの確認: python3 -m json.tool /root/chg/cr.json。
よくある間違い1: ロールバック時間を引かずに、「作業60分、ウィンドウ120分だから余裕がある」と判断することです。
よくある間違い2: rollback.triggerを「異常があれば原状復帰」のような、測れない言葉で書くことです。

材料のコピー

/opt/lab/capacity/change/のファイル5つ(requests.txt、inventory.json、plan.csv、window.env、rehearsal.log)を/root/chg/へコピーしてください。

cpでディレクトリの内容をコピーします。requests.txtから読んでみてください。

変更の種類を分ける

requests.txtの3つの要求A・B・Cを、それぞれstandard・normal・emergencyのいずれかに分類し、/root/chg/01-type.txtにA=、B=、C=の3行で書いてください。

承認済みの手順書をそのまま繰り返すのか、新しく評価が必要なのか、今すぐ行わなければ間もなく障害になるのかを見ます。

影響範囲をたどる

inventory.jsonのdepends_onを最後までたどり、db01の再起動の影響を受けるサービスをすべて見つけて、/root/chg/02-impact.txtにimpacted=<이름들, 쉼표로>(プレースホルダーは名前の一覧をカンマ区切りにしたものです)の1行で書いてください。ただしdb01自身は除きます。

db01を直接使っているサービスを先に探し、そのサービスを使っているサービスをさらに探す作業を、もう増えなくなるまで繰り返します。

作業ウィンドウと中止判断時刻

plan.csvとwindow.envから、/root/chg/03-window.txtに4行を書いてください: total_min=<minutes 합>、rollback_min=<rollback_minutes 합>、nogo_at=<WINDOW_END − rollback_min − BUFFER_MIN, HH:MM>、fits=<WINDOW_START + total_min 이 nogo_at 이하면 yes, 아니면 no>(プレースホルダーは、minutesの合計、rollback_minutesの合計、HH:MM形式の時刻、WINDOW_STARTにtotal_minを足した時刻がnogo_at以下ならyes、そうでなければnoです)。

ロールバックは最悪の場合(すべてのステップを元に戻す場合)で見積もります。ウィンドウの終わりから逆算して引くと、中止判断時刻が出ます。

変更要求書のヘッダー部

要求Bの変更要求書を/root/chg/cr.jsonに書いてください。最上位のオブジェクトに、id、type(Bの種類)、summary、window({"start": "02:00", "end": "04:00"})、impact(ステップ3のサービス名の一覧)、precheck(空でない文が2つ以上。そのうち1つはバックアップまたはスナップショットの確認)が必要です。

JSONはpython3 -m json.tool cr.jsonで文法を確認できます。影響の一覧は手で書き写さず、02-impact.txtから読み込んで入れてください。

ステップごとの確認とロールバック基準

cr.jsonにstepsとrollbackを加えてください。stepsは、plan.csvの順にid(S1…S5)と空でないverify(終わったと判断するための確認方法)を持つオブジェクトの一覧です。rollbackは、trigger(ステップ4のnogo_atの時刻を含む、測れる基準)、max_min(ステップ4のrollback_min)、steps(3つ以上のステップの一覧)を持つオブジェクトです。

triggerには、「問題が起きたら」ではなく時刻・割合・件数を入れる必要があります。中止判断時刻は03-window.txtから読み込んで入れてください。

リハーサル記録を読む

rehearsal.logから、/root/chg/04-rehearsal.txtに4行を書いてください: slowest_step=<계획보다 가장 많이 늦은 단계 id>、over_min=<그 단계가 늦은 분, 소수 첫째 자리>、finished_at=<마지막 done 의 HH:MM>、past_nogo=<리허설이 끝난 시각이 nogo_at 보다 늦으면 yes, 아니면 no>(プレースホルダーは、計画より最も遅れたステップのid、そのステップが遅れた分数(小数第1位)、最後のdoneのHH:MM、リハーサルが終わった時刻がnogo_atより遅ければyes、そうでなければnoです)。

ステップごとにdoneの時刻からstartの時刻を引いて実際の所要時間を求め、plan.csvのminutesと比べます。秒単位まであるので、分に直すときは60で割ります。