הגדרת Azure: מדוע התשתית נשברת בעומסי שיא
כשל בעומס שיא לעתים רחוקות נראה כמו שרת שקרס. לעתים קרובות זו שרשרת: התעבורה גדלה — וצוואר הבקבוק של המערכת התברר לא באפליקציה, אלא בתשתית הענן שמסביבה.
סקיילינג אוטומטי לא מעלה צמתים חדשים, כי מכסת המנוי נבחרה עוד בזמן ניסויים ידניים, ומגבלות החיבורים של מאזן העומסים לא נבדקו מחדש על ידי איש.
הסיבה העיקרית היא בדרך כלל אחת — סביבה שנבנתה ידנית דרך הפורטל. ההגדרות חיות בממשק, ולא בתיאור התשתית, ותיקונים "על רגל אחת" לפני שחרור לא נכנסים לא למאגר התצורה ולא לגיבוי. כעבור חודש איש לא זוכר למה כלל חומת האש פתוח ולמה סביבת הבדיקות שונה מזו היצרנית.
היעדר יתירות מוסיף נקודת כשל שנייה: אזור זמינות אחד, בסיס נתונים ללא העתק, וסודות משוכפלים במשתני הבנייה. כאשר אתר נופל, השחזור מתחיל מאפס ונמשך שעות.
הרשאות מעורפלות משלימות את התמונה: לקבלנים ולמתמחים יש תפקידי מנהל מנוי, מפתחות גישה אינם מוחלפים, ויומני הפעולות לא נקראים עד לקרות תקלה. ביקורת סביבה כמעט תמיד חושפת עשרות הרשאות מיותרות וחשבונות ממשימות שנסגרו.
לכן הגדרת Azure מתחילה לא בהפעלת שירותים, אלא בביקורת הסביבה: מה באמת מחזיק את העומס, היכן התצורה סוטה מהתיאור ומה יקרה כאשר אתר נופל. בהמשך נסביר כיצד זה נסגר.
מה נותן סדר ברשת, בגישה וביתירות
אנו מחלקים את הרשת למקטעים מבודדים: אפליקציות, נתונים, סביבת ניהול. כללי ברירת המחדל אוסרים תעבורה, ואנו פותחים הרשאות נקודתית — עבור שירות ופורט ספציפיים. פגיעה בצומת אחד אינה פותחת עוד נתיב לאחרים, וסוג הכשל "דרך הפרימטר הגיעו לבסיס הנתונים" יוצא ממודל האיומים.
אנו מעניקים גישה לא לאנשים, אלא לקבוצות, לפי סט ההרשאות המינימלי הנדרש, והשירותים מאמתים זהות באמצעות זהויות מנוהלות במקום מפתחות בתצורה. אין מפתח לגנוב ואין למי לשכוח להחליף — נעלם סוג כשל נפרד בגלל הגדרות שהתפזרו בין הסביבות.
יתירות נבנית באמצעות אזורי זמינות והעתק של האחסון באזור שני. כשל של אזור זמינות או של אזור מפסיק להיות עצירת שירות: התעבורה מועברת לאתר חי, האפליקציה ממשיכה לעבוד במצב של פונקציונליות מופחתת, ולא מחזירה שגיאה לכולם.
זוהי ירידה מבוקרת במקום קריסה: תורים מחליקים את השיא, מטמון מחזיק את הקריאה, ומגבילי עומס לא נותנים לצרכן אחד להפיל את האחרים. זמן השחזור המוגדר נמדד בדקות, ואנו מתעדים אותו בתרגילים, לא במצגת.
ב-Microsoft Azure כל התצורה מתוארת באופן הצהרתי ונמצאת במערכת בקרת גרסאות, לכן הסביבה משוחזרת אחד לאחד בכל סביבה. פעם ברבעון אנו מכבים אזור שלם ובודקים את זמן השחזור בפועל: המספר לאחר כל הרצה כזו או שמאושר, או שהופך למשימה בספרינט הבא.
אפשרויות פריסת עומס: מכונות, מכולות, שירותים
בחירת אופן הפריסה קובעת לא רק את עלות התפעול, אלא גם אילו משימות נפתרות ללא כתיבה מחדש של האפליקציה. העברת עומס בין אפשרויות כמעט אף פעם אינה מעבר פשוט: משתנים מודל הכשל, אופן הסקיילינג ומי שאחראי על עדכון הסביבה. לכן אנו משווים את המצבים לפי התאמה ומגבלות — עבור פרופיל עומס ספציפי, ולא לפי הרגל.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| מכונות וירטואליות | נדרשת שליטה מלאה על הסביבה, ספריות מערכת משלכם או תוכנה ברישיון על ליבה ספציפית | סקיילינג ידני או חצי-אוטומטי, עדכוני מערכת הפעלה באחריותנו, השבתה בעת יצירה מחדש |
| מכולות באשכול מנוהל | שירות מרובה רכיבים, שחרורים תכופים, סקיילינג אופקי צפוי | דורש בניית אימג'ים בשלה וניטור, עומסים עם שמירת מצב יקרים יותר לתחזוקה |
| שירותים מנוהלים | תורים, מטמון, בסיסי נתונים, איזון עומסים — היכן שהפלטפורמה עצמה מספקת עמידות בכשלים וגיבויים | פחות שליטה על ההגדרות, תלות בפלטפורמה, מעבר חזרה יקר יותר |
| מתאר היברידי | חלק מהנתונים חייב להישאר באתר שלכם, חלק מועבר לענן | התקשורת בין המערכות הופכת לנתיב קריטי, מורכבים יותר הניתוב והאימות האחיד |
המגבלות חשובות יותר מהיתרונות. מכונות וירטואליות נותנות שליטה, אבל יחד איתה — עדכונים שגרתיים ותגובה איטית לשיאים. שירותים מנוהלים מסירים עומס תפעולי, אך מצמצמים את מרחב ההגדרות. מתאר היברידי עונה לדרישות לגבי מקום אחסון הנתונים, אבל השיהוי בתקשורת יורגש בכל שירות.
מתחילים במדידות: פרופיל הפניות, שיאים יומיים ועונתיים, דרישות לאחסון ולשחזור, רגישות לשיהויים. לאחר מכן מפרקים את הרכיבים לאפשרויות — חלק עובר לשירותים מנוהלים, חלק נשאר על מכונות או באשכול — ומתעדים מה בדיוק ישתנה עם גידול העומס.
סדר העבודות: מביקורת ועד מסירה לתפעול
סדר העבודות נקבע לא לפי הנוחות של הקבלן, אלא לפי סדר הופעת הסיכונים: עד שלא נאסף מלאי, כל תכנית היא ניחוש, והגדרת Azure ללא בדיקות אינה נחשבת לבוצעה. לכן סביבות נבנות לאחר אישור התכנית, והמסירה לתפעול — רק לאחר בדיקת השחזור.
- ביקורת המערכת. מלאי של מנויים, מקטעי רשת ושירותים: מה עובד, מי הבעלים, היכן יש שינויים ידניים והיכן אין גיבויים. התוצר — מפת תלויות ורשימת סיכונים לפי עדיפות.
- תרשים תשתית. מצב יעד: גבולות של מנויים וקבוצות משאבים, פילוח רשת, נקודות יציאה, תפקידי גישה והפרדת סביבות. מאשרים לפני ההגדרה — תיקון תרשים זול מתיקון מערכת פעילה.
- הגדרת סביבות. פיתוח, בדיקות ופרודקשן נוצרים מתיאורים הצהרתיים לפי תבנית אחת. פרמטרים וסודות נשמרים בנפרד, ותיקונים ידניים במסוף אינם אפשריים.
- ניטור והתראות. אוספים מדדים ויומנים, מגדירים ספים ומסלולי התראות. התפעול מתחיל עם כללי תגובה מוכנים, לא בעיוורון.
- בדיקת שחזור. מריצים תרחישי כשל: אובדן צומת, אי-זמינות של מקטע, שחזור מגיבוי לסביבה נקייה. מתעדים את זמן השחזור בפועל.
- מסירה לתפעול. מוסרים גישות, תיעוד ונהלים, ומאמנים את הצוות: תקלות אופייניות, סדר הסלמה, נקודות בקרה.
מה נשאר אצלכם: תרשימים, מדיניות, נהלים
מערכת שנשענת על הסכמים בעל פה חיה עד עזיבת היוצר. לכן לקראת סיום העבודות אנו אוספים סט ארטפקטים, שלפיו הצוות שלכם או קבלן חיצוני יכול להקים את הסביבה, לנתח תקלה ולשנות תצורה בלעדינו. הכל נשמר במאגר שלכם ותחת חשבונות המשתמש שלכם ב-Microsoft Azure.
- תיעוד תשתית — תרשים של מנויים, קבוצות משאבים ורשת עם כתובות תת-רשת ונקודות חיבור למערכת המקומית.
- תצורה כקוד — מודולי תיאור של משאבי מחשוב, אחסון ואיזון עומסים עם רשימת קלטים וסדר יישום.
- תרשימי יתירות — אזורי זמינות, יעדי שחזור, לוח זמנים לגיבויים ותרחיש חזרה מאומת.
- נהלי גישה — תפקידים ותחומי פעולתם, הרשאות מינימליות, סדר הענקה ובחינה מחדש של הרשאות, חשבונות שירות נפרדים במקום אישיים.
- תיאור תפקידים — בעל המערכת, תורן, מי שמאשר שינויים בסביבת הייצור, וגבולות אחריות התמיכה.
- הוראות לתמיכה — אבחון תקלות אופייניות, היכן לחפש ביומנים ובמדדים, סדר פעולות בעת ירידה והסלמה.
- ניטור ויומן החלטות — בדיקות זמינות עם ספי התראה, החלטות שהתקבלו ומשימות שנדחו במודע.
תיעוד אינו נכתב "לשם התיקייה": את המסירה אנו מבצעים כקבלה — את הסביבה מקימים לפיו ללא רמזים מאיתנו.
מקרה בוחן: העברת שירות לענן ללא עצירת עבודה
שירות עם תעבורה יומית התנהל על שחרורים ידניים: בניות הופעלו מתחנת העבודה של המהנדס, הגישה לסביבה ניתנה דרך חשבון משותף, והחזרה לאחור נעשתה ידנית לפי הוראה פנימית. השחזור לאחר תקלה ארך שעות: סדר הפעולות היה בראש של אדם אחד, והעתק התצורה לא עודכן.
מה היה לפני המעבר
שחרור ארך 40–60 דקות ודרש חלון לילה — השירות הופסק בזמן הזה. גישה משותפת אפשרה לשנות את סביבת הייצור בלי לשים לב: לאחר תקלה איש לא יכול היה לומר מי ומה שינה לאחרונה. כשל בבסיס הנתונים שוחזר תוך 4–6 שעות, ואיבדו נתונים של היממה האחרונה.
כיצד הועבר ומה השתנה
הסביבה נפרסה ב-Microsoft Azure לפי גישת "תשתית כקוד": סביבות עולות מתיאור, ותיקונים ידניים בלוח הבקרה אסורים. הגישה חולקה לפי תפקידים — בונה, אחראי שחרור, תורן; כל שינוי עובר בדיקה ומשאיר עקבות ביומן.
המעבר התבצע במקביל לעבודה: התעבורה הועברה בהדרגה, החלקים גדלו לפי מדדים, והמערכת הישנה נשמרה מוכנה עד לאישור היציבות. הגיבויים וההעתק הועברו לאזור נפרד, והשחזור תורגל בתרגילים.
לסיכום: שחרור — 6 דקות ללא עצירת השירות, חזרה לאחור — פקודה אחת, שחזור לאחר כשל — 20–25 דקות, אובדן נתונים — לא יותר מ-5 דקות, ושיעור השינויים תחת בדיקות אוטומטיות עלה מ-20% ל-95%.
הגדרת Azure מאפס או העברת מערכת קיימת
הגישה נבחרת לפי מצב המערכת, לא לפי טעם: מערכת נקייה בונים כשאין עדיין עומס; העברת מערכת קיימת — כשהמוצר עובד והשבתה אינה אפשרית; מצב היברידי — כשחלק מהנתונים חייב להישאר באתר שלכם. בהמשך — במה התרחישים נבדלים ברמת העבודה והיכן כל אחד נתקל במגבלות.
במערכת נקייה מתכננים קודם כל רשת והרשאות, ולא מכונות: מקטעים מבודדים, אימות אחיד, מנויים נפרדים לכל סביבה, כדי שסביבת הפיתוח לא תגיע לנתוני הייצור. אם השכבה הזו מוגדרת מיד, משאבים נוספים מתווספים בלי בנייה מחדש, והפרדת הגישות נשארת ניתנת לניהול.
העברת מערכת קיימת מתחילה במלאי ובשכפול ניסיוני בסביבה מבודדת: משווים התנהגות, ואז מעבירים את התעבורה. מגבלות ההעברה — תלות בחומרה ספציפית, רישיונות לאתר, מערכות הפעלה מיושנות ושירותים ששומרים מצב בזיכרון ולא שורדים כיבוי מסודר. צמתים כאלה מועברים עם עיבוד מחדש, לא בהעתקה.
מצב היברידי משמעו שחלק מהעומס נשאר באתר שלכם; אז התקשורת המקשרת היא קריטית — ספריית משתמשים אחידה, פתרון שמות, ניתוב צפוי ומדיניות גישה זהה משני הצדדים. השיהוי בין המערכות קובע אילו שירותים הגיוני להפריד.
הגדרת Microsoft Azure בכל אחד משלושת התרחישים הולכת לפי עיקרון אחד: קודם גבולות, אחר כך עומס. בחירת הגישה קובעת את לוחות הזמנים ואיזה סוג כשל יישאר — השבתה מלאה או כשל במקטע אחד.
ספקות טכניים נפוצים: גישה, רשת, יתירות
הספקות של מהנדס לפני התחלה הם בדרך כלל אותם ספקות: מי ואיך מקבל גישה, כיצד להגביל את הרשת, במה נבדלות הסביבות ומה יקרה בעת כשל. אם אין תרשים מצב נוכחי, מתחילים במלאי — אבל את התשובות הבסיסיות עדיף לתעד מיד.
כיצד בנוי ניהול הגישות כשמדובר בעשרות אנשים?
הרשאות ניתנות לקבוצות, לא לאנשים: עובד נכנס לקבוצה — מקבל תפקיד, יוצא — מאבד. עבור שירותים אנו משתמשים בזהויות מנוהלות, לכן מפתחות לא נמצאים בתצורה. שלילת גישה אורכת דקות, וכל הפעולות נרשמות ביומן.
עד כמה ניתן להקשיח את הגבלת הרשת?
בסיסי נתונים ושירותים פנימיים אנו ממקמים בתת-רשתות פרטיות — הם כלל לא חשופים החוצה. נקודות ציבוריות נשארות רק לתעבורה חיצונית ומאובטחות בכללים ורשימות כתובות. מערכת היברידית מחוברת במנהרה מאובטחת לרשת המשרדית, ללא יציאה לאינטרנט הפתוח.
כיצד מופרדות הסביבות כדי שהבדיקות לא יפגעו בייצור?
מערכת הבדיקות מופרדת מזו היצרנית: קבוצות משאבים, מדיניות ומכסות משלה. בייצור אין גישה ידנית ישירה — שינויים עוברים בשחרורים אוטומטיים עם בדיקות. זה מסיר סוג כשל שבו ניסוי מפיל את שירות הייצור.
כיצד נבדקים גיבוי ושחזור נתונים?
המדיניות קובעת את תדירות הגיבויים ותקופת השמירה עבור בסיסי נתונים, דיסקים ותצורות. העיקר אינו קיום הגיבויים, אלא שחזור מאומת בסביבה נפרדת: מתעדים את זמן היעד ואת נקודת אובדן הנתונים ובודקים אותם בכשל תרגילי.
נדון במשימה ונחזור עם הערכה ותוכנית
שיחה עניינית מתחילה בנתוני מוצא, ולא בבריף של ארבעים עמודים. להגדרת סביבה בענן די במה שכבר יש לכם בהישג יד — את השאר המהנדסים שלנו יאספו בעצמם ויבהירו תוך כדי דיון במשימה.
- תרשים המערכת הנוכחית: אילו שירותים פועלים, היכן הם ממוקמים, מה כבר הועבר לענן ומה נשאר בתשתית שלכם.
- דרישות לסביבות: האם יש צורך במערכות נפרדות לפיתוח, בדיקות ותפעול ייצור, והאם עליהן להיות זהות בתצורה.
- פרופיל עומס: ערכי שיא, קפיצות עונתיות, דרישות לזמן תגובה ומצב זמינות יעד.
- כללי גישה והפרדת תפקידים: מי ולפי איזה מודל מקבל גישה למשאבים, והאם יש דרישות לתיעוד פעולות ולשמירת יומנים.
- מגבלות ומסגרות: תאריכים קשיחים, חלונות תחזוקה, דרישות רגולטוריות, התחייבויות קיימות כלפי ספקים.
- מהנדס אחראי מטעמכם, שמאשר החלטות ומקבל את תוצרי השלבים.
בתגובה תקבלו הערכת היקף עבודה עם פירוט לפי שלבים, תוכנית יישום עם סדר ותלויות, הרכב העבודות — מה אנחנו סוגרים ומה נשאר באחריותכם — ורשימת בדיקות המאשרות את מוכנות כל שלב. אם יש עדיין מעט נתונים, נתחיל במלאי: תארו את המשימה, ונחזור עם הערכה ותוכנית.