پادکست 3 – بررسی مفهوم Leaky Abstraction

تقریبا دو هفته پیش بود که به خاطر درخواست یکی از مشتریان AT&T مبنی بر مشکلی که برای ارتباطات و سرویس هاش در چندین کشور مختلف اروپا به وجود اومده بود، وارد پروسه ی خطایابی مشکل این مشتری شدم. معمولا زمانی معمارها و مشاوران درگیر چنین موضوعاتی میشن که تیم مهندسی نتونن مشکل رو رفع کنن و مشتری درخواست نظارت رده های بالاتر و از شرکت داشته باشه.

مشکل این مشتری این بود که از یک تاریخ مشخصی به طور ناگهانی در زمان هایی از روز در ارتباطات بین نقاط مختلفش در اروپا Packet loss زیادی مشاهده می شد و برخی از سرویس هاش به مشکل می خوردن.

تیم مهندسی شبکه تقریبا همه چیز رو بررسی کرده بود اما هنوز نتونسته بود عامل بروز این مشکل رو پیدا کنه. اتفاق عجیبی که هر 4 یا 5 ساعت یکبار رخ میداد و باعث این Packet loss می شد اما …

این ها بخشی از اتفاقی بود که برای یکی از مشتریان AT&T این اواخر رخ داده بود و در این پادکست شرح داده میشه.

در این رویداد خواهید دید که چطور تغییرات و تصمیم گیری هایی در یک بخش میتونن به بخش های دیگه ای از شبکه نفوذ کنن که شاید مستقیما درگیر اون تغییرات نیستن ولی تحت تاثیر اون ها قرار می گیرن. این مساله اصطلاحا Leaky Abstraction یا انتزاع رخنه گر نامیده میشه که قبلا توضیحی مختصر راجع به اون در این پست داده شده بود.

بعد از بررسی این رویداد به سراغ مثالی با توپولوژی زیر میریم و سعی می کنیم تا دقیق تر این مفهوم رو مورد بررسی قرار بدیم.

نویسنده: محمّد مقدّس

مسافر. عکاس تفریحی طبیعت. فرشته‌سرمایه‌گذار. هواخواه #رمزارز و Blockchain. ساکن اینترنت. معمار و مشاور شبکه/امنیت در AT&T. در حال ساختِ زیگ.

3 دیدگاه برای “پادکست 3 – بررسی مفهوم Leaky Abstraction”

  1. بسیار جالب بود واقعا استفاده کردم و اینکه ایده خیلی جالبی هست که مشکلاتی از نوع کاری و تخصصی تشریح بشه و مثال هایی براش زده بشه و چالش های کاری و تجربیات بیان بشه خیلی عالی بود .
    سلام محمد جان عزیز
    بنده که واقعا از اطلاعات مفید شما لذت میبرم و نهایت استفاده رو میکنم .
    راستش در مورد حوضه نگهداری و پشتیبانی نیاز به یکسری اطلاعات دارم که شامل موارد زیر میشه :
    1. وندور های که عمدتا در شبکه های کامپیوتری در سطوح متفاوت استفاده میشه چی هستن بطور مثال میدونم که سیسکو جونیپر ردبک ردلاین و غیر در زیر ساخت ششبکه و ارتباطات استفاده میشه اما اطلاعاتم خیلی جزئی و مختصر هست .
    2. اطلاعاتی هم درباره سیستم های عامل این وندور ها لازم دارم بطور مثال زبان برنامه نویسیشون چیه . از چه معماری برای طراحی استفاده کرده اند و اگر فریم ور یا پلتفرم هستن بازم ساختارهاشون به چه شکل هست .
    3. اطلاعاتی هم درباره فیچر ها ، سرویس ها و پروتکل هاشون لازم دارم که فکر میکنم داشتن RFC از هر وندوری کمک بکنه
    4. و در آخر سطح سازگاری وندور ها با یک دیگر چقدر هست ؟ و این سازگاری به چصورت بوجود آمده است ؟
    در صورت امکان خواستم که با کمک شما اطلاعات فوق رو بدست بیارم
    و تشکر میکنم از بذل توجه شما و وقتی که میذارین

    1. سلام.
      ممنون از نظر لطف شما.

      1. برای این مورد میتونین از گرازش های Quadrant Magic گارتنر استفاده کنین.
      2. خیلی کلی هست سوالتون و بنده عاجز از پاسخ اما اگر بیشتر تحقیق کنین حتماً جواب هاتون رو میتونین پیدا کنین.
      3. این سوال هم مانند مورد دوم. فقط نکته اینکه RFC (عموما) مستندات استانداردی هستن که توسط IETF تولید شدن و و پروتکل ها استاندارد هستن و وندورها ازونا پیروی میکنن. حالا ممکنه یک وندوری یک فیچری کم یا اضافه… که باز هم باید در رابطه با هر وندوری تخقیق کنین متسقلاً.
      4. کلاً هدف IETF تولید استانداردهای Interoperable هستن و وندورها برای پروتکل های استاندارد ازونا پیروی میکنن. (مثل مورد سوم؛ ممکنه یک وندور یک فیچر کم و زیاد… اما اصل پروتکل باید رعایت شده باشه)

      موفق باشید.

  2. سلام ممنونم
    عالی بود. به خصوص مبحث آخر که به trade off اشاره کردین و اینکه هر برند و ابزاری مزایا و معایب خودش رو داره و نباید مطلق گرایی کرد.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

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