פרודקשן (Production)

Why it matters

אתם יכולים לכתוב את הקוד הכי מבריק בעולם -- אבל אם הוא לא רץ בצורה יציבה בשרת אמיתי ומשרת משתמשים אמיתיים, אין לו ערך עסקי. Production (או "פרודקשן") הוא הסביבה שבה הקוד שלכם באמת חי, ומהרגע שהוא שם -- הכל צריך לעבוד.

הנושא הזה רלוונטי לכל תפקיד בהייטק, לא רק DevOps. מפתחים כותבים קוד שצריך לרוץ שם, Data Scientists בונים מודלים שצריכים לשרת שם, ו-Product Managers צריכים להבין מה אפשרי ומה לא בסביבה הזאת. אם אתם רוצים להבין מי אחראי על מה -- ראו מפת תפקידים (Roles Map).

Core ideas

מה זה "עולים ל-Production"?

כשמישהו אומר "עלינו ל-Production" -- הכוונה היא שהקוד עבר את כל השלבים וזמין למשתמשים אמיתיים. זה לא רק "להריץ את הסקריפט" -- זה אומר שהמערכת:

• רצה על שרתים (לא על הלפטופ שלכם).
• מטפלת באלפי/מיליוני בקשות במקביל.
• מתאוששת מתקלות בצורה אוטומטית.
• מנוטרת -- מישהו (או משהו) יודע אם יש בעיה.

שלוש הסביבות: Dev, Staging, Production

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│     Dev      │───▶│   Staging    │───▶│  Production  │
│  (פיתוח)     │    │  (הכנה)      │    │  (חי!)       │
└──────────────┘    └──────────────┘    └──────────────┘

 המחשב שלך /        העתק של Production   השרתים האמיתיים
 שרת פיתוח          עם Data מדומה        עם משתמשים אמיתיים

הדרך מקוד לשירות חי

  כתיבת קוד
       │
       ▼
  Git Push  ──────────▶  Repository (GitHub / GitLab)
                               │
                               ▼
                        CI Pipeline רץ:
                         ├── Build (בניית הקוד)
                         ├── Tests (בדיקות אוטומטיות)
                         └── Lint (בדיקת סגנון קוד)
                               │
                          ✅ הכל עבר?
                               │
                               ▼
                        CD Pipeline:
                         ├── Build Docker Image
                         ├── Push to Registry
                         └── Deploy to Staging
                               │
                         בדיקות ב-Staging ✅
                               │
                               ▼
                        Deploy to Production
                               │
                               ▼
                        Monitoring & Alerting
                        (שומרים שהכל עובד)

אסטרטגיות Deploy

לא כל Deploy הוא אותו דבר. הנה הגישות הנפוצות:

Docker -- למה הוא שינה את המשחק

Docker פותר את הבעיה הכי קלאסית בהייטק: "It works on my machine". הוא עושה את זה על ידי אריזה של הקוד שלכם יחד עם כל מה שהוא צריך -- הגרסה הנכונה של Python, כל ה-Libraries, ההגדרות -- לתוך Container אחד.

# דוגמה ל-Dockerfile פשוט
FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Kubernetes -- כש-Docker לבד לא מספיק

כשיש לכם עשרות או מאות Containers שצריכים לרוץ, Docker לבד לא מספיק. Kubernetes (K8s) מנהל את ה-Containers בשבילכם:

• Scaling -- מוסיף Containers כשיש עומס, מוריד כשהעומס יורד.
• Self-healing -- Container שקרס? Kubernetes מרים חדש אוטומטית.
• Load Balancing -- מחלק Traffic בין ה-Containers.
• Rolling Updates -- מעדכן בהדרגה בלי Downtime.

Monitoring, Logging, Alerting

ברגע שהקוד ב-Production -- צריך לדעת מה קורה:

Logging (רישום)

• כל פעולה חשובה נרשמת ב-Log.
• לדוגמה: "User #1234 logged in at 14:32", "Payment failed for order #5678".
• כלים נפוצים: ELK Stack (Elasticsearch, Logstash, Kibana), Datadog.

Monitoring (ניטור)

• מדידה מתמדת של מדדים: CPU usage, Response Time, Error Rate, Active Users.
• כלים נפוצים: Prometheus, Grafana, New Relic.

Alerting (התראות)

• כש-Monitoring מזהה חריגה -- נשלחת התראה.
• לדוגמה: "Error Rate עלה מ-0.1% ל-5% בדקה האחרונה" -> SMS / Slack / PagerDuty.

Four Golden Signals -- ארבעת המדדים שכל מערכת צריכה לנטר:

# דוגמה פשוטה ל-Logging ב-Python
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

def process_order(order_id):
    logger.info(f"Processing order {order_id}")
    try:
        # ... logic ...
        logger.info(f"Order {order_id} completed successfully")
    except Exception as e:
        logger.error(f"Order {order_id} failed: {e}")
        raise

Log Levels -- לא כל הודעה שווה

logger.debug("Variable x = 42")        # פרטים לפיתוח בלבד
logger.info("Order #123 created")       # פעולה רגילה שהתרחשה
logger.warning("Disk usage at 85%")     # משהו חשוד, אבל עדיין עובד
logger.error("Payment API returned 500") # משהו נכשל
logger.critical("Database is down!")     # הכל קורס, תקראו לכולם

SLA, SLO, SLI -- ההבטחה למשתמשים

מושגים שכל מי שעובד עם Production צריך להכיר:

כמה Downtime מותר?

Common confusions

