الزام ثبت فایل بازگشت پیش از پاسخ به هشدارها؛ استانداردی برای توقف خطاهای انسانی

تصور کنید ساعت ۲ صبح است، هشدار خرابی سیستم شما را از خواب می‌پراند و اولین واکنش شما، اجرای سریع دستوراتی برای ری‌استارت کردن سرویس است؛ دقیقاً همین عجله است که یک اختلال کوچک را به یک قطعی فاجعه‌بار تبدیل می‌کند. در ۲۳ سپتامبر ۲۰۲۶، استاندارد عملیاتی جدیدی در dev.to معرفی شد که پاسخ به هرگونه هشدار تولید را تا زمان ارائه یک «بسته تحویل» (Handoff Packet) رسمی که در آن فایل بازگشت (Rollback File) مشخص شده باشد، رد می‌کند. این پروتکل، پاسخ به حوادث را از مجموعه‌ای از حدس‌های امیدوارانه به یک قرارداد سخت‌گیرانه بین مهندس آن‌کال و سیستم تبدیل می‌کند.

بسیاری از تیم‌های مهندسی، وضعیت «آن‌کال» (On-call) را یک تقلا برای واکنش سریع می‌بینند. وقتی پیجر در ساعت ۲ صبح به صدا در می‌آید، غریزه مهندس این است که فوراً به سراغ لاگ‌ها برود و دستورات را اجرا کند. این «حدس‌زدن» اغلب منجر به نادیده گرفتن قوانین انجماد (Freeze Rules) و اجرای اقدامات اصلاحی بدون مالکیت می‌شود که خود باعث ایجاد حوادث ثانویه می‌گردد. طبق گزارش dev.to، وقتی هشدارها بدون یک بودجه زمانی مشخص برای تشخیص فعال می‌شوند، مهندسان به جای تحلیل، به حدس‌زدن روی می‌آورند و همین‌جا است که قوانین انجماد نادیده گرفته می‌شوند. بسته تحویل در اینجا مانند یک کلید قطع‌کننده عمل می‌کند و مهندس را مجبور می‌کند پیش از لمس هرگونه محیط خط فرمان (Shell)، استراتژی خروج را تعریف کند. سرعت بالای عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهای سریعی که متن را سریع می‌نویسند اما لزوماً منطق سیستم را نمی‌فهمند — اجازه نمی‌دهد مراحل این بسته نادیده گرفته شود؛ وصله‌های سریع در محیط‌های آزمایشی (Scratch Box) مفیدند، اما در حالی که مسیر مشتری منجمد نشده است، اجرای آن‌ها بی‌پروا و خطرناک است. این رویکرد در واقع پاسخی به چالش‌های مدیریت خطاهای کدنویسی است که پروتکل‌های زمانی سخت‌گیرانه برای مهار آن‌ها در محیط عملیاتی پیشنهاد شده است.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، جداسازی محیط‌های اجرایی از محیط‌های طراحی، کلید پایداری است. در این استاندارد، بسته تحویل یک شیء انتقال مبتنی بر YAML است. این فایل یک گزارش پس از حادثه (Postmortem) یا یک رمان نیست، بلکه یک فایل کوچک و اعتبارسنج شده است که اجازه می‌دهد مهندس پشتیبان بدون از دست دادن زمینه (Context)، مدیریت حادثه را به دست بگیرد. اگر مهندس اصلی با هشدار دومی مواجه شود، مهندس پشتیبان باید بتواند تنها با تکیه بر این فایل، عملیات را ادامه دهد. این ضرورت انتقال دقیق زمینه، یادآور تجربیات تلخی است که در آن عدم انتقال کامل تاریخچه عامل‌ها منجر به شکست در محیط Production شده است.

بر اساس مستندات این پروتکل، بسته تحویل باید شامل ۶ فیلد غیرقابل مذاکره باشد. این موارد به عنوان یک قرارداد با چرخه چرخش (Rotation) در نظر گرفته می‌شوند و در حین حادثه نمی‌توان بر سر آن‌ها چانه زد:

