كيف تبني نظام تنبيهات طوارئ للمحلات والشركات عبر التلجرام والواتساب باستخدام VPS؟

الساعة 2:17 صباحًا.

المحل مغلق منذ خمس ساعات.

لا يوجد موظف في المكان.

وفجأة ترتفع حرارة إحدى ثلاجات التخزين من:

4°C
إلى
11°C

الحساس سجل المشكلة.

لكن تسجيل المشكلة وحده لا يفيد صاحب النشاط إذا اكتشفها في الثامنة صباحًا.

السؤال الحقيقي هو:

كيف نجعل النظام يكتشف الحدث، يصنف خطورته، يبلغ الشخص المناسب فورًا، ويتأكد أن أحدًا شاهد التنبيه؟

هنا تتحول VPS صغيرة من مجرد Server على الإنترنت إلى مركز تنبيهات وتشغيل للشركة.

ما الذي يمكن للنظام مراقبته؟

التطبيق لا يقتصر على السرقة أو الأبواب.

في نشاط تجاري يمكن أن تأتي الأحداث من:

باب مخزن فتح خارج ساعات العمل

درجة حرارة ثلاجة تجاوزت الحد

Freezer توقفت

انقطاع الكهرباء

UPS دخلت على Battery

الإنترنت انقطع

Camera أو NVR أصبحت Offline

Server توقفت

موقع المتجر لا يرد

الدفع الإلكتروني يفشل

Database وصلت إلى حد خطير

مساحة التخزين قاربت الامتلاء

تدفق مياه غير طبيعي

دخان أو Leak Sensor

زر طوارئ يدوي

الفكرة واحدة مهما اختلف المصدر:

Event
↓
VPS
↓
Validation
↓
Decision
↓
Telegram / WhatsApp
↓
Acknowledgement
↓
Escalation if needed

لماذا نضع VPS في المنتصف؟

يمكن نظريًا أن تجعل كل جهاز يرسل Telegram بنفسه.

لكن بعد فترة ستجد:

Token داخل كل جهاز

قواعد مختلفة في كل مكان

رسائل مكررة

لا يوجد سجل مركزي

لا توجد Escalation

تغيير رقم المدير يحتاج تعديل عدة أجهزة

لا يوجد Failover منطقي

وجود طبقة مركزية يجعل الأجهزة ترسل Events فقط، بينما Server تقرر ماذا تفعل بها.

Architecture بسيطة

Shop / Office / Warehouse
        │
        ├── Sensors
        ├── POS
        ├── Router
        ├── UPS
        ├── Cameras/NVR
        ├── Website
        └── Local automation
             │
             ▼
        HTTPS / Webhook
             │
             ▼
        VPS Alert Gateway
             │
     ┌───────┼────────┐
     │       │        │
     ▼       ▼        ▼
 Validation Rules   Event Log
     │
     ▼
 Severity Engine
     │
 ┌───┴──────────┐
 ▼              ▼
Telegram      WhatsApp
     │
     ▼
Acknowledgement
     │
     ▼
Escalation

ثلاث درجات أفضل من اعتبار كل شيء طوارئ

إذا أرسلت رسالة حمراء وصوتًا عاليًا لكل حدث، سيتعلم الموظفون تجاهل النظام.

الأفضل تقسيم التنبيهات.

ابدأ برسالة تحتوي ما يحتاجه الشخص لاتخاذ قرار

تنبيه مثل:

Temperature alert!

ضعيف جدًا.

الأفضل:

🚨 CRITICAL

Branch:
Al Khoud

Device:
Freezer-02

Temperature:
11.4°C

Normal limit:
-18°C to -12°C

First detected:
02:17 AM

Duration:
4 minutes

Last update:
11.8°C

Incident ID:
INC-2026-00482

الموظف يعرف فورًا:

أين المشكلة؟
ما الجهاز؟
ما القيمة؟
من متى؟
وهل ما زالت تتفاقم؟

