Shell Scripts ו-Bash Automation

למה Bash scripts הורסים deployments, וכיצד Claude עוצר את זה

כל DevOps engineer מכיר את הסצנה: script שרץ מושלם במכונה המקומית, נכשל בproduction בשעה 02:00 בלילה. לא בגלל שהקוד שגוי, אלא כי אף אחד לא טרח להוסיף set -euo pipefail, בדיקה שהvariables לא ריקים, או rollback אוטומטי. סטארטאפ ישראלי עם 10M בקשות ביום למד את זה בדרך הקשה כשscript ה-rollback שלהם החזיר את production לגרסה ישנה בגלל תנאי בוליאני אחד שגוי.

Claude Sonnet 4.6 ו-Opus 4.7 לא רק כותבים bash, הם כותבים bash שעובד: עם error handling, logging, idempotency, ו-rollback מובנים. וכשscript נכשל, הם מאבחנים, מסבירים ומתקנים. זה לא code generation, זה שותף SysAdmin שמכיר את הlandmines.

ארבעת עקרונות ה-Production-Ready Bash

רוב scripts שנכתבים בחיפזון מדלגים על אחד או יותר מהעקרונות האלה:

בקשו מClaude לכתוב כל script עם ארבעת העקרונות האלה מפורשות בפרומפט, זה ההבדל בין script שמסתדר ובין script שמשבית production.

פרומפט 1: Deployment script שעושה rollback אוטומטי

זה הפרומפט שצוות DevOps בתל אביב משתמש בו לכל deployment:

אתה Senior SysAdmin עם 10 שנות ניסיון ב-Linux production.
כתוב Bash deployment script לDocker app על Ubuntu 22.04:

צעדי deployment:
1. Pull image חדש מ-ECR
2. הרץ DB migrations
3. החלף ב-zero-downtime עם docker-compose
4. בדוק health check ל-http://localhost:3000/health כל 5 שניות, 60 שניות
5. אם health check נכשל, rollback אוטומטי לגרסה הקודמת
6. שלח Slack webhook על success/failure

דרישות:
- set -euo pipefail בתחילה
- כל פקודה מתועדת עם timestamp ל-/var/log/deploys/YYYYMMDD-HHMMSS.log
- trap + cleanup function שרצה גם אחרי כישלון
- בדיקת prerequisites (docker, aws cli, curl) בהתחלה
- idempotent, ניתן להריץ פעמיים בלי נזק
- rollback function עצמאית שניתן לקרוא לה ידנית
- הסבר בהערות לכל section

למה כל מילה חשובה: set -euo pipefail-e עוצר על שגיאה, -u עוצר על variable לא מוגדר, -o pipefail עוצר אם אחד מהpipes נכשל. בלי pipefail: grep pattern file | process_output, אם grep לא מוצא כלום, exit code 1, אבל בלי pipefail הscript ממשיך בשמחה.

פרומפט 2: דיבוג "Works on Mac, Fails on Linux"

זו הבעיה הנפוצה ביותר שמפתחים מביאים לClaude. הסיבה: macOS משתמשת ב-BSD tools, Linux ב-GNU tools, אותן פקודות, התנהגות שונה:

הscript הזה עובד על Mac שלי אבל נכשל על Ubuntu 22.04 ב-CI:

[הדבק את הscript]

Error שאני מקבל ב-CI:
[הדבק את ה-error]

אבחן:
1. מה הסיבה המדויקת, BSD vs GNU? bash version? PATH שונה?
2. כל ההבדלים שעלולים לגרום לבעיות Mac vs Linux
3. Script מתוקן שעובד על שניהם
4. איך לבדוק עתידית: shellcheck + Docker test לפני deploy

הבדלים נפוצים שClaude יזהה: date -d לא עובד ב-BSD (צריך date -v), sed -i '' לעומת sed -ireadlink -f לא קיים ב-macOS ללא GNU coreutils.

Cron Jobs, Claude עוזר לכתוב, לאבחן ולמנוע בעיות

Cron syntax מבלבל כולם, אבל הבעיה האמיתית היא לא הsyntax, היא ש-cron רץ בסביבה מצומצמת: PATH מוגבל, אין terminal, ואין מי שרואה שגיאות. Claude פותר את הבעיות האלה:

כתוב cron jobs לפעולות הבאות:
1. גיבוי PostgreSQL כל לילה ב-03:00 בשעון ישראל (UTC+3)
2. ניקוי temp files ישנים מעל 7 ימים, כל יום ראשון ב-04:00
3. מחיקת Docker images ישנים כל ראשון בחודש
4. בדיקת disk usage כל שעה, שלח Slack alert אם מעל 85%

עבור כל cron:
- syntax מלא עם הסבר כל שדה
- MAILTO=devops@company.co.il לcatch errors
- flock למניעת concurrent runs
- full paths לכל פקודה (לא רק 'docker', '/usr/bin/docker')
- log לקובץ עם date בשם

הנקודה החשובה לגבי flock: אם job של גיבוי DB לוקח 2 שעות, cron ינסה להריץ שני DB backups במקביל. שני writes לאותה DB באותו זמן = corruption. flock -n /tmp/backup.lock מוודא שרץ רק instance אחד.

ShellCheck, הכלי שClaude ממליץ עליו תמיד

ShellCheck הוא static analyzer לbash שמוצא 90% מהבאגים הנפוצים לפני שהם מגיעים לproduction. Claude Code יכול להריץ אותו אוטומטית:

בדוק את הscript הזה עם shellcheck ותקן כל warning:

[הדבק script]

עבור כל תיקון שתעשה:
1. ציין את מספר האזהרה (SC2086, SC2039, וכו')
2. הסבר מה הבעיה ולמה היא מסוכנת
3. הראה לפני ואחרי
4. הוסף הסבר בהערה לcode שיעזור לצוות

כאשר Claude Opus 4.7 מגיע לscripts שנוגעים ב-credentials או בproduction data, בקשו גם security review ספציפי. "Claude performs dramatically better when it can verify its own work, without clear success criteria, it might produce something that looks right but doesn't work." (Anthropic Best Practices, 2026)

טעויות נפוצות וכיצד Claude עוצר אותן

• Variables ללא quotes: if [ $FILE == "old" ] ייכשל אם $FILE ריק, bash יפרש אותו כ-if [ == "old" ]. תמיד: "$FILE". Claude מתקן זאת אוטומטית בכל script שכותב.
• rm -rf ללא validation: rm -rf "$DIR/", אם $DIR ריק, זה rm -rf /. תמיד: [ -z "$DIR" ] && { echo "ERROR: DIR is empty"; exit 1; } לפני כל rm. בקשו מClaude לכלול validation זה מפורשות.
• Cron ללא full paths: ב-cron, PATH הוא /usr/bin:/bin בלבד. docker לבד לא יעבוד, צריך /usr/bin/docker. Claude יוסיף PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin בתחילת crontab.
• לא בודקים exit code של subprocess: OUTPUT=$(my_command), אם my_command נכשל, OUTPUT ריק אבל הscript ממשיך. פתרון: OUTPUT=$(my_command) || { echo "ERROR: failed"; exit 1; }

סיכום: מה לבקש מClaude בכל script

• תמיד ציינו: set -euo pipefaillogging עם timestampidempotent
• בקשו הסבר בהערות לכל section, הצוות לומד, לא רק copy-pastes
• לאחר קבלת script: בקשו שClaude יריץ shellcheck ויתקן את כל הwarnings
• לcron jobs: flock, MAILTO, full paths, כל שלושה, תמיד
• לscripts שנוגעים בproduction data: בקשו Claude Opus 4.7 לעשות security review נפרד