איך להתכונן לראיון עבודה DevOps — מדריך מעשי

ראיון עבודה בתחום ה-DevOps מורכב משילוב ייחודי של שאלות על תשתיות ענן, כלי CI/CD, קונטיינריזציה, סקריפטינג ותרבות עבודה — ומי שמגיע מוכן עם ידע מעשי בכלים כמו Kubernetes, Terraform, Jenkins ו-Docker, עם יכולת לספר סיפור טכני ברור על פרויקטים שעשה, מגדיל את הסיכוי שלו פי שלושה לעבור. זה לא קסם — זה הכנה. במדריך הזה אני נותן לך את הצעדים הקונקרטיים, עם דוגמאות קוד, טבלאות השוואה ושאלות אמיתיות שנשאלות בתעשייה הישראלית, כדי שתגיע לראיון הבא שלך מוכן/ת ברמה שונה לגמרי.

נתחיל בדוגרי: רוב המועמדים שנכשלים בראיונות DevOps לא נכשלים בגלל חוסר ידע — הם נכשלים בגלל שהם לא יודעים להציג את מה שהם יודעים. לפי סקר שנערך על ידי אתר המשרות StackOverflow ב-2024, למעלה מ-68% מהמראיינים בתחום ה-DevOps אמרו שהדבר החשוב ביותר להם הוא יכולת לתאר פתרון בעיה אמיתית מקצה לקצה, לא רשימת כלים בקורות חיים.

בישראל, שוק ה-DevOps רותח. חברות כמו Wix, Monday.com, CyberArk ו-Check Point מגייסות עשרות אנשי DevOps ו-SRE בכל רבעון. אבל ההתחרות עזה — ולכן ההכנה היא מה שמבדיל. בואו נפרק את זה לחלקים.

ארבע קטגוריות שאלות שחוזרות על עצמן

כמעט כל ראיון DevOps בתעשייה הישראלית מתחלק לארבע קטגוריות עיקריות. ההכנה שלך צריכה לכסות את כולן:

1. Linux וסקריפטינג: שאלות על ניהול תהליכים, מערכות קבצים, הרשאות, ופתרון בעיות ב-Bash. זה השלד — בלי זה אין DevOps.

2. CI/CD ואוטומציה: איך בנית Pipeline? מה קורה כש-build נכשל? איך עושים rollback? כאן המראיין בודק אם יש לך ניסיון מעשי או רק תיאורטי.

3. קונטיינרים ואורקסטרציה: Docker, Kubernetes, Helm — שאלות על ארכיטקטורה, debugging של Pods, ו-networking בתוך cluster.

4. ענן ותשתיות כקוד (IaC): AWS, GCP או Azure — יחד עם Terraform או Pulumi. כאן בודקים אם אתה יודע לנהל תשתיות בצורה מסודרת, לא בלחיצות בקונסולה.

מה שלא כתוב בתיאור המשרה אבל תמיד נבדק

הנה הסוד הפתוח: מעבר לשאלות טכניות, כל ראיון DevOps בודק גם soft skills ספציפיים. מראיינים רוצים לראות שאתה יודע לדבר עם מפתחים, שאתה מבין את ה-why מאחורי הכלים, ושאתה לא רק "מריץ סקריפטים" אלא חושב על מערכת כוללת.

לפי מחקר של Puppet Labs (State of DevOps Report 2024), צוותים שמשלבים תרבות DevOps אמיתית מגיעים ל-deployment frequency גבוה פי 208 מצוותים שלא. מראיינים מחפשים אנשים שמבינים את המספר הזה — ויודעים מה צריך לקרות ברמת התהליכים כדי להגיע לשם.

אל תקרא עוד מאמר ג'נרי. הנה תוכנית עבודה קונקרטית שמבוססת על מה שאנחנו רואים שעובד עם אנשים שעברו ראיונות בהצלחה בחברות ישראליות מובילות.

ימים 1-3: חיזוק בסיס — Linux, Networking וסקריפטינג

תתחיל מהבסיס. פתח טרמינל — לא מצגת — והתחל לעבוד. הקם VM עם Ubuntu, ותתרגל את הפקודות הבאות עד שהן אוטומטיות:

#!/bin/bash
# תרגול: סקריפט שבודק בריאות שרת בסיסית
# הריצו את זה על VM של Ubuntu ותבינו כל שורה

