שימוש ב-Claude לניהול שרתים: מדריך למנהלי מערכות

Claude עבור מנהלי מערכות: תחילה ייעוץ, לאחר מכן ביצוע

Claude עבור מנהלי מערכות פועל בצורה הטובה ביותר ככלי לסקירה. אתם מדביקים קטע מתוך לוג, קובץ תצורה, פקודה שאינכם מזהים או מחרוזת שגיאה, ומקבלים הסבר שניתן לבדוק לפני ביצוע שינויים כלשהם בשרת. תשובה שגויה אינה גורמת לנזק כל עוד לא הרצתם אותה, לכן שמירה על המודל בצד המייעץ של המשוואה היא כל מודל הבטיחות.

בכל שבוע עולות שש משימות בשרת VPS (שרת פרטי וירטואלי) מבוסס Linux. לכל אחת מהמשימות להלן יש תבנית prompt שעובדת, הפקודה שמאמתת את התשובה, ומצב הכשל שצפוי להתרחש. אף אחת מהן אינה דורשת מהמודל גישה לשרת שלכם. ניתן להדביק מידע מתוך לשונית בדפדפן או מחלון בשולחן העבודה שלכם, שכן Claude פועל באופן טבעי על Linux הן כאפליקציית שולחן עבודה והן כ-CLI.

הסדר קריטי בשרת ייצור: קראו את ההסבר, הריצו את הבדיקה בעצמכם, ורק אז החליטו. אוטונומיה היא בסדר גמור במכונה וירטואלית לבדיקות (scratch VM). בשרת שמשרת את הלקוחות שלכם, הסקירה היא הקובעת, כיוון שהמודל אינו יכול לראות את המצב (state) שהוא מנסה לנחש.

מה אסור להדביק לעולם

כל מה שנמצא בתוך ה-prompt עוזב את השרת שלך. ארבע קטגוריות חייבות להישאר על השרת:

• מפתחות פרטיים: ~/.ssh/id_ed25519, /etc/ssh/ssh_host_*_key, וכל מפתח TLS (אבטחת שכבת תעבורה) תחת /etc/letsencrypt/live/.
• קובצי הרשאות: .env, ~/.aws/credentials, /root/.docker/config.json, וסיסמאות מסדי נתונים בכל קובץ או שורת לוג.
• נתוני חשבון: /etc/shadow ו-/etc/gshadow. אף שאלת ניהול מערכת אינה דורשת hash של סיסמה כדי לקבל מענה.
• כל דבר השייך למשתמשים שלך: כתובות אימייל, שורות הזמנה, לוגים של בקשות המכילים session cookies או PII (מידע מזהה אישי).

מפתחות ציבוריים בטוחים להדבקה. מפתחות פרטיים אינם בטוחים, ושני סוגי הקבצים נראים דומים במבט חטוף, לכן קרא את השורה הראשונה לפני ההעתקה: קובץ שהשורה הראשונה שלו מכילה BEGIN OPENSSH PRIVATE KEY לעולם לא אמור להיכנס לתוך ה-prompt. שמירה על סדר בחומרי מפתח ה-SSH שלך שווה עשר דקות של למידה בפני עצמה.

בצע עריכה (redaction) לפני ההדבקה, במקום לסמוך על עצמך שתזהה טוקן אחד בתוך 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, אשר מבצע ולידציה ולא מדפיס דבר. לגבי המדיניות הרחבה יותר בנוגע למה מותר לסוכן לראות, שמירה על סודות מחוץ לסוכני AI מכסה את הצד של סביבת העבודה.

משימה 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 עבד מצוין עד שערכתי את ה-unit לפני שעה. להלן systemctl status ו-100 השורות האחרונות מה-journal. איזו שורה היא השגיאה האמיתית הראשונה, ומה היא אומרת? אין עדיין תיקון.

המשפט "אין עדיין תיקון" מבצע עבודה חשובה בהנחיה הזו. לוגים קוברים את הכשל הראשון תחת הניסיונות החוזרים שהוא גרם להם, לכן מודל שמתבקש לספק תיקון יסביר את השורה האחרונה שהוא ראה. השורה שחשובה נמצאת בדרך כלל עשרים שורות מעל הרעש.

