توقف الموقع في الثانية فجرًا: كيف تدير الحادثة بمساعدة الذكاء الاصطناعي؟

إدارة حادثة توقف الموقع ليلًا تمر بخمس مراحل: اكتشاف العطل قبل أن يبلغك العميل، وفرز سريع يحدد حجمه، وتحقيق يجمع الدليل، وإصلاح يعيد الخدمة، ثم مراجعة تمنع تكراره. الذكاء الاصطناعي يختصر مرحلة التحقيق أكثر من غيرها: يقرأ السجلات والمقاييس في دقائق، ويقترح إصلاحًا مع دليله، ويبقى قرار التنفيذ لإنسان.

ما الذي يحدث عادة حين يتوقف الموقع ليلًا؟

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

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

ما الفرق بين وقت الاكتشاف ووقت الإصلاح؟

تقسيم الحادثة إلى فترات يوضح أين يضيع الوقت، وأين يفيد كل أداة:

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

كيف تفرز الحادثة في الدقائق الأولى؟

قبل أي إصلاح أجب عن أربعة أسئلة، وهي أسئلة يجيب عنها المساعد من الأدوات بسرعة:

1. هل التوقف لموقع واحد أم لكل مواقع الخادم؟ موقع واحد يعني غالبًا مشكلة في التطبيق أو الحساب. كل المواقع تعني مشكلة في الخادم أو خدمة مشتركة مثل قاعدة البيانات.
2. هل الخادم نفسه يستجيب؟ إن لم يستجب إطلاقًا، فالمشكلة في الشبكة أو لدى مزود الخادم، لا في الموقع.
3. ما الذي يراه الزائر؟ رمز 502 يختلف عن خطأ قاعدة بيانات، ويختلف عن تحذير شهادة SSL منتهية، أو مجال لا يُحل في DNS.
4. ما الذي تغيّر مؤخرًا؟ تحديث، أو نشر، أو وظيفة Cron جديدة، أو تغيير في الإعدادات.

ثم حدد درجة الخطورة، لأنها تحدد من يُوقَظ ومتى تبلغ العملاء:

كيف يبدو جدول زمني واقعي لحادثة؟

لنفترض أن شركة استضافة في الرياض تدير خادمًا عليه عشرات المواقع، منها متجر على example.sa. هذا جدول زمني افتراضي يوضح سير الحادثة، والأرقام فيه للتوضيح فقط:

01:40  cron      job "import-products" (account: shop) starts, scheduled every 5 minutes
01:45  cron      second run starts while the first is still running
01:50  metrics   memory usage climbing steadily, swap in use
02:04  kernel    Out of memory: Killed process 812 (mariadbd)
02:04  php       mysqli_real_connect(): (HY000/2002): No such file or directory
02:05  monitor   example.sa returns "Error establishing a database connection" (2 checks failed)
02:05  alert     sent to on-call engineer with assistant summary
02:06  assistant investigation opened: metrics, kernel log, cron log, recent changes
02:09  on-call   acknowledges alert, reads the summary on the phone
02:11  on-call   approves: pause cron job "import-products" for account shop
02:12  on-call   approves: restart the database service
02:13  monitor   all sites respond normally
02:14  on-call   status update sent to affected customers
02:45  on-call   no new errors for 30 minutes, incident marked resolved

ملخص المساعد الذي وصل إلى المناوب كان قصيرًا وفيه الدليل:

Summary: MariaDB was killed by the kernel at 02:04 (out of memory). All sites
on this server that use a database are failing since 02:04.
Evidence: kernel log 02:04; memory metrics 01:40 to 02:04; cron log shows
"import-products" (account: shop) running 5 overlapping copies.
Not the cause: disk space (41% used), recent plugin updates (none in 24h).
Proposed: 1) pause that cron job, 2) restart the database service.
Rollback: re-enable the cron job from the account's Cron jobs screen.

في هذا المثال الافتراضي كان وقت الاكتشاف دقيقة واحدة، ووقت الاستعادة تسع دقائق. لاحظ أين ذهب الوقت: لم يقرأ المناوب السجلات بنفسه، بل راجع دليلًا جاهزًا ووافق على خطوتين. ولو بدأ الموقع بالعمل بعد إعادة تشغيل قاعدة البيانات دون إيقاف وظيفة Cron، لعاد العطل نفسه بعد دقائق. لهذا يهم أن يحدد التحقيق السبب، لا العَرَض فقط.

السبب الجذري هنا أن الوظيفة تستغرق أكثر من خمس دقائق، فتتراكم نسخ منها. الإصلاح الدائم في الصباح: منع تشغيل نسخة جديدة قبل انتهاء السابقة، وتقليل تكرار الوظيفة.

# crontab for account "shop": skip the run if the previous one is still running
*/15 * * * * flock -n /home/shop/tmp/import.lock php /home/shop/public_html/import-products.php

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

لماذا تحتاج دليل تشغيل (Runbook) لكل عطل متكرر؟

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

مثال لدليل تشغيل مكتوب بصيغة منظمة:

runbook: database-down
symptoms:
  - "Error establishing a database connection" on several sites
  - mariadbd not running
checks:
  - kernel log for "Out of memory" in the last hour
  - disk usage on the data partition
  - cron jobs and imports running at the time of failure
