معرفی هایپرنیکس

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

اپلیکیشن موبایل هایپرنیکس به کاربران اجازه می‌دهد دستگاه اعلام سرقت خود را از راه دور کنترل کنند. پشت این تجربه ساده، پلتفرمی قرار دارد که باید ارتباط دستگاه‌ها، APIهای محصول و جریان پیام‌ها را به‌شکلی امن و پایدار مدیریت کند. در یک محصول مرتبط با امنیت، اختلال زیرساخت فقط یک خطای فنی نیست؛ مستقیماً بر اعتماد کاربر و قابلیت اتکای محصول اثر می‌گذارد.

مسئله: زیرساخت برای محصولی که باید همیشه قابل اتکا باشد

هایپرنیکس با یک زیرساخت قدیمی یا بحران‌زده به Dropp Tempo مراجعه نکرد. همکاری از ابتدای پروژه آغاز شد و مسئله اصلی، طراحی درست زیرساخت پیش از شکل‌گرفتن بدهی عملیاتی بود.

سه الزام از ابتدا بر تصمیم‌های مهندسی اثر می‌گذاشتند: امنیت کد و زیرساخت، دسترس‌پذیری دائمی سرویس‌های حیاتی و امکان رشد تعداد دستگاه‌ها. پلتفرم باید خرابی محدود یک جزء را تحمل می‌کرد، دید عملیاتی کافی برای تشخیص سریع اختلال ارائه می‌داد و در عین حال با معماری بیش‌ازحد پیچیده و هزینه غیرضروری ساخته نمی‌شد.

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

Audit: تبدیل الزام‌های کسب‌وکار به تصمیم‌های زیرساختی

در یک پروژه Greenfield، Audit به معنای پیدا کردن اشکال‌های یک معماری قبلی نیست. Dropp Tempo پیش از ارائه Proposal، نیازمندی‌های محصول، حساسیت امنیتی، ظرفیت مورد انتظار، وابستگی سرویس‌ها، Failure Scenarioها، Backup، Disaster Recovery و مسیر رشد را بررسی و مستند کرد.

خروجی این مرحله، فهرستی از ابزارهای محبوب نبود؛ یک مجموعه تصمیم متناسب با ریسک و بودجه پروژه بود. هر جزء باید دلیل عملیاتی مشخصی می‌داشت و هزینه نگهداشت آن نیز قابل توجیه می‌بود. این رویکرد به تیم اجازه داد High Availability را در لایه‌های ضروری ایجاد کند، بدون اینکه پروژه به سمت Active–Active کامل و پیچیدگی زودهنگام حرکت کند.

تصمیم مهندسی: High Availability بدون Over-engineering

یکی از گزینه‌های بررسی‌شده، معماری Active–Active گسترده بود. این گزینه می‌توانست سطح بالاتری از خودکارسازی را فراهم کند، اما پیچیدگی عملیاتی، هزینه سرور و ریسک رفتارهای پیش‌بینی‌نشده در زمان ناپایداری را نیز افزایش می‌داد. برای مقیاس و بودجه فعلی پروژه، این Trade-off منطقی نبود.

معماری نهایی در لایه API، پلتفرم IoT، MQTT Messaging و پایگاه داده افزونگی ایجاد می‌کند. Replication داده و Backup منظم، ریسک از دست رفتن اطلاعات را کاهش می‌دهند. Failover نیز به‌صورت کنترل‌شده انجام می‌شود: Alertها وضعیت را به تیم اعلام می‌کنند و Incident Commander پس از ارزیابی شرایط، درباره سوییچ تصمیم می‌گیرد.

دستی‌بودن این تصمیم به معنای نبود High Availability نیست؛ انتخابی آگاهانه برای جلوگیری از سوییچ‌های متوالی در اختلال‌های ناپایدار است. به همین دلیل در این پروژه از ادعاهایی مانند «Failover کاملاً خودکار» یا «Zero Downtime تضمین‌شده» استفاده نمی‌کنیم. آنچه پیاده‌سازی شده، افزونگی چندلایه با مسیر بازیابی کنترل‌شده است.

Build: معماری زیرساخت برای API، IoT و MQTT

زیرساخت اصلی پروژه طی حدود دو ماه آماده شد و هم‌زمان با توسعه محصول تکامل پیدا کرد. Dropp Tempo محیط‌های موردنیاز، مسیر استقرار سرویس‌ها، لایه ارتباط MQTT، Replication داده، کنترل دسترسی، Monitoring و فرایندهای Backup را به‌عنوان اجزای یک سیستم واحد طراحی کرد.

جزئیات Broker، QoS، Session Management و توپولوژی داخلی به دلایل امنیتی منتشر نمی‌شوند. در سطح قابل انتشار، معماری به‌گونه‌ای طراحی شده است که از دسترس خارج‌شدن یک Microservice یا جزء محدود، الزاماً به قطعی کامل پلتفرم منجر نشود. رخدادهای عملیاتی نیز عمدتاً به حالت Degraded یا اختلال جزئی در یک سرویس محدود مانده‌اند.

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

