連休前日の夕方、デスクで壁のカレンダーの休み期間を見上げながら、監視画面を最後にもう一度確かめている一人運用の保守担当者
障害対応・運用監視約16分

連休前にやる運用チェック｜一人運用でも安心して休むための準備

休みに入る前日の夕方。荷物をまとめて、席を立つ直前に、なぜかもう一度だけ監視画面を開いてしまう。 特に何かの兆候があるわけではありません。それでも、「このまま何日も見ない」と思うと、指が勝手にブラウザに伸びる。

一人でシステムを見ていると、連休は嬉しいはずなのに、少しだけ落ち着かない時間でもあります。それは備えが足りないからではなく、「何が起きうるのか」がまだ言葉になっていないからです。頭の中でぼんやり心配していることを、紙の上に出してしまえば、たいていは思っていたより小さな山になります。

結論：連休前の準備は、①連休中に「動くもの」と「期限が来るもの」を洗い出す → ②アラートが休み中の自分に届くか確かめる → ③どこまで対応するかの線を先に引く → ④連絡先を1枚にまとめるの順で進めます。順番に意味があります。何が動くか分からないうちに連絡体制だけ整えても、鳴らせる相手が決まらないからです。

全部そろえる必要はありません。①と②だけでも、休み中の落ち着かなさはかなり減ります。所要は、初回でも2時間ほどです。

何が起きているか：連休の障害が長引く理由

連休中の障害が大ごとになりやすいのは、障害そのものが大きいからとは限りません。平日なら30分で終わることが、休みだと3日かかる——そういう構造の問題であることのほうが多いのです。

IPAの「長期休暇における情報セキュリティ対策」でも、長期休暇はシステム管理者が長期間不在になるなどいつもとは違う状況になりがちで、その状況でインシデントが起きると対応が遅れたり想定外の事象へ発展したりする、と整理されています。何が違ってくるのかを、運用の側から4つに分けてみます。

逆に言えば、この4つはどれも休みに入る前に手が打てるものです。障害そのものは防げなくても、長引く原因のほうは減らせます。次から順番に見ていきます。

連休前にやる4ステップ

連休中に通知が来たときの対応を、すぐ動く・翌朝に見る・休み明けの3段階に分けて並べた図
「鳴ったら全部すぐ対応」ではなく、3段階に分けておくと迷わない

一度に全部やろうとしなくて大丈夫です。上から順に、できたところまでで構いません。

① 連休中に「動くもの」と「期限が来るもの」を洗い出す

最初にやるのは、対策ではなく棚卸しです。カレンダーを開いて連休の期間を書き、その期間に何が起きるかを並べます。見るのは2種類だけです。

連休中に勝手に動くもの

洗い出しは、記憶ではなく実物から拾います。

crontab -l              # 実行ユーザーごとに確認する
sudo crontab -l -u www-data
ls -l /etc/cron.d/ /etc/cron.daily/
systemctl list-timers --all   # systemd タイマーで動いているもの

ここで月をまたぐかを必ず見ます。月初のバッチや締め処理が休み期間に入っていると、影響が大きくなりがちです。洗い出したバッチが休み中に静かにこけても気づけるように、失敗の通知だけは確かめておきます（cronバッチが静かに失敗するのを見逃さない仕組み）。

連休中〜直後に期限が来るもの

証明書の期限は、その場で確認できます。

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

期限が連休期間＋1週間以内に来るものがあれば、休みに入る前に更新してしまうのがいちばん楽です。詳しい進め方はSSL/TLS証明書の期限切れを防ぐ更新と監視にまとめています。

② アラートが「休み中の自分」に届くか確かめる

洗い出しができたら、次は気づける状態にします。ここは手数が少ないわりに効き目が大きいところです。

ノイズを放置したまま休みに入ると、本物の1件が誤発報の山に埋もれます。鳴らしすぎを減らすのは、休むための準備でもあります。

③ どこまで対応するかの線を、先に引く

ここが、連休の落ち着かなさに一番効く部分かもしれません。「鳴ったら全部すぐ対応」を前提にしていると、休み中ずっと身構えることになります。そうではなく、鳴る前に3段階に分けておきます。

レベル例連休中の動き方
すぐ動くサイト全体が表示できない／全ユーザーがログインできない／データが壊れている疑い気づいた時点で対応する
翌朝に見る一部の機能だけエラー／夜間バッチが1回失敗／表示が一部崩れている朝、落ち着いてから見る
休み明け軽微な表示崩れ／すでに暫定対処済みの事象／改善要望メモに残して連休明けに

大事なのは、この線を自分ひとりで決めないことです。「サイトが表示できない場合だけ、私が休み中に対応します。それ以外は休み明けに見ます」と、休みに入る前に上長へ1通送っておく。それだけで、判断の重みが自分ひとりの肩から降ります。

あわせて、自分がやっていいことの範囲も先に合意しておきます。

そして連休中の原則は、戻すことに徹して、直しきろうとしないことです。相談できる人が少ない状況で恒久対応まで一気に進めると、事故が事故を呼びます。この線引きは一時対処（暫定対応）と恒久対応を分けて管理する方法と同じ考え方です。

④ 連絡先を1枚にまとめる