mitigation:
  - stop the process that is consuming memory (needs approval)
  - restart the database service (needs approval)
  - confirm all sites respond, watch memory for 30 minutes
escalate_if:
  - database fails to start twice
  - tables reported as corrupted: do not repair at night, call the database owner
communication:
  - notify affected customers within 15 minutes of a critical incident

ثلاث قواعد لدليل تشغيل جيد:

• خطوات قابلة للتراجع أولًا. إعادة تشغيل خدمة أو إيقاف وظيفة مؤقتًا أسهل في التراجع من تعديل البيانات.
• حدود واضحة للتصعيد. متى يتوقف المناوب ويتصل بشخص آخر.
• لا خطوات هدّامة ليلًا. استعادة نسخة احتياطية فوق موقع يعمل، أو إصلاح جداول قاعدة بيانات، قرار يحتاج تفكيرًا وموافقة صريحة. والنسخ الاحتياطية الجاهزة تجعل هذا القرار ممكنًا عند الحاجة؛ راجع استراتيجية 3-2-1.

كيف تتواصل مع العملاء أثناء الحادثة؟

العميل يتحمل التوقف أكثر حين يعرف أنك تعرف. الصمت هو ما يحوّل حادثة قصيرة إلى عميل يبحث عن مزود آخر. أرسل ثلاث رسائل على الأقل:

الرسالة الأولى، فور التأكد من الحادثة:

نعلم بوجود عطل يؤثر على عدد من المواقع على أحد خوادمنا منذ الساعة 02:04 بتوقيت الرياض. فريقنا يعمل عليه الآن، وسنرسل تحديثًا خلال 30 دقيقة.

رسالة التحديث:

عادت المواقع للعمل منذ 02:13. السبب توقف خدمة قاعدة البيانات بسبب نفاد ذاكرة الخادم. نراقب الوضع، وسنرسل ملخصًا كاملًا خلال يوم العمل.

رسالة الإغلاق: ملخص بلغة واضحة لما حدث، ومدته، وما الذي تغيّر لمنع تكراره. لا تذكر أسماء عملاء آخرين، ولا تنشر تفاصيل حساب عميل لغيره.

المساعد يكتب مسودة هذه الرسائل من بيانات الحادثة نفسها، والإنسان يراجعها ويرسلها. ولتفاصيل استخدام الذكاء الاصطناعي في الرد على التذاكر راجع مقال دعم العملاء في شركات الاستضافة.

ماذا تكتب في مراجعة ما بعد الحادثة؟

المراجعة ليست بحثًا عن شخص تلومه، بل عن ثغرة في النظام. اكتبها خلال أيام قليلة من الحادثة، ما دامت التفاصيل حاضرة:

سجل التدقيق يجعل الجدول الزمني دقيقًا: من وافق على ماذا ومتى، وما الذي اقترحه المساعد، وما القيمة قبل التغيير وبعده.

ما الذي لا تتركه للذكاء الاصطناعي أثناء الحادثة؟

المساعد ممتاز في قراءة كمية كبيرة من السجلات بسرعة، وفي ربط الأحداث بالوقت، وفي كتابة الملخصات والمسودات. لكنه قد يخطئ، وقد يقدّم سببًا معقولًا غير صحيح. لذلك تبقى للإنسان قرارات الخطر: هل نعيد التشغيل الآن أم ننتظر؟ هل نستعيد نسخة احتياطية؟ هل نوقف حساب عميل؟ وماذا نقول للعملاء؟ تقسيم العمل هذا مشروح بتفصيل أكبر في مقال الذكاء الاصطناعي ومدير الخادم.

كيف يساعدك bPanel؟

يراقب الذكاء الاصطناعي في bPanel الخادم والمواقع. وعندما يحدث عطل يقرأ السجلات والمقاييس، ويحدد السبب مع الدليل، ويقترح إصلاحًا لا يُنفَّذ إلا بموافقة صاحب الصلاحية، وكل إجراء يُكتب في سجل التدقيق. ووظائف Cron في bPanel لها سجل لكل تشغيل وتنبيه عند الفشل، والنسخ الاحتياطية اليومية للملفات وقواعد البيانات والبريد محفوظة على الخادم وفي تخزين خارجي، مع استعادة بنقرة واحدة على الخادم نفسه أو على خادم جديد.

تشخيص توقف موقع يكلف عادة من 3 إلى 5 من نقاط الذكاء الاصطناعي، وكل باقة تتضمن نقاطًا شهرية مجانية. يمكنك تجربة bPanel على خادمك سبعة أيام دون بطاقة ائتمان من ابدأ مع bPanel.

الخلاصة

• معظم وقت الحادثة يضيع في الاكتشاف والتشخيص، لا في الإصلاح نفسه.
• افرز أولًا: موقع واحد أم الخادم كله، وما الذي تغيّر مؤخرًا، وما درجة الخطورة.
• استعد الخدمة بخطوات قابلة للتراجع ليلًا، واترك الإصلاح الجذري لوقت يمكن فيه الاختبار.
• أبلغ العملاء مبكرًا وبوضوح، واكتب مراجعة تعتمد على سجل التدقيق لا على الذاكرة.
• المساعد يجمع الدليل ويقترح، والإنسان يقرر ويوافق.