05 · پیام‌رسان داخلی برای زمان قطعی

MRM

وقتی اینترنت قطع شد، ابزاری را ساختم که شرکت برای ادامه کار به آن نیاز داشت.

MRM یک پیام‌رسان داخلی و خودمیزبان است که همان روزهای قطعی تعریف، طراحی، ساخته و راه‌اندازی کردم. حدود ۴۰ نفر تا برگشت اینترنت از آن استفاده کردند.

زمان
۱۴۰۵
وضعیت
داخلی · استفاده شده هنگام قطعی
نقش من
مالک محصول · توسعه‌دهنده Full-stack
تیم
برای یک شرکت حدود ۴۰ نفره ساختم و همان تیم از آن استفاده کرد
حدود ۴۰ نفردر زمان قطعی با هم در ارتباط ماندند
ساخته‌شده در بحرانتعریف، ساخت و راه‌اندازی در زمان محدود
خودمیزبانمتناسب با زیرساخت محدود شرکت
استفاده واقعیتا زمان برگشت اینترنت در استفاده بود
MRM پیام‌رسان داخلی برای زمان قطعی
01

این محصول چرا ساخته شد

داستان پروژه

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

مسئله اصلی

تیم یک پیام‌رسان تازه و پر از قابلیت نمی‌خواست. ابزاری آشنا لازم داشت که سریع روی زیرساخت خود شرکت بالا بیاید و برای اجرا به CDN، سرویس ابری یا دانلود از خارج وابسته نباشد.

برای چه کسانی

کارکنان و مدیرانی که برای ادامه کار به پیام مستقیم و گروهی، فایل، وضعیت حضور و برگشت مطمئن پیام بعد از قطعی نیاز داشتند.

نتیجه‌ای که دنبالش بودم

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

02

چه چیزی کار را سخت می‌کرد

01

دسترسی ناپایدار به اینترنت بین‌الملل

نمی‌شد روی package registryها، فایل‌های CDN یا پلتفرم‌های ابری حساب کرد.

02

استفاده فوری

فرصتی برای آموزش نبود؛ لازم بود اعضای تیم از همان نگاه اول ابزار را بفهمند و با آن احساس آشنایی کنند.

03

اتصال مقطعی

قطع‌و‌وصل کوتاه نباید باعث می‌شد گفت‌وگوها از بین بروند یا وضعیت پیام‌های خروجی نامعلوم بماند.

04

راه‌اندازی ساده

برنامه و دیتابیس باید روی زیرساخت خود شرکت و بدون وابستگی به پلتفرم ابری یا ابزارهای نصب‌شده از اینترنت اجرا می‌شدند.

03

اول چه چیزی را ساختم و چرا

  1. 1
    اجراشده

    فقط مسیرهای ضروری

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

  2. 2
    فعال

    حذف وابستگی به سرویس‌های خارجی

    کتابخانه‌های مرورگر محلی سرو می‌شوند، وابستگی‌های production همراه پروژه‌اند و راه‌انداز می‌تواند mirror در دسترس Ubuntu را انتخاب کند.

  3. 3
    فعال

    بازیابی بعد از قطع‌و‌وصل

    IndexedDB گفت‌وگوها را نگه می‌دارد، پیام‌های خروجی در صف محلی می‌مانند و بعد از اتصال دوباره همگام می‌شوند.

  4. 4
    اجراشده

    راه‌اندازی برای استفاده واقعی

    سیستم را روی زیرساخت داخلی راه انداختم و حدود ۴۰ نفر تا برگشت اینترنت عادی با آن کار کردند.

04

تصمیم‌های اصلی من

تصمیم 1فعال

استفاده از الگوی آشنای پیام‌رسان‌ها

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

تصمیم 2فعال

یک استک ساده و خودمیزبان

Node، Express، Socket.IO، MongoDB، Nginx و systemd باعث شدند اجرای سیستم روی زیرساخت شرکت ساده و قابل بازیابی بماند.

تصمیم 3فعال

پشتیبانی از قطع‌و‌وصل کوتاه

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

تصمیم 4اجراشده

محدوده استقرار خصوصی

MRM برای زیرساخت داخلی شرکت ساخته شده است. پیش از هر دسترسی عمومی، به بررسی امنیتی مستقل نیاز دارد.

05

سیستم چطور کار می‌کند

01

مرورگر و PWA

کلاینت بدون فریم‌ورک، کتابخانه‌های محلی، IndexedDB، service worker و اعلان.

02

شبکه محلی

ارتباط HTTPS و WebSocket از طریق Nginx بدون وابستگی به SaaS عمومی.

03

برنامه

سرویس Node و Express، REST APIها را ارائه می‌دهد و Socket.IO رویدادهای لحظه‌ای را مدیریت می‌کند.

04

ذخیره‌سازی

MongoDB خودمیزبان اطلاعات را نگه می‌دارد و فایل‌ها و رسانه‌ها در فضای محلی ذخیره می‌شوند.

05

عملیات

Systemd، وابستگی‌های همراه پروژه، انتخاب mirror و Nginx راه‌اندازی دوباره سیستم را ساده نگه می‌دارند.

کارهایی که خودم انجام دادم

  • تعریف مسئله در شرایط اضطراری، اولویت‌بندی، طراحی تعامل و پیاده‌سازی
  • پیام لحظه‌ای، حضور کاربران، وضعیت تحویل و خواندن، واکنش، پاسخ، فایل و گروه
  • صف آفلاین، کش محلی، همگام‌سازی بعد از اتصال، PWA و اعلان
  • استقرار خودمیزبان، راه‌اندازی متناسب با وضعیت شبکه، تأیید مدیر و پشتیبانی کاربران
06

چیزهایی که می‌شود بررسی کرد

استفاده واقعی

استفاده در زمان اختلال

حدود ۴۰ نفر در دوره قطعی، تا زمان برگشت اینترنت عادی از MRM برای هماهنگی کار استفاده کردند.

مخزن کد

تاب‌آوری واقعاً در کد پیاده شده

وابستگی‌های همراه پروژه، فایل‌های محلی، تست mirror، systemd، صف آفلاین، IndexedDB و رفتار اتصال دوباره همگی در مخزن قابل بررسی‌اند.

مرزبندی

محدودیت‌های فنی مستندشده

در مستندات مشخص شده سیستم در چه شرایطی تاب‌آور است و در چه بخش‌هایی به شبکه داخلی در دسترس و بررسی امنیتی مستقل نیاز دارد.

07

امروز پروژه کجاست

MRM در دوره قطعی امکان هماهنگی ضروری یک شرکت حدود ۴۰ نفره را فراهم کرد و تا زمان برگشت اینترنت عادی مورد استفاده بود.

چیزی که یاد گرفتم

  1. 01

    در بحران، بهترین نقشه راه کوتاه‌ترین مسیر برای برگشتن به کار ضروری است.

  2. 02

    محدودیت زیرساخت بخشی از کشف محصول است، نه فقط کار DevOps.

  3. 03

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

پروژه بعدیApex