نگاهی بر ابزار MTR

به عنوان یک مدیر شبکه نیاز است تا برای مدیریت و خطایابی ساختار، با ابزارهای مختلفی آشنایی داشته باشید. در دنیای شبکه، ابزارهای متفاوتی برای خطایابی وجود دارند که در میان آن‌ها ping و taceroute از شهرت بیشتری برخوردارند. بااین‌حال ابزار دیگری نیز وجود دارد که شاید همانند این دو ابزار شهرت زیادی نداشته باشد اما فراهم‌کننده‌ی اطلاعاتی به‌مراتب بیشتر و مهم‌تر است. این ابزار قدرتمند، MTR نام دارد.

MTR به مدیر شبکه کمک می‌کند تا خطاها را شناسایی کرده و گزارشی از وضعیت کلی شبکه به دست آورد. در این مطلب سعی شده تا به MTR، داده‌های تولیدی توسط آن و نحوه‌ی تحلیل و تفسیر اطلاعات حاصل از این ابزار، پرداخته شود.

مروری بر عملکرد ابزارهای اصلی خطایابی شبکه

ابزارهای خطایابی شبکه چون ping، traceroute و MTR از Control Message Protocol (ICMP) برای تست ارتباطات و ترافیک تبادلی میان دو نقطه در اینترنت استفاده می‌کنند. هنگام ping یک IP، تعدادی پکت ICMP از مبدأ به سمت مقصد ارسال شده و مقصد نیز در پاسخ تعدادی پکت ICMP برای مبدأ ارسال می‌کند. برحسب پاسخ‌های تبادلی میان این دو نقطه، کاربر قادر خواهد بود تا مقدار round trip time (RTT) مابین این دو نقطه را محاسبه کند.

اما ابزارهایی همانند MTR و traceroute، با کمک فیلد TTL (Time to Live) در هدر پکت IP، تعداد گام‌ها (hop) در مسیر میان مبدأ و مقصد را محاسبه می‌کنند. TTL مشخص‌کننده‌ی تعداد گام‌هایی است که پکت قبل از منقضی شدن می‌تواند از آن‌ها عبور کند. هنگامی‌که از traceroute یا MTR استفاده می‌شود، برای شمارش تعداد hopها، ابتدا چند پیام ICMP با کمترین مقدار برای TTL (مقدار 1) ارسال شده و به‌تدریج مقدار TTL افزایش می‌یابد تا نهایتاً بسته به مقصد موردنظر رسد.

MTR را می‌توان ترکیبی از دو ابزار ping و traceroute معرفی کرد. این ابزار علاوه بر دید کلی از مسیری که ترافیک از مبدأ تا یک مقصد مشخص طی می‌کند، اطلاعات بیشتری در رابطه با وضعیت، ارتباطات و پاسخگویی hopهای قرارگرفته میان مبدأ و مقصد را نیز فراهم می‌آورد.

ادامه خواندن “نگاهی بر ابزار MTR”

فرز و چابک به سبک اسکرام : چارچوب Cynefin

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

تاریخچه ی Scrum

پیدایش Scrum رو معمولاً به انتشار یک مقاله در سال 1986 تحت عنوان: “The New New Product Development Game” نوشته‌ی : Takeuchi و Nonaka، نسبت میدن. مقاله‌ای در توصیف این که چطور شرکت‌هایی مثل هوندا، Canon و Fuji-Xerox با استفاده از روش‌های مقیاس‌پذیر و مبتنی بر تیم به جای روش‌های سنّتی تولید محصول، تونستن سهم نسبتاً خوبی از بازار جهانی رو برای خودشون به دست بیارن. از طرف دیگه، این اولین مقاله‌ای بوده تا اون زمان، که به اهمیت تیم‌های قدرتمند و self-organized اشاره میکنه و نقش مدیریت رو در روند توسعه‌ی محصول مشخص میکنه.

در این مقاله آقایون Takeuchi و Nonaka، برای توصیف روند توسعه‌ی محصول از یک استعاره کمک می‌گیرن. این استعاره در واقع عملی بوده در ورزش راگبی تحت عنوان: Scrum.

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