لماذا Telegram ممتازة كبداية؟

Telegram Bot مناسبة جدًا للتنبيهات التقنية لأنها سهلة الربط مع Backend عبر HTTP API.

يمكن للنظام إرسال رسالة إلى:

مدير
مجموعة فريق
قناة خاصة
فريق تقني

ويمكن تقسيم المجموعات.

مثلًا:

Technical Alerts
Management Alerts
Security Alerts
Branch Muscat Alerts

إنشاء Bot ليس هو النظام كله

بعد إنشاء Telegram Bot والحصول على Token، يجب التعامل مع الـToken كأنه Password.

لا تضعه:

داخل Git repository

داخل JavaScript يصل للمتصفح

داخل Screenshot

داخل رسالة دعم عامة

خزنه في:

Environment Variable
أو
Secrets Manager

إرسال Telegram من Server

المبدأ بسيط.

POST
https://api.telegram.org/bot<BOT_TOKEN>/sendMessage

مع بيانات مثل:

{
  "chat_id": "DESTINATION",
  "text": "Emergency alert..."
}

لكن في Production لا تجعل كل Sensor تعرف Bot Token.

اجعل Sensor تتحدث مع Alert Gateway الخاصة بك، والـGateway وحدها تملك Credential الخاصة بـTelegram.

WhatsApp: استخدم المسار الرسمي

إذا كانت الشركة تعتمد على WhatsApp في التواصل، من المغري استخدام Script تسجل الدخول إلى WhatsApp Web وتضغط الأزرار آليًا.

هذا ليس التصميم الذي نريده لنظام طوارئ تجاري.

استخدم:

WhatsApp Business Platform
Cloud API

بحيث ترسل Server الرسائل من خلال API رسمية.

الطلب يكون من حيث المبدأ إلى Endpoint الرسائل المرتبط بـPhone Number ID، مع Access Token مخزنة على Server.

استخدم دائمًا API Version الحالية والتعليمات الحالية من Meta عند التنفيذ، لأن سياسات WhatsApp وإصدارات Graph API يمكن أن تتغير.

لماذا نستخدم Telegram وWhatsApp معًا؟

ليس لأن الرسالة الواحدة تحتاج نسختين دائمًا.

يمكن استخدامهما كطبقتين.

مثلًا:

Warning
→ Telegram

Critical
→ Telegram
→ WhatsApp للمدير

Critical غير مؤكدة بعد 5 دقائق
→ WhatsApp لمدير ثانٍ

Critical غير مؤكدة بعد 10 دقائق
→ تصعيد إضافي

بهذا لا يتحول WhatsApp إلى قناة Spam داخل الشركة.

لا ترسل كل Reading من Sensor

لنفترض أن Temperature Sensor ترسل قراءة كل 30 ثانية.

ودرجة الحرارة أصبحت غير طبيعية لمدة عشر دقائق.

إذا أرسلت Notification مع كل Reading:

20 رسالة خلال 10 دقائق

النظام أصبح مصدر إزعاج بدل أن يكون أداة طوارئ.

استخدم حالة Incident

عند أول تجاوز حقيقي:

Incident:
OPEN

وبعدها تحدث نفس Incident بدل إنشاء واحدة جديدة.

مثلًا:

02:17
Temperature high
Incident opened

02:22
Still high
No new Telegram flood

02:27
Escalation

02:34
Temperature normal

02:36
Incident resolved

أضف Debounce قبل فتح الحادثة

إذا تجاوزت الحرارة الحد لمدة ثانيتين ثم عادت، قد تكون قراءة مؤقتة.

لذلك يمكن أن تكون القاعدة:

Temperature > threshold
FOR 3 minutes
→ Open Incident

وباب:

Door opened
outside business hours
FOR 30 seconds
→ Critical

القواعد تعتمد على نوع النشاط والخطر.

لكن لا تستخدم Delay غير مناسب للأحداث الخطيرة