Sanitized Architecture
دستگاه‌های IoT
ورودی امن
پیام‌رسانی MQTT
سرویس‌های API
لایه داده
Observabilityکنترل‌های امنیتیBackup و Disaster Recovery

این دیاگرام مسیر کلی جریان پیام را نشان می‌دهد: از دستگاه‌های متصل تا لایه داده، از یک ورودی امن عبور می‌کند و از طریق پیام‌رسانی MQTT به سرویس‌های API می‌رسد. Observability، کنترل‌های امنیتی و Backup/Disaster Recovery روی تمام این لایه‌ها به‌صورت عرضی اعمال می‌شوند؛ جزئیات پروتکل و توپولوژی داخلی به دلایل امنیتی منتشر نشده‌اند.

امنیت از طراحی تا عملیات روزمره

در هایپرنیکس، امنیت یک مرحله انتهایی پیش از Release نبود. کنترل‌های امنیتی در طراحی شبکه، دسترسی مدیریتی، Pipeline و نگهداشت روزانه وارد شدند.

Network Segmentation با pfSense انجام شد و Portها و مسیرهای دسترسی به حداقل موردنیاز محدود شدند. دسترسی مدیریتی به سرورها از طریق Teleport و احراز هویت دومرحله‌ای انجام می‌شود. ارتباطات حساس با TLS محافظت می‌شوند و RBAC، مدیریت Secrets، Hardening، Patch Management و Audit Logging بخشی از عملیات زیرساخت‌اند.

در زنجیره تحویل نرم‌افزار نیز Imageها با Trivy اسکن می‌شوند و SonarQube تحلیل کد را انجام می‌دهد. هدف از این لایه‌ها ادعای «امنیت مطلق» نیست؛ هدف، کاهش سطح حمله، کنترل دسترسی، پیدا کردن زودتر ریسک‌ها و ایجاد یک فرایند قابل‌تکرار برای بهبود امنیت است.

TrivySonarQubepfSenseTeleport

CI/CD و Infrastructure as Code

زیرساخت و استقرار سرویس‌ها نباید به حافظه افراد یا مجموعه‌ای از فرمان‌های دستی وابسته باشد. Dropp Tempo زیرساخت را با Infrastructure as Code مدیریت می‌کند و برای سرویس‌های پروژه CI/CD کامل و Deployment خودکار در نظر گرفته است.

انتشار سرویس‌ها به‌صورت منظم انجام می‌شود و در صورت بروز مشکل، مسیر Rollback سریع در دسترس تیم است. تعداد دقیق Deploymentها و زمان Rollback در این Case Study به‌عنوان KPI منتشر نمی‌شوند، زیرا مقادیر موجود برآورد عملیاتی تیم‌اند و نه گزارش تجمیع‌شده Pipeline.

برای اضافه‌کردن هر سرویس جدید نیز فرایند مشخصی وجود دارد: نیازمندی بررسی می‌شود، زمان و هزینه برآورد می‌شوند و پس از تأیید، زیرساخت به‌صورت IaC آماده و سرویس از مسیر استاندارد Deployment وارد محیط می‌شود. این فرایند کمک می‌کند رشد محصول ریتم عملیات را به هم نزند.

Observability: از Dashboard تا اقدام عملیاتی

Observability فقط نصب Dashboard نیست. در این پروژه سلامت سرورها، منابع، APIها، Endpointهای اصلی، پایگاه داده، Replication، لایه Messaging، Connectionهای دستگاه‌ها، Certificateها و موفقیت Backupها پایش می‌شود.

Uptime Kuma دسترس‌پذیری Endpointهای اصلی را از بیرون بررسی می‌کند. Alertها از طریق ایمیل و Rocket.Chat به تیم Dropp Tempo می‌رسند و مشتری نیز هشدارهای مرتبط را در Mattermost دریافت می‌کند. این مسیر چندکاناله باعث می‌شود هشدار صرفاً در یک Dashboard باقی نماند و به تیم مسئول اقدام برسد.

در یکی از رخدادها، سرویس مسئول ارسال Notification از دسترس خارج شد. Monitoring لحظه‌ای اختلال را آشکار کرد و تیم پیش از آنکه رخداد به قطعی گسترده پلتفرم تبدیل شود، سرویس را بازیابی کرد. برای این رخداد MTTR دقیق منتشر نمی‌شود، اما نمونه نشان می‌دهد طراحی Observability چگونه به تشخیص و اقدام عملیاتی متصل شده است.

Uptime KumaRocket.ChatMattermost

Backup و Disaster Recovery قابل‌آزمون