در این مقاله اینطوری عنوان میشه که:

“همونطور که در بازی راگبی در هنگام شروع مجدد (یا اسکرام) تیم باید به گونه‌ای چیده بشه که بتونه با بیشترین قدرت و سرعت، توپ رو به دست بیاره و بازی رو در دست بگیره، در شرایط رقابتی بازار امروز هم دقیقاً همین نکته صدق میکنه. یعنی اگر قرار هست بازار یک محصول رو به دست بیاری باید تیمی داشته باشی که در کم‌ترین زمان، با بیشترین قدرت و سرعت، با کیفیت‌ترین محصول رو ارائه بدن.”

 

ادامه خواندن “فرز و چابک به سبک اسکرام : چارچوب Cynefin”

بلاک‌چین یا زنجیره بلوک – ققنوسی برخاسته از خاکستر تورنت

این روزا هرجا رو نگاه می‌کنی، از مطبوعات تا تلویزیون تا شبکه‌های مجازی، محاله حداقل با یک تیتر در رابطه با Blockchain (یا نام‌های دیگه‌ی اون یعنی: بلاک‌چین، زنجیره بلوک، زنجیره بلاک) مواجه نشی. یه عده میگن بلاک‌چین مساوی با همون بیت‌کوین(!) و متحول کننده‌ی دنیای اقتصاد و مبادلاتش هست. یه عده میگن زنجیره بلاک آینده‌ای محقق شده از نسل نوی اینترنت هست. یه عده میگن زنجیره‌بلوک بَده و منحرف‌کننده‌ی بشریت از راه راست و باید کلاً از چرخه‌ی هستی محو بشه و … امّا از اونجایی که ذهن جستجوگر من همیشه سرش درد میکنه برای موضوعاتی که این همه حاشیه دور و برش هست و دوست داره از حقیقتشون سر دربیاره، تصمیم گرفتم برم دنبالش و ببینم این بلاک‌چین نهایتاً چیه. اولین جواب رو به سؤال ساده‌ی من در رابطه با این که “بلاک‌چین چیه؟“، ویکی‌پدیا داد:

برداشت آزادی از تعریف بلاک‌چین (Blockchain) در ویکی‌پدیا:

“بلاک‌چین، دفترحساب توزیع‌شده و غیرمتمرکزی عمومی (Public) است که از آن به منظور ثبت معاملات میان چندین کامپیوتر، در ساختاری peer-to-peer استفاده می‌شود.”

نکته: در این مطلب شما بارها و بارها با کلمه‌ی بلاک‌چین یا معادل‌های اون که در پاراگراف اول، داخل پرانتز ذکر شدن، و همینطور بلاک یا همون بلوک، روبه‌رو میشید که دلیلش اینه که تمام این کلمات یکسان هستن و معادل همدیگه و در متون و گفتارهای فارسی از همه‌ی این کلمات استفاده میشه، بنابراین هدف این شد که با استفاده از تمام این کلمات معادل، مخاطبی که این مطلب رو میخونه اگر بعدها چشمش به هرکدوم از این کلمات افتاد بدونه که منظور از همه‌ی این واژه‌ها، همون Blockchain هست.

نگاهی به گذشته: از زیرساخت‌های Server Base تا ایده‌ی شبکه‌های تورنت (Torrent)

بیشتر ارتباطات در دنیای اینترنت از گذشته تا به الان بر مبنای ساختاری Client/Serverای هست. به این صورت که معمولاً دیتابیس‌ها که محل نگهداری اطلاعات هستن، به صورت متمرکز در یک سرور (یا سیستم) ذخیره و نگهداری میشن و هرکس قصد دسترسی به اطلاعات رو داشته باشه باید به سرور متصل بشه و درخواست دریافت داده‌های موردنظرش رو بده. پس به عبارتی ما در دنیای اینترنت با ساختار سلسله مراتبی از ارتباطات روبه‌رو هستیم.

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