!!! warning ""זה עובד לי על המחשב" (It works on my machine)" זה כנראה הבלבול הכי קלאסי בהייטק. הקוד רץ מצוין על הלפטופ שלכם, אבל נשבר ב-Production. למה?

| סיבה | דוגמה |
|------|-------|
| **גרסאות שונות** | "אצלי Python 3.11, ב-Production יש 3.9" |
| **חסרות Dependencies** | "שכחתי להוסיף library ל-`requirements.txt`" |
| **Environment Variables** | "ה-API key מוגדר אצלי אבל לא בשרת" |
| **Data שונה** | "בדקתי עם 10 רשומות, ב-Production יש 10 מיליון" |
| **הרשאות** | "אצלי יש הרשאת Admin, בשרת לא" |

**הפתרון?** Docker. כשאתם עובדים בתוך Container, הסביבה **זהה** בכל מקום -- על הלפטופ, ב-Staging, וב-Production.

Tiny example

דמיינו שבניתם אפליקציית TODO פשוטה. ככה נראה המסלול ל-Production:

# שלב 1: פיתוח מקומי (Dev)
$ python app.py  # רץ על localhost:5000
# בודקים ידנית שהכל עובד

# שלב 2: דוחפים ל-Git
$ git add .
$ git commit -m "Add delete-task feature"
$ git push origin main

# שלב 3: CI רץ אוטומטית (GitHub Actions)
# ✅ Tests passed (14/14)
# ✅ Lint passed
# ✅ Docker image built

# שלב 4: Deploy ל-Staging
# -> הצוות בודק את ה-Feature החדש

# שלב 5: Deploy ל-Production
# -> המשתמשים רואים את ה-Feature החדש

# שלב 6: Monitoring
# -> Grafana מראה: Response Time = 45ms, Error Rate = 0.01%
# -> הכל תקין ✅

Alert: Error Rate spike to 12%!
   │
   ▼
DevOps / On-call Engineer רואה את ההתראה
   │
   ▼
בודק Logs: "NullPointerException in delete_task()"
   │
   ▼
שתי אפשרויות:
   ├── Rollback: חוזרים לגרסה הקודמת (מהיר, בטוח)
   └── Hotfix: מתקנים את ה-Bug ועושים Deploy חדש

דוגמה: GitHub Actions CI/CD Pipeline

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          pip install -r requirements.txt
          pytest tests/ -v

  build:
    needs: test  # רץ רק אם הבדיקות עברו
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Push to registry
        run: docker push myapp:${{ github.sha }}

  deploy:
    needs: build  # רץ רק אם ה-Build הצליח
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: kubectl set image deployment/myapp myapp=myapp:${{ github.sha }}

דוגמה: Incident Response -- מה קורה כשהאתר נופל

17:00 - Alert: "Homepage returning 503 errors"
        │
        ▼
17:01 - On-call Engineer מקבל SMS + Slack notification
        │
        ▼
17:03 - בודק Dashboard: Error Rate = 45%, CPU = 98%
        │
        ▼
17:05 - מזהה: Deploy האחרון (לפני 10 דקות) הכניס Memory Leak
        │
        ▼
17:07 - מבצע Rollback לגרסה הקודמת
        │
        ▼
17:08 - Error Rate חוזר ל-0.1%, CPU חוזר ל-30%
        │
        ▼
17:10 - כותב הודעת Post-mortem ראשונית ב-Slack
        │
        ▼
למחרת - Post-mortem meeting: "מה קרה, למה, ואיך נמנע בעתיד"

🛤️ מאיפה מתחילים

מסלול למידה מומלץ להבנת Production:

שלב 1: בסיס (שבוע 1-2)

1. להבין מה זה Client-Server Architecture -- איך Browser מדבר עם Server
2. ללמוד Git בסיסי -- commit, push, pull, branches
3. להכיר את ה-Terminal / Command Line -- ניווט, הרצת פקודות בסיסיות
4. משאב מומלץ: The Missing Semester של MIT (חינמי)

שלב 2: Docker (שבוע 3-4)

1. להתקין Docker ולהריץ Container ראשון
2. לכתוב Dockerfile לפרויקט קטן (אפליקציית Flask / FastAPI)
3. להבין Docker Compose -- להריץ כמה Services ביחד
4. משאב מומלץ: Docker Getting Started (הדוקומנטציה הרשמית מעולה)

שלב 3: CI/CD (שבוע 5-6)

1. להגדיר GitHub Actions Pipeline פשוט -- Build + Test
2. להוסיף Linting ובדיקות אוטומטיות
3. להגדיר Deploy אוטומטי ל-Staging
4. משאב מומלץ: GitHub Actions Documentation + דוגמאות

שלב 4: Cloud Basics (שבוע 7-8)

1. לפתוח חשבון ב-AWS / GCP / Azure (יש Free Tier)
2. להרים שרת בסיסי (EC2 / Cloud Run / App Service)
3. לעשות Deploy של האפליקציה שלכם לענן
4. ללמוד על Load Balancers, DNS, ו-SSL

שלב 5: Monitoring + Observability (שבוע 9-10)

1. להוסיף Logging מסודר לאפליקציה
2. להגדיר Monitoring בסיסי (Prometheus + Grafana, או Datadog Free)
3. להגדיר Alert אחד פשוט: "שלח לי הודעה אם Error Rate עולה על 5%"

💼 שאלות לראיון עבודה

Links to other notes

• מפת תפקידים (Roles Map) -- מי אחראי על מה בדרך ל-Production?
• Docker -- הכלי שפותר את "It works on my machine"
• CI/CD -- איך עושים Deploy אוטומטי בצורה בטוחה
• AI, ML & DL -- איך מודלי ML מגיעים ל-Production?