ソフトウェア エンジニアにとって、インシデントへの対応は大変です。土曜日の午前 3 時にオンコール ページが呼び出されたらどうしますか? それは恐怖を誘い、魂を吸い取られるような、まったく忌まわしい出来事です。職場で頻繁に発生すると、文字通り PTSD を引き起こす可能性があります。 残念ながら、これはソフトウェアの時代精神の一部です。むしろ、これらは真のエンジニアリングが鍛えられるきっかけです。これらの出来事は、堅牢なシステムを設計する方法、そして多くの場合、そうしない方法を教えてくれます。 この記事では、ソフトウェア インシデントに対処する方法について 2 つの側面を説明します。 🛠️ これらの経験を防ぎ、そこから学ぶために、ソフトウェア プラットフォームとチームに浸透させる必要があるプラクティス。 🧘 こうした経験から無傷で立ち直るだけでなく、経験した以上のものを得るためには、回復力を持つ姿勢が必要です。 私たちが取り上げるトピックは次のとおりです。 システムを可能な限り自動化する 先行指標と遅行指標の追跡 「実用的な」アラートは自明であるべきである 明確なコールチェーンとエスカレーションパスを確立する 最前線で大きな決断を下せるようにする すべての事件が同じように起こるわけではない まずは解決し、後で質問する 必ず1人が責任者となるようにしてください 明確かつ頻繁にコミュニケーションをとる 非難のない事後検証が重要 事後検証のフォローアップは重要 MTTDが低い限り、インシデントは悪くない ユーモアは偉大な平等主義者 詳細を見ていきましょう。 システムを可能な限り自動化する インシデント発生から数日または数週間後に、顧客から、または重大な会計上の不一致から知るインシデントの数を に抑えたいものです。「自動化」はエンジニアリングでは使い古された言葉ですが、これは、信号対雑音比の適切なバランスを見つけ、人間の介入を必要とせずにあなたとあなたのチームがアラートを受信できるようにすることが本当に必要な領域の 1 つです。 最小限 選択できる項目が多すぎる場合は、非常に高レベルにしてください。選択できる最高レベルの指標は何でしょうか。コンポーネント システムが期待どおりに動作しない場合、標準から逸脱するものは何でしょうか。これは、プラットフォームを流れる収益を追跡すること (e コマース、金融、またはドルベースのプラットフォームの場合)、または現在のアクティブ ユーザーの数 (ソーシャル メディア プラットフォームの場合) である可能性があります。 数値が急激に低下したり、標準偏差が 1 ～ 2 倍低下したりした場合は、すぐに開発チームに警告してください。最初の (または最も重要な) アラートをビジネスの動向やコア ユーザー エクスペリエンスに重点的に当てることは、監視するのに最適な指標になります。システムが洗練され、より深く理解できるようになると、可観測性の観点からスタックをさらに深く調べ始めることができます。 先行指標と遅行指標の追跡 先行指標は本質的に予測的なものであり、問題が起こりそうなことを示唆する傾向がありますが、遅行指標は事後的なもので、問題がかなり進行した後の余波を表します。遅行指標（「注文数が急減している」など）に加えて、または遅行指標の代わりに、先行指標（「セッション期間」が短縮し始めているなど）を活用できれば、かなり壊滅的な事態を回避できる可能性があります。 「実用的な」アラートは自明であるべき アラートは、アラートが発せられたときに次に取るべき手順が明確になるように、自明である必要があります。問題の重大性を確認するため、インシデントのトラブルシューティングのため、または問題の修復のためなど、アラートに関連する十分な詳細が必要です。アラートをどう処理するかを決定するために、事前に多くの議論が必要にならないようにする必要があります。 これらの詳細をアラート自体のコンテンツに盛り込むこともできますし、詳細がかなり長い場合は、チームがこの種の問題に対して管理しているランブックにリンクすることもできます。 明確なコールチェーンとエスカレーションパスを確立する アラートが発生したときに何が起こるか、サービス所有権、タイムゾーン認識などに基づいて誰にルーティングされるかなど、アラートが発生したときに何が起こるかを明確に把握しておくことは、迅速な対応を確実にするために重要です。その即時の第一防衛線を超えて、インシデント対応者がインシデントをどのように、誰にエスカレーションできるかを明確にすることも同様に重要です。 多くの場合、問題が複雑であったり、1 人で処理できる範囲をはるかに超える場合は、より上級の人 (またはチーム内の複数の人) や部門横断的な関係者を巻き込む必要があるかもしれません。ツール (PagerDuty、OpsGenie など) や非常に明確なドキュメント (実行ブック、Wiki ページ、リポジトリの README) を通じて、これらすべてに簡単にアクセスできるようにすることで、壊滅的なインシデントになるか、大したことない問題になるかの違いが生じる可能性があります。 最前線で大きな決断を下せるようにする 明確なエスカレーション パスは必要ですが、それがデフォルトの対応であってはなりません。上級管理職に相談することなく、最初の対応者が 行動を起こして被害を食い止めたり、その場で修復の決定を下したりできるようにする必要があります。これは、影響を最小限に抑えるという点で会社にとっても良いことであり、また、大きな決定を下すという信頼を寄せられている高い責任を与えられた従業員にとってもよいことです。煩雑な手続きを減らし、個人の権限を拡大しましょう。 実際に すべての事件が同じように起こるわけではない コール チェーンやエスカレーション パスなどとともに、もう 1 つ重要な資料として、インシデントの優先度スケールがあります。これは通常、最初の対応者やインシデント指揮官がすぐに参照できるものです。インシデントの重大度をすばやく特定し、異なるレベルの対応が必要になる可能性があるため、重大度に応じてラベルを付けるのに役立ちます。 重大なインシデント (システム停止や財務データの破損など) と軽微な問題 (カラーパレットの不具合など) を区別することは、対応者が誤報を回避するために不可欠です。また、チームの対応が効果的かつ集中的であることも保証します。 まずは解決し、後で質問する 間違いなく、最も重要なことの 1 つは、できるだけ早くインシデントを解決することです。インシデントが進行中に、なぜ何かが起こったのか、またはどうすれば防げたのかを哲学的に考えることに時間を費やしたくはありません。それは事後検証のために取っておけます。今のところは、容赦なくインシデントの解決に集中し、難しい質問は後でしましょう。 責任者を一人に絞る 場合によっては、インシデントが大きくなりすぎることがあります。インシデントが多くのサービスに影響を及ぼしたり、複数のビジネス ドメインにまたがったり、収益や評判に大きな影響を与えたりすることがあります。そのような場合、インシデント全体を「取り締まる」担当者を 1 人任命することが 重要です。Place Exchange では、複雑なインシデント対応のトレーニングを受けた少人数のグループである「インシデント コマンダー」を設置しています。 絶対に このような役割を持つことが非常に重要である理由は、複数の関係者が関与している場合、誰かがトラフィックを誘導する必要があるためです。多くの場合、エンジニアは問題の複雑さについて深く考えたり、問題を解決する方法を理解しようとしたりし始めます。 インシデント コマンダーの役割は、グループの焦点を迅速なインシデント解決に向けることです。インシデント コマンダーは、全員が行動を起こすことに注力していることを確認し、副次的な調査も重要ではありますが、前進の勢いを確保することがさらに重要です。また、インシデント コマンダーは、内部および外部の利害関係者やパートナーとの明確で継続的なコミュニケーションを確保する責任も負っています。 インシデント指揮官は通常、Slack のハドルや Google Meet ミーティングのような音声通信の同期ラインを開始します。これにより、インシデントの解決に不可欠な人々が常に連絡を取り合うことが保証されます。チャットを使用して非同期で問題を解決できるようにするだけの場合と比べて、この小さなことがどれほど効果的であるかは驚くべきことです。 インシデント指揮官は、実行する必要のあるタスクの明確な委任が行われていること、およびそれらのタスクに対する応答や結果を取得する責任があることを確認する責任も負います。 諺にあるように、馬に餌をやるのに 2 人を頼めば、馬は死んでしまいます。インシデント コマンダーは、そのような事態を防ぎ、最終的にインシデントの迅速な解決に責任を負います。 明確かつ頻繁にコミュニケーションをとる チームがインシデントの解決に懸命に取り組んでいることを常に知らされていれば、人々はお気に入りのアプリやソフトウェアがダウンしても許すでしょう。インシデントを完全に把握していないと感じたり、自分やチームがインシデントについて恥ずかしい思いをしたりして、物事を隠そうとすることは、コミュニケーションが外部に流れるのを止める理由にはなりません。 社内外のパートナーの両方に対して簡潔かつ頻繁に、透明性のあるコミュニケーションを行うようにしてください。そうすることで、信頼関係を築くのに役立ちます。 非難のない事後検証が重要 事後検証や事後回顧は学習文化を築く上で重要であり、絶対に非難されるべきではありません。批判するのはプロセスであって、人ではありません。この問題を引き起こした可能性のある人ほど自分自身に厳しい人はいません。公の場で彼らを非難しても何も得られません。むしろ、あらゆる調査が、これを行うと実際に損をすることを示唆しています。Etsy の人々はこれについて話すのがはるかに上手なので、詳しく知りたい場合は を読んでください。 https://www.etsy.com/codeascraft/blameless-postmortems 事後検証のフォローアップは重要 こうしたインシデントから学ぶための認識とフィードバック ループを構築するために、自ら事後検証を実施することは重要ですが、将来このような事態が発生しないようにするために議論されるアクション項目の方がおそらくもっと重要です。グループがシステム内のギャップや脆弱性を特定した場合、同じ問題が再発しないように、それらをタイムリーに解決することに集中して注意を払うことが非常に重要です。 インシデントの発生を防ぐのは難しく、一般的には企業や顧客との話し合いは難しいものになります。しかし、同じインシデントが何度も発生すると、防御が 難しくなり、チームの健全性とスキルに重大な問題があることが示されます。 はるかに MTTDが低い限り、インシデントは悪くない 誰もが理解しています。ビジネス関係者でさえも理解しています。ソフトウェアの構築は困難であり、すべてのソフトウェアに何百、何千もの依存関係があり、断層線が割れる可能性のある世界では、予測は不可能です。大変なことが起こっても大丈夫です。インシデントの発生を防ぐことはできません。ただし、本当に役立つのは、インシデントの MTTD が非常に低いことを確認することです。 平均検出時間 (MTTD) は、組織がインシデントまたはセキュリティの脅威を特定するのにかかる平均時間を測定する主要業績評価指標 (KPI) です。ビジネス ドメイン、影響の重大度などを考慮すると一般化は困難ですが、MTTD を数秒から数分に短縮できれば、インシデントの影響を、数時間から数日 (残念ながら数週間や数か月の可能性も十分あります) と比べて大幅に軽減できる可能性が高くなります。 ユーモアは瞬間的な痛みを和らげる これらはすべて非常に深刻です。お金が失われ、顧客はひどい経験をします。しかし、その中でユーモアのセンスを持つことが極めて重要であることがわかりました。このプロセスにおいては誰もが人間であり、さまざまな程度のストレスを経験していることを忘れてはなりません。適切なタイミングでユーモアを交えることで、そのプレッシャーをいくらか軽減できます。 これにより、チームが地獄の孤島にいるのではなく、一緒に取り組んでいるという仲間意識が生まれます。 以上です。読んでいただきありがとうございました! ⭐ この種のコンテンツが気に入ったら、ぜひフォローするか、 に登録してください! ⭐ https://a1engineering.substack.com/subscribe 特集写真はUnsplashのJulien Lによるものです
