続報を氷室に渡したあと、机の上で紙が三枚並んだままになっている。

新筐体側の経路表に、別棟の旧ラボ 10.4.50.0/24 と倉庫 10.4.60.0/24 を指す行が無い。旧筐体の保存済み running-config 抜粋には、両セグメントを次の渡し先 10.4.0.2 へ向ける手書きの経路が並んでいた。研究所側と工場側は新筐体の経路表に並んだまま動いており、本社側の各回線収容口は link/protocol up。週末交換のときに、後から手で追加された個別経路だけが、主要 config のコピーから漏れていた、までは続報で並んだ。誰の手で、どの工程で抜けたかは確かめられていない。

「観測の向きが揃ったなら、もう本社側ルータに経路を入れ直す方向で動いていいですよね」と瀬戸が紙を持ち直す。

そこで一度止まる。直す範囲をどこまで小さく絞るか、戻す条件は何か、戻ったと言える確認は何方向か。別棟側の窓口にも、変更時間と確認内容を短く返しておく必要がある。

どこを、どこまで直すか

修正の候補を、氷室と並べて紙の上に三つ書く。

ひとつめ。本社側ルータに、別棟の旧ラボ 10.4.50.0/24 と倉庫 10.4.60.0/24 を指す手書きの経路を、それぞれ次の渡し先 10.4.0.2 で追加する。動かす対象は二行で、観測で見えた抜けと一致する範囲だ。戻すのも二行で済む。

ふたつめ。本社側ルータの running-config を、旧筐体の保存済み backup で丸ごと上書きする。抜けていた経路はまとめて拾えるが、新筐体に交換した後で他セグメント向けに更新されている設定があれば、まとめて上書きされて消える。研究所側や工場側まで巻き込む方向に出る。

みっつめ。本社側ルータを再起動する。表をまとめて作り直す発想に見えるが、再起動の間、本社境界配下の通信全体が止まる。別棟以外の利用者まで巻き込む。

「みっつめは、止まる人が多すぎますね」と瀬戸が首を振る。

「別棟の対象2セグメント向けに経路が無いだけ、と見えている事案に対して、配下まるごと数十秒落とすのは合わない」と氷室。「副作用のほうが本事象より大きい修正は、最初に外しなさい」

ふたつめは、上書きの間に旧 backup と新 running-config の差分がそのまま入れ替わる。研究所側や工場側の経路、新筐体になってから追加された設定があれば、まとめて消える方向に出る。今日の症状と一致しない範囲まで影響を引っ張る。

ひとつめが残る。対象別棟2セグメント向けに、観測で並ばないと分かっている経路だけを足す。変更行は二行、戻すのも二行だ。

「ふたつだけ足して、本当に研究所や工場の通信は影響しないんですか? 経路表に追加するなら、いま並んでいる行がいったん抜けたりしませんか」と瀬戸。

「はぁ? なんでそうなるのよ」と氷室。「丸ごと上書きと、行を足す書き方を、ごっちゃにしないで。ip route で足すだけの書き方を使えば、いま経路表に並んでる研究所側と工場側の行はそのまま残るの。書いた瞬間も、その二方面の通信は切れない」

「えっと…足す書き方なら、いま動いている研究所側と工場側の経路は、書いた瞬間も巻き込まれない、です」

「そう。それと、足したあと、対象別棟2セグメントが経路表に並ぶ。期待状態をひとつ持っておきなさい」

「つまり、変更前は研究所と工場だけ、変更後は研究所と工場と別棟2セグメント、ってことですか?」

「『先に並べてから触る』の順番、腑に落ちたわね」

戻し方を、入れる前に決めておく

修正の方向が決まっても、コマンドを構える前に戻し方を決める。戻すための条件を二つ、氷室と合わせて決める。

• 追加コマンド投入後3分以内に、別棟の旧ラボと倉庫の端末から本社業務サーバへの疎通が戻らない場合
• 研究所側や工場側の島から、追加の通信影響の連絡が入った場合