• alert_id: این شناسه مستقیماً از صفحه هشدار کپی می‌شود تا بسته تحویل و پیجر در مراحل بعدی دچار انحراف یا ناهماهنگی نشوند.
• rollback_file: مسیری به یک آرتیفکت واقعی (مثلاً deploy/rollback/checkout-api.last-good.txt) که شامل آخرین تصویر سالم (Image)، تعداد رپلیکاها و هویت پیکربندی است. در اینجا بازگشت به حالت قبل، تبدیل به یک «مسیر فایل» می‌شود، نه یک دستور حفظ‌شده در ذهن مهندس خسته.
• diagnostic_budget_seconds: یک محدودیت سخت — معمولاً ۳۰۰ ثانیه — برای اینکه ۵ دقیقه اول تشخیص، به طور نامحسوس تبدیل به یک ساعت عیب‌یابی نشود.
• freeze_scope: یک سطح مشخص برای انجماد (مثلاً checkout-api-canary) تا از استراتژی بی‌پروا و خطرناک انجماد کل سیستم شرکت جلوگیری شود.
• unfreeze_owner: یک شخص نام‌برده که مسئول باز کردن انجماد تولید است تا اطمینان حاصل شود که تصمیم‌گیری در شب هرگز به صورت یک تصمیم گروهی ضمنی نباشد.
• escalation_target: شخص متفاوتی که پس از اتمام بودجه زمانی تشخیص باید فراخوانده شود، تا در لحظه اتمام بودجه، انسان بعدی از پیش مشخص باشد.

اگر هر یک از این فیلدها نامشخص باشد، مهندس باید به جای اختراع یک مقدار فرضی که کامل به نظر برسد، مستقیماً مالک سرویس را فراخواند. یک بسته زیبا با مالکان جعلی، بدتر از یک صفحه ردشده است، زیرا عدم قطعیت را به اقدام تبدیل می‌کند.

ساختار فنی بسته تحویل

برای درک بهتر، یک نمونه از فایل oncall-handoff.packet.yaml برای سرویس checkout-api به این شکل است:

apiVersion: oncall.packet/v1
kind: HandoffPacket
metadata:
  alert_id: example-ALERT-0000
  service: checkout-api
  opened_at: 2026-09-23T02:14:00Z
spec:
  diagnostic_budget_seconds: 300
  rollback_file: deploy/rollback/checkout-api.last-good.txt
  rollback_file_sha256: pending
  customer_visible: true
  freeze_scope: checkout-api-canary
  unfreeze_owner: primary-oncall
  escalation_target: payments-secondary
  first_commands:
    - kubectl get deploy checkout-api -o wide
    - kubectl logs deploy/checkout-api --tail=200 --since=10m
    - curl -sS https://status.internal.example/checkout-api/healthz
  notes: proposed packet; do not treat hostnames as real inventory

مکانیزم فایل بازگشت

فایل بازگشت را باید عمداً «خسته‌کننده» طراحی کرد، زیرا در لحظه هشدار، سادگی تنها چیزی است که اهمیت دارد. این فایل در کنار مسیر استقرار قرار می‌گیرد و سه داده حیاتی را نگه می‌دارد: آخرین تصویر سالم (Image)، تعداد رپلیکاها و هویت ConfigMap.

مثالی از deploy/rollback/checkout-api.last-good.txt:

image: checkout-api:sha-example
replicas: 3
configmap: checkout-api-2026-09-01

اگر این فایل موجود نباشد، اعتبارسنج (Validator) پیش از آنکه مهندس به خط فرمان دست بزند، اجازه شروع کار را نمی‌دهد. این امر تضمین می‌کند که مسیر بازیابی یک آرتیفکت شناخته‌شده باشد، نه دستوری که مهندس خسته به یاد می‌آورد.