echo "=== System Health Check ==="

# בדיקת שימוש בדיסק
echo "--- Disk Usage ---"
df -h | grep -E '^/dev/' | awk '{print $1, $5, $6}'

# בדיקת שימוש בזיכרון
echo "--- Memory Usage ---"
free -h | awk '/^Mem:/ {printf "Used: %s / Total: %s (%.1f%%)\n", $3, $2, ($3/$2)*100}'

# בדיקת עומס CPU
echo "--- CPU Load Average ---"
uptime | awk -F'load average:' '{print $2}'

# בדיקת שירותים קריטיים
echo "--- Critical Services ---"
for service in docker kubelet nginx sshd; do
    if systemctl is-active --quiet "$service" 2>/dev/null; then
        echo "$service: ✅ RUNNING"
    else
        echo "$service: ❌ NOT RUNNING"
    fi
done

# בדיקת חיבוריות רשת
echo "--- Network Connectivity ---"
if ping -c 1 -W 2 8.8.8.8 &>/dev/null; then
    echo "Internet: ✅ Connected"
else
    echo "Internet: ❌ Disconnected"
fi

# בדיקת פורטים פתוחים
echo "--- Open Ports (Listening) ---"
ss -tlnp | grep LISTEN | awk '{print $4, $6}' | head -10

echo "=== Health Check Complete ==="

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

בנוסף, תתרגל networking: מה זה DNS, מה ההבדל בין TCP ל-UDP, מה עושה iptables, ואיך עובדים עם curl ו-netcat ל-debugging. שאלות networking חוזרות ב-90% מהראיונות.

ימים 4-5: CI/CD — בנה Pipeline אמיתי

אין תחליף לבנות Pipeline אמיתי בעצמך. לא לקרוא על זה — לבנות. הנה דוגמה ל-GitHub Actions workflow שמריץ build, test ו-deploy לאפליקציית Node.js:

# .github/workflows/ci-cd-pipeline.yml
name: CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

env:
  DOCKER_IMAGE: myapp
  DOCKER_REGISTRY: ghcr.io/${{ github.repository_owner }}

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run unit tests
        run: npm test -- --coverage

      - name: Upload coverage
        uses: codecov/codecov-action@v3

  build-and-push:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    permissions:
      packages: write
      contents: read

    steps:
      - uses: actions/checkout@v4

      - name: Log in to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            ${{ env.DOCKER_REGISTRY }}/${{ env.DOCKER_IMAGE }}:${{ github.sha }}
            ${{ env.DOCKER_REGISTRY }}/${{ env.DOCKER_IMAGE }}:latest

  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4

      - name: Configure kubectl
        uses: azure/k8s-set-context@v3
        with:
          kubeconfig: ${{ secrets.KUBE_CONFIG }}

      - name: Deploy to Kubernetes
        run: |
          kubectl set image deployment/myapp \
            myapp=${{ env.DOCKER_REGISTRY }}/${{ env.DOCKER_IMAGE }}:${{ github.sha }} \
            -n production
          kubectl rollout status deployment/myapp -n production --timeout=300s

שים לב — ה-Pipeline הזה מכסה את כל הזרימה: test → build → push → deploy. בראיון, כשישאלו "תתאר Pipeline שבנית," תוכל לצייר את הזרימה הזו על הלוח ולהסביר כל שלב. זה מה שמבדיל מועמד מנוסה ממועמד שקרא תיעוד.

ימים 6-7: Kubernetes ותשתיות כקוד

אם יש דבר אחד שמוכרח להיות חזק — זה Kubernetes. לפי סקר של CNCF לשנת 2024, 84% מהארגונים משתמשים בקונטיינרים ב-production, ו-Kubernetes הוא הסטנדרט. הנה פקודות kubectl שאתה חייב לדעת להריץ עם העיניים עצומות:

# פקודות kubectl חיוניות לראיון DevOps

# ===== מידע בסיסי על הקלאסטר =====
kubectl cluster-info
kubectl get nodes -o wide
kubectl top nodes

# ===== עבודה עם Pods =====
# רשימת כל ה-pods במרחב השמות production
kubectl get pods -n production -o wide

# צפייה בלוגים של pod ספציפי (כולל container ספציפי)
kubectl logs -n production  -c  --tail=100 -f

# כניסה ל-shell בתוך pod לדיבאגינג
kubectl exec -it -n production  -- /bin/sh

