چالش: صرافی فعال، زیرساخت خارج از دسترس

زیرساخت هر سه صرافی روی سرورهای خارج از ایران قرار داشت. با افزایش اختلال‌های اینترنتی، کاربران داخل کشور با ناپایداری و کندی دسترسی مواجه می‌شدند و ارتباط سرویس‌ها نیز تحت تأثیر قرار می‌گرفت. برای کسب‌وکاری که APIهای معاملاتی، WebSocket، قیمت، KYC، Deposit، Withdrawal و Notification باید پیوسته در دسترس باشند، این وضعیت یک ریسک مستقیم عملیاتی بود.

هم‌زمان، تیم DevOps مشخصی روی پروژه‌ها وجود نداشت. سرویس‌ها Containerized نبودند، فقط محیط Production داشتند، Deployment دستی بود، فایل‌ها روی دیسک سرورها نگهداری می‌شدند و Monitoring، Redundancy، Backup، DR و کنترل‌های امنیتی به بلوغ بیشتری نیاز داشتند.

مسئله فقط انتقال چند سرور نبود؛ هر صرافی به زیرساختی نیاز داشت که پس از مهاجرت نیز یک تیم مشخص مسئول سلامت، امنیت، Deployment و Incidentهای آن باقی بماند.

Audit: نقشه راه مهاجرت پیش از اولین تغییر

Dropp Tempo پیش از اجرا، زیرساخت خارجی هر سه پروژه را Audit کرد. معماری سرویس‌ها، پایگاه‌های داده، مسیر Deployment، وابستگی‌های خارجی، Monitoring، Backup، دسترسی‌ها، Hardening و سناریوهای Failure بررسی شدند.

Audit نشان داد چند اولویت باید هم‌زمان جلو بروند: انتقال میزبانی به ایران، Dockerize کردن سرویس‌ها، ساخت Staging، ایجاد Redundancy در لایه‌های حیاتی، استانداردسازی Deployment، انتقال فایل‌ها به Object Storage و ایجاد مسیر قابل‌اتکا برای Backup و Recovery.

برای هر پروژه Runbook مهاجرت، Cutover و Rollback جداگانه آماده شد. به این ترتیب Build از یک نقشه عملیاتی مشخص شروع شد، نه از انتخاب عجولانه ابزارها.

سه مهاجرت در حدود ۲۰ روز، بدون Data Loss

مهاجرت هر پروژه در حدود ۲۰ روز انجام شد. ابتدا سرویس‌ها Dockerize و محیط Staging ساخته شد. سپس یک انتقال آزمایشی اجرا شد تا Deployment، ارتباط سرویس‌ها، بازیابی داده و عملکرد محیط مقصد پیش از Cutover اصلی بررسی شود.

در پنجره نهایی، سرویس‌ها به حالت Read-only رفتند و پایگاه‌های داده MongoDB و SQL Server با فرایند کنترل‌شده Dump و Restore منتقل شدند. پس از Restore، تیم Dropp Tempo یکپارچگی داده را بررسی کرد و تیم توسعه تست‌های کاربردی خود را انجام داد.

هر سه Cutover در حداکثر دو ساعت و بدون Data Loss تکمیل شدند. زیرساخت قبلی نیز یک ماه روشن باقی ماند تا در دوره تثبیت، مسیر Rollback در دسترس باشد.

معماری برای Availability، Performance و بازیابی

در مجموعه این سه پروژه از Kubernetes و Docker Swarm استفاده شده است. سرویس‌ها روی کلاسترهای چندنودی اجرا می‌شوند و NGINX یا CDN توزیع ترافیک را بر عهده دارد. این ساختار، استقرار سرویس‌ها و مدیریت ظرفیت را استاندارد و خرابی محدود یک Node را قابل‌کنترل کرده است.

در لایه داده، MongoDB به‌صورت Replica Set و SQL Server با Standby Node پیاده‌سازی شد. فایل‌های محصول نیز از دیسک Application Serverها به Object Storage منتقل شدند. Failoverها کنترل‌شده‌اند و Incident Commander پس از بررسی وضعیت درباره سوییچ تصمیم می‌گیرد.