فرض کنین قراره در یک سازمان، دیتابیسی برای ذخیره اطلاعات کارکنان راه‌اندازی بشه؛ مسئول انفورماتیک اون سازمان به عنوان مدیر این دیتابیس تصمیم می‌گیره که چه نوع داده‌هایی در دیتابیس ذخیره بشن، چه کسانی بتونن داده‌ای رو در دیتابیس ذخیره کنن یا تغییر بدن، چه کسانی فقط مجوز خوندن اطلاعات از دیتابیس رو داشته باشن، چه کسانی اصلاً اجازه‌ی دسترسی به دیتابیس رو نداشته باشن و …

خب پس دو تا مشکل دیگه که در رابطه با دیتابیس‌های سنّتی وجود داره عبارت‌اند از: اول این که فقط یک مرجع قدرت وجود داره (به عبارتی یک مدیر/ یک مکان فیزیکی برای دیتابیس اصلی)، و از طرف دیگه همین تک مرجعی بودن قدرت باعث میشه که فقط یک نقطه‌ی شکست وجود داشته باشه (معروف به SPoF یا Single Point of Failure). اگر مرجع اصلی قدرت بنا به هر دلیلی از دست بره، دسترسی و مدیریت دیتابیس هم به گونه‌ای از بین میره یا حداقل بازگردانی‌ش پیچیده و هزینه‌بر خواهد بود.

امّا همزمان با حضور قدرتمند زیرساخت‌های کلاینت/سروری در دنیای اینترنت، ساختاری خلق شد به اسم تورنت (Torrent). احتمالاً حداقل یک بار با torrent سر و کار داشتین و باهاش کار کردین. امّا به‌جهت یادآوریِ تعریف تورنت و پاسخ ساده‌ای به سوال «تورنت چیست؟»:

“در ساختار تورنت با مجموعه ای از کلاینت‌های peer-to-peer (کلاینت‌هایی که مستقیم به هم متصل و با هم در ارتباط‌ اند) سر و کار داریم که این کلاینت‌ها از طریق پروتکلی که مشهورترینش BitTorrent نام داره، قادرند تا فایل‌هایی رو در بستر اینترنت توزیع کنند.”

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

در واقع ما در ساختار تورنت، دیتابیسی از فایلها رو داریم که برعکس ساختار دیتابیس‌های سنّتی که در بالا شرح دادیم، این دفعه ما نخواستیم یا اصلاً هزینش رو نداشتیم که یک سرور برای ذخیره‌ی دیتابیس‌مون تهیه کنیم. پس، محل ذخیره‌ی دیتابیس تو این ساختار، سیستم کاربرانی هست که به ساختار تورنت متصل میشن.

حالا ما به جای یک دیتابیس متمرکز در یک سیستم (سرور)، یک دیتابیس توزیع‌شده (distributed database) داریم که هر کاربری توی این ساختار با استفاده از برنامه‌ای که از پروتکل BitTorrent پشتیبانی میکنه، می‌تونه به این دیتابیس توزیع شده‌ی عظیم در حد گستره‌ی جهانی متصل بشه و فایل‌هایی رو که می‌خواد برای خودش کپی کنه.

امّا ساختار تورنت، یک نقص بزرگ داره:
در این ساختار امکان رهگیری فایل‌ها وجود نداره. همین موضوع هم عاملی هست برای این که از یک فایل میلیون‌ها کپی در سراسر دنیا منتشر شده و این ساختار به نوعی غیرقانونی قلمداد بشه (تصور کنین یک فایل یک بار خریداری بشه و بارها و بارها به رایگان در اینترنت توزیع بشه. قطعاً این امر می‌تونه به خیلی از صنایع مثل: فیلم، موسیقی، نشر و … آسیب‌های جبران‌ناپذیری وارد کنه).

