פיתוח תוכנית התאוששות מאסון עבור 1С-ביטריקס

שחזור חירום של 1С-Битрикс: היכן זה נשבר ומדוע

שחזור חירום של 1С-Битрикс מתחיל לא מגיבויים, אלא ממפת נקודות הכשל. בתצורה טיפוסית ישנן ארבע: צומת מסד הנתונים, אחסון הקבצים עם המסמכים והתמונות שהועלו, שכפול בין השרתים ותצורת היישום עצמו — הגדרות, כללי סנכרון עם 1С, מודולים מותאמים אישית.

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

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

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

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

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

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

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

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

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

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

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

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

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

תרחישי שחזור: קר, חם, מבוזר

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

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

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

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

שלבי פיתוח תוכנית התאוששות מאסון

תוכנית התאוששות אינה מסמך "על המדף", אלא רצף של עבודות הנדסיות, שבו כל שלב הבא נשען על תוצאות השלב הקודם.

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

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

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

ארטיפקטים: תצורות, תרשימים, מדיניות גישה

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

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

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

מקרה בוחן: התאוששות לאחר כשל בצומת מסד הנתונים

הלקוח — חנות מקוונת קמעונאית על 1С-Битрикс עם תשתית עצמאית: שרת אינטרנט, שרת אפליקציות וצומת מסד נתונים נפרד.

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

מה היה לפני

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

מה שינו

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

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

מה נהיה

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

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

במה שונה גיבוי מתוכנית התאוששות?

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

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

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

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

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

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

ספקות טכניים נפוצים

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

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

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

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

בכמה יגדל העומס על השרתים?

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

כמה זמן לוקח היישום ומה היקף העבודה?

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

מהן הדרישות לסביבה?

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

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

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

• כיצד בנוי האחסון: שרת עצמאי, מכונה וירטואלית או פלטפורמת managed, מי אחראי על התשתית.
• סכמת הנתונים: מסד נתונים אחד או כמה, האם יש master-master, אילו מודולים ואינטגרציות חיצוניות קשורים ל-«1С-Битрикс».
• מה כבר מוגדר: גיבוי, שכפול, ניטור, האם יש נקודות שחזור מאומתות.
• מדדי יעד: זמן השבתה מותר ואובדן נתונים מותר בתקופה האחרונה — מהם תלויה הארכיטקטורה.
• מגבלות: דרישות לגישות, תקנות אבטחה, חלונות לעבודות, מי בצד הלקוח מקבל החלטות.
• היסטוריית תקלות: מה כבר נשבר, כיצד שוחזר, כמה זמן זה לקח בפועל.

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

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