Vibe Coding · レッスン

インシデントに対応する

稼働中の問題を診断して修正します。

レッスン 4/413 ステップ

「インシデントに対応する」はCoddyKit上の無料Vibe Codingレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはVibe Coding学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Vibe Codingコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

It Will Break

Every production system fails eventually. The difference between a minor blip and a disaster is how prepared and calm you are when it happens.

This lesson uses your AI assistant as an incident partner: helping you detect, diagnose, mitigate, and learn from outages without flailing.

Alert on Symptoms, Not Causes

Good alerts fire on what users feel: errors and slowness. Alerting on every internal hiccup trains you to ignore the dashboard.

Ask the assistant to define a small set of high-signal alerts tied to your golden signals, with thresholds that mean real trouble.

Define a minimal set of alerts based on user-facing symptoms: error rate above 2% for 5 minutes, p95 latency above 1s, and the queue backing up past 1000 jobs. For each, suggest a threshold and explain why it indicates a real problem worth waking someone for.

Detect, Then Declare

When an alert fires, the first job is to confirm it's real and decide if it's an incident. Declaring early gets the right people focused before things cascade.

Have the assistant draft a triage checklist so you assess severity quickly instead of staring at graphs.

Draft a triage checklist for when an alert fires: how to confirm it's a real user-facing issue, how to classify severity, and the first three things to check. Tailor it to a web app with a database, a cache, and a background worker.

Mitigate Before You Diagnose

During an active incident, stopping the bleeding comes before understanding the root cause. Users care that it works again, not why it broke.

Ask the assistant for fast mitigations: rolling back, disabling a feature flag, or shedding load, and the trade-offs of each.

We just deployed and error rate spiked. List immediate mitigations ranked by speed and safety: roll back the release, disable the new feature flag, or scale up. For each, tell me the command and what could go wrong.

Read the Signals Together

Now diagnose. Feed the assistant the evidence you already collected: recent deploys, the spiking metric, and the error logs around the start time.

A model that sees logs, the metric shape, and what changed can correlate them far faster than scrolling alone.

Here are the error logs from the last 15 minutes, the latency graph, and the list of changes deployed today. Correlate them: what is the most likely root cause, and what single piece of evidence would confirm or rule it out?

Find What Changed

Most incidents trace back to a recent change: a deploy, a config edit, a dependency update, or a traffic shift. "What changed?" is the highest-yield question in any outage.

Ask the assistant to line up the incident's start time against your change log.

The incident started around 14:32 UTC. Compare that timestamp against our deploy history, config changes, and any dependency or infrastructure events. Identify the change closest to the start time and assess whether it could plausibly cause these symptoms.

Communicate Clearly

During an incident, stakeholders need honest, jargon-free updates: what's affected, what you're doing, and when you'll update next.

Let the assistant draft a status update so you can keep people informed without losing focus on the fix.

Write a short status-page update for an ongoing incident: checkout is failing for some users, we've identified a likely cause and are rolling back, next update in 15 minutes. Keep it calm, specific, and free of internal jargon.

Confirm Recovery

An incident isn't over when the fix ships, it's over when metrics confirm users are healthy again. Closing too early invites a second outage.

Ask the assistant which signals must return to baseline and how long to watch before declaring all clear.

We applied a mitigation. Which specific signals (error rate, p95 latency, queue depth, checkout success rate) need to return to baseline before we declare the incident resolved, and how long should we watch them to be confident it isn't flapping?

Write a Blameless Postmortem

After recovery, capture what happened while it's fresh. A blameless postmortem focuses on the system and process, not on who to blame, so people stay honest.

Have the assistant turn your timeline and notes into a structured document with concrete follow-ups.

Turn these incident notes into a blameless postmortem: summary, user impact, timeline, root cause, what went well, what went poorly, and a list of concrete action items with owners. Keep the tone focused on systems and process, never on individuals.

Turn Lessons Into Guardrails

A postmortem that produces no change is just paperwork. The real value is converting each lesson into an automated guardrail that prevents a repeat.

Ask the assistant to translate action items into tests, alerts, or validation that would have caught this incident earlier.

For each action item from this postmortem, propose a concrete guardrail: a test, an alert, a deploy check, or a validation that would have caught this class of failure before it reached users. Prioritize the ones that are cheap to add.

Calm and Prepared

Incident response is a skill you build before you need it. Alerts on symptoms, a triage checklist, fast mitigations, and a blameless culture turn chaos into routine.

Your AI assistant accelerates every phase, but the discipline of mitigate-then-diagnose and learn-then-guardrail is what keeps small failures small.

Quick Check

Test your understanding of incident response.

Recap

Effective incident response follows a clear arc: alert on user-facing symptoms, triage and declare, mitigate before diagnosing, then correlate logs, metrics, and recent changes to find the cause.

Communicate honestly, confirm recovery against baseline, and close the loop with a blameless postmortem that becomes automated guardrails.

無料で開始

AI チューターと学ぶ JavaScript — 無料

ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。

コース
25
レッスン
100

よくある質問

「インシデントに対応する」レッスンは無料ですか?

はい。「インシデントに対応する」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Vibe Codingコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Vibe Codingコースには全4レッスンが含まれています。

「インシデントに対応する」で何を学びますか?

稼働中の問題を診断して修正します。 ブラウザで直接実行するハンズオンコードでVibe Codingを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Vibe Codingを始めるのに経験は必要ですか?

事前経験は必要ありません。CoddyKitのVibe Codingは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。

「インシデントに対応する」レッスンにはどのくらい時間がかかりますか?

ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このVibe Codingレッスンでコードを書いて実行できますか?

はい。すべてのVibe Codingレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. プロトタイプからプロダクトへ
  2. プロンプトでパフォーマンスを改善する
  3. ログとメトリクスを追加する
  4. インシデントに対応する
← Vibe Codingに戻る