התועלת היא שורה כמו Main PID: 1841 (code=exited, status=203/EXEC). קוד יציאה 203/EXEC אומר שה-kernel לא הצליח להריץ את הקובץ שצוין ב-ExecStart: או שהנתיב לא קיים, או שהקובץ קיים אך אינו ניתן להרצה. שורת #! שמציינת מפרש (interpreter) שאינו מותקן תפיק את אותו הסטטוס. כל אלו ניתנים לבדיקה באמצעות 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 אכן קיימת. שירות שנקשר לכתובת IP ספציפית ייכשל בעת האתחול עם bind: Cannot assign requested address, והפתרון הוא Wants=network-online.target יחד עם After=network-online.target. השנייה היא Type=simple עבור תוכנית שמבצעת daemonize: ‏systemd מתייחס לתהליך הראשון כאל השירות, תהליך האב מסתיים מיד, והיחידה מסומנת כמתה בזמן שהתהליך האמיתי ממשיך לרוץ ללא ניהול. זו הטעות שסביר ביותר שמודל יציע לכם, מכיוון שהוא לא יכול לדעת מהפקודה שלכם אם הקובץ הבינארי מבצע fork, לכן כדאי להכיר את מה כל ערך של Type= מבטיח ל-systemd לפני שאתם מקבלים את הטיוטה.

עבור תזמון, בדקו אותו במקום לקרוא אותו:

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

פקודה זו מדפיסה את הצורה המנורמלת ואת הפעם הבאה שהביטוי יופעל, מה שמיישב כל ויכוח לגבי המשמעות שלו. אם אתם מתלבטים בין timer לבין crontab, המאמר שירותי systemd ו-timers ב-VPS מסביר את השיקולים.

ל-cron יש מלכודת שאף מודל לא יזהיר אתכם מפניה אלא אם תשאלו. Cron מריץ משימות עם סביבה מינימלית, כך ש-PATH הוא בערך /usr/bin:/bin ופרופיל ה-shell שלכם לעולם לא נקרא. משימה שעובדת כשאתם מדביקים אותה לטרמינל תיכשל ב-cron עם /bin/sh: 1: docker: not found, מכיוון שהקובץ הבינארי נמצא ב-/usr/local/bin. השתמשו בנתיבים מלאים ב-crontabs. אם ההתעמקות של קובץ יחידה בפירוט המשתמש, הסביבה והתלויות נראית לכם כמו טרחה מיותרת לעומת שורת crontab בודדת, הבעיות ש-systemd נועד לפתור מסבירות מאיפה הגיעה המילוליות הזו.

משימה 3: סקירת קובץ Nginx או Compose לפני עלייה לאוויר

משימה זו מניבה את התוצאות הטובות ביותר. הדביקו את הקובץ, ציינו מה הוא אמור לבצע, ובקשו פירוט שורה-אחר-שורה של הפעולות שהוא מבצע בפועל.

ה-vhost הזה אמור להגיש את example.com מעל HTTPS ולבצע proxy ל-/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 כאשר ההזחה (indentation) שלכם שגויה.

אף אחד מהכלים הללו לא בודק את הכוונה. תצורה שעוברת את nginx -t עדיין יכולה לבצע proxy לפורט הלא נכון, או להאזין ב-0.0.0.0 כאשר התכוונתם ל-127.0.0.1. הפער הזה הוא המקום שבו המודל מוכיח את ערכו, אך זהו גם המקום שבו הוא עלול להיכשל: כאשר מבקשים ממנו לתקן הוראה אחת, הוא לעיתים קרובות מחזיר את כל הקובץ כשהוא כתוב מחדש, תוך השמטה שקטה של שתיים מההוראות המקוריות שלכם. בקשו את השורות ששונו ואת הסיבה לכל שינוי, ולאחר מכן בצעו את העריכה ידנית.

אמתו מה חשפתם בפועל:

sudo ss -tulpn

ללא sudo אתם תראו את ה-sockets המאזינים אך לא את התהליכים שבבעלותם. אם הפלט הזה מפתיע אתכם, מהם פורטים וכיצד Linux מקשרת אותם הוא קריאה קצרה ומומלצת.

משימה 4: הסבר פקודה לא מוכרת לפני הרצתה

הדביקו את הפקודה ושאלו ארבע שאלות לגביה: מה עושה כל דגל (flag), מה היא כותבת, מה היא מוחקת, ומה קורה אם מריצים אותה פעמיים. השאלה האחרונה מונעת נזק רב יותר מהאחרות.

קחו לדוגמה את find /var/log -name '*.gz' -mtime +7 -delete. תשובה טובה תסביר ש--mtime +7 סופר יממות מלאות של 24 שעות ומתעלם משארית הזמן, לכן הוא יתאים לקבצים בני שמונה ימים לפחות ולא שבעה. היא גם תציין ש-find מעריך את הביטוי שלו משמאל לימין, כך שהעברת -delete לפני -name תמחק את כל מה שנמצא תחת נתיב ההתחלה. הנקודה השנייה הזו מופיעה כאזהרה בדף ה-man של find, והיא כבר עלתה לאנשים ב-/var/log שלהם.