最後に、連休中に必要になる連絡先だけを1枚にします。日ごろの連絡網とは別に、休み用の縮小版を作るイメージです。IPAの資料でも、長期休暇前の対策としてまず挙げられているのが委託先企業を含めた緊急連絡体制の確認です。連絡フローが今の体制に合っているか、担当者の電話番号が変わっていないか——このあたりは、確認しない限り静かに古びていきます。

1枚に載せる項目は、これくらいで足ります。

ベンダーの緊急窓口は、契約していないと使えないことが珍しくありません。当日になって初めて知る、というのがいちばん困ります。連休前に一度問い合わせておくと、それだけで一つ肩の荷が下ります。

置き場所にも一工夫を。社内VPNの先にしか置いていないと、そのVPNや社内ネットワークが落ちたときに読めません。スマホから見られる場所か、印刷して財布に折りたたんでおくくらいで十分です。第一報の文面そのものは障害の第一報テンプレートを、そのまま使えます。

おまけ：連休前に「やらないこと」も決めておく

準備というと足す話ばかりになりますが、やらないことを決めるのも同じくらい効きます。

具体例：お盆に9連休、社内システムと公開サイトを一人で見ている場合

社内の業務システムと会社の公開サイトを一人で保守している、という状況で考えてみます。会社は8月8日から16日までの9連休です。

①洗い出しをしてみると、3つ見つかりました。毎月15日に走る月次の集計バッチが休み期間のど真ん中に入っていること。公開サイトの証明書の期限が8月14日に来ること。そして受注データを取り込む連携処理が毎日動いていること。証明書は自動更新の設定はあるが、更新の成否を確認する人が休みという状態でした。

対応は前倒しにしました。証明書は8月6日に手で更新して、次の期限を10月に飛ばしておく。月次バッチは、動かすこと自体は変えず、失敗したら気づける形にする——という判断です。

②届き先の確認では、バッチの失敗通知が数年前に作った社内メーリングリスト宛のままで、いまは誰も見ていないことが分かりました。ここに普段使っているチャットアプリへの通知を1本足して、テストで1回鳴らし、スマホのロック画面に出るところまで確認。所要は40分ほどです。この40分が、この準備でいちばん値打ちのある40分でした。

③線引きは、上長へ1通メールを送って合意をとりました。「公開サイトが全面的に表示できない場合のみ、休み中に対応します。再起動と直前リリースのロールバックは私の判断でやらせてください。それ以外は8月17日に対応します」。返信は「了解」の一行でしたが、その一行があるだけで、休み中の判断がぐっと軽くなります。

④連絡先1枚では、開発を頼んでいるベンダーが8月13日から16日まで休業で、緊急窓口は年間の保守契約に入っている会社だけが使える、と分かりました。自社は対象外です。がっかりする発見ですが、知らずに休みに入るより、はるかにましな状態です。その前提で、③の線引きを少し保守的に引き直しました。

準備にかかった時間は、合計で2時間ほど。結果として、この9連休で鳴ったアラートは月次バッチの警告が1件だけで、それは「翌朝に見る」に振り分けて、翌日の午前に確認して終わりました。

影響：連休の準備が変えるもの

この準備の効き目は、障害が起きたかどうかとは別のところにも出ます。

Googleの「Site Reliability Engineering」でも、当番（オンコール）を持続可能にするうえで、呼ばれる範囲と対応の手順があらかじめ決まっていることが繰り返し重視されています。一人運用ではチーム分の仕組みまでは作れませんが、「範囲を決めて、書いて、共有する」という芯の部分は、一人でも十分できます。

明日やること：カレンダーに連休を書くところから

いきなり全部は要りません。明日できる、いちばん小さな一歩はこれです。

  1. カレンダーを開いて、次の連休の期間を書き出す（何日から何日まで）。
  2. crontab -l と systemctl list-timers で、その期間に動くものを書き出す。
  3. 証明書・ドメイン・カード・トークンの期限が、連休期間＋1週間に入っていないか確かめる。
  4. アラートの届き先に、休み中に見る端末への経路を1本足して、テストで1回鳴らす。
  5. 対応レベルの3段階を書いて、上長へ1通メールを送る。

1〜3までなら、1時間かからないことが多いはずです。この時点で、心配ごとの半分は紙の上に降りています。頭の中でぐるぐる回っているうちが、いちばんしんどい時間です。

「連休前の運用チェック」チェックリスト

コピーして、自分のメモに当ててみてください。全部そろえる必要はありません。

まず外せない最低ラインはこの3つです。時間がなくても、ここだけは確かめます。

次の項目は、余裕があるとき・より確実にしたいときに追加で確認します。当てはまらなければ飛ばして大丈夫です。

全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「テストで1回鳴らした」さえ言えれば、いまよりずっと安心して休めます。

よければ、こちらも

連休の準備は、普段の運用の型がそのまま縮小版になって出てきます。土台のほうを整えておくと、次の連休はもっと軽くなります。

連休初日の朝、スマホを机に置いたまま窓辺で温かい飲み物を手に取り、穏やかに休みを迎えている保守運用の担当者

連休前の準備は、休み中に何も起こさないためのものではありません。何かが起きても大丈夫なようにして、あなたが安心して休むためのものです。 今日は、カレンダーに連休の期間を書いて、動くものを書き出すところまでで十分です。そこまで書けたなら、あとは休んでください。動いて当たり前のシステムを一年かけて支えてきた人が、数日休むための準備をしている。それは、とても真っ当な仕事です。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語