وجود فایل Backup به‌تنهایی معادل آمادگی برای بازیابی نیست. Dropp Tempo علاوه بر تهیه منظم Backup، بازیابی نسخه‌ها و سناریوی Disaster Recovery را به‌صورت دوره‌ای آزمایش می‌کند.

پس از راه‌اندازی عملیاتی نیز Failure، Restore، DR، Security و Rollback Test انجام شدند. در این آزمون‌ها RTO سی دقیقه و RPO یک ساعت محقق شد. این اعداد نتیجه آزمون کنترل‌شده‌اند و به‌عنوان وعده قطعی برای هر Incident احتمالی مطرح نمی‌شوند؛ اما نشان می‌دهند مسیر بازیابی فقط روی کاغذ تعریف نشده است.

فراتر از پلتفرم محصول: زیرساخت عملیاتی فناوری‌های هیرکانیا

دامنه همکاری Dropp Tempo به سرویس‌های مستقیم محصول هایپرنیکس محدود نیست. ابزارهای داخلی شرکت فناوری‌های هیرکانیا نیز برای ادامه کار روزمره تیم حیاتی‌اند؛ از GitLab و Nextcloud تا n8n، Baserow و Outline.

Dropp Tempo استقرار و نگهداشت زیرساخت این سرویس‌ها را نیز بر عهده دارد. این دامنه گسترده باعث می‌شود زیرساخت محصول و ابزارهای عملیاتی شرکت به‌صورت جزیره‌های جداگانه مدیریت نشوند و امنیت، Backup، Monitoring و پاسخ‌گویی به Incident در یک مدل مسئولیت‌پذیر واحد قرار بگیرند.

TECHNICAL OUTCOME

نتایج فنی

  • بیش از ۱۰۰۰ دستگاه فعال و آزمایشی روی پلتفرم قرار دارند.
  • Endpointهای اصلی آپتایم بالاتر از ۹۹.۹٪ ثبت کرده‌اند.
  • افزونگی در لایه API، پلتفرم IoT، MQTT Messaging و پایگاه داده پیاده‌سازی شده است.
  • RTO سی دقیقه و RPO یک ساعت در آزمون‌های پس از راه‌اندازی محقق شدند.
  • CI/CD خودکار و Infrastructure as Code، استقرار و توسعه زیرساخت را قابل‌تکرار کرده‌اند.
  • Monitoring چندلایه از Endpoint و API تا Replication، Messaging، Device Connection و Backup را پوشش می‌دهد.
  • تست دوره‌ای Restore و Disaster Recovery بخشی از عملیات جاری است.
  • رخدادها عمدتاً به اختلال جزئی یا Degraded Mode محدود مانده‌اند و Incident گسترده‌ای ثبت نشده است.
BUSINESS IMPACT

اثر تجاری

هایپرنیکس از ابتدای توسعه محصول، یک تیم مشخص برای مالکیت زیرساخت در اختیار داشته است؛ تیمی که فقط محیط اولیه را تحویل نداده و مسئولیت Monitoring، امنیت، Deployment، Incident Response و بازیابی را نیز حفظ کرده است.

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

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

Retain: پنج سال همراهی و مسئولیت مستمر

همکاری Dropp و فناوری‌های هیرکانیا از سال ۱۴۰۰ آغاز شد. این مسیر از بررسی نیازمندی و طراحی زیرساخت عبور کرد، هم‌زمان با توسعه و آزمایش محصول تکامل یافت و با ورود محصول به عملیات واقعی متوقف نشد.

امروز کل تیم DevOps در Dropp Tempo در پشتیبانی هایپرنیکس مشارکت دارد. Monitoring، Logging، Alerting، Incident Response، Backup، Disaster Recovery، امنیت و استقرار سرویس‌های جدید به‌صورت مستمر ادامه دارند. پشتیبانی ۲۴/۷ است و زمان پاسخ کمتر از ۳۰ دقیقه تعریف شده است.

این همان Retain در مدل Dropp Tempo است: تیمی که منطق تصمیم‌های معماری را می‌شناسد، مسئولیت سلامت روزانه و تکامل بعدی زیرساخت را نیز حفظ می‌کند. نتیجه، زیرساختی است که همراه محصول رشد می‌کند و قرار نیست با هر Release وارد وضعیت اضطراری شود؛ همان فلسفه‌ای که Dropp Tempo آن را «ship in rhythm, not in panic» می‌نامد.

زیرساخت IoT باید بخشی از اعتماد به محصول باشد

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

پروژه هایپرنیکس نشان می‌دهد High Availability همیشه به معنای پیچیده‌ترین معماری یا خودکارسازی کامل نیست. تصمیم درست، معماری‌ای است که با ریسک، بودجه، ظرفیت و توان عملیاتی سازمان تناسب داشته باشد و یک تیم مسئول، آن را به‌صورت مستمر اداره کند.

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

درخواست جلسه بررسی معماری و پایداری زیرساخت IoT