או קחו את rsync -a --delete /srv/app/ /backup/app/. הלוכסן (slash) בסוף נתיב המקור אומר "התוכן של תיקייה זו". השמיטו אותו ותקבלו את /backup/app/app/. הוסיפו את --delete וכל מה שנמצא ביעד וחסר במקור יימחק; זהו מצב תקין עבור שיקוף (mirror), אך אסון כאשר נתיב המקור שגוי.

אמתו מול הכלי, לא מול המודל:

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

הריצו את find ללא -delete ותקבלו רשימה במקום אובדן נתונים.

מצב כשל: הזיית דגלים (flag hallucination). המודל אמין בכלים בעלי תיעוד של שלושים שנה, אך חלש משמעותית בממשקי שורת פקודה (CLI) של ספקים ובפקודות משנה חדשות; שם הוא עלול לייצר דגל שנשמע הגיוני לחלוטין אך אינו קיים. --help מכריע בסוגיה זו בשנייה אחת. ציטוטים (quoting) הם נקודת תורפה נוספת, לכן כאשר פקודה עוטפת ביטוי $(...), קראו על אופן ההרחבה של החלפת פקודות לפני הרצת הפקודה במקום לסמוך על ההסבר.

משימה 5: הפיכת היסטוריית ה-shell ל-runbook

בילית הרגע שעתיים בפתרון בעיה. הידע הזה נמצא כרגע ב-scrollback של הטרמינל שלך, והוא ייעלם בחודש הבא.

history 200 > /tmp/session.txt

קרא את הקובץ ומחק כל שורה המכילה סיסמה, token או מזהה לקוח לפני שתעביר אותו למקום אחר. היסטוריית ה-shell היא אחד המקומות האמינים ביותר למציאת סודות במערכת Linux, כיוון שכל אחד מקליד אותם בשורת הפקודה לפחות פעם אחת. הגדר את HISTCONTROL=ignorespace בתוך ה-~/.bashrc שלך, ופקודה שמתחילה ברווח לא תיכתב להיסטוריה כלל.

ה-prompt שמייצר runbook שמיש דורש בדיקות, לא רק שלבים:

זוהי סשן shell שהפך שרת Debian 13 נקי להתקנת Postgres עובדת. כתוב זאת כ-runbook ממוספר. פקודה אחת לכל שלב. לאחר כל שלב, ציין את הפקודה שמוכיחה שהפעולה הצליחה ותאר כיצד נראה פלט תקין. סמן כל שלב שהיה תלוי במארח הספציפי שלי.

מצב כשל: סיפור מסודר מדי. בסשן שלך היה שלב שביצעת פעמיים לפני שהצלחתו, וזה בדיוק השלב שהמודל יחליק, כיוון שהתמליל נראה נקי יותר בלעדיו. השווה את ה-runbook מול ההיסטוריה שלך והחזר את התיקון. המודל גם ממציא פקודות אימות סבירות, לכן הרץ כל בדיקה שהוא כותב לפני שתשמור את הקובץ. אם ה-runbook מכסה אתחול ראשון, קרא אותו מול עשר הדקות הראשונות ב-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 שני שנותר מאחור עקב טעינה מחדש (reload) שנכשלה, או ב-Apache שהותקן כחלק מתלות והופעל על ידי החבילה שלו.

מצב כשל: פתרון שעובד על ידי הסתרת הסיבה. chmod 777, --privileged, השבתת SELinux, והרצת השירות כ-root – כולם גורמים לשגיאה להיעלם. סרבו לכל פתרון שמרחיב הרשאות עד שהמודל יסביר מדוע ההרשאה המצומצמת נכשלה. הסבר זה הוא התשובה האמיתית. פתרון עוקף (workaround) רק משתיק את השגיאה.

מה הוא מפספס, באופן עקבי

• הוא לא יכול לראות את השרת שלך. כל תשובה היא פונקציה של מה שהדבקת, והוא לא יציין אם הקטע שסיפקת היה קצר מדי.
• הוא נוטה לסטות בגרסאות. שמות חבילות ודגלי ברירת מחדל משתנים בין הפצות ובין גרסאות, והמודל מבצע ממוצע של כולם.
• הוא נשמע משכנע גם כשהוא טועה. מנגנון מומצא נקרא בדיוק כמו מנגנון תקין, וזו הסיבה שכל סיבה לעיל מלווה בפקודה שבודקת אותה.
• הוא מאבד את הרצף בשיחות ארוכות. עובדות מתחילתה של שיחה בת שעתיים מפסיקות להשפיע על התשובות בסופה.

