Golickの講演です。パフォーマンスの高いハイクオリティなソフトウェアをデプロイしたければ、あらゆるレベルでバグ修正ができるようになること。エピソードとして紹介しているのが、友人の会社のサイトが落ちて、あいにく、その会社のエンジニアが出払ってしまっていて、どうにかしてほしいと助けを求められたときのこと。ソースコードを見たことない。システムの構成を知らない。SSHでアクセスできる情報だけはある。いう状況の中で、phpはおそらくApacheプロセスを実行しているだろうからということで、pidファイルを確認。次に、straceコマンドを使って、プログラムが実行したシステムコールをチェック。システムコールは、ユーザランドのプログラムとOS間のインターフェースを提供していて、ファイルを書込んだり、ソケットを扱ったり、メモリをアロケートしたりと様々なことに役に立つ。返り値で構成されている。Rubyなどのデバッグでも役立つし、詳細なドキュメントも用意されているので、参照されたし。アウトプットの量が膨大でも、読み方のコツとしては必ず最後から順に追うこと。Err」などを見つけたら、その後にある詳細内訳はおそらく役に立たないから、エラーの原因があると思われる、その前のアウトプットを調べる。比較的近い位置に原因に関する情報があることが多い。directory)というエラーメッセージを見つけた。13という成功したシステムコードがある。grepで確認したところ、indexはdb.in.phpをincludeしていているので、パーミッションの設定が悪いと思いきや、ファイルは確かに存在していた。よって、db.inc.phpというタイプミスだとわかった。いうかたちで対処した。次に、顧客が、パッケージクラウドレポジトリを最新のUbuntuでインストールしようとしたときのこと。ignore)に次いでクリティカルなファイルに該当するURLを表示するメッセージが続き、アプリが何も見つけられなかったか、もしくはリクエストが失敗したことがわかる。パッケージインデックスがワークしていない。前回はエラー後の既存のプロセスを分析したが、今回は違って、straceコマンドの傘下でプロセスを実行し、数メガのデータを生成。アプリが見つけられないファイル」の箇所を発見。line...」という箇所があり。S3が400エラーを返しているという不思議な情報。ここから先は思ったより大変。Hatのディストリビューションは相当なパッチがされているので、パッケージに表示されているバージョン番号のソースからはかなり内容が変わっている可能性がある。パッケージ名」で実際のソースを自分のシステムのホームディレクトリに持ってくるのがよい。解決には何らかの手がかりが必要。ソースコードにおそらくハードコーディングされてるであろうstringを探してみる。line」という表現がソースのどこかで見つけられると推定した。line」というメッセージが定義されていた。C++をよく知らなくても、ここは頑張ってよくコードを睨んで想像してみる。PCで全画面表示すると読めます。)HTTPパーサーが一般的なものよりもかなり厳しめなのがわかる。line」のエラーをだしている。plain-text」とすることで解決。自分がわかってるはずと思うことは全部忘れること。システムの他のレイヤでのデータも調べること。(こちらのスライドにレイヤの詳細あり。)見るべき正しいソースコードの場所を特定すること。ソースコードの中でgrepできるハードコーディングされたstringを見つけること。ソースコードを合点がいくまでよく見ること。壊れてるところは全て直す。