Dropp Tempo زیرساخت APIهای معاملاتی، WebSocket، سرویس قیمت، Deposit و Withdrawal، KYC و Notification را مستقر و نگهداری می‌کند. منطق مالی، دارایی کاربران، Wallet و کلیدهای خصوصی خارج از Scope این همکاری‌اند.

از انتشار دستی به Deployment ده‌دقیقه‌ای

Dropp Tempo برای هر سه پروژه Pipeline مبتنی بر GitLab CI و GitLab Container Registry ایجاد کرد. مسیر استاندارد انتشار شامل نصب Dependencyها، Lint، Build، Release و Deploy است و اجرای کامل Pipeline حدود ۱۰ دقیقه زمان می‌برد.

در محیط‌های Kubernetes، Argo CD وضعیت مطلوب سرویس‌ها را از Git دریافت و اعمال می‌کند. در Docker Swarm نیز Deployment با Webhook پورتینر انجام می‌شود. Rollback از طریق Argo CD یا قابلیت Rollback پورتینر در حدود ۱۰ دقیقه قابل انجام است.

تیم توسعه Release را اجرا می‌کند و Dropp Tempo مسئول نگهداری، عیب‌یابی و بهبود Pipelineها، Registry و زیرساخت Deployment باقی می‌ماند.

دسترسی پایدار در ایران، اتصال کنترل‌شده به جهان

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

Dropp Tempo با استفاده از pfSense یا MikroTik و Tunnelهای مبتنی بر OpenVPN و WireGuard، مسیرهای خروجی موردنیاز را طراحی و وارد Monitoring کرد. در یکی از پروژه‌ها Tunnel پشتیبان نیز پیاده‌سازی شد تا خرابی مسیر اصلی به توقف کامل ارتباطات خارجی منجر نشود.

این لایه یکی از مهم‌ترین تفاوت‌های زیرساخت صرافی با یک نرم‌افزار معمولی بود؛ چون سلامت سرورها به‌تنهایی برای سالم‌ماندن محصول کافی نبود و مسیر دسترسی به سرویس‌های بیرونی نیز باید بخشی از معماری و Incident Response می‌شد.

pfSense

امنیت چندلایه و قابل ممیزی

دسترسی مدیریتی هر سه پروژه از VPN عبور می‌کند و اتصال به سرورها با Teleport و MFA انجام می‌شود. لاگ دسترسی‌های VPN و Teleport قابل ممیزی است و Secretها متناسب با هر محیط در GitLab Environment Variables، Portainer یا HashiCorp Vault مدیریت می‌شوند.

تمام سرورها با Playbook اختصاصی Ansible تیم Dropp Tempo Hardening می‌شوند. Imageهای ساخته‌شده با Trivy اسکن می‌شوند و در لایه CDN نیز WAF، Rate Limiting و DDoS Protection فعال است. Backupها نیز پیش از انتقال به Object Storage رمزنگاری می‌شوند.

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

TrivyTeleport

Observability برای بیش از پنج میلیون Request روزانه

Prometheus، Grafana و Alertmanager سلامت سرورها، کلاسترها، پایگاه‌های داده، Endpointها و Business Metricهای Exposeشده را پایش می‌کنند. ELK برای تجمیع Log و APM به کار می‌رود، Sentry خطاهای Application را ثبت می‌کند و Uptime Kuma دسترس‌پذیری Endpointهای اصلی را از بیرون می‌سنجد.

Alertهای عملیاتی هم‌زمان به کانال پشتیبانی مشتری در Mattermost و Rocket.Chat داخلی Dropp Tempo ارسال می‌شوند. تیم On-call با دریافت Alert بحرانی یا تماس مشتری فعال می‌شود و Incident Commander مسئول هماهنگی تشخیص، Failover، Rollback و بازیابی سرویس است.