הנקודה האחרונה היא בעיית עבודה יותר מאשר בעיית מודל, ו-ניהול הקשר בשיחת Claude Code ארוכה הוא הפתרון המעשי: שיחות קצרות יותר, משימה אחת בכל פעם.

התקנת הסוכן על השרת עצמו

כל מה שצוין לעיל מבוסס על העתק-הדבק, כך שהמודל לעולם לא ניגש למכונה שלכם. ברגע שהוא רץ על השרת, קורא קבצים ומריץ פקודות, אופי הסיכון משתנה: פקודה שגויה עלולה כעת להשבית שירות. הקצו לו משתמש ללא הרשאות מיוחדות (unprivileged) במקום להריץ אותו כ-root, הרחיקו אותו משרת ה-production בזמן שאתם לומדים את אופן פעולתו, ובצעו snapshot לפני כן. המדריך הרצת Claude Code בצורה בטוחה על VPS מכסה את נושאי ה-sandboxing ומודל ההרשאות. המדריך הפעלת Claude Code בתוך tmux פותר את החצי השני של הבעיה, שכן ניתוק של סשן SSH (secure shell) קוטע סוכן שרץ ב-foreground באמצע עבודתו. בנו את החשבון כפי שהייתם בונים כל חשבון שירות אחר, כפי שמפורט במדריך משתמשים בעלי הרשאות מינימליות ב-VPS.

FAQ

האם Claude יכול לקרוא את לוגי השרת שלי ישירות?

לא באופן עצמאי. ממשק הצ'אט רואה רק את הטקסט שאתה מדביק לתוכו. Claude Code, המורץ על השרת ככלי שורת פקודה, יכול לקרוא קבצים ולהריץ פקודות בהרשאות המשתמש שהפעיל אותו, מה שמהווה החלטת אמון משמעותית יותר. עבור שאלת תמיכה רגילה, הדבקת קטע ערוך של 100 שורות היא מהירה ובטוחה יותר מאשר מתן גישת shell לסוכן.

מה לעולם אין להדביק מתוך שרת?

מפתחות פרטיים, קובצי .env ומאגרי הרשאות אחרים, /etc/shadow, וכל מידע השייך למשתמשים שלך. ערוך אסימונים (tokens) מתוך קטעי לוג לפני שהם מגיעים להנחיה (prompt). מקרה אחד שאינו מובן מאליו: הפלט של docker compose config כולל את ערכי ה-.env שלך כשהם מוטמעים בתוכו, לכן השתמש ב-docker compose config -q, אשר מאמת את הקובץ ואינו מדפיס דבר.

האם זה בטוח לתת ל-Claude להריץ פקודות ב-VPS בסביבת ייצור (production)?

התייחס אליו כאל מנהל מערכת חדש ללא הקשר: הוא מתאים לקריאה, אך נדרשת ביקורת לכתיבה. בסביבת ייצור, בקש הסבר והרץ את הפקודה בעצמך. אם אתה בכל זאת מעוניין שסוכן יבצע פעולות, הענק לו חשבון ייעודי ללא הרשאות מיוחדות (unprivileged) ללא גישת sudo גורפת, והתחל בסביבת staging שבה טעות תעלה לך בבנייה מחדש במקום בהשבתה.

מדוע Claude מציע דגל (flag) שלא קיים?

מכיוון שהוא חוזה טקסט סביר, ודגל סביר נראה בדיוק כמו דגל אמיתי. זה קורה בעיקר עם כלי שורת פקודה של ספקים ועם פקודות משנה חדשות, שבהן התיעוד שמאחורי המודל דל או שהשתנה מאז. --help ו-man הם הבוררים, וכל פקודה שמוחקת או דורסת נתונים ראויה להרצה בבדיקה יבשה (dry run) תחילה.

כיצד אוכל לבדוק יחידת systemd לפני שאפעיל אותה?

הרץ את sudo systemd-analyze verify /etc/systemd/system/myapp.service. הוא מנתח את הקובץ באמצעות המנתח של systemd עצמו, מדווח על הנחיות לא מוכרות עם מספרי השורות שלהן, ומסמן קובץ בינארי ExecStart שחסר או שאינו ניתן להרצה. לאחר מכן הרץ את daemon-reload, start, וקרא את systemctl status לפני שאתה מבצע enable, מכיוון שיחידה שנטענת בצורה תקינה עדיין עלולה להיכשל בהרצה הראשונה שלה.