6 مهام خادم ينجزها Claude لمسؤولي الأنظمة

Claude لمسؤولي الأنظمة: ابدأ بالنصيحة ثم بالتنفيذ

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

تتكرر 6 مهام كل أسبوع على VPS يعمل بنظام Linux ومستأجر. لكل مهمة أدناه نمط prompt فعّال، والأمر الذي يثبت صحة الإجابة، ونمط الفشل المتوقع. لا تحتاج أي من هذه المهام إلى وصول النموذج إلى خادمك.

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

ما يجب ألا تلصقه مطلقاً

كل ما يرد في المطالبة يغادر خادمك. هناك 4 فئات يجب أن تبقى على الخادم:

• المفاتيح الخاصة: ~/.ssh/id_ed25519 و/etc/ssh/ssh_host_*_key وأي مفتاح TLS (أمان طبقة النقل) ضمن /etc/letsencrypt/live/.
• ملفات بيانات الاعتماد: .env و~/.aws/credentials و/root/.docker/config.json وكلمات مرور قاعدة البيانات في أي ملف أو أي سطر في السجل.
• بيانات الحسابات: /etc/shadow و/etc/gshadow. لا يحتاج أي سؤال لإدارة النظام إلى تجزئة كلمة مرور للإجابة عنه.
• أي بيانات تخص المستخدمين: عناوين البريد الإلكتروني، وصفوف الطلبات، وسجلات الطلبات التي تحتوي على ملفات تعريف ارتباط الجلسات أو معلومات التعريف الشخصية (PII).

المفاتيح العامة آمنة للصقها. أما المفاتيح الخاصة فليست كذلك، ويبدو الملفان متشابهين عند النظرة الأولى. لذلك اقرأ السطر الأول قبل النسخ: الملف الذي يحتوي سطره الأول على BEGIN OPENSSH PRIVATE KEY لا تضعه مطلقاً في مطالبة. تستحق المحافظة على تنظيم مواد مفاتيح SSH 10 دقائق بمفردها.

احجب البيانات قبل لصقها، بدلاً من الاعتماد على قدرتك على اكتشاف رمز واحد وسط 200 سطر:

sudo journalctl -u myapp -n 200 --no-pager | sed -E 's/(token|secret|password|api[_-]?key)[=:][^[:space:]]+/\1=REDACTED/gI'

هناك حالة خاصة مرتبطة بـDocker. يوسّع docker compose config قيم .env في المخرجات التي يطبعها، ولذلك تكون تلك المخرجات سراً حتى إذا لم يكن الملف الموجود على القرص سرياً. استخدم docker compose config -q، فهو يتحقق من الإعداد ولا يطبع شيئاً. لمعرفة السياسة الأوسع بشأن البيانات التي يُسمح لوكيل برؤيتها، يشرح موضوع إبقاء الأسرار خارج وكلاء الذكاء الاصطناعي جانب البيئة.

المهمة 1: لماذا فشلت هذه الخدمة؟

ابدأ بالأمرين اللذين يتضمنان الإجابة:

systemctl status myapp.service --no-pager
sudo journalctl -u myapp.service -b -n 100 --no-pager -o short-iso

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

Ubuntu 24.04. كان myapp.service يعمل بشكل صحيح حتى عدّلت الوحدة قبل ساعة. إليك systemctl status وآخر 100 سطر من السجل. ما أول سطر يتضمن خطأ فعلياً، وماذا يعني؟ لا تقدّم إصلاحاً بعد.

عبارة "لا تقدّم إصلاحاً بعد" تؤدي دوراً مهماً في هذا الطلب. تخفي السجلات الفشل الأول بين عمليات إعادة المحاولة التي تسبب فيها، لذلك سيشرح النموذج آخر سطر يراه إذا طلبت منه إصلاح المشكلة. يكون السطر المهم عادة قبل الضوضاء بنحو 20 سطراً.