إنذار حريق أو زر Panic مختلف عن ارتفاع Storage من 79% إلى 80%.

بعض الأحداث يجب إرسالها فورًا.

لذلك لكل Event Type:

Severity
Debounce
Escalation delay
Recipients

شكل Event موحد يسهل كل شيء

بدل جعل كل جهاز يرسل Format مختلفة، استخدم Payload موحدة.

{
  "event_id": "evt_9f82...",
  "source": "freezer-02",
  "branch": "muscat-01",
  "type": "temperature_high",
  "severity": "critical",
  "value": 11.4,
  "threshold": -12,
  "timestamp": "2026-08-08T02:17:00+04:00"
}

الآن Alert Engine لا يهمها إذا كان المصدر:

Home Assistant
Node-RED
ESP32 Gateway
POS System
Website
Monitoring Agent
Python Script

طالما أنه يرسل Event مفهومة.

لا تثق بأي Webhook تصل إلى Server

إذا كان Endpoint:

https://alerts.example.com/event

مفتوحًا للعالم بدون Authentication، يستطيع أي شخص يعرف الرابط محاولة إرسال Events مزيفة.

هذا غير مقبول لنظام طوارئ.

استخدم توقيع HMAC

يمكن أن يمتلك كل مصدر Secret.

يرسل:

X-Timestamp
X-Signature

وتحسب Signature مثل:

HMAC-SHA256(
    timestamp + "." + request_body,
    shared_secret
)

الـVPS تعيد الحساب وتقارن النتيجة.

إذا لم تتطابق:

401 Unauthorized

ولا يتم إنشاء Incident.

Timestamp تمنع Replay البسيط

Signature صحيحة وحدها لا تكفي إذا استطاع مهاجم التقاط Request قديمة وإرسالها مرة أخرى.

لذلك تحقق أن:

abs(server_time - event_time)
< allowed_window

مثل عدة دقائق حسب النظام.

واستخدم event_id لمنع Duplicate

الشبكات تفشل.

Client قد ترسل Event ثم لا تحصل على Response وتعيد المحاولة.

إذا لم يكن لديك Idempotency:

Request 1
→ Incident

Retry
→ Incident ثانية

Retry
→ Incident ثالثة

الأفضل:

event_id UNIQUE

إذا وصل نفس ID مرة ثانية:

Already processed
→ return success
→ do not resend alerts

قاعدة البيانات المطلوبة ليست معقدة

يمكن أن تبدأ بجداول مثل:

sources
events
incidents
alert_deliveries
recipients
escalation_rules

ويحفظ `alert_deliveries` مثلًا:

incident_id
channel
recipient
provider_message_id
status
attempts
sent_at
delivered_at
failed_at

هذا يجعل النظام قابلًا للتدقيق.

لماذا نحتاج Queue؟

لا تجعل HTTP Request القادمة من Sensor تنتظر WhatsApp وTelegram.

افصل العمليتين:

Sensor
↓
API
↓
Validate
↓
Save Event
↓
Queue Job
↓
Return 202

ثم:

Worker
↓
Evaluate
↓
Send Telegram
↓
Send WhatsApp
↓
Save delivery status

لو Telegram تأخرت ثانيتين، Endpoint التي تستقبل Events لا تتعطل بسببها.

Redis مفيدة لكن ليست شرطًا للبداية

يمكن استخدام:

Redis Queue

مع Application Worker.

لكن في مشروع صغير يمكن البداية بـDatabase-backed Queue إذا كانت التقنية المستخدمة تدعمها بشكل جيد.

التصميم أهم من اسم الأداة.

ماذا لو Telegram نفسها تعطلت؟

هذا أحد أهم أسئلة نظام الطوارئ.

إذا كان عندك:

Emergency system
→ Telegram only

فأنت نقلت Single Point of Failure من مكان إلى مكان آخر.