حالا چی میشه اگر بتونیم به این نظام بی قانون، اندکی نظم و قانون بدیم؟ یعنی بتونیم ساختاری رو ایجاد بکنیم که بر مبنای مزیت‌های زیرساختی ارتباطات peer-to-peer که به نوعی زیرساخت بهتری نسبت به ساختارهای سنّتی ذخیره‌سازی دیتابیس‌ها محسوب میشن، این امکان رو هم داشته باشه که فایل‌ها رو در اون رهگیری کنیم و از طرف دیگه به گونه‌ای فایل‌ها رو امن کنیم که مطمئن باشیم هر فایلی که در این ساختار ردوبدل میشه نسخه‌ی اصل هست و نه نسخه‌ای کپی یا جعلی و تزریق شده به ساختار از جانب یک هکر. در واقع این‌ها سؤالاتی بود که در هنگام تولد ایده‌ی بلاک‌چین مطرح شدند.

بلاک‌چین: مفاهیم پایه

بلاک چین از ساختار ارتباطات peer-to-peer بهره می‌گیره امّا با این تفاوت که در اینجا، تمام اقداماتی که در بستر این ساختار انجام بشن، قابل رهگیری هستن. برای رهگیری دقیق فایل‌ها باید این امکان رو داشته باشیم که مطمئن بشیم الان اون تنها نسخه از اون فایل هست که دست من هست و همزمان به فرد دیگه‌ای تعلّق نداره. پس در هنگامی که من فایل رو از کاربر دیگه‌ای دریافت میکنم، باید تاریخچه‌ای از این که اون فایل کجاها بوده و دست کیا بوده و این که الان دست من هست رو هم دریافت کنم و از طرفی مطمئن باشم که این تاریخچه از مبادلات فایل، توسط کسی دستکاری نشده. ادامه خواندن “بلاک‌چین یا زنجیره بلوک – ققنوسی برخاسته از خاکستر تورنت”

وقتی سرنوشت‌ها به هم گره می‌خورند: کوتاه درباره‌ی اصطلاح Fate sharing

یه فلسفه‌ای هست تو دنیا که میگه اتفاقایی که برای ما میوفته بخشیش دست ما نیست و در گروی اثر عملی هست که سایر عناصر عالم بر زندگی ما دارن که بهش میگن تقدیر یا سرنوشت. حالا همین موضوع در دنیای شبکه هم صدق می‌کنه. اولین‌بار این اصطلاح رو در دنیای شبکه، آقای کلارک (David D. Clark) در سندی تحت عنوان “فلسفه‌ی طراحی پروتکل‌های اینترنتی DARPA” در سال 1988 معرفی کرد. به زبون ساده، fate sharing میگه:

“اگر ما مجموعه‌ای از عناصر متصل به هم رو داشته باشیم که عملکرد هر کدومشون در گرو عملکرد صحیح سایر عناصر باشه، در این صورت اگر یک عنصر بنا به هر دلیلی fail بشه، سایر عناصر هم به صورت خودکار fail خواهند شد.”

یه مثال تو دنیای واقعی برای درک بهتر این موضوع: سوار پرایدتون (مثلاً) هستین و دارین برمیگردین خونه که یهو متوجه میشین ماشین داره به سختی حرکت میکنه. سریع میزنین کنار و پیاده میشین و می‌بنین که بله یکی از چرخای عقبتون پنچر شده. موتور ماشین سالمه، سه تا چرخ دیگش سالمه امّا چون یه چرخش دچار مشکل شده عملکرد ماشینتون هم دچار مشکل شده و ماشین نمیتونه به حرکت خودش ادامه بده.

امّا ببینیم تو دنیای شبکه کجاها ممکنه fate sharing رخ بده. یکی از مصداقای اصلی بروز fate sharing در هنگام مجازی‌سازی (virtualization) هست. یعنی زمانی که ما یک یا چندتا توپولوژی مجازی رو بر روی یک بستر فیزیکی پیاده‌سازی می‌کنیم. در این صورت هر مشکلی برای اون بستر فیزیکی رخ بده، قطعاً توپولوژی‌های مجازی که بر روی اون پیاده‌سازی شدن هم دچار مشکل میشن. ادامه خواندن “وقتی سرنوشت‌ها به هم گره می‌خورند: کوتاه درباره‌ی اصطلاح Fate sharing”

فرز و چابک به سبک Scrum! (مقدمه)

