顧客先に着いてまず依頼すること

一言でいうと

初日に詰まる理由は実力ではなく権限です。何を依頼すべきかを知っていれば1日を稼げ、知らなければ3日待ちます。そして権限を受け取ったら、受け取ったものが本当に依頼したものかどうかを、その場で確認します。

なぜ必要なのか

顧客先への初訪問でよくある1日は、こうです。午前は紹介、午後はノートPC持ち込みの承認、翌日はVPNアカウント、その翌日にサーバーへのアクセス。実際に手を付けられるのは4日目です。ところが4日目にログを開いてみると、保存期間が2週間で、顧客が言った3週間前の障害のログはすでに消えています。問題を見つけても、直す権限は読み取りだけなので、変更申請を新しく出し直さなければなりません。この遅れは、ほとんどが、何が必要かを事前に言っていなかったことによって生じます。

承認プロセスは、おおむね直列です。VPNの承認が終わらないとアカウントの申請が上がらず、アカウントが出ないと権限の申請ができません。段階ごとに承認者が違い、承認者ごとに1日ずつかかります。そのため、初日にすべてを同時に投げれば、並列で進みます。順序を守る必要があるものでも、「次に何を申請するか」を事前に知らせておけば、前の段階が終わった瞬間に、次の承認が上がります。

何を依頼するのか

依頼	なぜ必要か	よく抜けるもの
ネットワークアクセス(VPN/専用線)	何もできない	2FA端末の登録が別手順
アカウントと権限	参照すらできない	読み取り権限と実行権限が別
サーバー一覧・構成図	どこを見ればよいかわからない	最新版がWikiではなく誰かのPCにある
ログの場所・保存期間	調査範囲が決まる	30日で消えることを、あとで知る
担当者と連絡体制	行き詰まったときの相談先	夜間・週末の連絡ルール
変更手順	直すには必ず必要	緊急変更でも承認が必要な場合

これにもう1つ、最もよく抜けるものがあります。テスト環境があるか、あるなら本番環境と何が違うかです。「同じです」という答えは、たいてい事実ではありません。データ量、外部連携、証明書が違います。本番環境でだけ起きる問題をテスト環境で再現しようとして1日を使う前に、違う点の一覧を先にもらいます。

受け取った権限を確認する方法

アカウントが出たという連絡を受けたら、接続した直後にいくつかを見ます。どれも読み取りだけのコマンドなので、見知らぬサーバーでも安全です。

id; groups                 # which groups this account belongs to
sudo -l                    # what may be run as root, without running it
chage -l "$USER"           # account and password expiry dates
timedatectl                # is the clock synced, which time zone

sudo -lは、実行権限を実際には使わずに、一覧だけを表示します。ここで必要なコマンドが抜けていたら、初日にすぐ追加の申請を出します。chage -lの有効期限は、意外とよく引っかかります。パートナー企業のアカウントは短く発行されることが多く、調査の真っ最中にアカウントがロックされます。時計とタイムゾーンは、あとで複数の機器のログを突き合わせるときに必要です。

ログの保存期間は、口頭で聞くのではなく、設定で確認します。ファイルログは、たいていlogrotateが管理しています。rotateは削除する前に残しておく個数で、ローテーションの周期(daily、weekly)と掛け合わせて期間になります。weeklyにrotate 4なら、いま使っているファイルと、約4週間分の過去のファイルが残ります。maxageがあれば、その日数より古いファイルは、個数に関係なく削除されます。

grep -nE 'daily|weekly|monthly|rotate|maxage' /etc/logrotate.conf /etc/logrotate.d/*
journalctl --disk-usage
ls -d /var/log/journal     # absent: the journal may live in memory only
journalctl --list-boots | head -3

systemdのジャーナルは、期間ではなく容量で削除されるのが既定です。既定の上限は、ファイルシステムサイズの10%で最大4Gであり、期間の制限(MaxRetentionSec)は既定ではオフです。そのため、ログが多いサーバーほど、ジャーナルがカバーする期間が短くなります。もっと重要な落とし穴があります。既定の設定(Storage=auto)では、/var/log/journalディレクトリがあるときだけディスクに保存し、なければメモリにだけ置きます。そのサーバーは、再起動した瞬間に以前のジャーナルがすべて消えます。journalctl --list-bootsに起動が1つしかなければ、このケースを疑います。

何に触らないのか

最初の1週間の基本姿勢は、読み取りだけにすることです。これは臆病さではなく、計算です。見知らぬシステムでは、変更1つの影響範囲を予測できないからです。

触る前に、3つを確認します。

元に戻せるか: 元に戻す方法を、言葉で説明できなければなりません。
誰が影響を受けるか: このサーバーを誰が使っているかわからなければ、まだ早いです。
今やるべきか: 調査の段階で直すことから始めると、原因を失います。

特に3つ目です。再起動は、症状を消すと同時に証拠も一緒に消します。再起動が必要であっても、その前に状態を残します。プロセス一覧、メモリ、開いているファイル、最近のログ。数秒で終わります。

date -u +%FT%TZ                          # when this snapshot was taken
ps auxf                                  # process tree
free -m                                  # memory
ss -tanp                                 # sockets and their owners
lsof -p "$PID"                           # files the process holds open
journalctl -u "$UNIT" --since "30 min ago"

時刻を先に記録する理由は、スナップショットがいくつも積み重なると、どれが再起動前のものか区別できなくなるからです。このスナップショット1つが、あとでレポートの半分になります。

信頼は最初の週に決まる

技術的に正しいことを言っても、それを聞いてくれる関係がなければ、何も変えられません。最初の週に信頼を築く方法は単純です。

小さなものを早く返す: 3日がかりの分析より、1時間で出せる確認結果を、先に出す必要があります。
わからないことをわからないと言う: 推測を事実のように言うと、一度に信頼を失います。
約束した時刻に報告する: 進展がなくても、「まだありません」を時間どおりに伝えます。

現場での姿

調査していて、ログが20日分しかないとわかった → 初日に保存期間を聞いていれば、調査範囲を違うように取れたはずです。顧客に「3週間前の障害はログで確認できません」という事実を初日に伝えていれば、ほかの証拠(モニタリングの指標、顧客側の記録)を前もって探せたでしょう。
サーバーが再起動されたあと、ジャーナルが空になった → 保存方式がメモリだったのです。障害の原因が再起動の直前にあったなら、その記録は最初から残りようがありませんでした。
問題を見つけたのに、直す権限がない → 変更手順を事前に確認しなかった結果です。読み取り権限と実行権限が別であることを、sudo -lで初日に見ていれば、詰まりませんでした。
調査の途中でアカウントがロックされた → パートナー企業のアカウントの有効期限を確認していませんでした。
再起動で症状が消えて、原因不明のまま終了した → スナップショットなしで再起動した代償です。

続く学習で確認すること

すぐ後の理論で、変更の前に何が何に及ぶかを描く方法を扱います。そのあとのラボで、初日の依頼リスト、保存期間、上流と下流、共有状態、バッチウィンドウを自分で掘り出し、ロールバックスクリプトと再起動前のスナップショットスクリプトを作ります。この節で見た保存期間の計算とスナップショットのコマンドが、そのまま使われます。