الحوادث الحرجة يمكن أن تستخدم:

Primary:
Telegram

Secondary:
WhatsApp

Optional third path:
Email / SMS / Voice provider

حسب أهمية النشاط.

لا تعتبر HTTP 200 دليلًا أن المدير قرأ الرسالة

هناك فرق بين:

Accepted by provider

Sent

Delivered

Read

Acknowledged by responsible employee

نظام Incident الحقيقي يهتم بالأخير:

هل أحد تحمل مسؤولية الحادثة؟

أضف زر «استلمت التنبيه»

في Telegram يمكن تصميم Workflow تجعل المسؤول يضغط زرًا مثل:

✅ استلمت البلاغ

فيرسل النظام:

Incident INC-482
Acknowledged by:
Operations Manager

02:20 AM

ثم يوقف Escalation لذلك المستوى.

إذا لم يرد أحد، النظام لا يصمت

مثال:

02:17
Critical alert
→ Supervisor

02:22
No acknowledgement
→ Branch Manager

02:27
Still no acknowledgement
→ Operations Manager

02:32
Still open
→ Company Owner

هذه هي Escalation Policy.

يمكن أن تختلف حسب الحدث.

الأشخاص أيضًا يحتاجون جدول مناوبات

لا ترسل إنذار الساعة الثالثة صباحًا إلى موظف إجازته هذا الأسبوع.

يمكن أن يكون للنظام:

On-call schedule

Branch assignment

Role

Working hours

Escalation priority

ثم يحدد Recipient المناسبة وقت الحادثة.

مثال: متجر لديه ثلاث فروع

الفرع الأول:

Muscat

الثاني:

Sohar

الثالث:

Salalah

بدل مجموعة واحدة فيها الجميع:

Muscat critical
→ Muscat Supervisor

Sohar critical
→ Sohar Supervisor

Salalah critical
→ Salalah Supervisor

وإذا لم تتم المعالجة:

→ Central Operations

مثال عملي: انقطاع الإنترنت عن الفرع

يوجد Agent داخل الفرع يرسل Heartbeat كل دقيقة:

{
  "source": "branch-muscat-router",
  "type": "heartbeat"
}

إذا لم تصل Heartbeat لمدة:

3 minutes

تفتح VPS Incident:

Branch connectivity lost

لكن هناك مشكلة.

إذا الإنترنت نفسها انقطعت عن الفرع، لن يستطيع Agent إرسال رسالة تقول:

«الإنترنت انقطع.»

لهذا الـHeartbeat أفضل.

Server الخارجية هي التي تلاحظ أن الفرع اختفى.

وهذا سبب قوي لوجود VPS خارج المحل

لو Alert System كلها داخل نفس المكان:

Electricity failure
↓
Router off
↓
Local server off
↓
Alert system off

لن يبلغك أحد.

أما VPS في Datacenter مستقل فتستطيع اكتشاف فقدان الاتصال من الخارج.

مثال آخر: توقف موقع المتجر

VPS تستطيع فحص:

https://store.example.com/health

كل دقيقة مثلًا.

لكن لا يكفي:

Ping successful

الأفضل أن Health Check تتأكد من أجزاء مهمة:

Application
Database
Cache
Storage dependency

بدون تنفيذ عملية ضارة أو طلب حقيقي.

ما الذي ترسله عند توقف الموقع؟

🔴 STORE DOWN

Started:
14:31

Endpoint:
/health

HTTP:
503

Database:
FAIL

Redis:
OK

Last successful check:
14:30

Incident:
INC-519

هذه رسالة قابلة للتصرف.

مثال: باب المخزن بعد الإغلاق

قاعدة بسيطة:

IF
door = open

AND
current_time outside business_hours

AND
state remains open > 30 seconds

THEN
severity = critical

لكن لا ترسل صور كاميرات أو بيانات حساسة إلى أي قناة بلا داعٍ.

