チームが執筆してくれました。同書の続編も発売に向けて準備が進んでいるようです。コンピューティング時代のトラブルシューティングを取り上げます。レポートの基本的な書き方については前編をご覧ください。システムのトラブルシューティングは、コンピュータそのものと同じくらい古くから行われており、職人技とまで言われることもあります。チームによるトラブルシューティングの方法は根本的に変わろうとしています。トラブルシューティングは、運や経験だけで成功させられるようなものではありません。教えることや学ぶことのできる意識的な仕事です。レポートの書き方については前編をご覧ください)。チームとの共同作業が始まります。インフラストラクチャの技術的な問題を診断する担当者は、状況の説明(仮説)と説明の根拠となる証拠を探します。短期的には、問題と関係のあるシステム内の変化を探し出し、問題を緩和して直接的な影響を止めるための第一歩としてロールバックを目指します。それに対して長期的な目標とは、問題の根本的な原因を突き止めて解決し、問題が再発しないようにすることです。視点から見ると、トラブルシューティングの一般的なアプローチは次のようになります。可能な範囲で問題の影響を緩和する。観察されたことを集約、共有する。観察されたことを説明するための仮説を立てる。:仮説を証明、または反証するテスト方法を見つける。テストを実施し、結果の解釈を統一する。次の仮説に移り、問題が解決するまでこのプロセスを繰り返す。プロバイダーと協力して問題のトラブルシューティングにあたる場合は、自分ではコントロールできない部分がいずれ出てきます。あなたにはあなたの側で行うべきことがあります。チームに報告を送るときに行うべきことは次のとおりです。ページをチェックするなど、おそらく何らかのトラブルシューティングをすでに行っているはずです。実施したことと、それによってわかったことをプロバイダーに知らせましょう。ブックを残しておき、プロバイダーと共有してください。ブックを残すようにしなければならないということです。プロバイダーが有している場合もあります。あなたのシステムの特定の実装に起因する依存関係は自明ではないかもしれません。リソースの特定の利用方法は非公開かつプロプライエタリであるため、見晴らしのきくあなたの視点はきわめて重要です。問題を診断できていると判断したときは、その結論に至った経緯を説明しましょう。ほかの人間でも問題を再現できるようであれば、そのための手順も説明に含めます。レポートに含まれていると、通常は最速での解決につながります。推理の根拠となるような証拠を探すあまり、反対証拠を無視して確証バイアスに陥らないように注意してください。ギャップが生じることをよくご存じでしょう。プロバイダーとのやり取りでは、情報を一方的に説明するのではなく、シェアするようにしてください。すれば、あなたが言っていることを相手が誤解する可能性が低くなり、トラブルシューティングのスピードアップにつながります。プロバイダーならすべての情報を知っているはずだと思い込んではなりません。設計上、顧客のプライバシーに関わる事項については、プロバイダーが知っていることは限られます。情報のシェアは、たとえば次のようにします。見たとおりのものを示すため、スクリーンショットを添付する。Archive)ファイルを提供する。トレースなどの情報を添付する。本番アウテージは早い段階で報告するアプリケーションがユーザーにトラフィックを送信しなくなったり、同等の重大な影響をビジネスに及ぼすようになったりしたら、それは本番アウテージと見なされます。プロバイダーのサポート部門にできる限り早く知らせましょう。開発者用のテスト環境で少数の開発者がアクセスできなくなるような問題が起きても、それは本番アウテージとは見なしません。報告の優先順位も低くなります。チームに本番アウテージを知らせると、彼らは次の手順ですぐにトリアージに着手します。インフラストラクチャに影響を及ぼす既知の問題を直ちにチェックする。問題の性質を確認する。通信チャネルを開設する。一般に、次の内容を含む簡潔なメッセージをプロバイダーに送ると、すばやい対応が期待できます。レポートをすぐに作成し、そのあとで自分の側のトラブルシューティングを深めていくことです。プロバイダーへのエスカレーションを早い段階で行う必要があります。プロバイダーのネットワークは膨大かつ複雑であり、さまざまなテクノロジーやチームが関与しています。した中で重要なのは、ネットワーク固有の問題をすばやく特定し修復できるチームと協力して作業を行うことです。ネットワークに関連する問題の多くは、「サーバーに接続不能」というように、類似した症状を示します。このレベルの報告は漠然としており、根本的な原因を突き止めるうえで役には立ちません。多くの診断情報を提供する必要があるのです。つの地点(送信側と受信側)が関わっています。ネットワーク関連の問題を報告するときは、これらの地点に関する情報を必ず含めるようにしてください。フロー図の概念ツールを使用しましょう。エンドポイントを識別する。ホスト名との関連の有無など、エンドポイントに関して意味がある情報を書き込む。ゲートウェイなど、間に入るカプセル化や間接参照の情報を書き込む。途中のフィルタリングの情報を書き込む。キャプチャが必要です。キャプチャ(pcap。トラフィックを観察することです。難しい場合もありますが、両方のエンドポイントで同時にパケットをキャプチャすることが重要です。Wireshark)の使い方に慣れ、必要になる前にインストールしておくようにしてください。必要に応じてエスカレーションする状況の変化次第では、問題の緊急度を引き上げて、プロバイダーにすぐに対処してもらわなければならないこともあります。ビジネスへの影響が大きくなったり、サポート部門といくらやり取りしても状況の進展が見られなかったり、その他の要因で早期解決が必要になったりした場合はエスカレーションを要求します。エスカレーションが必要な理由をコメントの形で提供し、サポート部門が適切に対応できるようにしましょう。ドキュメントを作成する時間の経過とともに、新しい事実に光が当てられたり、仮説が除外されたりして、問題の状態や関連情報は変化していきます。その間に新しい担当者が調査に参加することもあるでしょう。ドキュメントに情報を集約し、最新の情報が伝達されるようにしておいてください。ドキュメントには次のような特徴があります。最新の状況が冒頭にまとめられている。レポートや社内バグ管理情報へのリンクがまとめられている。正しいかもしれない仮説と、すでに除外された仮説のリストがまとめられている。特定の仮説について検証を開始するときはそのように書き、使用する予定のテストやツールを明らかにする。することで、適切なアドバイスをもらえたり、作業の重複を避けたりすることができる。ドキュメントの書式例です。<次のステップ>13:00:00顧客への影響は緩和され、解決された。プロバイダーが当社のトラフィックを制限している。今後は財務部門との連絡を強化したい。人以上の顧客から寄せられている。バランサだけに絞っている。サポートと協力して、この問題が発生した理由と経緯を調査している。当社のエンジニアは上流のネットワークに問題があると考えている。プロバイダーに連絡を取り、上流に問題があるかどうかを確かめることである。人の顧客から届いている。当社のエンジニアが問題を調査している。つの問題だけを扱うようにしてください。レポートを再度使用してはなりません。新しいレポートにおいて類似の問題の参照情報を提供すると、根本原因によって引き起こされるパターンをプロバイダー側が認識しやすくなります。スキルを磨く細かい技術情報を明確にアクショナブルな形で伝えることは容易ではありません。そのためには集中と特別なスキルが必要です。ストレスが溜まる場面では、これが特に難しくなります。ストレスに対する生物学的反応が、明快で状況を見据えた推論の足を引っ張るのです。全員に対してわかりやすいコミュニケーションを取るには次のテクニックが役に立ちます。レポートを読み進めるにあたって、推論や計算が必要になることがあります。これが認知的負荷を生み出し、技術的な問題の解決に使える精神的エネルギーを減退させます。レポートは、できる限り具体的かつ詳細に記述するようにしてください。細部に注意を払うと、そのぶん作成にかかる時間は増えます。レポートは多くの人に何度でも参照されることになるため、全員が包括的な情報を得ていれば問題を早く解決できます。レポートには略語や社内のコード名などを使わないようにしてください。第三者に情報を開示するときも、顧客のプライバシー保護に十分配慮しましょう。テリング)のテクニックを使う“昔々あるところに...”人間は、ストーリーの形になっている情報の吸収に特に長けています。そこで、この能力を活用すれば、効果的に論点を理解してもらえます。状況説明から始めてください。問題を観察したときに何が起きたか、どのような解決方法を試みたか、誰が関与していたか、彼らにとってその事象はなぜ問題だったのか。レポートにビジュアルな要素を組み込みましょう。メールの一部として送信すると、見分けがつきにくくなります。入れる)、重要な部分に注意を向けやすくなります。自体を短くするようにしてください。項目を列挙する場合は、箇条書きリストを使用し、インスタンス名などの重要な細部については目立つようにします。手順の箇条書きには番号を付加してください。グラフ時系列データをわかりやすくするうえで、グラフはとても効果があります。プラクティスを常に心がけましょう。タイトルや軸ラベルを付けた状態でスクリーンショットを取得する。絶対数には単位(分あたりのリクエスト数、秒あたりのエラー数など)を付加する。スクリーンショットに矢印や丸でコメントを付け、重要なポイントを目立たせる。何を測定しているグラフなのかを簡潔に説明する。正常な場合のグラフがどのような形になるかを簡潔に説明する。グラフに対する自分なりの解釈、問題との関連を簡潔に説明する。次のアンチパターンに注意してください。軸が個別的なエラー(たとえば自分のハンドラ内の例外数)を示しており、調査中の問題(たとえば永続化レイヤのレイテンシ)との関係がはっきりしない。このような場合は、問題にとってこのグラフがなぜ重要なのかを説明する必要がある。分あたりの数)になっていて、相対的な影響についての手がかりが得られない。