תשתית ענן ב-Selectel: אוטומציה ו-IaC

תשתית הענן של Selectel: היכן זה נשבר

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

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

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

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

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

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

מה משתנה לאחר העברת השירותים לענן מנוהל

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

ב-Selectel זה מתיישב על המשאבים המקוריים של הספק — רשתות, מאזני עומסים וקלאסטרים מתוארים באותם קבצים של האפליקציה.

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

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

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

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

אפשרויות פריסה: תשתית ענן או שרתים משלכם

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

מכונות וירטואליות משלכם נותנות גישה מלאה למערכת ההפעלה ולרשת, אבל עדכונים, גיבויים וניטור נשארים באחריותכם.

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

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

סדר העבודה: מהאודיט ועד למסירה לתפעול

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

1. אודיט תשתית. עורכים מיפוי של מה רץ היכן, אילו שירותים מקושרים זה לזה, היכן נותרו פעולות ידניות ונקודות כשל בודדות. בפלט — מפת מצב נוכחי עם רשימת סיכונים וסדרי עדיפויות.
2. סכמת רשת וסביבת יעד. מקבעים סגמנטציה, כללי גישה, ניתוב בין סאבנטים וגיבויים. הסכמה מאושרת לפני תחילת ההגדרה, כדי לא לעצב מחדש את הסביבה תוך כדי.
3. תיאור הסביבה כקוד. הקונפיגורציה נשמרת בריפוזיטורי ולא בצ'קליסטים: הסביבה עולה מהתיאור ומשוחזרת אחד לאחד — סביבת הבדיקה משכפלת את הפרודקשן.
4. בדיקה תחת עומס. מריצים תרחישים בפרופיל שיא, בודקים זמן תגובה והתנהגות בעת כשל של צומת בודד. צווארי הבקבוק שמתגלים מטופלים לפני המעבר, ולא אחריו.
5. הגירת שירותים. מעבירים בקבוצות, החל מהלא-קריטיים, עם אפשרות חזרה לאתר הקודם. הנתונים מועברים עם בדיקת שלמות והשוואת סכומי ביקורת.
6. תיעוד. נהלי שחזור, סכמות, הוראות לצוות התורן וסדר ביצוע שינויים — מה שמאפשר לסביבה לחיות בלעדינו.
7. מסירה לתפעול. מוסרים הרשאות, מעבירים הדרכה לצוות, מקבעים אחראים על השינויים. בהמשך נשארים בקשר לצורך שדרוגים מתוכננים.

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

ערכת המסירה: סכמות, מדיניות גישה, נהלים

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

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

מקרה בוחן: העברת שירותים בלי עצירת העבודה

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

החזרה לאחור אחרי שחרור כושל פירושה פריסת סנפשוט והגדרה ידנית משלימה — כלומר שעות של השבתה ברגע הגרוע ביותר.

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

מדדים לפני ואחרי

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

מה עושים אם חלק מהשירותים כבר על משאבים משלכם?

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

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

נקודת כניסה אחת מסירה את הקושי המרכזי של ההיבריד: האפליקציה לא צריכה לדעת על איזה אתר חי חלק שלה. בכניסה שמים מאזן עומסים עם בדיקות זמינות, ומאחוריו — שירותים משני האתרים; TTL קצר ב-DNS מעביר את התעבורה לאתר החדש בתוך דקות. מערכות פנימיות ומשתמשים פונים לכתובת אחת, ולכן המעבר לא מחייב שינויים בצד שלהם.

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

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

שאלות טכניות נפוצות: גישה, אבטחה, חזרה לאחור

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

מה יקרה לחשבונות שלנו אחרי הפרויקט?

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

איך בנויים הגיבויים והאם נבדק השחזור?

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

מהי תכנית השחזור לאחר תקלה?

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

היכן גבול האחריות של הקבלן?

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

נדון במשימה ונחזור עם הערכה ותכנית

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

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

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

תארו את המשימה בצורה חופשית — נחזור עם הערכה ותכנית.