ابدأ بالمعلومة المطلوبة لاتخاذ القرار، واجعل الوصول إلى الأنظمة الأمنية نفسها محكومًا بصلاحيات مستقلة.

يمكن بناء الـEngine بـn8n

للشركات التي لا تحتاج Application مخصصة بالكامل، يمكن أن تكون البنية:

Webhook
↓
n8n
↓
Validation
↓
IF / Switch
↓
Database
↓
Telegram
↓
WhatsApp API
↓
Escalation Workflow

ميزة هذا الأسلوب هي سرعة البناء والتعديل.

وتستطيع فصل Workflows:

Receive Event

Classify Incident

Telegram Delivery

WhatsApp Delivery

Escalation

Daily Report

Health Monitoring

بدل Workflow واحدة ضخمة يصعب تشخيصها.

ومتى نكتب Application خاصة؟

إذا أصبح لديك:

مئات الفروع

آلاف الأجهزة

قواعد معقدة

Multi-tenant customers

صلاحيات دقيقة

Audit requirements

SLA قوية

قد يكون Backend مخصص أفضل.

يمكن أن يبقى التصميم نفسه:

API
Queue
Workers
Database
Notification Providers

لكن التطبيق يكون مكتوبًا خصيصًا للشركة.

لا تخزن Secrets داخل Workflow نفسها بلا ضرورة

Credentials مثل:

Telegram Bot Token

WhatsApp Access Token

Webhook shared secrets

يجب أن تكون في Credential Store أو Environment Secrets مناسبة.

ولا تظهر في Logs.

ضع Rate Limits

حتى Source مصادق عليها يمكن أن تتعطل وتبدأ بإرسال آلاف Events.

لذلك:

Source A
max 60 events/minute

كمثال حسب طبيعة المصدر.

وعند تجاوز غير طبيعي:

Throttle
+
Log
+
Generate system warning

لا تجعل Failure في WhatsApp توقف Telegram

خطأ معماري شائع:

Send Telegram
↓
Send WhatsApp
↓
If WhatsApp failed:
whole workflow failed

الأفضل حفظ Delivery لكل Channel بصورة مستقلة.

Telegram:
sent

WhatsApp:
retrying

ثم Retry WhatsApp بدون إعادة إرسال Telegram كل مرة.

Retries تحتاج Backoff

بدل:

Retry every second forever

استخدم شيئًا مثل:

Attempt 1
immediate

Attempt 2
30 sec

Attempt 3
2 min

Attempt 4
5 min

مع حد نهائي واضح.

احذر من Alert Storm

تخيل انقطاع الكهرباء عن فرع يحتوي:

12 Cameras
4 POS
1 Router
1 NVR
3 Access Points
1 Local Server

بعد دقيقتين قد تحصل على 22 Alert منفصلة.

لكن السبب واحد:

Branch Power Failure

النظام الأفضل يعمل Correlation.

إذا اختفى الفرع كله في اللحظة نفسها، ينشئ Incident رئيسية بدل إغراق الفريق بعشرات الرسائل.

أضف Maintenance Mode

إذا الفني سيقطع الكهرباء عن الفرع للصيانة، يجب أن يستطيع تحديد:

Maintenance:
Branch Muscat

From:
01:00

Until:
02:00

فتسجل Events لكن لا ترسل طوارئ متوقعة خلال النافذة.

راقب نظام التنبيهات نفسه

أخطر شيء أن يتوقف Alert System بصمت.

استخدم:

External uptime check

Queue health

Last event timestamp

Worker heartbeat

Database health

Disk usage

Certificate expiry

ويفضل أن توجد طريقة خارجية ثانية تراقب الـVPS نفسها.

Backup لنظام الطوارئ ليست رفاهية

احفظ:

Configuration

Recipients

Rules

Database

Workflow definitions

Secrets بطريقة آمنة

Incident history حسب الحاجة

واختبر Restore.

وجود Backup لم يتم اختبار استعادتها لا يكفي.