# תיאור מלא של pod — כולל events, שזה הדבר הראשון שבודקים כשמשהו תקוע
kubectl describe pod -n production 

# ===== Debugging נפוץ =====
# למה pod ב-CrashLoopBackOff?
kubectl get events -n production --sort-by='.lastTimestamp' | tail -20

# בדיקת resource requests/limits
kubectl get pods -n production -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].resources}{"\n"}{end}'

# ===== Rolling update ו-rollback =====
# עדכון image של deployment
kubectl set image deployment/myapp myapp=myapp:v2.1.0 -n production

# מעקב אחרי rollout
kubectl rollout status deployment/myapp -n production

# שגיאה? rollback מיידי
kubectl rollout undo deployment/myapp -n production

# היסטוריית rollouts
kubectl rollout history deployment/myapp -n production

# ===== Horizontal Pod Autoscaler =====
kubectl autoscale deployment myapp --min=3 --max=10 --cpu-percent=70 -n production
kubectl get hpa -n production -w

כל פקודה כאן מייצגת שאלת ראיון פוטנציאלית. "איך תדבאג Pod שלא עולה?" — ו-kubectl describe + kubectl logs + kubectl get events זו התשובה. תתרגל את זה על minikube או kind קלאסטר מקומי.

אחת השאלות הנפוצות בראיון: "למה בחרת בכלי X ולא Y?" — חשוב להכיר את היתרונות והחסרונות של הכלים העיקריים. הנה טבלת השוואה שתעזור לך לענות בצורה מושכלת:

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

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

"ספר על תקלה שטיפלת בה ב-production"

זו השאלה הכי חשובה בראיון. המראיין לא שואל מתוך סקרנות — הוא בודק את תהליך החשיבה שלך. השתמש במתודולוגיית STAR (Situation, Task, Action, Result) אבל עם טוויסט DevOps: הוסף מה שינית בתהליך כדי שזה לא יקרה שוב.

דוגמה מצוינת: "זיהינו ש-pod מסוים עושה CrashLoopBackOff. בדקתי logs ו-events, ראיתי שהבעיה היא OOMKilled — הזיכרון שהוקצה ל-container היה 256Mi אבל האפליקציה צריכה 512Mi ב-peak. תיקון מיידי: עדכון resource limits. תיקון לטווח ארוך: הוספתי Vertical Pod Autoscaler ו-monitoring alerting ב-Prometheus שמתריע כשמתקרבים ל-80% מה-memory limit."

"איך אתה מנהל סודות ו-credentials?"

שאלה שמפילה מועמדים רבים כי הם עונים "Kubernetes Secrets" ונעצרים שם. תשובה מלאה צריכה לכסות:

• שכבת אחסון: HashiCorp Vault / AWS Secrets Manager / Azure Key Vault — ולא Kubernetes Secrets בלבד (שהם base64 encoded, לא encrypted by default).

• שכבת הזרקה: External Secrets Operator ש-sync מ-Vault ל-K8s Secrets, או Vault Agent Sidecar שמזריק ישירות ל-Pod.

• שכבת מדיניות: rotation אוטומטי, least privilege, audit logging.

# דוגמה: שימוש ב-External Secrets Operator
# התקנה עם Helm
helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets -n external-secrets --create-namespace

# יצירת SecretStore שמתחבר ל-AWS Secrets Manager
cat <

# תשובה מעשית: Backend configuration עם S3 + DynamoDB locking

# backend.tf
cat <<'EOF'
terraform {
  backend "s3" {
    bucket         = "mycompany-terraform-state"
    key            = "production/infrastructure/terraform.tfstate"
    region         = "eu-west-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}
EOF

# יצירת DynamoDB table ל-state locking (מונע race conditions בין חברי צוות)
aws dynamodb create-table \
  --table-name terraform-state-lock \
  --attribute-definitions AttributeName=LockID,AttributeType=S \
  --key-schema AttributeName=LockID,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --region eu-west-1

# best practices שחשוב להזכיר בראיון:
# 1. State מרוחק (remote) — אף פעם לא local
# 2. Locking — מונע שני אנשים יעשו apply במקביל
# 3. Encryption at rest — state מכיל מידע רגיש
# 4. Workspaces או directory structure לסביבות שונות
# 5. State import עבור משאבים קיימים: terraform import aws_instance.web i-1234567890abcdef0