Scrum که یکی از چارچوب‌ها یا همون framework‌های Agile محسوب میشه در واقع چارچوبی مدیریتی هست برای تولید و توسعه‌ی پروژه‌ها و محصولات خلاقانه! (البته خیلی جاها این خلاقانه رو میگن پروژه‌های پیچیده)

اصلاً اسکرام (Scrum) چیه؟ Agile چیه؟ قضیه چیه؟ چارچوب مدیریتی رو چه به شبکه؟؟؟ 😐

پاراگراف Bold شده‌ی بالا به همراه سوالاتی که مطرح شد، نقشه راه موضوعی هستن که قراره یه چند وقتی زیاد باهاش سر وکار داشته باشیم و به سراغش بریم 🙂

***

تا حالا شده شما هم مثل من به این فکر بیوفتین که چرا خیلی از پروژه‌ها با وجود داشتن سرمایه‌گذاری خوب، تیم خبره و حتی ایده‌های اولیه‌ی فوق‌العاده، به نتیجه‌ی مطلوب نمی‌رسن و اکثر اوقات با انبوهی از پروژه‌های به سرانجام نرسیده و نیمه‌کاره و یا با خروجی که در حد انتظار نبوده، چه در حد کلان و چه در حد سازمان‌های متوسط و کوچیک، در اکثر حوزه‌ها، حتی همین حوزه‌ی IT که بیشتر باهاش آشنا هستیم، روبه‌رو می‌شیم؟

برای پیدا کردن جواب این چراها بیاین برگردیم به دهه‌ی 1990 میلادی، زمانی که این مشکلات خیلی خیلی بیشتر از حال حاضر بودن و ریشه‌‌‌ی این مشکلات و راهکارهایی که برای حلشون داده شد رو از اونجا رهگیری کنیم.

در اون زمان، فاصله و تأخیر زیادی بین نیازهای تجاری دنیای صنعت و محصولی که در پاسخ به این نیازها به صنعت تحویل داده می‌شد، وجود داشت. به زبون ساده، دنیای تجارت و صنعت نیازی رو مطرح میکرد، اما اون چیزی که در پاسخ به نیازش دریافت میکرد متفاوت از اون چیزی بود که خواسته بود و از طرف دیگه زمانی محصول یا تکنولوژیش رو دریافت میکرد که شاید دیگه خیلی دیر شده بود. همین عامل باعث می‌شد که خیلی از پروژه‌ها کنسل بشن!

علتش هم واضح بود: زمانی که تأخیر زیادی تا تحویل محصول نهایی رخ بده، مطمئناً نیازهای بازار و مشتریان در طی این مدت تغییر می کنه. در نتیجه محصول نهایی دیگه اون چیزی نیست که مشتری می‌خواد.

برای مثال بیاین بریم سراغ حوزه‌ای در دنیای تکنولوژی که بیشتر باهاش آشنایی داریم یعنی حوزه‌ی نرم افزار و ببینیم در اون زمان اوضاعش چه شکلی بوده.

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

فازهای مدل Waterfall منبع: Scrum Reference by Michael James and Luke Walter

مشکل بزرگ مدل Waterfall تأخیر زمانی زیاد تا تحویل نهایی محصول بود. بنابراین این روش قادر نبود به فرآیند تولید سرعت ببخشه و عملاً نمی‌تونست پاسخگوی نیازهای دنیای صنعت باشه. همین مشکل باعث شد تا یک سری از رهبرای فکری دنیای نرم‌افزار (یه گروه هفده نفره)، در سال 2000 و بعدش 2001 دور هم جمع بشن و با معرفی یه فلسفه‌ی فکری و عملکردی جدید و انتشار یه بیانیه در رابطه با این فلسفه‌ی فکری، سعی کنن به این اوضاع نابه‌سامون اندکی سروسامون بدن.

این فلسفه‌ی فکری جدید Agile نام داشت و بیانیه‌ای که به معرفی ارزش‌های اون پرداخت تحت عنوان Agile Manifesto یا ارزش‌های Agile، منتشر شد. ادامه خواندن “فرز و چابک به سبک Scrum! (مقدمه)”