نقشهٔ صفحه‌ها · ۱۵ صفحه

نوشته‌شده برای: تیم‌های مهندسی، عملیات و بازبینی رخدادها

1. 1

   قطعی درگاه کرایه: پست‌مورتم بدون سرزنش

   • این یک بازبینی بدون سرزنش از قطعی خیالی درگاه کرایه در سامانهٔ حمل‌ونقل یک شهر است.
   • عامل آغازگر یک فایل پیکربندی بیش از حد بزرگ بود، نه اشتباه یک فرد.
   • هدف این است که بفهمیم سیستم چگونه اجازهٔ این خرابی را داد، نه اینکه تقصیر را به گردن کسی بیندازیم.
   • مخاطبان این بازبینی تیم‌های مهندسی، عملیات و بازبینی رخدادها هستند.
2. 2

   رخداد در یک نگاه: کرایه‌ها کی و چگونه از کار افتادند

   • مسافران نمی‌توانستند کرایه بپردازند، چون درگاه کرایه دیگر درخواست‌ها را اعتبارسنجی نمی‌کرد.
   • عامل آغازگر فایلی پیکربندی بود که از حدی که درگاه می‌توانست بارگذاری کند بزرگ‌تر شد.
   • برای رسیدن به نخستین خرابی، یک انتشار عادی پیکربندی کافی بود.
   • این خلاصه دامنهٔ گاه‌شمار دقیقی را که در ادامه می‌آید مشخص می‌کند.
3. 3

   پیامد برای هر یک از سرویس‌های حمل‌ونقل

   • هر سرویس حمل‌ونقل به شکل متفاوتی به درگاه وابسته بود، پس پیامد در هر سرویس فرق داشت.
   • سرویس‌هایی که کرایه را در دروازه به‌صورت برخط اعتبارسنجی می‌کنند بیشترین آسیب را دیدند.
   • سرویس‌هایی که حالت آفلاین داشتند ملایم‌تر افت کردند.
   • تیم‌های عملیات هر جا لازم بود ناچار به روش‌های دستی یا دروازهٔ باز روی آوردند.
4. 4

   دو نسل از درگاه کرایه

   • نسل قدیمی‌تر درگاه پیکربندی را در یک بافر حافظه با اندازهٔ ثابت می‌خواند.
   • نسل جدیدتر طوری ساخته شد که پیکربندی را به‌صورت پویا بارگذاری کند و با اندازهٔ آن بزرگ شود.
   • هر دو نسل در دورهٔ مهاجرت در کنار هم کار می‌کردند.
   • دو نسل با فایل بیش از حد بزرگ رفتار متفاوتی داشتند و همین عیب‌یابی را دشوارتر کرد.
5. 5

   چرخهٔ خرابی که بارها تکرار شد

   • یک نمونهٔ درگاه فایل جدید را بارگذاری کرد و هنگام شروع یا بازخوانی شکست خورد.
   • راه‌اندازی مجدد خودکار آن را دوباره بالا آورد و همان فایل دوباره بارگذاری شد.
   • هر راه‌اندازی مجدد خرابی را تکرار کرد، پس نمونه‌ها هرگز سالم نماندند.
   • بازیابی به تغییر فایل نیاز داشت، نه فقط به راه‌اندازی مجدد فرایند.
6. 6

   گاه‌شمار: نخستین ساعت‌های قطعی

   • پیکربندی منتشر شد و به نمونه‌های درگاه رسید.
   • نمونه‌ها شروع به خرابی کردند و نرخ خطای کرایه بالا رفت.
   • هشدارهای اولیه بیشتر شبیه مشکل شبکه یا ظرفیت بودند تا مشکل پیکربندی.
   • پاسخ‌دهندگان فراخوانده شدند و یک کانال رخداد باز کردند.
7. 7

   گاه‌شمار: بازگردانی و بازیابی

   • پاسخ‌دهندگان پیکربندی جدید را تغییر مشترک میان همهٔ نمونه‌های خراب شناسایی کردند.
   • تیم به آخرین فایل سالمِ شناخته‌شده بازگشت.
   • نمونه‌ها مرحله‌به‌مرحله راه‌اندازی شدند تا سیستم‌های پایین‌دستی بیش از حد بار نگیرند.
   • اعتبارسنجی کرایه بازیابی شد و تیم پیش از اعلام پایان رخداد اوضاع را پایش کرد.
