何も分からない状態から始める

一言でいうと

見知らぬシステムの前で最初の30分にすることは、問題を直すことではなく、何を見なくてよいかを確定することです。

なぜ必要なのか

自分のチームのサービスなら、障害報告を受けた瞬間に手が先に動きます。ダッシュボードがどこにあるか、ログがどのディレクトリにたまるか、昨日誰が何をデプロイしたかが、すでに頭に入っているからです。顧客先では、その3つがすべてありません。モニタリングが何なのかを知らず、ログの場所を知らず、昨日何が変わったかを知らないまま、隣ではいつ直るのかと聞かれます。

この条件で、経験のある人とそうでない人を分けるのは知識の量ではなく順序です。順序がないと目についたログから開くことになり、見知らぬ環境のログは海なので、2時間たっても同じ場所にいます。

だから最初のステップはいつも偵察です。直すものを探すのではなく、地形を描きます。

どう動くのか

偵察で確定することは4つあります。

1つ目は、接続と権限です。本能はログから開けと言いますが、診断の途中で権限がないことに気づくと、その依頼と承認にかかる時間がまるごと無駄になります。さらに悪いのは、権限を超えた行動です。顧客の本番環境で権限を超えたコマンドを1つ実行すると、障害より大きな信頼の損失を生みます。今持っているのが読み取りか書き込みか、本番環境かステージング環境かを、チケットの一番上に書いてから始めます。

2つ目は、システムが何の上に立っているかです。ディストリビューション、カーネル、実行中のプロセス、開いているポート。/etc/os-releaseの1行が、以後のすべてのコマンドの文法を決めます。ログの既定のパスだけでも、RHEL系は/var/log/messages、Debian系は/var/log/syslogと違います。他人のドキュメントをそのまま持ち込むと、最も頻繁に壊れる部分がここです。

3つ目は、データがどこにどれだけあるかです。どのファイルが最も大きいか、ログが何行か、どんな形式か。サイズを知らないと、grep1つが数秒で終わるのか数分かかるのか予測できず、すでに負荷がかかっているシステムでは、診断コマンド自体が障害を大きくします。

4つ目は、リソースの余裕です。ここでは必ず2回見る必要があります。df -hで容量を、df -iでinodeを、別々に見ます。容量とinodeはまったく別のリソースだからです。

現場での姿

最もよく出会う落とし穴を1つ、先に言っておきます。アプリケーションが「No space left on device」で落ちたのに、df -hは余裕が30%あると言います。このとき犯人は次の3つのどれかです。inodeが枯渇したか、削除されたのにまだ開かれているファイルがブロックを握っているか、そのパスが実際には別のファイルシステムであるかです。

Linuxではファイル名は実体ではなく、実体を指す1つの参照にすぎないので、名前を消しても、そのファイルを開いているプロセスがあればブロックは解放されません。そのため、ログローテーションのあとでプロセスがファイルを開き直さないと、消したログがディスクを使い続けます。dfとduの値が大きく違うなら、ほぼいつもこの話です。

この1つを知っているだけで、「ディスクがいっぱいになった」という報告で、ほかの人より20分を節約できます。そしてその20分が、FDEが売っているものです。

偵察で何を残すのか

偵察の成果物は、頭の中ではなく文書でなければなりません。理由は2つあります。1つ目は、同じシステムを次に見るとき(または別の人が見るとき)、30分をもう一度使わなくて済むことです。2つ目は、顧客に「私たちが何を把握したか」を見せること自体が、信頼を生むことです。初日に何も直せなくても、地図が1枚できれば、その時間は無駄ではありません。

環境地図に入れるものは、おおむね決まっています。

• 接続経路と権限: どのアカウントでどこに入るのか、読み取りか書き込みか、そしてそのサーバーが本番かどうかを書きます。
• 何が動いているか: プロセス、開いているポート、そしてそれらが互いにどう呼び合っているかを書きます。ポートの一覧だけでも、依存関係の半分が見えます。
• データがどこにあるか: ログ、データディレクトリ、設定ファイルを、それぞれのサイズと形式とともに書きます。
• リソースの余裕: 容量とinodeを一緒に書きます。
• わからないこと: この項目が最も重要です。確認できなかったことをそのまま書いておけば、あとでその部分に仮定を置いたことを忘れずに済みます。

推測と確認した事実を混ぜて書かないことが、この文書の唯一の規則です。「たぶんnginxが前段だろう」と「ポート80をnginxが待ち受けている」は別の文で、数日後には両者を区別できなくなります。確認したことには、それを確認したコマンドを一緒に書いておけば、あとで状態が変わったかどうかを、同じコマンドでもう一度見られます。

最後に、偵察には時間の上限を置きます。30分でも1時間でも決めておき、その中で描き切れなかったら、描き切れないまま次のステップに進みます。完璧な地図を描こうとして肝心の問題を見逃すことは、地図なしで飛び込むことの次によくある失敗です。

次のラボですること

顧客先のサーバーと想定したPodに入って、ディストリビューションを確認し、データのインベントリを作り、容量とinodeを一緒に記録して、環境地図を1枚残します。何も直しません。描くことだけをします。