این سه زیرساخت در مجموع بیش از پنج میلیون Request روزانه در لایه NGINX ثبت می‌کنند و در بازه ۳۰روزه منتهی به انتشار، هر سه آپتایم بالاتر از ۹۹.۹۵٪ داشته‌اند. در یکی از پروژه‌ها نیز زیرساخت طی یک کمپین پرترافیک مرتبط با جام جهانی، بدون اختلال قابل‌توجه به سرویس‌دهی ادامه داد.

Uptime KumaRocket.ChatMattermost

Backup و Disaster Recovery آماده برای عملیات واقعی

از تمام پایگاه‌های داده هر ۲۴ ساعت Full Backup و هر ۳۰ دقیقه Incremental Backup گرفته می‌شود. Backupهای رمزنگاری‌شده روی Object Storage خارج از زیرساخت اصلی قرار می‌گیرند و به مدت ۳۰ روز نگهداری می‌شوند. Database Replication نیز در کنار Backup از سرویس‌های حیاتی محافظت می‌کند.

پس از پیاده‌سازی، Restore Test انجام شد و برای داده و سرویس‌های حیاتی RPO پانزده دقیقه و RTO یک ساعت تعریف شد. محیط Passive در دیتاسنتر دوم همان Cloud Provider آماده است، داده‌های حیاتی با آن Sync می‌شوند و سرویس‌ها از قبل روی مقصد Deploy شده‌اند.

در سناریوی Disaster، انتقال ترافیک با تصمیم Incident Commander و به‌صورت کنترل‌شده انجام می‌شود. این طراحی به تیم اجازه می‌دهد به‌جای شروع بازیابی از صفر، از یک محیط ازپیش‌آماده‌شده استفاده کند.

نتایج فنی و تجاری

  • اجرای سه پروژه مهاجرت و بازطراحی، هرکدام در حدود ۲۰ روز
  • Cutover حداکثر دوساعته و بدون Data Loss در هر سه پروژه
  • رفع اختلال دسترسی کاربران داخل ایران و بهبود پایداری و سرعت سرویس
  • پردازش بیش از پنج میلیون Request روزانه در لایه ورودی زیرساخت
  • ثبت آپتایم بالاتر از ۹۹.۹۵٪ برای هر سه پلتفرم
  • تبدیل Deployment دستی به Pipeline استاندارد حدوداً ده‌دقیقه‌ای
  • Rollback حدوداً ده‌دقیقه‌ای از طریق Argo CD یا Portainer
  • ایجاد Staging، Database Replication و Object Storage
  • پیاده‌سازی Monitoring، Logging، APM، Alerting و External Uptime Monitoring
  • استقرار کنترل‌های امنیتی از VPN و MFA تا Hardening، Image Scanning، WAF و DDoS Protection
  • ایجاد Backup رمزنگاری‌شده، Restore Test و محیط Passive بازیابی
  • پشتیبانی ۲۴/۷ با SLA پاسخ اولیه کمتر از ۳۰ دقیقه

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

Retain: مسئولیت زیرساخت بعد از Go-live تمام نمی‌شود

هر سه پروژه پس از مهاجرت وارد مرحله Retain شدند. تیم شش‌نفره Dropp Tempo شامل CTO، DevOps Team Lead، دو Senior DevOps Engineer و دو Junior DevOps Engineer به‌صورت مستمر Monitoring، Incident Response، نگهداری Pipeline، Patch Management، Capacity Planning، Backup، Restore Test، Performance و توسعه زیرساخت سرویس‌های جدید را پوشش می‌دهد.

پشتیبانی ۲۴/۷ و SLA پاسخ اولیه کمتر از ۳۰ دقیقه یعنی مشتری پس از تحویل زیرساخت تنها نمی‌ماند. همان تیمی که تصمیم‌های معماری و مسیر مهاجرت را می‌شناسد، مسئول سلامت روزانه و تکامل بعدی سیستم نیز باقی می‌ماند.

اگر در حال مهاجرت، بازطراحی یا پایدارسازی زیرساخت یک صرافی رمزارز یا پلتفرم مالی هستید، Dropp Tempo می‌تواند کار را با یک Architecture & Reliability Review آغاز کند و از Audit تا Build و Retain در کنار تیم شما بماند.