قانون دستورات اول «فقط-خواندنی»

یکی از سخت‌گیرانه‌ترین محدودیت‌ها، جداسازی دستورات اولیه است. پروتکل حکم می‌کند تمام گام‌های تشخیصی اول باید فقط-خواندنی (Read-only) باشند. هر دستوری که نیاز به apply یا delete یا restart یا scale داشته باشد، از لیست first_commands حذف می‌شود. مهندس باید از خود بپرسد: «اگر مالک انجماد امشب در دسترس نبود، آیا باز هم این دستور را اجرا می‌کردم؟»

برای یک هشدار تأخیر (Latency)، دستورات پیشنهادی فقط-خواندنی شامل موارد زیر است:

• kubectl get deploy checkout-api -o jsonpath='{.spec.replicas}{\n}'
• kubectl describe pod -l app=checkout-api | sed -n '1,80p'
• kubectl get events --field-selector involvedObject.name=checkout-api --sort-by=.lastTimestamp
• curl -sS -o /tmp/healthz.json -w "%{http_code}\n" https://status.internal.example/checkout-api/healthz
• sha256sum deploy/rollback/checkout-api.last-good.txt

مهندسان باید هش‌های خروجی را در یادداشت‌های بسته ثبت کنند تا نفر بعدی همان شواهد را ببیند، نه یک بافر ترمینال که پاک شده است. یک حاشیه‌نویسی انجماد (Freeze Annotation) جزو دستورات اول نیست؛ بلکه تنها پس از اتمام بودجه زمانی و با استفاده از --dry-run=client طراحی می‌شود. برای مثال، یک انجماد تحت مالکیت انسان به این شکل خواهد بود: kubectl annotate deploy checkout-api oncall.packet/frozen=true --dry-run=client -o yaml.

هوش مصنوعی به عنوان پیش‌نویس، نه اپراتور

این چارچوب خط قرمز شدیدی برای عامل‌های هوش مصنوعی ترسیم می‌کند. در حالی که دموهای فراخوانی تابع (Function Calling) نشان می‌دهند عامل‌ها مستقیماً APIهای تولید را از داخل یک ادیتور اجرا می‌کنند، این پروتکل چنین دسترسی را بی‌پروا می‌داند. دستیاری که می‌تواند دستور را بنویسد، نباید اجازه اجرای آن را داشته باشد. تولید دستور باید از خوشه‌ای (Cluster) که در حال ارسال هشدار است، کاملاً جدا باشد. این تفکیک دقیق بین تولید دستور و اجرای آن، با رویکرد تأیید منطق پیش از اجرا برای اعتبارسنجی عامل‌های هوش مصنوعی هم‌راستا است.

عامل‌هایی مانند MonkeyCode به محیط‌های «جعبه شنی» (Scratch Box) منتقل شده‌اند. آن‌ها می‌توانند در نوشتن فایل YAML یا پیشنهاد دستورات خواندنی کمک کنند، اما هرگز نمی‌توانند «مالک انجماد» باشند. مهندس انسان باید هر قطعه کد تولید شده توسط AI را بازبینی و دستی کپی کند تا هیچ دستور تغییردهنده‌ای بدون حسابرسی انسانی وارد تاریخچه Git نشود. گزینه سرور رایگان ارائه شده توسط MonkeyCode به عنوان مکانی ایزوله برای اجرای اعتبارسنج استفاده می‌شود، نه به عنوان یک Jump Host برای ورود به خوشه.

هنگام استفاده از دستیار، پرامپت باید سخت‌گیرانه باشد:

• داده‌های مشتری را حذف (Redact) کن.
• فقط دستورات تشخیصی فقط-خواندنی پیشنهاد بده.
• هر دستور باید نام باینری، منبع و خروجی برای ذخیره‌سازی را ذکر کند.
• صراحتاً دستورات kubectl apply ،delete ،rollout restart یا scale را ممنوع کن.
• گام‌های باز کردن انجماد (Unfreeze) را پیشنهاد نده.
• فقط یک قطعه YAML برای first_commands برگردان.

