در یک سال گذشته اینترنت بینالملل در ایران دو بار برای مدت طولانی قطع شد: از ۱۸ دی تا ۸ بهمن ۱۴۰۴ حدود بیست روز، و بعد از ۹ اسفند ۱۴۰۴ تا ۵ خرداد ۱۴۰۵ حدود ۸۸ روز. وزیر ارتباطات خسارت هر روز قطعی را حدود ۵ هزار میلیارد تومان برآورد کرد. حتی در شهریور ۱۴۰۵ هم گزارشها از اتصالی ناپایدار و اختلالهای پراکنده حرف میزدند.
برای خیلی از سازمانها این دوره یک آزمون ناخواسته بود. شرکتی که ایمیلش روی Gmail بود، ورود کارمندانش با حساب گوگل انجام میشد و سامانهٔ تیکتش یک سرویس خارجی بود، یک صبح دید که عملاً هیچ ابزاری ندارد. در همان روزها سامانههایی که روی سرور داخلی بودند کار میکردند، ولی نه همهشان. بعضی بیسروصدا از کار افتادند چون یک وابستگی کوچک به بیرون داشتند که کسی از آن خبر نداشت.
ما در فنپینو چند سامانه را برای مشتریهایی اجرا میکنیم که روی شبکهٔ داخلی کار میکنند، از جمله یک سرور که از اردیبهشت ۱۴۰۵ اصلاً اینترنت خروجی ندارد. این نوشته از همان تجربه آمده: چه چیزی باید داخلی باشد، کجا وابستگی پنهان پیدا کردیم، و یک سازمان قبل از قطعی بعدی چه چیزهایی را باید چک کند.
«داخلی بودن» یعنی چه؟
اینکه سرور در دیتاسنتر داخلی باشد کافی نیست. سؤال درست این است: اگر فردا فقط شبکهٔ ملی باقی بماند، این سامانه برای انجام کار روزمره به چه چیزی بیرون از مرز نیاز دارد؟ جواب معمولاً طولانیتر از انتظار است. فونت از Google Fonts، کتابخانهٔ جاوااسکریپت از یک CDN خارجی، ورود با گوگل، ارسال پیامک از یک API خارجی، تمدید گواهی SSL، دانلود ایمیج Docker، و در سالهای اخیر فراخوانی یک مدل هوش مصنوعی خارجی. هر کدام از اینها میتواند یک سامانهٔ «داخلی» را از کار بیندازد.
ایمیل سازمانی: جایی که بیشترین ضربه را خوردند
ایمیل اولین چیزی است که در قطعی احساس میشود، چون هم ابزار ارتباط داخلی است و هم ابزار ورود به سامانههای دیگر (بازیابی رمز، کد تأیید، اعلانها). سازمانی که صندوقهایش روی Gmail یا Microsoft 365 است، در قطعی کامل حتی به ایمیلهای داخلی خودش دسترسی ندارد، چون ایمیل بین دو همکار در یک اتاق هم از سرور آن سوی مرز رد میشود.
روی میل سرور داخلی وضع فرق دارد. پیامی که از یک صندوق به صندوق دیگر روی همان سرور میرود هیچوقت شبکهٔ داخلی را ترک نمیکند. ایمیل به مقصدهای خارجی هم گم نمیشود: سرور SMTP آن را در صف نگه میدارد و بارها دوباره تلاش میکند. فقط باید بدانید صف تا کی نگه میدارد. خیلی از سرورها بعد از چند روز پیام را برمیگردانند و در یک قطعی ۸۸ روزه این مهلت کافی نیست. اگر ایمیل خارجی برایتان مهم است، زمان نگهداری صف را بدانید و به کاربران بگویید برگشتی به چه معناست.
ما ایمیل یک دانشگاه با حدود ۱۰ هزار صندوق را از یک سرویس تجاری به سرور خودمیزبان (self-hosted) منتقل کردیم و هزینهاش حدود ۹۰ درصد کم شد. دلیل اصلی آن پروژه هزینه بود، نه قطعی، ولی نتیجهٔ جانبیاش این شد که ایمیل دانشگاه به هیچ سرویس خارجی وابسته نیست. اگر هنوز روی سرویس ایمیل ایرانی بدون دامنهٔ اختصاصی هستید، چرا اکثر سرویسهای ایمیل ایرانی امکان دامنه اختصاصی نمیدهند را هم ببینید.
ورود کاربران: «ورود با گوگل» اولین قربانی است
اگر کارمندان با حساب گوگل یا مایکروسافت وارد سامانهها میشوند، در قطعی نهتنها ایمیل بلکه همهٔ سامانههای متصل هم قفل میشوند. همین دربارهٔ کد تأیید پیامکی که از یک سرویس خارجی ارسال میشود صدق میکند.
راهی که در سامانههایمان رفتیم این است: ورود با ارائهدهندهٔ هویت داخلی (مثل سامانهٔ ورود یکپارچهٔ خود دانشگاه یا دولت من)، و کد یکبارمصرف با پنل پیامک داخلی. اپهای authenticator مثل Google Authenticator هم خوشبختانه آفلاین کار میکنند، چون کد را از ساعت دستگاه میسازند و به اینترنت نیازی ندارند. جزئیات تصمیم پیامکی را در لاگین پیامکی، نه فقط اپ authenticator نوشتهایم.
سروری که اصلاً اینترنت ندارد
از اردیبهشت ۱۴۰۵ یک سرور داریم که عمداً هیچ دسترسی خروجی ندارد. آرشیو اسناد پژوهشی با جستوجوی هوشمند (EnergyFile)، سامانهٔ جستوجوی استاندارد پروب۳۶۱ و یک داشبورد روی آن اجرا میشوند. کار کردن با چنین سروری چند عادت را عوض میکند که در قطعی همه به آن احتیاج پیدا میکنند:
- هیچ چیز در لحظهٔ اجرا دانلود نمیشود. روی آن سرور
docker pullوnpm installکار نمیکند. ایمیج کامل را جای دیگری میسازیم و باdocker saveاز طریق SSH منتقل و آنجاdocker loadمیکنیم. اگر بهروزرسانی سامانهٔ شما به یک رجیستری خارجی وابسته است، در قطعی نمیتوانید حتی یک باگ ساده را درست کنید. - بهروزرسانی بدون قطعی سرویس. چون هر انتقال ایمیج وقت میبرد، استقرار را طوری نوشتیم که کانتینر جدید کنار قدیمی بالا بیاید، سلامتش چک شود و بعد جایگزین شود. اگر سالم بالا نیاید، نسخهٔ قبلی دستنخورده میماند.
- فرانتاند هیچ فایلی از CDN خارجی نمیگیرد. فونتها و کتابخانهها داخل خود ایمیج هستند. یک صفحه که فونتش از Google Fonts بیاید در قطعی چند ثانیه سفید میماند و کاربر فکر میکند سامانه از کار افتاده.
گواهی SSL: ساعتی که بیصدا تیک میزند
این یکی را سخت یاد گرفتیم. گواهیهای Let's Encrypt نود روز اعتبار دارند و معمولاً خودکار تمدید میشوند. تمدید معمول (روش HTTP-01) یعنی سرور Let's Encrypt از بیرون به پورت ۸۰ سرور شما وصل شود. از اوایل تیر ۱۴۰۵ این اتصال برای چند دامنهٔ ما در مسیر ورودی ایران شکست میخورد و تمدید خودکار بدون هیچ خطای آشکاری متوقف شد. گواهیهای قبلی هنوز معتبر بودند و همهچیز سالم به نظر میرسید، تا روزی که تاریخ انقضا نزدیک شد.
راهحل ما تمدید با روش DNS-01 از یک ماشین متصل به اینترنت و کپی کردن فایل گواهی روی سرور داخلی بود. برای بعضی دامنهها هم CDN داخلی (ابرآروان) گواهی لبه را مدیریت میکند. درس اصلی این است که تاریخ انقضای هر گواهی را جایی بنویسید و یادآور بگذارید. در قطعی، تمدید خودکار چیزی است که نباید رویش حساب کنید.
هوش مصنوعی و APIهای خارجی: شکست بیصدا
یکی از سامانههای یک مشتری دانشگاهی ترجمهٔ خودکار را با یک مدل خارجی انجام میداد که از طریق تونل به بیرون وصل میشد. تونل بعد از یک تغییر پیکربندی از کار افتاد و ترجمه حدود یک ماه کار نکرد، بدون اینکه کسی متوجه شود، چون سامانه خطا را قورت میداد و فقط متن ترجمهنشده نشان میداد. هیچ قطعی سراسری هم در کار نبود. حالا فکر کنید همین در یک قطعی سهماهه چه شکلی پیدا میکند.
برای دستیار هوش مصنوعی یک دانشگاه دیگر از اول برعکس عمل کردیم: کل سامانه روی یک ارائهدهندهٔ آزمایشی داخلی ساخته و تست شد و ارتباط با مدل خارجی فقط یک لایهٔ قابل تعویض است. پایگاه برداری و اسناد قرار است روی سرور خود دانشگاه باشند، نه یک سرویس ابری. هدف طراحی این است که اگر مدل خارجی در دسترس نبود، بازیابی اسناد سر جایش بماند و فقط تولید پاسخ متوقف شود، با پیغامی که کاربر بفهمد. قاعدهٔ ساده این است که هر قابلیتی که به یک سرویس خارجی وابسته است باید وقتی شکست خورد، شکستش را نشان بدهد.
ابزارهایی که کار واقعی با آنها انجام میشود
بعد از ایمیل و ورود، نوبت ابزارهای عملیاتی است: سامانهٔ تیکت و پشتیبانی، نرمافزار کارگاه، اپ بازرسی. اینها دو حالت شکست دارند. یا سرورشان خارج از کشور است، که در قطعی کاملاً از دسترس خارج میشوند. یا سرور داخلی است ولی کاربر در محلی کار میکند که اصلاً شبکهٔ پایداری ندارد، مثل کف کارگاه یا سایت پروژه.
برای حالت اول، جواب نصب روی سرور خود سازمان یا دیتاسنتر داخلی است. موقع خرید سامانهٔ تیکتینگ یا نرمافزار تعمیرگاه بپرسید نسخهٔ قابل نصب روی سرور خودتان دارد یا نه، و اگر دارد، بهروزرسانیاش بدون اینترنت چطور انجام میشود. برای حالت دوم باید اپ واقعاً آفلاین کار کند: داده روی دستگاه ذخیره شود و بعد از برگشت اتصال همگامسازی شود. سامانهٔ اجرای تولید فیدار برای کارگاههای فولادی و علاقهمندیهای آفلاین پروب۳۶۱ همینطور ساخته شدهاند. فرق آفلاین واقعی و آفلاین نمایشی را در آفلاین واقعی در برابر آفلاین دروغین توضیح دادهایم.
چکلیست قبل از قطعی بعدی
این فهرست را میشود در یک جلسهٔ دوساعته با تیم IT مرور کرد:
- فهرست همهٔ سامانهها را بنویسید و جلوی هر کدام بنویسید سرورش کجاست.
- برای هر سامانه، یک روز آن را از شبکهای که فقط به اینترنت داخلی دسترسی دارد باز کنید. هر چه کار نکرد، یک وابستگی پنهان است.
- ایمیل: آیا صندوقها روی سرور داخلی هستند؟ صف ارسال خارجی چند روز نگه میدارد؟
- ورود: آیا کسی برای ورود به حساب گوگل یا مایکروسافت نیاز دارد؟ کد تأیید از کجا فرستاده میشود؟
- گواهیها: تاریخ انقضای هر دامنه را بنویسید و روش تمدیدی داشته باشید که به ورود از بیرون روی پورت ۸۰ وابسته نباشد.
- بهروزرسانی: آیا بدون دسترسی به Docker Hub یا npm میتوانید یک نسخهٔ جدید مستقر کنید؟
- پشتیبان: نسخهٔ پشتیبان کجا نگهداری میشود؟ اگر روی یک فضای ابری خارجی است، در قطعی به آن دسترسی ندارید.
- هوش مصنوعی و APIهای خارجی: اگر در دسترس نباشند، سامانه چه نشان میدهد؟
پرسشهای رایج
آیا ایمیل داخلی به Gmail هم ایمیل میفرستد؟ بله، وقتی اتصال بینالملل برقرار است، مثل هر میل سرور دیگری. در قطعی، پیامهای خارجی در صف میمانند و ایمیل داخلی سازمان بدون مشکل کار میکند.
میزبانی در دیتاسنتر داخلی کافی است؟ لازم است ولی کافی نیست. وابستگیهای کوچک مثل فونت، CDN، ورود با گوگل و تمدید گواهی را هم باید حذف کنید.
اپ آفلاین با سامانهٔ داخلی چه فرقی دارد؟ سامانهٔ داخلی در قطعی اینترنت بینالملل کار میکند. اپ آفلاین حتی وقتی کاربر هیچ شبکهای ندارد کار میکند. کف کارگاه و بازرسی میدانی به دومی نیاز دارند.
قطعی بعدی را نمیشود پیشبینی کرد. ولی زمان مناسب برای پیدا کردن وابستگیهای پنهان، وقتی است که اینترنت هنوز وصل است و میشود با خیال راحت جایگزین را آزمایش کرد.
