توسعه برای دیباگ؛ الگوبرداری از طراحی قابلیت عیب‌یابی درونی در Oxide

مقدمه و زمینه

همیشه این شوخی معروف در دنیای زیرساخت وجود دارد که وقتی چیزی خراب می‌شود، مقصر اصلی سیستم DNS است. در شرکت Oxide، کنترل‌پلان سیستم از دو سرویس مجزا برای DNS داخلی و خارجی استفاده می‌کند. منبع اصلی حقیقت (Source of Truth) برای تمام داده‌های DNS، پایگاه‌داده توزیع‌شده و سازگار CockroachDB است.

هسته مرکزی کنترل‌پلان کامپوننتی به نام Nexus است. هنگامی که تغییری در سیستم رخ می‌دهد (مانند اضافه یا کم شدن یک سرویس)، ابتدا تغییرات DNS در پایگاه‌داده ثبت می‌شود. سپس مجموعه‌ای از تسک‌های پس‌زمینه (Background Tasks) در Nexus وظیفه انتشار و انتشار این تنظیمات به تمامی سرورهای DNS در حال سرویس‌دهی را بر عهده دارند. این فرآیند ناهمگام (Asynchronous) است و معمولاً در عرض چند ثانیه کامل می‌شود.

تفکر به سبک توسعه برای دیباگ (Developing for Debugging)

هنگامی که این سیستم طراحی می‌شد، تیم توسعه از خود پرسید: اگر مشتری گزارش دهد که رکورد DNS مورد انتظارش وجود ندارد، دقیقا چه جاهایی ممکن است خراب شده باشد؟ گزینه‌های احتمالی عبارتند از:

• داده‌های DNS موجود در پایگاه‌داده اشتباه باشد.
• فرآیند انتشار (Propagation) متوقف شده باشد یا Nexus متوجه تغییرات نشده باشد.
• لیست سرورهای DNS در Nexus به‌روز نباشد.
• سرور DNS داده‌های اشتباهی را سرویس دهد.

برای حل این مشکل، آن‌ها ابزاری به نام omdb (دیباگر Omicron، که نام داخلی کنترل‌پلان Oxide است) را توسعه دادند. هدف این بود که سیستم بتواند وضعیت خود را به دقت گزارش کند و به جای خطاهای گنگ، شواهد محکمی ارائه دهد که آیا واقعاً کار می‌کند یا خیر.

جزئیات فنی و تسک‌های پس‌زمینه

سیستم انتشار DNS بر اساس یک انتزاع جدید به نام تسک‌های پس‌زمینه پیاده‌سازی شده است. این تسک‌ها در واقع توابع ناهمگام در زبان Rust هستند که ویژگی‌های زیر را دارند:

• در پاسخ به رویدادهای خاصی فعال می‌شوند.
• به صورت دوره‌ای (Periodic) نیز اجرا می‌شوند تا خطاهای موقتی را پوشش دهند.
• مجموعه آن‌ها به صورت ایستا تعریف می‌شود.
• می‌توانند یک ساختار داده دلخواه (به شکل schemaless JSON) به عنوان وضعیت بازگردانند.

با استفاده از این ساختار، ابزار omdb می‌تواند گزارش‌های بسیار دقیقی تولید کند. برای مثال، با دستوراتی مانند omdb nexus background-tasks show می‌توان اطلاعات زیر را مشاهده کرد:

• آخرین زمان اجرای تسک و مدت زمان آن.
• نسخشنی که در حال انتشار است.
• لیست سرورهای DNS مقصد و نتیجه تلاش قبلی برای هر سرور (مانند success).

چرا این موضوع برای مهندسان اهمیت دارد؟

این نوع طراحی مزایای فراوانی برای تیم‌های مهندسی نرم‌افزار به همراه دارد:

• تایید کارکرد به جای نبود خطا: سیستم به جای پیام کلی «بدون خطا»، دقیقاً می‌گوید که چه نسخه‌ای از DNS را در چه تاریخی به کدام سرورها فرستاده است.
• دیباگر-درون توسعه (Debugger-driven Development): می‌توان از ابزارهایی مثل omdb حتی پیش از نوشتن تست‌های خودکار برای بررسی رفتار سیستم در حال ساخت استفاده کرد.
• آموزش و Onboarding: بررسی وضعیت زنده سیستم، ابزار بسیار قدرتمندی برای آموزش دادن نحوه کارکرد بخش‌های مختلف به اعضای جدید تیم است که ارزشی فراتر از مستندات متنی دارد.