اعتبارسنجی خودکار و منطق «رد هشدار»

برای اجرای این نظم، یک اعتبارسنج مبتنی بر پایتون به کار گرفته می‌شود. این اسکریپت روی یک سرور مجزا یا لپ‌تاپ اجرا می‌شود — هرگز به عنوان یک کنترلر خوشه استفاده نمی‌شود. این ابزار در صورت خالی بودن فیلدهای ضروری، عملیات را متوقف می‌کند. اعتبارسنج وجود فایل بازگشت را بررسی می‌کند، هش SHA256 را تایید می‌کند و به دنبال کلمات کلیدی تغییردهنده شامل apply ،delete ،restart ،scale ،cordon ،drain ،replace و patch می‌گردد.

#!/usr/bin/env python3
"""Proposed handoff packet validator. Example only; not production incident data."""
from __future__ import annotations
import hashlib
import re
import sys
from pathlib import Path
try:
    import yaml
except ImportError:
    print('install pyyaml in the scratch environment, not on the frozen host')
    sys.exit(2)

MUTATING = re.compile(r'\b(apply|delete|restart|scale|cordon|drain|replace|patch)\b', re.I)
REQUIRED = ('alert_id', 'rollback_file', 'diagnostic_budget_seconds', 'freeze_scope', 'unfreeze_owner', 'escalation_target')

def load_packet(path: Path) -> dict:
    data = yaml.safe_load(path.read_text())
    if not isinstance(data, dict):
        raise ValueError('packet must be a mapping')
    spec = data.get('spec') or {}
    meta = data.get('metadata') or {}
    return {**meta, **spec}

def main() -> int:
    packet_path = Path(sys.argv[1] if len(sys.argv) > 1 else 'oncall-handoff.packet.yaml')
    pkt = load_packet(packet_path)
    errors: list[str] = []
    for key in REQUIRED:
        if not pkt.get(key):
            errors.append(f'missing {key}')
    budget = pkt.get('diagnostic_budget_seconds')
    if not isinstance(budget, int) or budget <= 0 or budget > 900:
        errors.append('diagnostic_budget_seconds must be an int between 1 and 900')
    rollback = Path(str(pkt.get('rollback_file', '')))
    if not rollback.is_file():
        errors.append(f'rollback_file does not exist: {rollback}')
    else:
        digest = hashlib.sha256(rollback.read_bytes()).hexdigest()
        print(f'rollback_file sha256={digest}')
    commands = pkt.get('first_commands') or []
    if not commands:
        errors.append('first_commands must contain at least one read-only command')
    for cmd in commands:
        if MUTATING.search(str(cmd)):
            errors.append(f'mutating first command: {cmd}')
    if pkt.get('unfreeze_owner') == pkt.get('escalation_target'):
        errors.append('unfreeze_owner and escalation_target must be different people')
    if errors:
        print('REFUSE THE PAGE')
        for item in errors:
            print(f'- {item}')
        return 1
    print('packet complete; freeze_scope may be applied by the named owner')
    return 0

if __name__ == '__main__':
    raise SystemExit(main())

اگر اعتبارسنج پیام «REFUSE THE PAGE» را چاپ کند، مهندس تشخیص را شروع نمی‌کند و مستقیماً مالک سرویس را فرا می‌خواند. این کار مانع از آن می‌شود که «عدم قطعیت» در قالب «اقدام» شست‌وشو داده شود. مهندس پشتیبان نیز می‌تواند همین اسکریپت را روی لپ‌تاپ خود اجرا کند و باید به همان نتیجه برسد تا تکرارپذیری تضمین شود.

توقف سخت: ساعت ۵ دقیقه‌ای

