نویسندهی تحویل شیفت آنکال: شیفت درهمریخته رو به یه تحویل حادثهی تمیز تبدیل کنEXCERPT: دیگه شیفت آنکال رو با یه پیام عجولانه توی Slack تحویل نده که نصف context رو جا بذاره. این Prompt یادداشتهای پراکندهی شیفت رو به تحویلی تبدیل میکنه که مهندس بعدی توی کمتر از پنج دقیقه بتونه روش اقدام کنه.
چرا این پرامپت اهمیت دارد
Vague handoffs are a well-documented driver of extended incident resolution times: the next on-call engineer re-investigates problems that were already diagnosed, misses that a 'resolved' incident still has an open root cause, or doesn't learn about a degrading system until it pages again at 3am. A five-minute handoff write-up costs far less than the hour a team loses re-discovering context that already existed in someone's head.
ما از آن برای چه استفاده می‌کنیم
An on-call engineer wrapping up a 8-hour shift with three alerts, one resolved incident with a lingering root cause, and a flaky Redis layer, who has ten minutes before the next engineer logs on and needs to hand off clearly instead of firing off a rushed Slack message that leaves out half the context.
پرامپت
Act as a senior site reliability engineer who writes clear, actionable on-call handoffs that the next engineer can read in under five minutes. CONTEXT: - Shift window: [START TIME/DATE] to [END TIME/DATE] - Alerts and incidents during the shift: [LIST EACH ALERT/INCIDENT WITH ROUGH TIME AND SYSTEM AFFECTED, e.g. "02:14 — payment-api p99 latency breached 2s threshold for 8 minutes"] - Actions taken and outcomes: [WHAT YOU DID FOR EACH ITEM AND WHETHER IT RESOLVED, MITIGATED, OR IS STILL OPEN] - Current system state: [ANYTHING DEGRADED, FLAKY, OR BEING WATCHED EVEN IF IT DIDN'T PAGE] - Scheduled or in-flight changes: [DEPLOYS, MIGRATIONS, OR MAINTENANCE THAT STARTED OR IS PLANNED DURING THE NEXT SHIFT] TASK: Convert these shift notes into a handoff document the next on-call engineer can act on immediately, without needing to ask follow-up questions or dig through dashboards to understand current state. CONSTRAINTS: - Do not write vague status language like "keep an eye on things" or "should be fine." Every open item needs a specific next action and, if known, an owner. - Separate items that need immediate attention from items that are informational only — do not bury a live risk among resolved items. - If an incident was resolved, state the resolution and whether a follow-up (postmortem, ticket, permanent fix) is still outstanding — "resolved" and "fully closed" are not the same thing. - If you don't have enough information to assess severity or next steps for an item, say so explicitly rather than guessing. OUTPUT FORMAT: 1. One-line TL;DR at the top — the single most important thing the next engineer needs to know before anything else 2. Still-Open Issues — table with columns: Issue | Current State | Next Action | Owner (if known) 3. Resolved During Shift — what broke, what fixed it, and whether a follow-up ticket/postmortem is still outstanding 4. Watch List for Next Shift — things that didn't page but are trending toward a problem 5. In-Flight Changes — anything deploying or migrating that could affect the next shift
نتیجه
Shift: Oct 9, 22:00 – Oct 10, 06:00 UTC
TL;DR
Payment API latency spike is resolved but the root cause (a slow downstream fraud-check call) is not fixed — it will likely recur under similar load. Redis cache layer is flapping and needs attention before it causes a real outage.
Still-Open Issues
| Issue | Current State | Next Action | Owner |
|---|---|---|---|
| Redis cache-layer connection drops (3x this shift, ~90s each) | Self-recovers each time, no customer impact yet, but frequency doubled vs. last week | Check connection pool sizing and recent Redis client version bump; escalate to infra if it recurs before 10:00 | Unassigned — flagging for infra team |
| Fraud-check service p99 latency at 1.4s (up from 400ms baseline) | Caused the payment-api latency spike at 02:14; mitigated by raising payment-api's timeout, not fixed at the source | File a ticket with the fraud-check owners; current mitigation is a band-aid that will mask further degradation | Payments team (ticket not yet filed) |
Resolved During Shift
02:14 — payment-api p99 latency breach (8 min). Root cause: fraud-check service slowdown. Fix applied: raised payment-api's downstream timeout from 1s to 2s, which stopped the cascading retries. This is a mitigation, not a fix — follow-up ticket still outstanding (see Still-Open Issues above).
Watch List for Next Shift
Redis connection pool: if drops hit 4+ occurrences or exceed 90 seconds, treat as a page-worthy incident rather than a watch item. Fraud-check latency: if it crosses 2s p99, the current timeout mitigation will stop working and payment-api will start erroring instead of just slowing down.
In-Flight Changes
None scheduled for the next shift. A database index migration on the orders table was originally planned for 08:00 but has been pushed to tomorrow — confirm with the DB team before assuming it's still off.
هر چرخه‌ی آنکال یه الگوی خرابی یکسان داره: مهندسی که شیفتش تموم می‌شه دقیقاً می‌دونه چی شده، ولی هیچ‌کدوم از این دانش از تحویل شیفت جون سالم به در نمی‌بره. مهندس شیفت بعدی یه پیام Slack می‌گیره که می‌گه یه اتفاقی برای پرداخت‌ها افتاده، یه داشبورد پر از جهش‌های توضیح‌نشده تحویل می‌گیره و بیست دقیقه‌ی اول شیفتش رو صرف بازسازی contextای میکنه که دوازده ساعت پیش توی ذهن یکی دیگه وجود داشته. این Prompt برای متوقف کردن همین اتلافِ تکراری و مشخص نوشته شده.
چرا این Prompt تفکیک شدت رو اجباری میکنه
ساختارش عمداً «موضوعات هنوز باز» رو از «موارد حل‌شده در طول شیفت» و از «لیست تحت نظر» جدا میکنه، به جای اینکه یه لیست صاف از اتفاق‌ها بسازه. این تفکیک به این دلیل هست که خطرناک‌ترین خرابی تحویل شیفت، یه فکت جاافتاده نیست — یه ریسک فعاله که وسط یه دیوار متن، کنار پنج مورد روتین و حل‌شده دفن می‌شه. کسی که تحت فشار زمانی یه تحویل شیفت طولانی رو سریع می‌خونه، با همه‌چیز توی یه لیست صاف مثل اولویت‌های تقریباً برابر برخورد میکنه، که دقیقاً برعکسه. اجباری کردن اینکه موضوعات باز توی جدول خودشون با یه اقدام بعدی و مسئول مشخص بیان، یعنی مهندس بعدی می‌تونه در چند ثانیه شدت رو اولویت‌بندی کنه، نه اینکه هر خط رو بخونه تا بفهمه چی هنوز مهمه.
چرا «حل‌شده» و «کاملاً بسته» دو وضعیت متفاوت حساب می‌شن
این محدودیت که تفاوت بین حل شدن یه حادثه و کاملاً بسته شدنش رو اجباری میکنه، یه اشتباه مشخص و رایج رو هدف می‌گیره: اعمال یه راهکار موقت، دیدن اینکه نشانه از بین رفت و بعد نوشتنش به عنوان تموم‌شده. توی خروجی نمونه، بالا بردن timeout جهش تأخیر payment-api رو متوقف کرد، ولی علت واقعی — یه سرویس کند بررسی تقلب — دست‌نخورده مونده و تحت همون شرایط بار دوباره سر برمی‌آره. تحویل شیفتی که فقط می‌گه «درست شد» پنهان میکنه که همون حادثه احتمالاً توی شیفت بعدی تکرار می‌شه. اجباری کردن یه یادداشت صریح درباره‌ی کارهای پیگیری باقی‌مونده یعنی مهندس بعدی با تکرار چیزی که بهش گفته شده بود حل شده، غافلگیر نمی‌شه.
چرا واچ‌لیست بخش جداگانه‌ی خودش رو داره
هر چیزی که ارزش گفتن داشته باشه، باعث پیج شدن نمی‌شه. یه connection pool که بیشتر از حد معمول بالا و پایین می‌ره، یه متریک latency که روندش صعودیه ولی هنوز زیر آستانه‌ست، یه دیسک که آروم داره پر می‌شه — اینا دقیقاً همون سیگنال‌هایی هستن که توی تحویل شفاهی گم می‌شن، چون به سطح «یه اتفاقی افتاد» نمی‌رسن، حتی با اینکه اغلب نشونه‌ی اولیه‌ی چیزی هستن که شیفت بعدی رو پیج میکنه. اختصاص دادن یه فضای جداگانه به این دسته توی فرمت خروجی یعنی این سیگنال‌ها نوشته می‌شن، به جای اینکه تا آخر شیفت توی ذهن مهندس شیفت قبل بمونن و فراموش بشن.
از این بخش آخر هر شیفت آنکال، چرخش incident، یا تحویل پشتیبانی استفاده کن — جایی که هزینه‌ی گم شدن context با دقیقه‌هایی که صرف بررسی مجدد می‌شن سنجیده می‌شه، یا بدتر، یه incident تکراری که هیچ‌کس پیش‌بینی‌ش رو نکرده بود چون هیچ‌کس ننوشته بودش.