このどちらかが当てはまったら、追加した手書き経路を no ip route で取り消して、追加前の状態へ戻す。戻したあとは、上位の判断を仰ぐためにエスカレーションする。判断の期限は、変更後3分以内。書いた瞬間か、フレームが境界を往復する短い時間で結果が出る種類の変更だから、長く様子を見るほうがかえって判断を遅らせる。

「戻し方を先に決める、っていうのは、もう直す手前に書いておくんですか?」と瀬戸。

「ちょっと、今の本気で言ってる?」と氷室。「決めずに入れて、何か起きてから戻し方を考えていたら、戻すまでの時間が延びるでしょう。判断期限、戻す手順、戻したあとどこへ上げるか、まとめて先に書いとくの」

「つまり、戻る道を確保してから、進む、ってことですか?」

「言い直せたなら、続報はそこで閉じていい」

変更前の状態を保存し、別棟側へ短く予告する

実際に手を動かす前に、変更前の確認結果をテキストに残す。本社側ルータで、対象範囲の経路設定をもう一度引いておく。

R-CORE01# show running-config | section ip route
(no static route entries found)

手書きの経路は一行も並んでいない。続報で見えた抜けと一致する状態だ。これを変更前の状態として記録する。

別棟側の窓口には、変更の予告だけ短く入れる。

別棟だけ繋がらない件、原因の方向が見えました。本日この後、本社側ルータで設定を二行入れる予定です。研究所側と工場側の通信に影響が出ないことは確認しており、変更直後の数分は念のため監視を続けます。完了後、改めて結果をお知らせします。

長くしない。変更が入ること、研究所側と工場側に影響が予想されないこと、終わったら次の連絡が来ること、の三つだけだ。原因の細部や、どの行をどう変えたかの説明は、いま別棟側の窓口が紙の控えで業務を回す判断に使う情報ではない。

入れる

運用リーダーから承認を取ったあとで、コンソールから設定を入れる。

R-CORE01# configure terminal
R-CORE01(config)# ip route 10.4.50.0 255.255.255.0 10.4.0.2
R-CORE01(config)# ip route 10.4.60.0 255.255.255.0 10.4.0.2
R-CORE01(config)# end
R-CORE01# write memory

コマンドは二行、エラーなく通る。

変更後、対象範囲の running-config に二行が並んだことを、まず同じ場所で見る。

R-CORE01# show running-config | section ip route
ip route 10.4.50.0 255.255.255.0 10.4.0.2
ip route 10.4.60.0 255.255.255.0 10.4.0.2

別棟の旧ラボと倉庫を指す二行が並んだ。続報で抜けていた範囲が、追加された方向にいる。期待していた変更後の状態とそろっている。

復旧確認は、三方向から

「直したから、もう終わりですよね」と瀬戸が紙を伏せようとする。

「はぁ? なんでそうなるのよ」と氷室の赤ペンが机を一度叩く。「あんた、設定を書き換えた事実と、復旧した事実を混ぜてるでしょう。確認しないといけないことが、まだ三方向あるのよ」

ひとつめ、本社側ルータの経路表で、対象別棟2セグメントが並ぶかを見る。

R-CORE01# show ip route static
S    10.4.50.0/24 [1/0] via 10.4.0.2
S    10.4.60.0/24 [1/0] via 10.4.0.2

S は手書きの経路で並んでいる、という意味の種別表記だ。続報で「並ばない」側にいた二つのセグメントが、ここで初めて経路表に並ぶ方向に出た。次の渡し先 10.4.0.2 も、旧筐体の保存済み backup で並んでいた値と一致する。

ふたつめ、疎通の確認。別棟の旧ラボ端末と倉庫端末から、本社業務サーバへ ping を打つ。

LAB-PC01# ping 10.1.10.20
!!!!!
Success rate is 100 percent (5/5)

WHSE-PC01# ping 10.1.10.20
!!!!!
Success rate is 100 percent (5/5)

5発打って5発戻る。続報で 0/5 だった両側が、ここで 5/5 に変わる。経路表に対象別棟2セグメントが並んだあとで、ようやく双方向の疎通が戻る方向に出た。