بودجه ۳۰۰ ثانیه‌ای تشخیص، یک توقف سخت است، نه یک پیشنهاد. وقتی تایمر به صفر می‌رسد، مهندس باید از پیشنهاد فرضیات دست بردارد. اگر علت ناشناخته ماند، محدوده انجماد (freeze_scope) فعال شده و حادثه به escalation_target ارجاع داده می‌شود.

این کار مانع از تله «لاگ‌های جالب» می‌شود؛ جایی که مهندس یک ساعت وقت صرف عیب‌یابی یک موضوع کنجکاوی‌برانگیز می‌کند در حالی که مسیر مشتری در حال سوختن است. لاگ‌های جالب پس از دقیقه پنجم باید در یادداشت‌های ارجاع (Escalation Note) قرار گیرند، نه در یک جلسه عیب‌یابی محلی طولانی‌تر. این ساعت از قانون انجماد محافظت می‌کند و تضمین می‌کند که بداهه پردازی‌ها برای گزارش پس از حادثه (Postmortem) ذخیره شوند، نه برای حادثه زنده. فرضیات اضافی ارزان هستند، اما تغییرات اضافی در زمان انجماد، راهی برای نوشتن هشدار بعدی است.

ماتریس تصمیم‌گیری برای وضعیت بسته

جدول زیر سیاست‌های مورد دفاع در پل ارتباطی حادثه (Incident Bridge) را تعریف می‌کند:

ارجاع و محدودیت‌ها

ارجاع (Escalation) یک انتقال بسته است، نه یک احساس. وقتی بودجه به صفر می‌رسد، مهندس از پیشنهاد فرضیات جدید دست می‌کشد و محدوده نام‌برده را منجمد می‌کند. او بسته تحویل، هش‌های خروجی دستورات و نتیجه اعتبارسنج را در یادداشت ارجاع قرار می‌دهد. مهندس از ارسال لاگ‌های چت مخلوط با اطلاعات محرمانه، وصله‌های تولید شده توسط دستیار AI یا انجماد سرویس‌هایی که در بسته نام بر نشده‌اند، خودداری می‌کند. مهندس در تماس می‌ماند اما به عنوان یک خواننده، نه به عنوان مالک دوم انجماد.

این گردش کار محدودیت‌های خاصی دارد. فرض بر این است که شما می‌توانید پیش از هشدار، یک فایل بازگشت را نام‌گذاری کنید. اگر سرویسی فاقد آرتیفکت استقرار، مالک سرویس یا پشتیبان باشد، اعتبارسنج به درستی هر هشدار را رد می‌کند. این دلیلی برای نادیده گرفتن فراخوانی انسان‌هایی که سرویس را می‌شناسند نیست. علاوه بر این، تیم‌هایی که یک فرمانده حادثه (Incident Commander) رسمی دارند که سیاست انجماد را مدیریت می‌کند، نباید این بسته را به عنوان منبع حقیقت دوم اضافه کنند. اگر هشدارها صرفاً اطلاع‌رسانی هستند، بودجه ۵ دقیقه‌ای تنها یک نمایش است؛ در عوض مسیریابی هشدارها را اصلاح کنید.

این تغییر در رویکرد، صنعت را از «فرهنگ قهرمانی» — جایی که یک مهندس با یک ری‌استارت شانس‌آور روز را نجات می‌دهد — به سمت یک قرارداد تکرارپذیر و حسابرسی‌شده سوق می‌دهد. این رویکرد اذعان می‌کند که در محیط‌های تولید با ریسک بالا، کند و درست بودن بی‌نهایت بهتر از سریع و اشتباه بودن است.

گام بعدی شما

• بررسی کنید آیا سرویس‌های شما دارای فایل بازگشت (Rollback File) با داده‌های به‌روز هستند یا خیر.
• دستورات تشخیصی تکراری خود را در قالب یک لیست «فقط-خواندنی» استاندارد کنید.
• دسترسی عامل‌های AI را از محیط‌های اجرایی تولید جدا کرده و آن‌ها را تنها به نقش پیش‌نویس محدود کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.