والنتيجة قد تكون سطراً مثل Main PID: 1841 (code=exited, status=203/EXEC). تعني حالة الخروج 203/EXEC أن kernel تعذر عليه تنفيذ الملف المحدد في ExecStart: إما أن المسار غير موجود، أو أن الملف موجود لكنه غير قابل للتنفيذ. كما ينتج السطر #! الذي يحدد مفسراً غير مثبت حالة الخروج نفسها. ويمكن اختبار جميع هذه الاحتمالات باستخدام ls -l وhead -1.

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

المهمة 2: اكتب وحدة systemd أو إدخالاً في cron

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

sudo systemd-analyze verify /etc/systemd/system/myapp.service
sudo systemctl daemon-reload
sudo systemctl start myapp.service
systemctl status myapp.service --no-pager

يحلّل systemd-analyze verify الملف بالطريقة التي يستخدمها systemd، ولذلك يلتقط الأخطاء التي قد تفوت المراجعة البشرية. يؤدي توجيه مكتوب خطأ إلى طباعة /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring.. ويؤدي غياب ملف ثنائي إلى طباعة Command /usr/local/bin/myapp is not executable: No such file or directory. لا يظهر أي من الخطأين أثناء daemon-reload، ولذلك قد تُحمَّل الوحدة بنجاح ثم تفشل لحظة تشغيلها.

يتكرر خطآن في كتابة الوحدات. الأول هو After=network.target، الذي يعني فقط أن مكدس الشبكة أُعدّ، لا أن عنواناً أصبح متاحاً بعد. تفشل الخدمة التي تربط نفسها بعنوان IP محدد عند الإقلاع وتعرض bind: Cannot assign requested address، ويكون الإصلاح باستخدام Wants=network-online.target مع After=network-online.target. والثاني هو Type=simple لبرنامج يعمل كخدمة خلفية: يتعامل systemd مع العملية الأولى على أنها الخدمة، ثم تنتهي العملية الأب مباشرة، فتُعلَّم الوحدة بأنها متوقفة بينما تستمر العملية الفعلية في العمل دون إدارة.

بالنسبة إلى الجدولة، تحقّق منها بدلاً من قراءتها:

systemd-analyze calendar 'Mon *-*-* 04:00:00'

يطبع ذلك الصيغة الموحّدة وموعد التشغيل التالي للتعبير، ويحسم أي خلاف حول معناه. إذا كنت تختار بين مؤقت وcrontab، فراجع خدمات ومؤقتات systemd على VPS لمعرفة المفاضلة بينهما.

يحتوي Cron على فخ لن يحذرك منه أي نموذج ما لم تطلب ذلك. يشغّل Cron المهام ببيئة محدودة، ولذلك يكون PATH تقريباً /usr/bin:/bin ولا يُقرأ ملف تعريف shell أبداً. تفشل المهمة التي تعمل عند لصقها في الطرفية عند تشغيلها تحت cron وتعرض /bin/sh: 1: docker: not found، لأن ذلك الملف الثنائي موجود في /usr/local/bin. استخدم المسارات المطلقة في ملفات crontab.

المهمة 3: راجع ملف nginx أو Compose قبل تشغيله في بيئة الإنتاج

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

يجب أن يقدّم هذا الـvhost example.com عبر HTTPS، وأن يوجّه /api إلى خدمة محلية على المنفذ 8080. اقرأه لي، واذكر أي شيء لا يطابق هذا الوصف.

ثم شغّل الأداة التي تتحقق من صحة البنية:

sudo nginx -t
docker compose config -q

يعرض nginx -t القيمة nginx: configuration file /etc/nginx/nginx.conf test is successful، أو يذكر اسم الملف ورقم السطر، كما في nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12. أما docker compose config -q فلا يعرض شيئاً عندما تكون صياغة الملف صحيحة، ويعرض رسالة مباشرة مثل yaml: line 7: did not find expected key عندما تكون المسافات البادئة غير صحيحة.

