مسئله‌ای فراتر از یک شبکه
رابرت کان با همکاری وینت سرف در طراحی TCP/IP نقش داشت. مسئله صرفاً ساخت یک شبکهٔ بزرگ‌تر نبود؛ شبکه‌های مستقل باید می‌توانستند با یکدیگر ارتباط برقرار کنند.
پرسش برای امروز
وقتی سامانه‌ای چند سازمان یا چند فناوری را به هم متصل می‌کند، قرارداد تعامل اهمیت ویژه دارد. چه چیزی باید مشترک باشد و چه چیزی می‌تواند مستقل بماند؟ این پرسش هنوز برای طراحی زیرساخت‌های توزیع‌شده کاربرد دارد.
معماری باز و استقلال اجزا
«شبکه‌ای از شبکه‌ها» با یک شبکهٔ بزرگِ کاملاً یکدست تفاوت دارد. در معماری باز، بخش‌ها می‌توانند توسط سازمان‌های مختلف اداره شوند و ویژگی‌های داخلی متفاوت داشته باشند. آنچه باید مشترک باشد، حداقل قرارداد لازم برای تعامل است. این تمایز کمک می‌کند رشد سیستم به تعویض همهٔ اجزای قبلی وابسته نشود.
چنین استقلالی رایگان به دست نمی‌آید. وقتی مرزهای مدیریتی متفاوت‌اند، خطا، تأخیر و تغییر نسخه اجتناب‌ناپذیر می‌شوند. یک طراحی خوب باید بداند چه اطلاعاتی در مرز منتقل می‌شود، چه تضمینی وجود دارد و کدام خطا باید به لایهٔ بالاتر گزارش شود. پنهان‌کردن همهٔ شکست‌ها، گاهی تشخیص علت را دشوارتر می‌کند.
مثال آموزشی: اتصال دو شعبه
دو شعبه را تصور کن که تجهیزات و ظرفیت متفاوت دارند. هدف ارتباط امن میان سرویس‌های ضروری است، نه یکسان‌کردن هر تنظیم در هر دو محل. پیش از انتخاب ابزار، لازم است مسیرها، سرویس‌های مجاز، مسئول نگه‌داری و رفتار هنگام قطع لینک مشخص شوند. یک اتصال برقرار، به‌تنهایی طراحی کامل محسوب نمی‌شود.
اگر ارتباط بین دو محل قطع شود، چه کاری باید محلی ادامه یابد و چه کاری باید متوقف شود؟ آیا داده‌ها بعداً قابل همگام‌سازی هستند؟ چه کسی از اختلال مطلع می‌شود؟ پاسخ به این سؤال‌ها مرز میان یک آزمایش اتصال و یک سامانهٔ قابل اتکا را روشن می‌کند.
برداشت آموزشی IROSG
برای یک سامانهٔ چندبخشی، دو نمودار بکش: یکی مسیر داده و دیگری مسئولیت ادارهٔ اجزا. اغلب این دو نمودار یکسان نیستند. نقطه‌ای که درخواست از یک حوزهٔ مسئولیت به حوزهٔ دیگر می‌رود، باید قرارداد، لاگ و روش پیگیری مشخص داشته باشد.
مطالعهٔ کار کان از این زاویه، فرصتی برای فکرکردن به رشد، استقلال و تعامل است. همکاری او با سرف در طراحی TCP/IP در منابع تاریخی توضیح داده شده؛ مثال دو شعبه در این متن، برداشت آموزشی امروز است و ادعای بازسازی یک پروژهٔ تاریخی مشخص ندارد.
از یک شبکهٔ بزرگ تا همکاری شبکه‌ها
برای بررسی مفهوم شبکه‌ای از شبکه‌ها، سه محیط فرضی در نظر بگیرید: آزمایشگاه دانشگاه، شبکهٔ یک شرکت و سامانهٔ یک مرکز خدماتی. هر کدام نیاز و مدیریت خودش را دارد. مسئله این نیست که همهٔ آن‌ها یک نرم‌افزار داخلی داشته باشند؛ مسئله، ایجاد راهی برای تعامل قابل فهم است. این مثال آموزشی کمک می‌کند تفاوت میان گسترش یک محیط واحد و اتصال محیط‌های مستقل را ببینیم.
در طراحی پیشنهادی، ابتدا فهرست تصمیم‌های مشترک و مستقل را جدا کنید. نام‌گذاری مقصد و قواعد تبادل باید قابل توافق باشند، اما جزئیات داخلی هر شبکه می‌تواند متفاوت بماند. اگر مرز مشترک بیش از اندازه بزرگ شود، استقلال دشوار می‌شود؛ اگر خیلی مبهم باشد، تعامل شکننده خواهد بود. یافتن این تعادل، مسئله‌ای است که در معماری شبکه و سامانه‌های نرم‌افزاری تکرار می‌شود.
تمرین طراحی یک دروازهٔ ساده
روی کاغذ دو قالب پیام متفاوت تعریف کنید و دروازه‌ای میان آن‌ها قرار دهید. مشخص کنید دروازه چه چیزی را می‌فهمد، چه چیزی را تغییر می‌دهد و چه چیزی را نباید تفسیر کند. اگر مقصد موجود نبود، پیام بیش از اندازه بزرگ بود یا بخشی از داده معتبر نبود، رفتار را بنویسید. این تمرین، پیاده‌سازی تاریخی اینترنت نیست؛ ابزاری برای آشکارکردن مسئولیت‌های یک مرز ارتباطی است.
سپس یک قابلیت تازه به یکی از قالب‌ها اضافه کنید. آیا دروازه باید فوراً تغییر کند؟ آیا طرف مقابل می‌تواند بدون فهم قابلیت جدید، بخش لازم را پردازش کند؟ پاسخ به این پرسش‌ها هزینهٔ تکامل را نشان می‌دهد. قراردادی که فقط برای نسخهٔ امروز مناسب باشد ممکن است با نخستین تغییر مشکل ایجاد کند. سازگاری باید بخشی از طراحی باشد، نه کاری که بعد از بروز اختلال به‌صورت اضطراری انجام شود.
شکست جزئی را جدی بگیریم
در یک سامانهٔ چندبخشی، ممکن است یک مسیر از کار بیفتد ولی بخش‌های دیگر سالم باشند. پس عبارت «سیستم بالا است» به‌تنهایی وضعیت همهٔ کاربران را توضیح نمی‌دهد. باید معلوم باشد کدام خدمت، برای کدام مبدأ و در چه زمانی در دسترس است. این نگاه به طراحی پایش نیز کمک می‌کند: آزمایش از یک نقطه، تمام مسیرهای ممکن را پوشش نمی‌دهد.
برای تمرین، سه مرحلهٔ پردازش بسازید و یکی را به‌طور کنترل‌شده از دسترس خارج کنید. سپس ثبت کنید کدام درخواست‌ها موفق می‌شوند و کدام نه. هدف، ساخت اختلال در شبکهٔ واقعی نیست؛ از محیط مجزا و دادهٔ ساختگی استفاده کنید. نتیجهٔ خوب نشان می‌دهد برنامه چگونه خطا را اعلام می‌کند، چه چیزی قابل تکرار است و کاربر چه انتظاری باید داشته باشد. پنهان‌کردن شکست جزئی پشت یک پاسخ کلی، حل مسئله نیست.
تغییر مقیاس و هزینهٔ هماهنگی
وقتی تعداد اجزا افزایش می‌یابد، مدیریت دستی فرض‌ها دشوارتر می‌شود. نام‌گذاری، مستندسازی و قراردادهای قابل آزمون به همین دلیل اهمیت پیدا می‌کنند. برای هر جزء باید مالک، نسخه و روش بررسی سلامت معلوم باشد. این موضوع به معنی افزودن فرایند سنگین برای هر تغییر کوچک نیست؛ مستند کوتاه اما دقیق می‌تواند از گفت‌وگوهای تکراری و خطاهای ناشی از برداشت متفاوت جلوگیری کند.
یک جدول ساده برای محیط فرضی خود بسازید: جزء، مسئول، ورودی مجاز، خروجی و وابستگی. سپس یک تغییر برنامه‌ریزی‌شده را روی جدول دنبال کنید. کدام تیم باید خبر شود؟ کدام آزمون باید دوباره اجرا شود؟ اگر پاسخ‌ها معلوم نیستند، پیش از افزودن قابلیت تازه، مرزهای معماری نیاز به روشن‌شدن دارند. چنین تمرینی، رابطهٔ طراحی فنی و هماهنگی سازمانی را ملموس می‌کند.
برداشت آموزشی از مسیر کان
در منابع این صفحه، سهم رابرت کان در معماری و همکاری با سرف توضیح داده شده است. مطالعهٔ دقیق باید میان پیشنهاد معماری، پروتکل، پیاده‌سازی و گسترش عملی فرق بگذارد. هر کدام نوع متفاوتی از کار و شواهد دارد. عنوان‌های افتخاری می‌توانند مقدمهٔ آشنایی باشند، اما جای توضیح مسئله و نقش همکاران را نمی‌گیرند.
در پایان مطالعه، یک نمونه از پروژهٔ خودتان انتخاب کنید که چند فناوری یا چند سازمان را به هم وصل می‌کند. بنویسید چه چیزی باید مشترک باشد و چه چیزی می‌تواند مستقل بماند. سپس برای خطا، تغییر نسخه و اضافه‌شدن یک عضو جدید سناریو طراحی کنید. این برداشت، ادعای تازه‌ای دربارهٔ تاریخ نیست؛ روشی است برای استفاده از مطالعهٔ تاریخ در تصمیم‌های امروز، با حفظ تفاوت میان سند و تفسیر.