ماذا عن الخصوصية؟

لا ترسل أكثر مما تحتاج.

رسالة:

Door 3 opened
Branch Muscat
02:14

قد تكون كافية.

لا حاجة لأن تحمل Notification بيانات عملاء أو معلومات حساسة لا علاقة لها بالحادثة.

سجل كل قرار مهم

Audit Log جيدة تسجل:

Event received

Signature validated

Incident opened

Telegram sent

WhatsApp sent

Acknowledged by user

Escalated

Resolved

مع:

timestamp
incident_id
source
recipient
result

وهذا يصبح مهمًا عندما تسأل الشركة في اليوم التالي:

«متى عرفنا بالمشكلة؟ ومن استلمها؟ ومتى انتهت؟»

كم موارد VPS التي تحتاجها؟

لنظام تنبيهات لشركة صغيرة، الحمل عادة لا يأتي من إرسال الرسائل نفسها بقدر ما يأتي من عدد Events، Database، Workflows، والاحتفاظ بالسجلات.

ابدأ بالحساب:

Events per minute

عدد الفروع

عدد الأجهزة

Database size

Concurrent workflows

Retention period

Monitoring tools

ثم أضف Headroom بدل اختيار مواصفات عشوائية.

مثال بسيط:

Alert API
PostgreSQL
Redis
n8n
Monitoring

Small business workload

قد يبدأ على VPS متواضعة ثم تتم زيادة الموارد مع نمو عدد الفروع والأحداث.

الأهم أن تكون الترقية ممكنة وأن تراقب الموارد.

خطة تنفيذ خلال مراحل

لا تبدأ بربط كل أجهزة الشركة في اليوم الأول.

ابدأ:

المرحلة 1
VPS + HTTPS + Database

المرحلة 2
Telegram

المرحلة 3
مصدر Event واحد

المرحلة 4
Incident state + Deduplication

المرحلة 5
WhatsApp Critical Alerts

المرحلة 6
Acknowledgement

المرحلة 7
Escalation

المرحلة 8
Monitoring + Backup

المرحلة 9
إضافة الفروع والأجهزة تدريجيًا

واختبر الفشل عمدًا

قبل اعتبار النظام جاهزًا اسأل:

ماذا لو Telegram فشلت؟

ماذا لو WhatsApp API لم تستجب؟

ماذا لو Database توقفت؟

ماذا لو Worker ماتت؟

ماذا لو نفس Event وصلت عشر مرات؟

ماذا لو الإنترنت في الفرع انقطع؟

ماذا لو VPS نفسها توقفت؟

ماذا لو Access Token انتهت أو ألغيت؟

ثم اختبر كل سيناريو.

نظام الطوارئ الحقيقي لا يبدأ من Notification

يبدأ من سؤال:

ما الحوادث التي يمكن أن تكلف النشاط مالًا أو توقف العمل إذا لم يعرف بها أحد سريعًا؟

اكتبها.

ثم لكل واحدة حدد:

Source

Trigger

Severity

Delay

Recipients

Primary channel

Fallback channel

Acknowledgement time

Escalation path

Resolution rule

بعدها تتحول Telegram وWhatsApp من تطبيقات مراسلة إلى جزء من عملية تشغيل حقيقية.

إذا كنت تريد تشغيل Alert Gateway أو n8n أو Database ومكونات المراقبة على Server مستقلة عن المحل، تستطيع استخدام VPS Linux كبنية مركزية للنظام. قبل اختيار الباقة، احسب عدد الفروع والـEvents والخدمات التي ستعمل عليها ثم اختر الموارد المناسبة للحمل الفعلي.

الهدف ليس أن تستلم الشركة أكبر عدد ممكن من التنبيهات.

الهدف أن تصل المعلومة الصحيحة، للشخص الصحيح، في الوقت الصحيح، مع طريقة واضحة للتأكد أن أحدًا تعامل معها.