لا تتحقق أي من الأداتين من النية. يمكن لإعداد يمر عبر nginx -t أن يوجّه الطلبات إلى المنفذ الخطأ، أو يستمع على 0.0.0.0 بينما كنت تقصد 127.0.0.1. هنا تظهر فائدة النموذج، وهنا يفشل أيضاً: فعندما تطلب منه إصلاح directive واحد، يعيد غالباً كتابة الملف بأكمله مع حذف اثنين من directives الموجودة لديك من دون تنبيه. اطلب منه عرض الأسطر التي تغيّرت وسبب كل تغيير، ثم أجرِ التعديل يدوياً.

تحقق مما عرّضته فعلياً:

sudo ss -tulpn

من دون sudo سترى sockets التي تستمع، لكنك لن ترى العمليات التي تملكها. إذا فاجأك هذا الناتج، فاقرأ ما هي المنافذ وكيف يربطها Linux؛ فهذا شرح أقصر.

المهمة 4: اشرح الأمر غير المألوف قبل تشغيله

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

خذ find /var/log -name '*.gz' -mtime +7 -delete مثلاً. توضح الإجابة الجيدة أن -mtime +7 يحسب فترات كاملة مدتها 24 ساعة ويتجاهل الجزء الكسري، ولذلك يطابق الملفات التي مضى على تعديلها 8 أيام على الأقل، وليس 7 أيام. وتوضح أيضاً أن find يقيّم تعبيره من اليسار إلى اليمين، ولذلك فإن نقل -delete أمام -name يحذف كل شيء ضمن المسار الابتدائي. يرد هذا التحذير في صفحة الدليل الخاصة بـfind، وقد تسبب في فقدان /var/log لدى كثير من الأشخاص.

أو خذ rsync -a --delete /srv/app/ /backup/app/ مثلاً. تعني الشرطة المائلة اللاحقة في المصدر «محتويات هذا الدليل». احذفها لتحصل على /backup/app/app/. أضف --delete، وسيُحذف أي شيء موجود في الوجهة وغير موجود في المصدر. هذا صحيح عند إنشاء نسخة مطابقة، لكنه يؤدي إلى كارثة إذا كان مسار المصدر خاطئاً.

تحقق باستخدام الأداة، لا باستخدام النموذج:

rsync -a --delete --dry-run /srv/app/ /backup/app/ | head -20
find /var/log -name '*.gz' -mtime +7

شغّل find من دون -delete لتحصل على قائمة بدلاً من فقدان البيانات.

نمط الفشل: اختلاق الخيارات. يكون النموذج موثوقاً مع الأدوات التي تملك توثيقاً منذ 30 عاماً، لكنه أضعف بكثير مع واجهات سطر الأوامر (command line interfaces) الخاصة بالمورّدين ومع الأوامر الفرعية الحديثة، إذ ينشئ خياراً يبدو صحيحاً تماماً لكنه غير موجود. يحسم --help الأمر خلال ثانية واحدة. ويُعد الاقتباس نقطة ضعف أخرى، لذلك عندما يغلّف الأمر تعبير $(...)، اقرأ كيف تتوسع إحلالات الأوامر قبل تشغيل الأمر بدلاً من الوثوق بالشرح.

المهمة 5: حوّل سجل أوامر shell إلى دليل إجراءات

لقد أمضيت ساعتين في تشغيل شيء ما بنجاح. هذه المعرفة موجودة في سجل التمرير لديك، وستختفي في الشهر المقبل.

history 200 > /tmp/session.txt

اقرأ ذلك الملف واحذف كل سطر يحتوي على كلمة مرور أو رمز مميز أو معرّف عميل قبل أن ترسله إلى أي مكان. يُعد سجل أوامر shell من أكثر الأماكن موثوقية للعثور على سر في جهاز Linux، لأن الجميع يكتب سراً مضمّناً في الأمر مرة واحدة على الأقل. اضبط HISTCONTROL=ignorespace في ملف ~/.bashrc لديك، ولن يُكتب أي أمر يبدأ بمسافة في السجل.

يطلب prompt الذي ينتج دليلاً عملياً إجراء فحوصات، وليس الخطوات فقط:

