The Two A.M. Incident

Who this book is for

Người làm công nghệ và AI trong doanh nghiệp Việt Nam: nhân viên IT một mình hay trong nhóm nhỏ, lập trình viên, người dựng tính năng AI, trưởng nhóm kỹ thuật ở công ty vừa và nhỏ; vừa phải giữ hệ thống chạy ổn, vừa được giao đưa công cụ và AI mới vào công việc của các phòng khác.

Sound familiar?

• Customers report outages before the tech team knows.
• Incidents are a flurry of calls with no clear roles.
• The same failure returns a month later.
• There is no record of past incidents.

Each chapter answers one question

1. Chapter 1: Why do customers find our outages before we do?

   Who is the first to know when my system breaks?

   If customers are the ones reporting incidents, the monitoring system is not doing its job.

2. Chapter 2: Mid-outage, should we hunt for the cause first?

   What must be done in the first ten minutes when the system breaks?

   In an incident, the first job is to stop the bleeding, not to find the cause.

3. Chapter 3: Can you trust your own judgment at 2 a.m.?

   Does the on-call person know what to do when a familiar error happens?

   At two in the morning nobody thinks clearly; a prewritten checklist thinks for you.

4. Chapter 4: Does finding who's to blame make systems safer?

   After an incident, what did my team learn and what did we fix in the system?

   Ask who caused the error and people hide; ask why the system let it through and people talk.

5. Chapter 5: Is this a new incident, or an unpaid old one?

   Which errors have happened more than once in my system?

   A repeated incident is a sign the follow-up from last time was never done.