DevOps וענן לעסקים וסטארטאפים תשתית יציבה, פריסות בלי דרמה

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

לשירות בודד או לכמה שירותים קטנים, Docker Compose על שרת אחד או שירות קונטיינרים מנוהל מספיקים לרוב, והם פשוטים יותר לתפעול וזולים יותר. Kubernetes מתחיל להצדיק את עצמו כשיש הרבה שירותים, צורך בהרחבה אוטומטית לפי עומס, כמה צוותים שפורסים במקביל או דרישת זמינות גבוהה. אנחנו ממליצים על הכלי הפשוט ביותר שעונה על הצורך, אומרים במפורש מתי לא כדאי להעמיד קלאסטר, ובונים כך שאפשר לעבור אליו מאוחר יותר. בסקירה אנחנו מראים בכתב אילו חלקים בתשתית באמת מצדיקים את המורכבות ואילו עדיף להשאיר פשוטים, כדי שלא תשלמו על כלים שהצוות שלכם לא צריך ולא יתחזק.

בונים את הסביבה החדשה במקביל, מעתיקים נתונים וקבצים, ומריצים אותה בכתובת בדיקה עד שהכול נבדק. לפני המעבר מורידים את זמן התפוגה של רשומות ה-DNS, ובחלון זמן שקט מסנכרנים את השינויים האחרונים ומפנים את התנועה. השרת הישן נשאר פעיל כמה ימים כגיבוי, כך שאפשר לחזור אחורה בדקות. מסדי נתונים גדולים מועברים בשכפול מתמשך, והדומיין, הדוא״ל והאישורים נבדקים מראש כדי שלא יישברו בדרך. לפני המעבר כותבים תוכנית חזרה מסודרת, כדי שכל אחד מהשלבים יהיה הפיך ושהצוות יידע בדיוק מה עושים אם משהו לא עובד כמצופה.

מתחילים במדידה: מפרקים את החשבון לפי שירות וסביבה ומוצאים מה משלמים עליו בלי להשתמש. בדרך כלל מגלים שרתים שנשארו מפרויקט ישן, דיסקים ללא שרת, שרתים גדולים מהעומס שלהם, סביבות בדיקה שרצות בלילות וסופי שבוע, והעברת נתונים יקרה בין אזורים. אחרי הניקוי בוחנים התחייבות לטווח ארוך, מעבר לספק זול יותר כמו Hetzner כשזה מתאים, והתראות על חריגה בתקציב. כך החשבון נשאר צפוי גם כשהשימוש גדל. בסוף הניקוי מקבלים דוח קצר שמסביר כל שינוי, את ההשפעה שלו על הביצועים ואת מה שנשאר פתוח, כדי שתוכלו לשמור על החיסכון לאורך זמן.

זה תלוי ברמת השירות שתבחרו. במודל הבסיסי הניטור שולח התראה לצוות שלכם ואנחנו מטפלים בתקלה בשעות העבודה לפי זמני תגובה שנקבעו בכתב. במודל מורחב אפשר להגדיר כוננות מחוץ לשעות, עם התראה בעדיפות גבוהה ותגובה מהירה יותר. בשני המקרים יש מדריך תקלות כתוב וגיבוי שנבדק, כך שגם מי שאינו מומחה יודע מה לעשות. את זמני התגובה ותנאי הכוננות מגדירים מראש ובכתב, לפי מה שהעסק שלכם באמת צריך. אם העסק שלכם תלוי בשירות פעיל כל הזמן, אפשר גם להוסיף זמינות כפולה, כך שתקלה בשרת אחד לא תפיל את השירות כולו.

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