רוב הלקוחות שלנו בסדרה A מגיעים לאותה צומת. יש להם מוצר עובד, VM פרודקשן יחיד, ו-CTO שלא ישן ברציפות דרך deploy כבר שישה חודשים. הם יודעים שהם צריכים ״DevOps״, אבל הם לא יודעים איך טוב נראה, וכל היועצים שהם דיברו איתם רוצים למכור להם Kubernetes.
אנחנו לא מוכרים לאף אחד Kubernetes. אנחנו מוכרים להם סולם, ואומרים להם על איזו שלב הם נמצאים. כך נראים שמונה שבועות.
שבוע 1: קונטיינריזציה ותיעוד
לפני שנוגעים בתשתית, אנחנו שמים את האפליקציה ב-Dockerfile. לא כי קונטיינרים מטבעם יותר טובים, אלא כי הם מאלצים אותך לכתוב את חוזה ה-runtime: אילו חבילות OS, איזו גרסת runtime, אילו משתני סביבה, אילו פורטים. חצי מהזמן, זה חושף הגדרה שאף אחד בצוות לא יכול לשחזר מקומית.
גם כותבים את ה-runbook הראשון בשבוע הראשון. שלושה עמודים: איך לבצע deploy, איך לעשות rollback, איך לקרוא את הלוגים. אם מהנדס ג׳וניור לא יכול לעקוב אחריו ביום שישי אחה״צ, זה לא גמור.
שבועות 2–3: pipeline של deploy שאפשר לסמוך עליו
המטרה היא לא תחכום. המטרה היא ש-push ל-main יפיק artifact ניתן-לאימות וניתן-ל-rollback בפרודקשן תוך חמש עשרה דקות. GitHub Actions או GitLab CI, לבנות את ה-image, לתייג עם SHA של הקומיט, לדחוף ל-registry, לעשות deploy לסביבת staging, להריץ smoke tests, לקדם לפרודקשן מאחורי אישור ידני.
האישור הידני נשאר בחודש הראשון. קידום אוטומטי מגיע מאוחר יותר, כשה-smoke tests תפסו את הרגרסיה האמיתית הראשונה שלהם והצוות למד לסמוך עליהם.
שבועות 4–5: תצפית לפני סקייל
כאן רוב הצוותים טועים. הם מסקיילים קודם, ואז מנסים לדבג תקרית פרודקשן בלי מטריקות, בלי traces, ועם tail -f על קובץ לוג יחיד.
אנחנו מתקינים את הסטאק המשעמם: Prometheus למטריקות, Loki ללוגים, Grafana לדשבורדים, OpenTelemetry ל-traces. אלטרנטיבות מנוהלות אם הצוות מעדיף — Datadog, Honeycomb, Better Stack. הספק חשוב פחות מהמשמעת: כל שירות פולט לוגים מובנים, כל endpoint מתעד latency, כל שגיאה מקבלת fingerprint ייחודי.
הדשבורד הראשון שאנחנו בונים יש בו שישה panels: קצב בקשות, קצב שגיאות, p95 latency, pool חיבורי DB, עומק תור, ו-CPU/זיכרון לכל שירות. אם משהו לא בסדר, התשובה נמצאת בעמוד אחד.
שבוע 6: alerting שלא משקר
לרוב הצוותים יש יותר מדי אלרטים. ה-CTO השתיק את הערוץ כי 80 אחוז מה-pages הם רעש. אנחנו מוחקים 80 אחוז מהאלרטים.
מה ששורד הוא קבוצה קטנה של אלרטים מבוססי-סימפטום: תקציב השגיאות של ה-API הציבורי נצרך מהר יותר מהצפוי; עומק התור גדל בלי גבול; deploy נכשל ועשה rollback. כל אלרט מצביע על סעיף ב-runbook. כל סעיף ב-runbook מסתיים ב״אם זה לא עובד, תעירו את ה-on-call״.
רוטציית ה-on-call מתחילה עם שני אנשים. העברה שבועית. מסמך ההעברה מפרט מה שבור עכשיו, מה לא יציב, ומה השתנה בשבוע שעבר. אף פעם לא התחלנו רוטציה בלי מסמך העברה ואף פעם לא נעשה את זה.
שבוע 7: גיבויים, סודות, והדברים שאתה צריך רק פעם אחת
גיבויי DB חייבים להתקיים, חייבים להיות משוחזרים לפחות פעם אחת, וחייבים להיבדק בתרגיל התאוששות לפני ההשקה. אנחנו עושים את התרגיל בשבוע שבע, מול snapshot פרודקשן עדכני, עם סטופר. הראשון תמיד לוקח פי שלוש מהזמן שכל אחד ציפה.
סודות עוברים מקבצי .env ל-secret store אמיתי: AWS Secrets Manager, Doppler, או Vault. הקריטריון פשוט — האם מהנדס חדש יכול לעשות onboarding בלי שאף אחד ישלח לו DM עם credential? אם התשובה היא לא, המערכת לא בטוחה.
שבוע 8: תיעוד והעברה
השבוע האחרון הוא לכתוב דברים. כל בחירה מקבלת Architecture Decision Record בעמוד אחד. כל runbook עובר סקירה על-ידי מישהו שלא כתב אותו. לוח ה-on-call חי ב-PagerDuty (או Opsgenie, או Better Stack), והצוות יכול לבטא, בקול רם, מה לעשות כשכל אחת מחמש התקריות הסבירות ביותר מתרחשת.
אנחנו עוזבים את הצוות עם עומס תחזוקה שניתן למדידה בשעות לשבוע, לא ימים. ה-CTO ישן. הגיוס הבא עושה onboarding ביום במקום בשבוע. ואף אחד לא מזכיר Kubernetes.
כמה זה עולה
למערכת פרודקשן קטנה-בינונית, עלות הריצה נוחתת אי-שם בין $400 ל-$1,200 לחודש לתשתית, תלוי בתעבורה ובאחסון. עלויות הכלים בערך $200–$600 לחודש לסטאק התצפית בסקייל הזה, פחות אם הצוות מארח עצמית.
ההתקשרות שלנו רצה שמונה שבועות של זמן סניור, פלוס ריטיינר חודש לרוטציית ה-on-call הראשונה. אחרי זה, הצוות הוא בעלים. הנקודה של הסולם היא לא לשמור אותנו מועסקים — היא לתת לכם משהו שאתם יכולים להריץ בעצמכם.