念のため、研究所側と工場側からも本社業務サーバへ ping が引き続き通ることを引いておく。続報の段から変わらず 5/5 で戻り、繋がっていた方角への追加影響は出ていない。

みっつめ、利用者確認。別棟側の窓口に、業務側の感覚を聞く。

本社の業務サーバ、開けるようになりました。紙の控えからの戻し作業を進めて大丈夫ですか。

通常運用に戻してよい旨を伝える。

「直りました、って書きそうになりますね」と瀬戸。

「『何が直ったか』を分けて書きなさい」と氷室。「本社側ルータの経路表に対象別棟2セグメントが並んだこと、別棟の旧ラボと倉庫の両端から本社業務サーバへ ping が通ったこと、研究所側と工場側に追加影響が出ていないこと、利用者の業務感覚で業務サーバが開けるようになったこと。それぞれ別の観測なの。一つだけだと、どこかが落ちている可能性が残るの」

「つまり、経路表の確認、双方向の疎通、繋がる側の影響なし、利用者の業務確認、これだけそろって初めて『直った』と書ける、ってことですか?」

「事実と解釈を、ようやく別の欄に置けたわね」

別棟側へ返す、短い完了共有

別棟側の窓口へは、別の経路で完了の短い連絡を入れる。

別棟の旧ラボと倉庫から本社の業務サーバへ届かなかった件、本日の設定変更が完了しました。両側の端末から本社の業務サーバへ接続できることを確認しており、業務利用が戻っている旨もご確認いただいています。紙の控えで回していただいていた業務は、通常の運用にお戻しください。同様の症状が再発した場合のみ、改めてご連絡ください。

復旧したこと、通常の運用に戻ってよいこと、追加連絡が必要になる条件、の三つだ。これも長く展開しない。原因として何が起きていたか、どの設定をどう変えたかの説明は、別棟側の窓口が業務を回す判断に使う情報ではない。

氷室に残す報告書

確認がそろったあとで、氷室に残す報告書を組み立てる。報告書は、暫定対処と恒久対処の境界を分けて、六つの欄に分ける。

• 復旧した事実

  別棟の旧ラボと倉庫から本社の業務サーバへ届かない事象について、本日、本社側ルータに別棟の対象2セグメント向けの手書きの経路を二行追加。変更後、本社側ルータの経路表に対象2セグメントが並び、両側の端末から本社業務サーバへの ping が双方とも 5/5 で戻り、別棟側の窓口経由で業務利用が戻っている旨を確認。研究所側と工場側の通信に追加影響は発生していない。

• 原因として言える範囲

  週末交換後の本社側ルータの running-config に、別棟の対象2セグメントを指す手書きの経路が無く、旧筐体の保存済み backup には対応する経路が二行並んでいた。新筐体への主要 config コピーで、後から手で追加されていた個別経路が漏れていた。続報で見えた経路表の欠落、旧 backup 側の対応経路、別棟側だけ届かない症状、研究所と工場は届いている観測の向きが、変更後の経路表追加と双方向疎通復旧で同じ向きにそろい、補強された。

• まだ言えない範囲

  別棟側の対象2セグメント向けの手書き経路が、新筐体への移行のどの工程で、誰の確認で抜けたかは未確認。旧筐体時代に、それぞれの経路がいつ・誰の判断で手書きで追加されたかも未確認。同じ書きぶりの手書き経路の取りこぼしが、他のルータ交換手順で並んでいないかも、本日の範囲では確認できていない。

• 実施した修正

  • 暫定対処: 本社側ルータに ip route 10.4.50.0 255.255.255.0 10.4.0.2 と ip route 10.4.60.0 255.255.255.0 10.4.0.2 を二行投入。投入後の running-config に対象経路が並ぶことを確認し、構成を保存。切り戻し手順は、追加した二行を no ip route で取り消し、変更前の状態に戻したうえで上位へエスカレーションする形で事前に確定。判断期限は変更後3分以内。
  • 恒久対処(候補): 交換手順の検証段階で、新旧 config の差分検証手順を変更管理に組み込む方向で別途調整。手書きの経路一覧を旧側から抜き出し、新側へ流したことの突合を必須化する案を、変更管理担当へ持っていく。本話では実装まで進めず、記録事項として残す。

