מערכות הייצור אינן מורשות להיעצר. הפלטפורמה הפיננסית שמעבדת עסקאות בשעה 2 לפנות בוקר, מערכת רישומי הבריאות המשרתת רופאים באזורי זמן שונים, אפליקציית הלוגיסטיקה שעוקבת אחר משלוחים בין יבשות: לאף אחת מהן אין חלון תחזוקה זמין לספיגת מאמץ של שיפוץ. עם זאת, כולן צוברות חוב טכני, נושאות החלטות ארכיטקטורה שהתקבלו תחת אילוצים קודמים, ובסופו של דבר דורשות שינוי מבני כדי להישאר ניתנות לתחזוקה, ניתנות להרחבה ובטוחות. שיפוץ ללא זמן השבתה הוא התחום שפותר את המתח הזה: פיתוח מערכת חיה מבלי להפריע לשירות שהיא מספקת.
מודרניזציה ללא זמן השבתה
שדרגו את היישומים שלכם בזמן הייצור עם שליטה ודיוק ברמה ארגונית
לגלות SMART TS XLהאתגר אינו טכני בלבד. הוא ארגוני וארכיטקטוני. עיבוד מחדש של מערכת שלא יכולה לצאת מהרשת דורש מודל מנטלי שונה מאשר עיבוד מחדש של מערכת בפיתוח: כל שינוי חייב להיות תואם לאחור עד שאינו כזה, כל מעבר מבני חייב להיות הפיך, כל אימות חייב להתרחש מול תעבורה אמיתית ולא מול בדיקות סינתטיות. הטכניקות המאפשרות זאת, כולל פריסות כחול-ירוקות, החלפת תכונות, תבנית תאנה של חנק, הגירת מסדי נתונים מסוג הרחבה-הצטברות וארכיטקטורות מונחות אירועים אידמפוטנטיות, מתועדות היטב כל אחת בנפרד. מה שפחות מטופל הוא כיצד הן פועלות יחד כאסטרטגיה קוהרנטית לשינוי מבני בר-קיימא ובטוח במערכות שחייבות לשרת משתמשים לאורך כל התהליך.
כיצד הארכיטקטורה שלך צריכה להיראות עבור שינויים ללא זמן השבתה
השאלה הנפוצה ביותר שצוותים שואלים כאשר הם מתחייבים לשיפוץ מחדש ללא זמן השבתה היא השאלה הארכיטקטונית: מה צריך להשתנות באופן שבו המערכת בנויה לפני שהשיפוץ מחדש עצמו יכול להתחיל? התשובה אינה תבנית אחת אלא קבוצה של תכונות מבניות שמערכת חייבת להציג לפני ששיפוץ מחדש בזמן אמת יהיה בטוח. הבנת תכונות אלו היא תנאי הכרחי לכל שאר ההוראות במדריך זה.
המאפיין הראשון הוא פריסה עצמאית. כל רכיב שיעבור שיפוץ חייב להיות ניתן לפריסה מבלי לדרוש פריסה סימולטנית של התלויות שלו. אם שינוי שירות A דורש שינוי סימולטני של שירות B ושירות C כדי למנוע תקלה, אז פריסה ללא זמן השבתה של A היא בלתי אפשרית מבחינה מבנית: שלושת השירותים הם למעשה יחידת פריסה אחת ללא קשר למספר המאגרים בהם הם נמצאים. פריסה עצמאית דורשת ממשקים תואמים לאחור, חוזי גרסאות וביטול דרישות פריסה מתואמות בין שירותים.
המאפיין השני הוא הפיכות. כל פריסה שמשנה את ההתנהגות בזמן אמת חייבת להיות הפיכה תוך דקות, לא שעות. הפיכות אינה רק עניין של שמירה על הקובץ הבינארי הישן זמין. היא דורשת שמצב מסד הנתונים, מצב המטמון, מצב ההפעלה וכל מצב מערכת חיצוני שמשתנה על ידי הגרסה החדשה יהיו תואמים לגרסה הישנה. אם גרסה חדשה כותבת נתונים בפורמט שהגרסה הישנה אינה יכולה לקרוא, אזי הפריסה היא בלתי הפיכה מעצם הגדרתה, ואפס זמן השבתה אינו אפשרי מכיוון שכל חזרה למצב קודם תייצר שגיאות.
המאפיין השלישי הוא מעברי מצב נצפים. מאמץ של רפקטורינג שמעביר התנהגות מנתיב קוד אחד לאחר ללא מדדים נצפים בשני הנתיבים פועל בצורה עיוורת. הצוות אינו יכול לדעת אם המעבר מצליח או נכשל, אינו יכול לזהות רגרסיות מוקדם, ואינו יכול לקבל החלטות מבוססות נתונים לגבי מתי להאיץ או לעצור את ההעברה. יש לעבד את יכולת הנצפות לפני תחילת הרפקטורינג, לא להוסיף אותה לאחר שבעיה צצה. כפי שנבחן בהקשר של רכישת מחדש מצטברת וחוב טכני, הנראות המבנית של מה שקוד עושה ומה תלוי בו היא הבסיס לתכנון כל שינוי שלא יכול להרשות לעצמו להיכשל בתהליכי הייצור.
פריסה כחולה-ירוקה: דפוס הבסיס
פריסה כחולה-ירוקה היא הדפוס הבסיסי למהדורות ללא זמן השבתה. קיימות שתי סביבות ייצור זהות: הסביבה הכחולה המשרתת תעבורה חיה והסביבה הירוקה המקבלת את הגרסה החדשה. הגרסה החדשה נפרסת, נבדקת ומאומתת בסביבה הירוקה בעוד שהסביבה הכחולה ממשיכה לשרת משתמשים ללא הפרעה. כאשר הסביבה הירוקה מאומתת, התעבורה מועברת באופן אטומי. החזרה למצב הפוך היא ההפך: החזרת התעבורה לכחול, שנשארת זמינה לכל אורך הדרך.
הדפוס נשמע פשוט. הקושי שלו טמון בשכבת מסד הנתונים. כאשר שתי הסביבות חייבות לקרוא ולכתוב לאותו מסד נתונים, סכמת מסד הנתונים חייבת להיות תואמת לשתי הגרסאות בו זמנית. הגירה שמסירה עמודה, משנה שם של שדה או משנה סוג נתונים שוברת את הסביבה הישנה ברגע שהיא מופעלת. זו הסיבה שפריסה כחולה-ירוקה היא חלק בלתי נפרד מדפוס הגירת סכימה מסוג הרחבה-הצטמצמות המתואר בסעיף מסד הנתונים במדריך זה.
מהדורות קנרי וטכניקות השקה מדורגות
מהדורות קנרי מרחיבות את המודל הכחול-ירוק על ידי ניתוב אחוז מסוים מהתנועה לגרסה החדשה במקום להעביר את כל התנועה בבת אחת. פריסת קנרי עשויה להתחיל באחוז אחד מהמשתמשים, לבחון שיעורי שגיאות, השהייה ומדדי עסקיים עבור קבוצה זו, ולאחר מכן להגדיל בהדרגה את האחוז: חמש, עשרים, חמישים, מאה. בכל שלב, שערים אוטומטיים בודקים שמדדים מרכזיים לא ירדו מעבר לספים שהוגדרו. אם שער נכשל, הפריסה נעצרת ואחוז הקנריים מצטמצם בחזרה לאפס.
טכניקות פריסה מדורגות מוסיפות היגיון מיקוד להתקדמות זו. במקום ניתוב לפי אחוז בלבד, ניתן לפלח את התנועה לפי קבוצת משתמשים, אזור גיאוגרפי, רמת מנוי או מאפייני סשן. זה מאפשר לאמת את הגרסה החדשה מול אוכלוסיית המשתמשים הספציפית שלומדת עליה הכי הרבה לפני שאוכלוסייה זו מועברת במלואה. הדרישה המרכזית היא שתשתית הניתוב, בין אם מאזן עומסים, שער API או רשת שירותים, תתמוך ברמת המיקוד הנדרשת על ידי הפריסה.
יש להגדיר את המדדים השולטים בשערי קנרי לפני תחילת הפריסה. שיעור שגיאות, השהיית p99, זמן שאילתת מסד נתונים ומדדים ספציפיים לעסק כגון שיעור המרה או שיעור הצלחה בתשלום הם כולם קריטריונים תקפים לשער. יש לכייל את ספי השער מול קו בסיס הנמדד מהגרסה הקיימת תחת עומס דומה, ולא מול יעדים תיאורטיים. פריסה שעוברת שער בשני אחוזים מהתנועה אך נכשלת בעשרים אחוז לא אומתה: הקנרי היה קטן מדי מכדי להיות מייצג. פריסה מדורגת נכונה דורשת חשיפה מספקת לתנועה בכל שלב כדי לייצר השוואה בעלת משמעות סטטיסטית.
מתגי הפעלה וכיבוי של תכונות
כפתורי הפעלה (toggles) של תכונות (feature toggles) מנתקים את הפריסה של קוד מהפעלת התנהגות. נתיב קוד שעבר שיפוץ נפרס במצב לא פעיל, ונשלט על ידי כפתור שקובע אילו משתמשים או בקשות מבצעים את הלוגיקה החדשה. ניתן להפעיל את הלחצן באופן הדרגתי, למקד אותו לקבוצות ספציפיות, או להפוך אותו באופן מיידי ללא פריסה מחדש. זה הופך את כפתורי ההפעלה (toggles) של תכונות למנגנון העיקרי להגירה ללא זמן השבתה של לוגיקה עסקית, בניגוד לשינויים בתשתית שבהם דפוסים כחולים-ירוקים או קנריים מתאימים יותר.
מתגי השבתה (kill switches) הם המקבילה ההגנתית למתגי תכונה (feature toggles): מתגי השבתה שמטרתם אינה לאפשר התנהגות חדשה אלא להשבית אותה באופן מיידי אם היא מתנהגת בצורה לא תקינה. מתג השבתה בחישוב חיוב שעבר שחזור, זרימת אימות חדשה או שכבת גישה לנתונים חלופית מעניק למהנדס תורן נתיב שחזור בפעולה אחת שאינו דורש פריסה, חזרה למצב מסד נתונים או תיאום בין-צוותי. יש להגדיר את מתג ההשבתה במערכת המאפשרת את הפעלתו באמצעות קריאה ל-API, קונסולת ניהול דגלי תכונות או שילוב התראות אוטומטי, כך שהשהיית ההפעלה תהיה שניות ולא דקות.
היגיינת Toggles היא דאגה תפעולית אמיתית. Toggles שמעולם לא מנוקים מצטברים בבסיס הקוד, מה שמקשה יותר ויותר על ההיגיון בנוגע לזרימת הבקרה ויוצר תלות מרומזת בין מצב ה-toggle למצב הנתונים. לכל toggle צריך להיות בעלים מתועד, תאריך תפוגה מתוכנן וכרטיס ניקוי. חוב Toggle הוא אמיתי כמו כל צורה אחרת של חוב טכני, והוא מצטבר מהר יותר מכיוון ש-togles בדרך כלל מגנים על החלקים המשתנים ביותר במערכת.
שיפוץ מסד נתונים ללא זמן השבתה
שינויים במסד נתונים הם החלק הקשה ביותר בשיפוץ מסד נתונים ללא זמן השבתה, מכיוון שמסדי נתונים הם בעלי מצב (stateful), משותפים ואיטיים לשינוי בקנה מידה גדול. ניתן לפרוס את האפליקציה ולבצע שינוי חוזר תוך דקות. העברת מסד נתונים שמשנה טבלה עם מאות מיליוני שורות עשויה להימשך שעות, לא ניתן לבטלה בקלות לאחר ביצוע הביצוע, ומחזיקה נעילות שחוסמות קריאה וכתיבה למשך הזמן. ביצוע נכון של שיפוץ מסד נתונים דורש גישה שונה משיפוץ קוד יישום, ורוב הצוותים מגלים זאת בפעם הראשונה שהם מנסים לשנות סכימה בטבלה חיה עם תעבורה גבוהה.
העיקרון המרכזי הוא שכל שינוי במסד הנתונים חייב להיות תואם לאחור עם הגרסה הקודמת של האפליקציה עד שהגרסה הקודמת כבר לא נפרסת. זה נשמע מובן מאליו אך יש לו השלכות שאינן ברורות מאליהן. שינוי שם של עמודה דורש הוספת השם החדש ככינוי או ככפיל לפני שניתן להסיר את השם הישן. שינוי סוג עמודה דורש עמודת צל של הסוג החדש המאוכלסת במקביל לפני שניתן להוציא את העמודה הישנה משימוש. מחיקת טבלה דורשת אישור שאף גרסה פרוסה של האפליקציה לא קוראת ממנה. כל אחת מפעולות אלה היא תהליך רב-שלבי המתפרס על פני פריסות מרובות, לא הגירה אחת שפועלת פעם אחת. כפי שנדון בהקשר הרחב יותר של שיפוץ COBOL על פני מבני נתונים מדור קודם, האתגר של התפתחות מבני נתונים המשותפים על פני מספר תוכניות ומערכות ללא מעבר מתואם הוא אחד הקשיים המובהקים של שיפוץ בקנה מידה ארגוני.
דפוס ההתרחבות-התכווצות
תבנית ההרחבה-החוזה ממסדירה את הגישה הרב-שלבית לשינויי סכימה. בשלב ההרחבה, אלמנטים חדשים בסכימה מתווספים באופן אדיטיבי: עמודה חדשה לצד הישנה, טבלה חדשה לצד הישנה, אינדקס חדש לצד הישן. היישום מתעדכן לכתיבה גם למבנה הישן וגם למבנה החדש, אך ממשיך לקרוא מהמבנה הישן. לא אובדים נתונים, לא קיימות מעברי שאילתה, והגרסה הישנה של היישום ממשיכה לתפקד מכיוון שאלמנטים הישנים בסכימה עדיין קיימים.
בשלב ההתכווצות, המתרחש בפריסה נפרדת לאחר שהגרסה החדשה נפרסת ומאומתת במלואה, רכיבי הסכימה הישנים מוסרים. בשלב זה, אף גרסה פעילה של האפליקציה אינה תלויה בהם. ההסרה בטוחה מכיוון שהיא אומתה באמצעות תצפית ולא נלקחה בחשבון באמצעות תכנון.
דפוס ההרחבה-החוזה דורש משמעת בנוגע לרצף הפריסה. יש לפרוס את העברת מסד הנתונים שמוסיפה את העמודה החדשה לפני גרסת היישום שכותבת אליה. יש לפרוס את העברת מסד הנתונים שמסירה את העמודה הישנה לאחר שכל גרסאות היישום שקוראות ממנה יוצאות משימוש. דרישות הריצוף הללו צריכות להיות מקודדות בצינור הפריסה כך שלא ניתן יהיה להחיל העברות בסדר לא נכון.
כלים לעיבוד מחדש של צינורות נתונים מדור קודם מבלי לכתוב מחדש קוד
צינורות נתונים מדור קודם, במיוחד אלו הבנויים על מסגרות עיבוד אצווה, כלי ETL או תנועת נתונים מבוססת מיינפריים, מייצגים אתגר ספציפי: הם משנים ומעבירים נתונים ברציפות, לא ניתן לעצור אותם למשך ההגירה, ולעתים קרובות הם אינם מתועדים מספיק עד כדי כך שההיקף המלא של מה שהם עושים אינו ידוע עד שמשהו נשבר. עיבוד מחדש של צינורות אלה ללא כתיבה מחדש מלאה דורש כלים שיכולים לצפות מה הצינור עושה כעת, לאמת שהגרסה המחודשת מייצרת פלט שווה ערך, ולאפשר את המעבר להיות מדורג ולא פתאומי.
לכידת נתוני שינויים היא הכלי הרחב ביותר לשימוש בשיפוץ צינורות בזמן אמת. מערכת CDC לוכדת כל פעולת כתיבה בטבלת מקור כזרם אירועים, מה שמאפשר להזין גם את הצינור הישן וגם צינור חלופי חדש מאותו מקור מבלי לשנות אף אחד מהם. הצינור הישן ממשיך לפעול, הצינור החדש מופעל במקביל כנגד אותו זרם אירועים, והפלטים מושווים. פערים מזהים את לוגיקת הטרנספורמציה שלא יושמה מחדש כהלכה. כאשר אושרה הזוגיות, הצינור הישן מושבת.
כלי הגירת סכמות, כולל Liquibase ו-Flyway, מספקים הגירות גרסאות ורצפות שניתן להחיל אותן באופן הדרגתי ולבטל אותן בשילוב עם שיטות הרחבה-חוזה. הם עוקבים אחר ההגירות שהוחלו על כל סביבה ומונעים יישומים שאינם בסדר הנכון. עבור צינורות מדור קודם הפועלים על מיינפריים או מאגרי נתונים מבוססי VSAM, המקבילה מנוהלת באמצעות הרחבת JCL וניהול נתונים אשר שולט באופן שבו תוכניות ניגשות לנתונים במהלך המעבר, ומבטיח שהתוכנית הישנה וגם לא החדשה יפעלו על רקע פריסת מערך נתונים לא תואמת.
כיצד לחדש את מסדי הנתונים הישנים ללא זמן השבתה
האתגר הספציפי של מודרניזציה של מסד נתונים מדור קודם, מעבר מסכימת DB2 של מיינפריים למסד נתונים יחסי בסביבה המתארחת בענן, מעבר ממבנה VSAM מבוסס קבצים לסכימה יחסית, או איחוד מספר מסדי נתונים מדור קודם למאגר מאוחד חדש, דורש יישום של כל הטכניקות הנ"ל ברצף לאורך תקופה ממושכת.
הגישה שעובדת באופן עקבי היא: להתחיל עם זוגיות קריאה, לאחר מכן להשיג זוגיות כתיבה, לאחר מכן להעביר קריאות, לאחר מכן להעביר כתיבות, ולאחר מכן להוציא את האחסון הישן משימוש. זוגיות קריאה פירושה שהאחסון החדש מכיל את כל הנתונים שהאחסון הישן מכיל ויכול לשרת את כל השאילתות שהיישום מבצע. זוגיות כתיבה פירושה שכל כתיבה שהיישום מבצע לאחסון הישן מוחלת גם על האחסון החדש, בין אם באמצעות כתיבות כפולות ביישום ובין אם באמצעות שכפול CDC. לאחר ששני תנאי הזוגיות מאושרים תחת עומס ייצור, ניתן להעביר קריאות לאחסון החדש (לאימות פלטים), לאחר מכן ניתן להעביר כתיבות, ולאחר מכן ניתן להוציא את האחסון הישן משימוש.
בשום שלב ברצף זה אין הפרעה לשירות. בכל שלב, ניתן לשחזר את המצב הקודם על ידי העברת קריאות או כתיבות חזרה למאגר הקודם. משך כל שלב נקבע על ידי הביטחון שנוצר על ידי האימות, ולא על ידי תאריך לוח שנה קבוע.
כלים לשיפוץ מערכות מדור קודם מבלי לשכתב קוד
כתיבה מחדש של מערכת מדור קודם מאפס היא כמעט תמיד יקרה ומסוכנת יותר מאשר עיבוד מחדש הדרגתי שלה. כתיבה מחדש מלאה דורשת שמירה בו זמנית על המערכת הישנה בתהליך ייצור תוך בניית מערכת תחליפית בעלת פונקציונליות דומה, ניהול פער שוויון התכונות בין השתיים, וביצוע חיתוך (cutover) שהוא למעשה פריסה ללא זמן השבתה של מערכת שונה לחלוטין. רוב הארגונים שמנסים כתיבה מחדש מלאה מגלים, באמצע הדרך, שהמערכת הישנה הכילה התנהגות שלא תיעדו, שהמערכת החלופית עדיין לא משכפלת, ושהמשתמשים מסתמכים עליה.
שיפוץ מצטבר עם הכלים הנכונים נמנע מלכודת זו על ידי הפיכת המערכת הישנה לקריאה לפני שינוי בה. נקודת המוצא היא ניתוח מבני: הבנת מה כל רכיב במערכת הקיימת עושה, מה תלוי בו ובמה הוא תלוי. ניתוח זה לא יכול להתבצע על ידי קריאת תיעוד (שבדרך כלל חסר או לא מדויק במערכות מדור קודם) או על ידי קריאת קוד ידנית בקנה מידה גדול. זה דורש כלים אוטומטיים שמנתחים את הקוד הקיים, בונים גרף תלות והופכים את הגרף הזה לניתן לשאילתה. כפי שתואר בהקשר של ניהול אתגרי שילוב מערכות מדור קודם, הצעד הראשון בכל תוכנית שיפוץ מדור קודם הוא ביסוס נראות מבנית שאינה קיימת באף ארטיפקט המתוחזק על ידי אדם.
תבנית תאנת החונק למונוליתים
תבנית ה-strengler fig היא האסטרטגיה האדריכלית הדומיננטית להחלפה הדרגתית של מונולית ללא כתיבה מחדש מלאה או אירוע חיתוך. פונקציונליות חדשה נבנית כשירותים עצמאיים לצד המונולית. שכבת ניתוב, בדרך כלל שער API או פרוקסי הפוך, מיירטת בקשות נכנסות ומנתבת אותן למונולית או לשירות החדש בהתבסס על כללי ניתוב. המונולית ממשיך לשרת את כל התעבורה שטרם הועברה. השירות החדש מטפל רק בתעבורה המנותבת אליו במפורש.
עם הזמן, מתווספים עוד כללי ניתוב. נתיבים נוספים מופנים לשירותים חדשים. המונולית מטפל בפחות ופחות מהתעבורה הכוללת. בסופו של דבר, המונולית לא מטפל בכלום, וניתן להוציא אותו משימוש. אף פריסה בודדת במהלך תהליך זה אינה גדולה מספיק כדי לייצג סיכון משמעותי. כל שינוי בכלל ניתוב ניתן לבדיקה באופן אינדיבידואלי והפיך באופן אינדיבידואלי. איור החנק אינו טכניקה לטרנספורמציה מהירה: זוהי טכניקה לטרנספורמציה בטוחה לאורך שבועות, חודשים או שנים, תלוי במורכבות המערכת החנוקה.
דרישת היישום הקריטית עבור תבנית Strangler Fig היא ששכבת הניתוב תהיה מנותקת הן מהמונולית והן מהשירותים החדשים. שכבת ניתוב המוטמעת במונולית אינה יכולה לנתב תעבורה הרחק מהמונולית. ה-Proxy חייב לשבת מול שניהם, ולהיות מסוגל לכוון תעבורה לכל אחד מהם בהתבסס על תצורה שניתן לשנות מבלי לשנות את המונולית או את השירות החדש.
שינוי פקטורינג של ממשקי API מדור קודם לשירותי ענן מקוריים ללא זמן השבתה
העברת API מדור קודם לחלופה לענן היא יישום ספציפי של תבנית Strangler Fig עם אילוצים נוספים: ל-API מדור קודם עשויים להיות צרכנים שלא ניתן לעדכן בו זמנית, יש לשמור על חוזה ה-API לאורך המעבר, ולחלופה הענן עשויים להיות מאפייני ביצועים שונים המשפיעים על צרכנים בדרכים בלתי צפויות.
הגישה הסטנדרטית היא לפרוס את ההחלפה המקורית לענן מאחורי אותו חוזה API כמו ה-API הקודם, לנתב אחוז מסוים מהתנועה להחלפה באמצעות טכניקות קנריות, לאמת את שוויון הפלט עבור אחוז תנועה זה, ולהגדיל בהדרגה את אחוז הניתוב. צרכנים אינם צריכים לשנות דבר במהלך מעבר זה מכיוון שחוזה ה-API נשמר. שכבת הניתוב מטפלת במעבר בצורה שקופה.
ניתוק ללא זמן השבתה מאינטגרציות ליבה לממשקי API של תוכנות ביניים, המופיע כשאילתה בעלת כוונה גבוהה בנתוני Search Console עבור מאמר זה, הוא בדיוק התרחיש הזה: הרגע שבו שכבת הניתוב מתעדכנת כדי להפנות מאה אחוז מהתנועה למערכת החדשה וממשק ה-API הישן מושבת. ניתוק זה לעולם לא צריך להיות אירוע אטומי יחיד. זה צריך להיות השלב הסופי בפריסה הדרגתית שכבר אימתה את המערכת החדשה באחוזי תנועה גבוהים יותר ויותר. עד שהניתוק הסופי מתרחש, המערכת החדשה כבר טיפלה בנפח התנועה המלא; הניתוק רק מסיר את נתיב החלופי שכבר אינו נחוץ.
אידמפוטנטיות, ניסיונות חוזרים וגיבוי לגיבוי במערכות שעברו שיפוץ
עיבוד מחדש של מערכת המשתמשת בארכיטקטורה מונעת אירועים, תורי הודעות או קריאות שירות מבוזרות מציג סוג של בעיות שדפוסים המתמקדים אך ורק בפריסה אינם מטפלים בהן: מה קורה לפעולות במהלך הפעולה כאשר שירות עובר מהגרסה הישנה לגרסה החדשה? אירועים שפורסמו תחת הגרסה הישנה עשויים להגיע למטפל שמפעיל את הגרסה החדשה. בקשות שהוזמנו כנגד ממשק ה-API הישן עשויות להגיע למטפל שכבר עבר עיבוד מחדש למבנה פנימי חדש. ייתכן שיהיה צורך להשלים או לפצות עסקאות שהושלמו חלקית תחת הלוגיקה הישנה תחת הלוגיקה החדשה.
התשובה לכל הבעיות הללו היא אידמפוטנטיות: תכנון כל פעולה כך שתייצר את אותה התוצאה בין אם היא מבוצעת פעם אחת או מספר פעמים. מטפל אידמפוטנטי שמקבל אירוע כפול במהלך מעבר פריסה מייצר את אותו פלט כמו זה שמקבל את האירוע בדיוק פעם אחת. פעולת כתיבה אידמפוטנטית המופעלת מחדש כחלק מ"rollback" מייצרת את אותו מצב מסד נתונים כמו הכתיבה המקורית. אידמפוטנטיות אינה רק דאגה של רפקטורינג: זוהי תכונה כללית של מערכות מבוזרות גמישות. אבל דווקא במהלך מעברי רפקטורינג היעדרה גורם לכשלים הבולטים ביותר.
הוספת ניסיונות חוזרים וגיבוי לגיבוי ספקים ללא שינוי משמעותי (refactoring)
אחת השאלות הנפוצות ביותר בנתוני Search Console עבור מאמר זה היא כיצד להוסיף יכולות של ניסיון חוזר וגיבוי לאפליקציה קיימת, במיוחד אפליקציית Rails או אפליקציית framework דומה, מבלי לבצע מאמץ מקיף של שיפוץ מחדש. התשובה היא שניתן להוסיף יכולות של ניסיון חוזר וגיבוי לגיבוי כדאגה רוחבית בשכבת התשתית מבלי לשנות יישומי שירות בודדים.
בשכבת התשתית, ניתן להגדיר רשת שירותים כמו Istio או Linkerd לנסות מחדש בקשות שנכשלו באופן אוטומטי, עד לספירת ניסיונות חוזרים מוגדרת, עם ניתוק אקספוננציאלי וג'יטטר כדי למנוע התנהגות "עדר" (herd beat) רועמת. זה לא דורש שינויים בקוד האפליקציה מכיוון שהתנהגות הניסיון החוזר מיושמת בפרוקסי הצדדי (sidecar proxy) שמיירט את כל הבקשות הנכנסות והיוצאות. ניתן ליישם גיבוי לגיבוי של הספק באופן דומה: אם הספק הראשי מחזיר שגיאה מעל קצב סף, הרשת מנתבת בקשות עוקבות לספק משני עד שהראשי יתאושש.
בשכבת האפליקציה, כאשר ניסיונות חוזרים ברמת התשתית אינם מספיקים מכיוון שלוגיקת הניסיונות החוזרים צריכה להיות מודעת למצב העסק, ניתן להכניס ספריית ניסיונות חוזרים קלת משקל או תור משימות בגבול בין האפליקציה לתלות חיצוניות מבלי לארגן מחדש את האפליקציה באופן פנימי. המפתח הוא לבודד את לוגיקת הניסיונות החוזרים והגיבוי לגבול האינטגרציה במקום לפזר אותה ברחבי שכבת הלוגיקה העסקית. זה הופך את התנהגות הניסיונות החוזרים לגלויה, ניתנת לבדיקה וניתנת להגדרה מבלי לגעת במבנה הליבה של האפליקציה. כפי שנדון בהקשר של שיטות רפקטורינג זריזות, הכנסת דפוסי אמינות ברמת התשתית לפני עיבוד מחדש של לוגיקה עסקית מפחיתה את שטח הפנים של מה שיש לאמת לאחר כל שינוי.
אידמפוטנטיות בארכיטקטורות מונחות אירועים עם זרמי Redis
ארכיטקטורות מונחות אירועים בעלות השהייה נמוכה המשתמשות ב-Redis Streams או בטכנולוגיות דומות מתמודדות עם אתגר אידימפוטנטיות ספציפי במהלך שחזור נתונים: קבוצות צרכנים עשויות לעבד אירועים בקצב שונה, ייתכן שהצרכן שקורא אירועים בגרסה החדשה כבר עיבד אירועים שהגרסה הישנה לא עיבדה, ופעולות שחזור או שחזור יכולות לספק את אותו אירוע מספר פעמים למטפלים שלא תוכננו לטפל בכפילויות.
הגישה הסטנדרטית היא להקצות מזהה ייחודי לכל אירוע בנקודת הפרסום ולעקוב אחר מזהי אירועים מעובדים במאגר מתמשך. לפני עיבוד אירוע, המטפל בודק האם המזהה כבר עובד. אם כן, האירוע מאושר ומושלך ללא עיבוד חוזר. אם לא, האירוע מעובד והמזהה נרשם. לוגיקת ביטול כפילויות זו חייבת להיות אטומית: אם המטפל מעבד את האירוע אך נכשל לפני רישום המזהה, האירוע יעובד מחדש במסירה הבאה. שימוש בפעולות אטומיות של Redis או בכתיבות טרנזקציונליות כדי לרשום את המזהה כחלק מפעולת העיבוד מונע מצב מרוץ זה.
במהלך מעבר של רפקטורינג שבו לוגיקת הצרכן משתנה, מזהי אידמפוטנטיות מספקים יתרון נוסף: הם מאפשרים להפעיל מחדש את זרם האירועים מול לוגיקת הצרכן החדשה ולהשוות פלטים מול הפלט המוקלט של לוגיקת הצרכן הישנה, מה שמאפשר בדיקות השוואה מבלי לחשוף משתמשים ללוגיקה החדשה.
אוטומציה של שחזור נתונים בצינורות CI/CD
לא ניתן לקיים את המשמעת של שיפוץ מחדש ללא זמן השבתה באמצעות תהליכים ידניים. כל פריסה בתוכנית ללא זמן השבתה דורשת רצף של אימותים: בדיקות טרום פריסה שהגרסה החדשה תואמת למצב מסד הנתונים הנוכחי, הערכות קנרי גייט בכל תוספת של אחוזי תעבורה, השוואה אוטומטית של פלטים בין נתיבי קוד ישנים וחדשים, ואימות לאחר פריסה שהמדדים המרכזיים לא נפגעו. ביצוע שלבים אלה באופן ידני עבור כל שינוי אינו בר קיימא מבחינה תפעולית ומכניס שגיאות אנוש בנקודות הקריטיות ביותר בתהליך.
צינור CI/CD עבור שיפוץ מחדש ללא זמן השבתה אינו רק צינור בנייה ופריסה. זהו צינור אימות: רצף של שערים אוטומטיים שחייבים כולם לעבור לפני ששינוי מתקדם לשלב הבא של הפריסה. כל שער הוא קריטריון ספציפי ומדיד. כשל בשער עוצר את הצינור ומפעיל התראה. מעבר כל השערים מקדם את הפריסה לשלב הבא באופן אוטומטי. כפי שתואר בדיון הרחב יותר של שיטות CI/CD עבור סביבות מיינפריים וארגוניותהדרישה הבסיסית היא שה-pipeline יאכוף את אותה משמעת פריסה עבור כל שינוי, ללא קשר לגודלו, ושהאכיפה תהיה אוטומטית ולא תלויה בתשומת הלב של מהנדסים בודדים.
שערי שלב צינור עבור שיפוץ חי
שערי שלבים (stage gateways) הם נקודות ביקורת אימות שחייבת פריסה לעבור לפני שהיא מתקדמת. עבור צינור שיפוץ (refactoring pipeline) ללא זמן השבתה, קבוצת השערים המינימלית היא כדלקמן.
טרום פריסה: בדיקת תאימות סכימה מאשרת שהעברת מסד הנתונים תואמת לאחור לגרסה הנוכחית של היישום, בדיקות חוזים אוטומטיות מאמתות שתגובות ה-API של הגרסה החדשה תואמות לחוזה של הגרסה הקודמת, וניתוח תלות סטטי מאשר שאף תלות שהגרסה החדשה מציגה לא תתנגש עם תלות הנדרשת על ידי הסביבה הקיימת.
לאחר פריסה בקנרי: השוואת שיעורי שגיאות בין הקנרי לתעבורה הבסיסית, השוואת זמן השהייה ב-p50, p95 ו-p99, השוואת מדדי עסקיים עבור כל מדד שמשפיע על נתיב הקוד שהשתנה, וחלון תצפית מינימלי שבמהלכו הקנרי חייב להישאר יציב לפני שאחוז התעבורה גדל.
לאחר פריסה מלאה: חבילת בדיקות רגרסיה כנגד נקודות קצה של ייצור, בדיקות עקביות של מסד נתונים המאשרות שכל הגירה של כתיבה כפולה או הרחבת חוזה שמרה על עקביות, ואישור שארפקט הפריסה הקודם נותר זמין לביטול פעולות קודם.
רפקטורינג ואכיפה מונחי תאימות
שיפוץ מבוסס תאימות מציג אילוץ נוסף ש-Pipeline Gateways חייבים לאכוף: כל שינוי חייב להיות עקבי באופן מוכח עם דרישות המדיניות הרגולטוריות או הארגוניות הרלוונטיות. בתעשיות מפוקחות, משמעות הדבר היא ש-Pipeline Gateway חייב לייצר נתיב ביקורת המציג מה שונה, מתי הוא נפרס, איזה אימות בוצע ומי אישר אותו. שערי Pipeline אוטומטיים המתעדים את הביצוע שלהם, כולל מצב קלט, קריטריוני שער ותוצאת עובר/נכשל, מספקים נתיב ביקורת זה ללא מאמץ תיעוד ידני.
פלטפורמות שיפוץ חכמות עם יכולות אכיפה כלל-צוותיות, המופיעות כשאילתה בנתוני Search Console עבור מאמר זה, הן כלים המשלבים אימות תאימות בתהליך העבודה של שיפוץ: אכיפה של יישום עקבי של דפוסי שיפוץ בין הצוותים, של אי-הכנסת ממשקים שהוצאו משימוש, ושל עמידה בסטנדרטים אדריכליים המוגדרים ברמה הארגונית. יכולות אלו חורגות ממה שמספק צינור CI/CD לבדו, משום שהן דורשות הבנת הסמנטיקה של הקוד המשתנה, לא רק האם הוא נבנה ועובר בדיקות.
שיפוץ מיינפריים ו-CICS ללא זמן השבתה
סביבות מיינפריים מציגות את הגרסה התובענית ביותר של שיפוץ מחדש ללא זמן השבתה מכיוון שהאילוצים הם מבניים ולא ניתנים להגדרה. לא ניתן להחליף תוכנית טרנזקציות של CICS על ידי פריסת תמונת מכולה חדשה והחלפת מאזן עומסים. החלפת תוכנית ב-CICS דורשת פקודה NEWCOPY או PHASEIN, שטוענת גרסה חדשה של התוכנית לזיכרון. NEWCOPY מחליף את הגרסה הישנה באופן מיידי, ומשפיע על כל הטרנזקציות שמתחילות לאחר ביצוע הפקודה. PHASEIN ממתין להשלמת כל הטרנזקציות הפעילות הנוכחיות המשתמשות בגרסה הישנה לפני החלפתה, ומספק מעבר נקי יותר עבור טרנזקציות ארוכות טווח.
אף אחד מהמנגנונים אינו מספק החזרה מיידית לגרסה הקודמת. אם בגרסה החדשה של התוכנית יש פגם, חזרה לגרסה הישנה דורשת הנפקה מחודשת של NEWCOPY או PHASEIN עם מודול הטעינה הקודם. זה דורש שמודול הטעינה הקודם יישמר בספריית הטעינה ושתהליך ההחזרה לגרסה הקודמת יתועד, יתרגל וניתן להפעילו על ידי הצוות התורן מבלי להזדקק למפתח המקורי.
קבצי VSAM משותפים מוסיפים אילוץ נוסף. מספר פעולות CICS ותוכניות אצווה עשויות לגשת לאותו קובץ VSAM בו זמנית. שינוי מבני בפריסת הקובץ, כגון הוספה או הרחבה של מקטע רשומה, דורש שכל התוכניות הניגשות לקובץ יעודכנו לפני או במקביל לשינוי הפריסה, או שהקובץ יתמוך בפורמטים מרובים של רשומות במהלך תקופת המעבר. זהו המקבילה המרכזית לדפוס ההרחבה-החוזה: הפריסה החדשה חייבת להיות תואמת לתוכניות ישנות במהלך המעבר, ותוכניות ישנות חייבות להתעדכן לפני שהפריסה הישנה יוצאת משימוש. הרחבה מבוקרת של פריסות מערכי נתונים ופרמטרי גישה לתוכניות היא המנגנון המאפשר דו-קיום תואם זה ללא החלפת קבצים.
אסטרטגיות אלימינציה של חלון אצווה
עיבוד אצווה מסורתי במחשבים מרכזיים מניח את קיומו של חלון אצווה: תקופה שבמהלכה עיבוד טרנזקציות מקוונות מושעה, עבודות אצווה פועלות ללא תחרות, והנתונים המתקבלים מוכנים לתקופת העיבוד המקוונת הבאה. ביטול חלון האצווה, הנדרש לפעולה אמיתית ללא זמן השבתה, פירושו עיצוב מחדש של מודל עיבוד האצווה כך שעבודות אצווה יוכלו לפעול במקביל לטרנזקציות מקוונות מבלי לפגוע בנתונים משותפים.
הגישות הסטנדרטיות הן נעילה ברמת המשאבים ברשומה ולא ברמת הקובץ, עיבוד מיני-אצווה מונחה אירועים המעבד עומסי עבודה קטנים ברציפות במקום עומסי עבודה גדולים באופן תקופתי, ומסדי נתונים של קריאה-שכפול המשרתים עומסי עבודה של דיווחי אצווה מבלי להתחרות עם עיבוד טרנזקציות מקוון על גישת כתיבה. כל אחת מהגישות הללו דורשת שינויים הן בתוכניות והן בדפוסי הגישה לנתונים, אך אף אחת מהן אינה דורשת שחלון האצווה יישאר במקומו במהלך המעבר: ניתן לבצע את המעבר עצמו באמצעות אותה גישת אימות כפולה המשמשת לכל שיפוץ אחר של מערכת חיה.
שיפוץ תוכנית COBOL באמצעות ניתוח השפעה
עיבוד מחדש של תוכנית COBOL בצורה בטוחה דורש לדעת, לפני ביצוע כל שינוי, בדיוק אילו תוכניות אחרות קוראות לה, אילו ספרי עותקים היא משתפת עם תוכניות אחרות, אילו מערכי נתונים היא קוראת וכותבת, ואילו מערכות במורד הזרם תלויות בנתונים שהיא מייצרת. ללא ידע מבני זה, כל שינוי בתוכנית נושא סיכון לא ידוע: התוכנית שעברה עיבוד מחדש עלולה לשבור קורא שלא זוהה, לייצר פלט בפורמט שמערכת במורד הזרם אינה יכולה לנתח, או לשנות מבנה נתונים משותף באופן שמשפיע על תוכניות אחרות הכוללות את אותו ספר עותקים.
ניתוח השפעה אוטומטי פותר בעיה זו על ידי בניית גרף תלות מלא של תוכנית COBOL לפני תחילת העיבוד מחדש. הגרף מציג כל קורא, כל ספר עותקים משותף, כל גישה למערך נתונים וכל צרכן במורד הזרם, מאורגן לפי סוג קשר ומיקום ייחוס ספציפי. לאחר מכן, תוכנית העיבוד מחדש נגזרת מגרף ההשפעה: תוכניות הקוראות לתוכנית שהשתנתה חייבות להיבדק מול הגרסה החדשה, ספרי עותקים ששונו חייבים להיות מאומתים מול כל התוכניות הכוללות אותם, ופריסות מערכי נתונים שמשתנות חייבות להיות מאומתות מול כל התוכניות הניגשות לאותם מערכי נתונים. כפי שמתואר ב- פתרונות ניתוח השפעה ש-IN-COM מספקת, יכולת זו היא ההבדל בין תוכנית שיפוץ שמגלה את השלכותיה לאחר הפריסה לבין כזו שמכמתת אותן לפני כן.
אימות, חזרה למצב קודם וצפייה
שחזור נתונים ללא זמן השבתה מייצר פלט רציף שיש לנטר אותו באופן רציף. הניטור אינו בדיקה לאחר מכן שהכל עבד: זהו שער פעיל בכל שלב בתהליך הפריסה, והוא המנגנון העיקרי שדרכו בעיות מזוהות מוקדם מספיק כדי למנוע השפעה מצד המשתמש.
מודל האימות עבור שחזור נתונים ללא זמן השבתה כולל שלוש שכבות. הראשונה היא ניטור סינתטי: טרנזקציות סקריפטיות המדמות התנהגות משתמשים ורצות באופן רציף מול תהליכי ייצור, ומאמתות שזרימות מפתח משלימות בהצלחה. ניטורים סינתטיים לוכדים כשלים המתרחשים בנתיבי קוד ספציפיים שמשתמשים אמיתיים עשויים שלא לממש בתקופות עם תנועה נמוכה, והם מספקים בסיס התנהגותי שמולו ניתן להשוות תוצאות קנריות.
השכבה השנייה היא ניטור דיפרנציאלי: השוואה בזמן אמת של מדדים בין פריסת הקנרי לפריסה הבסיסית, כולל שיעורי שגיאות, התפלגויות השהייה, מדדי עסקיים וצריכת משאבים. ניטור דיפרנציאלי אינו דורש ספים מוחלטים: הוא דורש השוואה יחסית. פריסה קנרית המציגה שיעורי שגיאות גבוהים בשני אחוזים מהבסיס היא בעיה ללא קשר לשאלה האם שיעור השגיאה המוחלט עולה על סף מוגדר בנפרד.
השכבה השלישית היא אימות עקביות נתונים. בכל עיבוד מחדש הכולל כתיבה כפולה, הגירת סכימה או הרצות מערכת מקבילות, יש לאמת באופן רציף את עקביות הנתונים בין הייצוגים הישנים והחדשים. השוואות סיכומי בדיקה, השוואות ספירת רשומות ושאילתות בדיקה נקודתיות המאמתות ערכי שדות ספציפיים מול טרנספורמציות צפויות, כולן תורמות לביטחון ששכבת הנתונים מתנהגת כהלכה במהלך המעבר. כפי שנבחן בהקשר של מהו ניתוח השפעה ומדוע הוא חשוב, היכולת לאמת את ההשלכות של שינוי מול סט מוגדר של ציפיות היא מה שמבדיל בין שיפוץ מובנה (structuring) לשינוי ספקולטיבי.
מנגנוני החזרה מיידית
תוכנית החזרה למצב קודם (rollback) שלוקחת שלושים דקות לביצוע אינה תוכנית החזרה למצב קודם למערכת ללא זמן השבתה. עד להשלמתה, שלושים דקות של שירות פגום כבר סופקו למשתמשים. החזרה למצב קודם מיידית דורשת שכל פריסה תהיה מתוכננת כך שתהיה הפיכה מההתחלה, ולא מותאמת לאחר מעשה כאשר מתרחשת בעיה.
עבור פריסות יישומים, החזרה מיידית פירושה שמירה על ארטיפקט הפריסה הקודם זמין, מחומם מראש ומכוון לאותו מצב מסד נתונים. החלפת תעבורה דרך מאזן עומסים או שינוי כלל שער API צריכה להיות הפעולה היחידה הנדרשת כדי לחזור לגרסה הקודמת. זה אפשרי כאשר מצב מסד הנתונים תואם לאחור לגרסה הקודמת, דבר המובטח על ידי משמעת הרחבה-חוזה בשכבת הגירת מסד הנתונים.
עבור העברות מסדי נתונים, החזרה מיידית דורשת שכל העברה המיושמת בשלב ההרחבה תהיה הפיכה ללא אובדן נתונים. עמודה שנוספה בשלב ההרחבה ניתנת לביטול בהחזרה. עמודה ששונתה בצורה הרסנית אינה ניתנת לשחזור ללא גיבוי. זו הסיבה שאין להחיל שינויים הרסניים בסכימה, אלו שמסירים עמודות, משנים סוגים בדרכים לא תואמות או מפחיתים את הדיוק, עד שהגרסה החדשה נפרסת ומאומתת במלואה והגרסה הישנה יוצאת משימוש במלואה.
איך SMART TS XL תומך בתוכניות שיפוץ ללא זמן השבתה
SMART TS XL מטפל בבעיית הנראות המבנית העומדת בבסיס כל כשל בשיפוץ ללא זמן השבתה: צוותים המנסים לשפץ מערכות חיות ללא תמונה מלאה של מהן מכילות מערכות אלו, מה תלוי במה, ומהן ההשלכות של כל שינוי מתוכנן. הפלטפורמה קולטת קוד מקור מכל שפה ופלטפורמה בסביבה, כולל COBOL, JCL, Java, .NET, Python, JavaScript ו-SQL, ובונה מודל הפניה צולבת מאוחד המייצג את הקשרים המבניים של המערכת כולה.
לפני ביצוע שינוי רפקטורינג, SMART TS XLיכולת ניתוח ההשפעה של עוקבת אחר גרף התלות מהרכיב המשתנה כלפי חוץ דרך כל קורא, כל מבנה נתונים משותף, כל צרכן במורד הזרם וכל תוכנית שתושפע מהשינוי. התוצאה היא רשימה ספציפית וממוספרת של השלכות, המאורגנות לפי חומרה ורכיב, ולא הערכה כללית של סיכון. רשימה זו היא שמאפשרת לתכנן נכון רצף שיפוץ עם זמן השבתה אפס: לדעת אילו צרכנים יש לעדכן לפני פריסת הרכיב שהשתנה, אילו העברות מסד נתונים יש לרצף לפני פריסות אילו יישומים, ואילו מערכות במורד הזרם יש לאמת לפני שהגרסה הישנה יוצאת משימוש.
SMART TS XLיכולת ויזואליזציית הקוד של הופכת את גרף התלות לנגיש לניווט עבור צוותים שאין להם היכרות מעמיקה עם כל שכבה של המערכת שעוברת שיפוץ. אדריכלים יכולים לראות כיצד רכיבים מתחברים לפני עיצוב מחדש של מבנה החיבור. מפתחים יכולים לראות מה קורא לפונקציה לפני שינוי החתימה שלה. צוותי תפעול יכולים לראות לאיזה מערך נתונים משמש לפני שינוי הפריסה שלו. נראות זו היא תנאי מוקדם לתוכנית שיפוץ מובנית, הפיכה ומוגדרת בשלבים, שדורשת פעולה ללא זמן השבתה.
שיפוץ ללא זמן השבתה כפרקטיקה מתמשכת
הטכניקות במדריך זה אינן התערבויות חד פעמיות. הן אוצר המילים התפעולי של ארגון פיתוח שהחליט להתייחס למערכות ייצור כמתפתחות ללא הרף ולא מוחלפות מעת לעת. פריסות כחול-ירוקות, שחרורי קנרי, החלפת תכונות, הגירת הרחבה-חוזה, חילוץ תאני חנק, עיבוד אירועים אידמפוטנטיים ושערי פריסה נאכפים על ידי צינור אינם נהלי חירום: הם נהלי התפעול הסטנדרטיים של צוות ששולח שינויים מבניים בבטחה בתדירות גבוהה.
הגעה למצב זה דורשת השקעה בכלים, תשתית ופרקטיקה ארגונית, מעבר לכל יוזמת שיפוץ מחדש בודדת. הכלים חייבים לתמוך בפריסה עצמאית, מעברי מצב נצפים והחזרה למצב קודם (rollback) מיידית. התשתית חייבת לתמוך בפיצול תעבורה, סביבות כחולות-ירוקות וסנכרון נתונים מבוסס CDC. הפרקטיקה הארגונית חייבת לכלול ניתוח השפעה לפני פריסה, ניטור דיפרנציאלי לאחר פריסה וחזרות החזרה למצב קודם באופן קבוע המאשר את פעולת נתיב ההחזרה למצב קודם בתנאים מציאותיים.
ארגונים שמבצעים השקעה זו מגלים שהעלות לכל שינוי פוחתת ככל שהפרקטיקה מתבגרת: כל שינוי חוזר פחות מסוכן מהקודם מכיוון שהתשתית התומכת כבר קיימת, הצוות פיתח שיקול דעת לגבי אילו ספי שער מתאימים לאילו שינויים, והידע המבני המצטבר בכלים כמו SMART TS XL הופך כל שינוי מתוכנן למדויק יותר בהיקף מאשר זה שלפניו. המטרה של שיפוץ ללא זמן השבתה אינה לבצע שינוי אחד בצורה בטוחה. היא לבצע כל שינוי בצורה בטוחה, ברציפות, מבלי לבקש ממשתמשים לקבל חלון תחזוקה.
