שאלות נפוצות, תשובות מומלצות וטיפים מקצועיים
בניתי pipeline ב-GitHub Actions שכולל: build, unit tests, integration tests, security scanning עם Snyk, Docker build ו-push ל-ECR, ו-deployment ל-EKS עם Argo CD. כל push ל-main עובר את כל השלבים ומגיע לפרודקשן תוך 15 דקות. יש rollback אוטומטי אם health checks נכשלים.
אני דוחף קוד לשרת ישירות.
אני עובד עם Terraform לניהול ה-cloud infrastructure — VPCs, EKS clusters, RDS, S3. כל השינויים עוברים PR review, יש state management ב-S3 עם locking ב-DynamoDB, ומריצים plan לפני כל apply. משתמש ב-modules לשימוש חוזר ו-workspaces לסביבות שונות.
אני מקליק בקונסול של AWS ואז אולי מתעד.
בשישי בבוקר, ה-database הראשי הפסיק להגיב. פתחתי incident channel, בדקתי את המטריקות ב-Grafana, גיליתי שה-disk מלא. ביצעתי failover ל-replica, ניקיתי logs ישנים, הגדלתי את ה-disk, ולאחר מכן כתבתי postmortem עם action items למניעה.
הפעלתי מחדש את השרת וזה עבד.
אני מתכנן עם multi-AZ deployment, load balancing, auto-scaling groups, ו-health checks. בנוסף, יש disaster recovery plan עם cross-region replication. בחברה האחרונה השגנו 99.99% uptime על ידי ארכיטקטורה של microservices עם circuit breakers ו-graceful degradation.
יש לנו שרת גיבוי שמפעילים ידנית אם צריך.
אני מיישם DevSecOps — אבטחה משולבת בכל שלב. Container scanning ב-CI, secrets management עם Vault, network policies ב-Kubernetes, IAM roles עם least privilege, ו-audit logging. מריץ penetration testing רבעוני ומטפל ב-CVEs באופן שוטף.
אבטחה זה של צוות הסייבר, אני מתמקד ב-infra.
שיטת STAR: Situation, Task, Action, Result — הדרך הטובה ביותר לענות על שאלות התנהגותיות.
החברה עברה מ-monolith ל-microservices אבל ה-deployment process היה ידני וארך 4 שעות עם downtime
הייתי צריך לבנות תשתית deployment אוטומטית שמאפשרת zero-downtime deployments
בניתי Kubernetes cluster עם Argo CD ל-GitOps, הגדרתי rolling updates עם health checks, הטמעתי canary deployments עם Istio, ויצרתי CI/CD pipeline מלא עם automated testing
Deployment ירד מ-4 שעות ל-8 דקות, אפס downtime, והצוות מבצע 15 deployments ביום במקום 2 בשבוע
הכר לעומק את ה-cloud provider הרלוונטי — AWS, GCP או Azure
היה מוכן לשאלות hands-on: כתוב Dockerfile, Terraform, Kubernetes YAML
הכן דוגמאות של שיפורי תהליכים עם מדדים — deployment frequency, MTTR, lead time
הכר את עקרונות ה-SRE: SLOs, SLIs, error budgets
היה מוכן לדון ב-tradeoffs: managed services vs self-hosted, monorepo vs multirepo
הכן שאלות על ה-stack, הארכיטקטורה והאתגרים הנוכחיים של החברה
לא להבין את עקרונות ה-12 factor app
גישה של ׳עובד אצלי על המכונה׳ בלי חשיבה על reproducibility
חוסר ידע באבטחת מידע בסיסית
לא להכיר monitoring ו-observability
להתעלם מ-cost optimization ולבנות infra מנופח
לבוש קז׳ואל של הייטק. ג׳ינס וחולצת טי או פולו. DevOps הוא אחד התפקידים הכי קז׳ואליים בתעשייה.
זה יתרון משמעותי. AWS Solutions Architect או CKA (Certified Kubernetes Administrator) הן ההסמכות הנפוצות ביותר. הן מראות ידע מוכח ומגדילות את הסיכויים בסינון ראשוני.
יש חפיפה גדולה. DevOps מתמקד יותר ב-CI/CD, automation ו-infrastructure. SRE מתמקד ב-reliability, monitoring ו-incident management. בפועל, הרבה תפקידים משלבים את שניהם.