• 検証結果

  • 経路表確認: 本社側ルータで show ip route static を引き、対象別棟2セグメントが S の種別で次の渡し先 10.4.0.2 として並ぶことを確認
  • 双方向疎通確認: 旧ラボ端末と倉庫端末から ping 10.1.10.20 で双方とも 5/5 成功
  • 副作用範囲確認: 研究所側と工場側から本社業務サーバへの疎通が、続報の段から変わらず通り続けることを確認
  • 利用者確認: 別棟側の窓口経由で、両側の業務利用が普段の通りに戻った旨を確認

• 記録へ戻す事項

  • 新旧 config の手書き経路差分を、ルータ交換手順の検証段階で突合する候補として、変更管理側へ戻す
  • 旧 backup 側に並んでいた手書き経路の一覧と、新 running-config 側に並ばなかった経路の一覧を、今後の交換手順検証で最初に重ねる手がかりとして残す
  • 別棟側の対象2セグメント向け経路が、旧筐体時代にいつ・誰の判断で追加されたかの経緯照会結果を、確認でき次第、追記欄に戻す
  • 同じ書きぶりの手書き経路の取りこぼしが、他のルータ交換で並んでいないかの定期確認を、運用部と変更管理担当の定例議題候補に上げる

「直したから終わり」と書かない理由

「未確認のところを、報告書から消したくなりますね」と瀬戸が紙の余白を見る。「直ったんだから、どの工程で抜けたかとか、いつ追加された経路かとか、書かなくても困らないんじゃないですか」

「ちょっと、今の本気で言ってる?」と氷室。「消したい気持ちは分かる。だけど、消したらどうなるかを考えなさいよ」

「えっと…次に同じ抜けが別のルータ交換で出た時、最初に何を見ればいいか分からなくなる、です」

「そう。『どの工程で抜けたか』を未確認のまま残しておけば、将来、別のルータ交換で同じ抜け方が起きたとき、最初に当たる先として残せる。確定として閉じてしまうと、その情報経路が無くなるの。原因者の名前を推測して書くのも違う。それと、暫定で経路を足した事実と、恒久で交換手順そのものを見直す話を、同じ欄にまとめないで」

「つまり、まだ言えない範囲と恒久対処の候補は、報告書から消さずに別の欄として並べておく、ってことですか?」

「その並びを、欄に書きなさい」

報告書の三つめの欄に、まだ言えない範囲が並び、四つめの欄では暫定対処と恒久対処が別の段落として分かれている。観測で言える範囲と言えない範囲、いま動かした範囲と後で動かす範囲が混ざらずに並ぶことが、次の対応をしやすくする。

同じ抜けが、次の交換でまた来るとき

報告書が氷室の手元に渡る。別棟側の窓口にも、別の経路で短い完了共有が入っている。新旧 config の差分検証手順を変更管理側へ組み込む案と、別棟側の対象2セグメント向け経路がいつ追加されたかの経緯照会は、別の流れで変更管理担当と運用部の定例に乗る。

ここまでで、週末交換翌朝からの「別棟だけ繋がらない」事象は、技術的にも業務的にも、いったん閉じる。

新筐体側の経路表に対象別棟2セグメントが並ばない、旧 backup 側には並んでいた、という観測の向きが見えてから、本社側ルータに対象経路を二行だけ足すという最小修正にたどり着くまで、四本のレールが並んでいた。直す範囲を二行に絞ったレール、戻し方を入れる前に決めたレール、復旧確認を経路表・双方向疎通・繋がる側影響・利用者確認の四方向でそろえたレール、未確認と恒久対処を消さずに別の欄として残したレール。どれか一本でも欠けていれば、報告書のどこかの欄が薄くなる。

机の上から、観測の紙と修正候補の紙と復旧確認の紙を、順に重ねていく。一番下に来る紙が、報告書だ。