هذه جلسة shell حوّلت جهاز Debian 13 جديداً إلى تثبيت Postgres يعمل. اكتبها في صورة دليل إجراءات مرقّم. ضع أمراً واحداً في كل خطوة. بعد كل خطوة، اذكر الأمر الذي يثبت نجاحها، واشرح كيف يبدو الخرج السليم. حدّد أي خطوة اعتمدت على مضيفي المحدد.

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

المهمة 6: حوّل رسالة خطأ إلى حل

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

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). رتّب الأسباب المحتملة، وأعطني أمراً واحداً لكل سبب لتأكيده أو استبعاده.

الآلية في هذه الحالة واضحة: توجد عملية أخرى تشغل المنفذ 80، وsudo ss -tulpn | grep ':80 ' يحددها. غالباً تكون هذه العملية نسخة ثانية من nginx master بقيت بعد فشل إعادة التحميل، أو Apache جرى سحبه كتَبعية وبدأته حزمته الخاصة.

نمط الفشل: حل ينجح عبر إخفاء السبب. يؤدي كل من chmod 777 و--privileged وتعطيل SELinux وتشغيل الخدمة بصفة root إلى اختفاء الخطأ. ارفض أي حل يوسّع الصلاحيات إلى أن يشرح النموذج سبب فشل الصلاحية المقيّدة. هذا الشرح هو الإجابة الفعلية. أما الحل الالتفافي فلا يؤدي إلا إلى إسكات الخطأ.

ما الذي يخطئ فيه باستمرار

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

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

وضع الوكيل على الخادم نفسه

كل ما سبق يعتمد على النسخ واللصق، لذلك لا يلمس النموذج جهازك. عندما يعمل الوكيل على الخادم ويقرأ الملفات وينفّذ الأوامر، يتغير نوع الخطر: فقد يؤدي أمر خاطئ إلى تعطيل خدمة. أنشئ له مستخدماً خاصاً غير مميّز بدلاً من استخدام root، وأبقِه خارج خادم الإنتاج أثناء التعرّف إلى سلوكه، وأنشئ لقطة أولاً. يشرح تشغيل Claude Code بأمان على VPS العزل ونموذج الصلاحيات. أما تشغيل Claude Code داخل tmux فيعالج الجانب الآخر، لأن انقطاع جلسة SSH (الصدفة الآمنة) ينهي الوكيل الذي يعمل في الواجهة الأمامية قبل إكمال مهمته. أنشئ الحساب بالطريقة نفسها التي تنشئ بها أي حساب خدمة، كما يوضّح المستخدمون ذوو أقل قدر من الصلاحيات على VPS.

FAQ

هل يستطيع Claude قراءة سجلات الخادم مباشرة؟

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

ما الذي يجب ألا ألصقه من الخادم مطلقاً؟

المفاتيح الخاصة، وملفات .env ومخازن بيانات الاعتماد الأخرى، و/etc/shadow، وأي بيانات تخص المستخدمين. احذف الرموز المميزة من مقتطفات السجلات قبل إدراجها في الطلب. هناك حالة غير واضحة: يضمّن ناتج docker compose config قيم .env لديك داخله، لذلك استخدم docker compose config -q، فهو يتحقق من صحة الملف ولا يطبع شيئاً.

هل من الآمن السماح لـClaude بتشغيل الأوامر على VPS مخصص للإنتاج؟

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

لماذا يقترح Claude علَماً غير موجود؟

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

كيف أتحقق من وحدة systemd قبل تفعيلها؟

شغّل sudo systemd-analyze verify /etc/systemd/system/myapp.service. يحلل الملف باستخدام محلل systemd نفسه، ويبلغ عن التوجيهات غير المعروفة مع أرقام أسطرها، ويشير إلى وجود ملف ثنائي ExecStart مفقود أو غير قابل للتنفيذ. ثم شغّل daemon-reload وstart، واقرأ systemctl status قبل أن enable الوحدة، لأن الوحدة التي تُحمّل بنجاح قد تفشل مع ذلك عند تشغيلها أول مرة.