8. 8

   خطا چگونه شناسایی و عیب‌یابی شد

   • سامانهٔ پایش افزایش خطاهای کرایه و نمونه‌های ناسالم درگاه را علامت‌گذاری کرد.
   • پاسخ‌دهندگان تغییرات اخیر را مقایسه کردند و خرابی‌ها را با انتشار پیکربندی تطبیق دادند.
   • گزارش‌های نمونه‌ها خطاهای بارگذاری مرتبط با اندازهٔ فایل را نشان دادند.
   • فرضیه‌های اولیه مانند خرابی شبکه با شواهد کنار گذاشته شدند.
9. 9

   سازوکار: یک فایل پیکربندی بیش از حد بزرگ چگونه درگاه را از کار انداخت

   • درگاه هنگام شروع یا بازخوانی، کل پیکربندی را در حافظه بارگذاری می‌کند.
   • فایل بیش از حد بزرگ از حدی که بارگذار می‌توانست پردازش کند فراتر رفت.
   • بارگذار به جای رد کردن فایل و نگه داشتن پیکربندی قبلی، خودش شکست خورد.
   • شکست در مرحلهٔ بارگذاری یعنی هیچ نمونه‌ای نمی‌توانست کرایه‌ها را پردازش کند.
10. 10

    عوامل مؤثر در پیدایش فایل بیش از حد بزرگ

    • پیکربندی با افزوده شدن مدخل‌ها به مرور زمان، کم‌کم بزرگ شد.
    • ابزار تولید فایل هنگام نزدیک شدن فایل به حد هیچ هشداری نداد.
    • حد اندازه جایی که نویسندگان ببینند مستند نشده بود.
    • رشد فایل در بازبینی عادی به نظر می‌رسید، چون تفاوت‌ها مدخل‌ها را نشان می‌دادند نه اندازهٔ کل را.
11. 11

    وضعیت سیستمی که اجازه داد فایل عبور کند

    • هیچ مرحلهٔ اعتبارسنجی پیش از انتشار، اندازهٔ فایل را با حد درگاه مقایسه نمی‌کرد.
    • انتشار، فایل را یک‌باره و بدون انتشار مرحله‌ای به همهٔ نمونه‌ها فرستاد.
    • هیچ چیز درگاه را وادار نمی‌کرد پس از بارگذاری ناموفق، آخرین پیکربندی سالم را نگه دارد.
    • هر یک از این حفاظ‌ها به‌تنهایی می‌توانست خرابی را مهار کند.
12. 12

    آنچه در واکنش به رخداد خوب پیش رفت

    • پاسخ‌دهندگان به‌سرعت کانال رخداد را تشکیل دادند و نقش‌ها را روشن نگه داشتند.
    • تیم از راه بازبینی تغییرات، پیوند میان تغییر و خرابی‌ها را پیدا کرد.
    • آخرین پیکربندی سالمِ شناخته‌شده برای بازگردانی در دسترس بود.
    • اطلاع‌رسانی به کارکنان عملیات امکان اجرای روش‌های دستی کرایه را فراهم کرد.
13. 13

    اقدامات اصلاحی و مسئولان آن‌ها

    • افزودن بررسی پیش از انتشار که فایل‌های بزرگ‌تر از حد اندازهٔ درگاه را رد کند.
    • درگاه اگر پیکربندی جدید بارگذاری نشد، پیکربندی قبلی خود را نگه دارد.
    • تغییرات پیکربندی به‌صورت مرحله‌ای منتشر شوند و هنگام بروز خطا خودکار متوقف شوند.
    • هر اقدام یک تیم مسئولِ مشخص و یک تاریخ بازبینی دارد.
14. 14

    پرسش‌هایی که بازبینی هنوز نتوانسته پاسخ دهد

    • هنوز روشن نیست چرا هشدارهای اولیه به سمت مشکل شبکه اشاره می‌کردند.
    • تیم هنوز تأیید نکرده است که فایل‌های قبلی تا چه اندازه به حد نزدیک شده بودند.
    • اینکه نسل قدیمی‌تر درگاه هم همین ضعف را دارد یا نه، هنوز پرسشی باز است.
    • این پرسش‌ها به‌عنوان بررسی‌های پیگیری دنبال خواهند شد.
15. 15

    شواهدی که این بازبینی بر آن تکیه دارد

    • این بازبینی بر گزارش‌های درگاه و سنجه‌های خطای کرایه در بازهٔ رخداد تکیه دارد.
    • تاریخچهٔ تغییرات پیکربندی نشان می‌دهد فایل چگونه به مرور زمان بزرگ شد.
    • سابقهٔ کانال رخداد، گاه‌شمار واکنش را فراهم می‌کند.
    • گفت‌وگو با پاسخ‌دهندگان زمینهٔ تصمیم‌های گرفته‌شده را روشن‌تر می‌کند.