הגדרת רישיון 1C-Bitrix: מדוע הפרודקשן קורס לאחר העברה
מפתח הרישיון של 1C-Bitrix קשור לסביבה, ולא לחומרה: המוצר בודק את הדומיין, הפורט והמהדורה. כל עוד הפרמטרים האלה תואמים לרישום במפתח, הפורטל נפתח כשורה.
ברגע שהסביבה משתנה — העברת הפרויקט לשרת חדש, החלפת הדומיין של הפורטל, מעבר לפורט לא סטנדרטי או חזרה לפורט הסטנדרטי — האתר נחשב לחדש, והמערכת עוברת למצב הדגמה או מחזירה שגיאה. מבחוץ זה נראה כמו «האתר לא זמין לאחר המעבר», למרות שהקבצים, מסד הנתונים וההגדרות במקומם.
סוג התקלות השני — חוסר סנכרון בין הפרמטרים. בעת מעבר מעתיקים קבצים וגיבוי של מסד הנתונים, אבל שוכחים את המפתח עצמו ואת קישור הסביבה לאתר: במקום אחד עדכנו את הדומיין, ובמקום אחר הוא נשאר הקודם.
אם תחת רישיון אחד פועלים כמה אתרים או שסביבת הבדיקה הועתקה מהסביבה הייצורית, אי-ההתאמה לא מתגלה מיד, אלא אחרי הסנכרון הראשון.
המחיר של טעות כזו אינו התראה מסודרת בפאנל, אלא פורטל לא זמין ואינטגרציות שנפלו. הגדרת רישיון 1C-Bitrix כאן אינה התקנה מחדש, אלא הבאת הסביבה למצב שהמפתח מזהה כשלו. נסביר איך סוגרים את זה בלי השבתה.
מה נותן סדר בסביבות: עדכונים יציבים וחזרות לאחור
כל עוד סביבת הבדיקה וסביבת הייצור חיות על אותו מפתח ואותו מסד נתונים, כל עדכון הופך להגרלה: שינויים בליבה, במודולים ובהגדרות ההרשאות עוברים ישירות לאתר הפעיל.
אי-תאימות של תבנית או מודול צפה כבר אצל המבקרים, והחזרה למצב הקודם נעשית ידנית וללא ערובה שהקבצים ומסד הנתונים חזרו באופן עקבי.
רישיון 1C-Bitrix שהוגדר כראוי מסיר את המגבלה הזו: הוא מיועד לדומיין בדיקה נפרד, ולכן העדכונים נבדקים תחילה על עותק.
אנחנו פורשים אותו על תמונת מצב של מסד הנתונים, מריצים עדכון ליבה ומודולים, בודקים תרחישי מפתח — הזמנה, תשלום, התחברות, סנכרון עם 1С — ורק אחר כך מעבירים את סט השינויים המאומת לסביבת הייצור.
בזכות זה זמן ההשבתה בעדכון מצטמצם מכמה שעות ל-10–20 דקות. החזרה למצב הקודם אורכת דקות, כי לפני כל פרסום נשמרת תמונת מצב של מסד הנתונים וגרסת קבצים מקובעת: השחזור לא תלוי בכך שמישהו זוכר מה בדיוק השתנה.
אפקט נפרד — הפחתת מספר התיקונים הידניים. העדכונים מתבצעים במנגנון התקני, הגדרות הסביבות מתועדות וניתנות לשחזור, וסביבת הבדיקה וסביבת הייצור נבדלות רק בהרשאות ובנתונים. יכולת החיזוי של המהדורות מפסיקה להיות משאלה: לכל פרסום יש תוכנית, נקודת חזרה ורשימת בדיקות לפני הפרסום.
הפעלה והעברת רישיון: איזה מצב מתאים
רישיון 1C-Bitrix קשור לדומיין, למהדורה של הפרויקט ולשרת — לכן הפעלה «איך שיצא» כמעט תמיד מסתיימת בקישור מחדש ובהשבתה של האתר. המצבים נבדלים בכמה אתרים ובאיזו סביבה הם מכסים: כדאי לבחור לפני ההרצה, ולא אחרי המעבר הראשון.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הפעלה על שרת אחד | אתר אחד, דומיין אחד | המפתח קשור לכתובת, מעבר דורש העברה |
| העברת מפתח לדומיין אחר | החלפת אחסון, כתובת חדשה | חלון אי-זמינות בין ביטול הפעלה להפעלה מחדש |
| רישיון מרובה אתרים | רשת אתרים, סניפים | מגבלה כוללת של אתרים, מפתח אחד לכולם |
| סביבה סגורה ללא בדיקה חיצונית | רשת בלי יציאה החוצה | העדכונים מותקנים ידנית, בחבילה |
העברת מפתח מתבצעת יחד עם המעבר: יוצרים עותק של מסד הנתונים וההגדרות, מבטלים את הקישור, ואז מפעילים מחדש על הדומיין החדש. סביבת בדיקה בטוח יותר לכסות ברישיון נפרד — אחרת ההעברה עוצרת את אתר הייצור.
החלפת מהדורה של הפרויקט היא תרחיש נפרד: המהדורה נבחרת לפי המודולים שבאמת נחוצים, והעדכון מותקן תחילה על עותק. אנחנו בודקים שהקטלוג, ההזמנות והסנכרון עם מערכת חיצונית עובדים ללא שגיאות, ורק אחר כך מעבירים את האתר הראשי.
בסביבה סגורה בדיקת הרישיון מתבצעת בתוך הרשת, והעדכונים מובאים בחבילה — את זה מכניסים לנוהל התחזוקה מראש, אחרת כבר העדכון הראשון נתקע.
סדר העבודות: מביקורת הסביבה ועד מסירה לתמיכה
את העבודות מתחילים בביקורת של הסביבה הנוכחית: קישור שגוי של המפתח לא שובר את האתר מיד — הוא בשקט מנתק עדכונים ותמיכה טכנית, ומתגלה ברגע שצריך לסגור פרצת אבטחה. לכן קודם מתעדים עובדות, ורק אחר כך משנים. הסדר שלמטה זהה גם להפעלה, גם להעברת רישיון לשרת אחר, וגם למעבר למהדורה מרובת אתרים.
- ביקורת הסביבה הנוכחית. משווים את מהדורת הרישיון למשימות האמיתיות של האתר, בודקים את תקופת העדכונים, מצב הליבה והמודולים, מאתרים עקבות של העברות קודמות ועותקי בדיקה שנשארו מקבלנים קודמים.
- ספירת מלאי של אתרים ודומיינים. אוספים את כל הדומיינים, תת-הדומיינים, הגרסאות הלשוניות וסביבות הבדיקה, ומסמנים אילו מהם משרת מפתח אחד ואילו דורשים רישיון נפרד.
- תרשים קישורי הרישיונות. מכינים מפה «מפתח — דומיין — אתר — אחראי». בה רואים מיד היכן מהדורה מרובת אתרים מתאימה והיכן צריך מפתח נפרד: זה מסיר קונפליקטים בהוספת אתרים חדשים.
- הפעלה והעברה. מקשרים את המפתח לדומיין בשרת היעד, מעבירים את הרישיון בעת החלפת אחסון, מסנכרנים את נתוני הרישיון עם פרמטרי האתר ומקבעים נקודת חזרה.
- בדיקה לאחר הפעלה. מריצים תרחישי עבודה: עדכון ליבה ומודולים, התקנת הרחבות, טפסים, תשלום, סנכרון עם 1С, שליחת דואר. בודקים לא את עצם ההפעלה, אלא שהרישיון לא מפיל תהליכים משויכים.
- מסירה לתמיכה. מוסרים את מפת הקישורים, נוהל הפעולות בעת החלפת דומיין או שרת וסדר החידוש — כך התמיכה רואה מה ואיפה נכשל, בלי לפענח הגדרות קודמות.
סט תרשימים, הרשאות ונהלים שנשאר אצלכם
הסט נחוץ לא «לצורכי דיווח», אלא כדי שאחרי שנה איש לא ינחש איזה דומיין קשור לאיזה רישיון ומי רשאי להעביר אותו. אנחנו מנהלים את המסמכים האלה לצד קוד הפרויקט ומעדכנים בכל שינוי בסביבה, ולכן בסיום נשארת אצל הלקוח תיעוד עובד, ולא דקורטיבי.
- מפת סביבות ואתרים — רשימת הסביבות (פיתוח, בדיקות קבלה, ייצור), הדומיינים ותת-הדומיינים המקושרים, מהדורת הרישיון בכל אחת, מספר האתרים והמשתמשים הפעילים, וגם נקודות שבהן הרישיון כבר קרוב למגבלה.
- מדיניות הרשאות ותפקידים — מי רשאי להפעיל, להעביר ולשנות מהדורה, כיצד מופרדות הרשאות מנהל המוצר, מנהל השרת והקבלן, ונוהל הענקה ושלילה של הרשאות עם עזיבת עובד.
- נוהל עדכונים — הרצף מעדכון בסביבת הקבלה ועד ענף הייצור, חלון העבודה, קריטריונים לחזרה לתמונת המצב הקודמת, ומי חותם על הפרסום.
- הוראות שחזור — היכן נמצאים גיבויי הקבצים ומסד הנתונים, עומק נקודות השחזור, וסדר הפעולות שלב אחר שלב בעת החלפת דומיין או מעבר לשרת אחר, כולל קישור מחדש של הרישיון.
- רשימת פרטי חשבון — מפתחות הפעלה, הרשאות לפאנל ניהול הרישיונות, רשומות שירות: היכן נשמרים, מי הבעלים, כיצד מועברים ובאיזו תדירות מוחלפים.
- תרשים רישיון מרובה — איזה רישיון מכסה איזה פרויקט, היכן מותר להשתמש במפתח אחד לכמה אתרים, והיכן זה מפר את התנאים ומוביל לחסימה.
- יומן שינויים ונקודת הסלמה — מה ומתי השתנה בתצורת הרישיונות, למי לפנות בעת כשל בהפעלה, ואיזה זמן תגובה אנחנו שומרים.
את המסמכים מוסרים בפורמט שחי במאגר הקוד או במאגר הידע שלכם — אפשר לערוך אותם בלעדינו, וקבלן חדש נכנס לפרויקט לפיהם, ולא לפי התכתבות.
מקרה בוחן: העברת פורטל לשרת חדש ללא אובדן גישות
הפורטל של הלקוח על 1C-Bitrix עם אזור אישי לעובדים ולקבלנים חיצוניים עבר לשרת חדש במקביל להחלפת דומיין. בעבר עבודות כאלה בוצעו בעצירת לילה: מסד הנתונים הועבר כדאמפ, הרישיון נשאר מקושר לכתובת הישנה, ובבוקר המנהלים טיפלו בזרם פניות ממי שלא הצליח להיכנס. זמן ההשבתה הגיע עד שש שעות, ולמחרת התמיכה קיבלה כמה עשרות פניות.
מה שינו בהכנה
תמונת מצב של מסד הנתונים נוצרה מראש והורצה על השרת החדש, עם רפליקה בסנכרון רציף — עד לרגע המעבר הפער נמדד בדקות, לא בשעות. הרשאות קבוצות, סשנים פעילים וסיסמאות מועברות יחד עם מסד הנתונים, ולכן איש לא היה צריך להזין שוב פרטי חשבון.
קישור מחדש של הרישיון לדומיין החדש בוצע לפני תחילת העבודות, כשלב נפרד — דווקא זה מונע הפעלות חוזרות אצל העובדים.
מה התקבל
המעבר ארך 25 דקות בחלון מתואם במקום שש שעות, וכל אותו זמן הפורטל הגיב בכתובת הישנה בהפניה, ולא בעמוד שגיאה. ביממה הראשונה הגיעו לתמיכה שלוש פניות, ואף אחת לא נגעה לגישה. לא היו הפעלות חוזרות או הוצאה מחדש של מפתחות אצל העובדים: הרישיון עבר יחד עם הדומיין בפעם אחת.
כעבור חודש, מעבר בקרה של סביבת הבדיקה לפי אותו נוהל ארך עוד פחות זמן ולא דרש תיקונים ידניים. עבור הפורטל הזה, העברה והחלפת דומיין הפכו לפעולה מתוכננת עם חלון צפוי מראש, ולא לאירוע חירום.
מה עושים אם המפתח כבר קשור לדומיין הישן
מפתח הרישיון נקשר לדומיין ברגע ההפעלה, ולכן המעבר עצמו לא שובר דבר — נשברת החבילה «מפתח + אתר». אם הדומיין הקודם לא זמין, המפתח לא מפסיק להיות בתוקף, אבל אי אפשר להפעיל אותו בכתובת חדשה בלי לנתק את הקישור. זה הדבר הראשון שכדאי להפריד בראש: הרישיון והעתק האתר הפעיל חיים בנפרד זה מזה.
בשלב הבא מבררים אם נשארה גישה לאתר הקודם, לפחות ברמת הקבצים ומסד הנתונים. כל עוד השרת מגיב, יוצרים גיבוי של הספרייה וייצוא של מסד הנתונים לפני כל פעולה עם הרישיון — כך העברת ההגדרות, המודולים והנתונים של המשתמשים תעבור בלי לאבד את התצורה.
אם הגישה אבדה לחלוטין, המקור היחיד הוא הגיבוי האחרון, הארכיון של ספק האחסון הקודם או עותק שנשאר אצל הקבלן הקודם.
הפעלה חוזרת בדומיין חדש מתבצעת דרך פנייה לתמיכה של 1C-Bitrix: מאשרים בעלות על המפתח, הקישור לכתובת שאינה זמינה מוסר, ואחר כך המפתח מופעל מחדש.
במקביל בודקים מה עוד קשור לדומיין הישן — רישיונות של מודולים נוספים, הגדרות דואר, סנכרון עם מערכת הנה״ח — אחרת חלק מהפונקציות יישארו לא פעילות למרות שהאתר נראה חי.
סדר שחזור העבודה במכוון לא מתחיל ברישיון. קודם מרימים עותק בכתובת טכנית, מוודאים שהאתר נפתח, שהסנכרון עובד, שההרשאות והדואר עובדים, ורק אחר כך מעבירים את המפתח ומחליפים דומיין. כך חלון ההשבתה מינימלי, והחלפה שלא הצליחה חוזרת אחורה בלי השלכות על המבקרים ועל תוצאות החיפוש.
ספקות טכניים: מפתחות, דומיינים, עותקי בדיקה
לפני עבודות על רישיונות בדרך כלל עולה אותו סט שאלות: איך יתנהג המפתח בעת העברה, מה עושים עם תוקף שפג, האם אפשר להרים עותק בדיקה של הפרויקט בלי לפגוע באתר הפעיל. להלן תשובות הנדסיות קצרות, כדי שההחלטה לגבי 1C-Bitrix תתקבל לפני השינויים, ולא אחריהם.
עותק, מעבר לענן ועדכון מודולים קשורים זה לזה: סדר פעולות שגוי משאיר את סביבת הייצור בלי עדכונים, והמפתח נקשר לאתר הלא נכון. לכן מתכננים מראש את ההפרדה בין האתרים.
האם צריך רישיון נפרד לעותק בדיקה של הפרויקט?
העותק מורם בכתובת נפרדת ואינו משרת מבקרים. לבדיקות קצרות מספיק אתר זמני, ולסביבת בדיקה קבועה — מפתח משלו, אחרת ההפרדה בין האתרים מיטשטשת.
מה קורה לאחר פקיעת תוקף הרישיון?
האתר עובד במהדורה הנוכחית, אבל מפסיק לקבל עדכוני מודולים וליבה. חידוש מחזיר את הגישה, אך קודם מקבעים גיבוי ובודקים תאימות של רכיבים שהותאמו.
האם המפתח מועבר בעת מעבר לענן?
כן: הרישיון קשור לפרויקט, ולא לשרת. קודם מרימים עותק בענן ובודקים אותו, אחר כך מעבירים את המפתח ומחליפים את קישור האתר.
האם אפשר לעדכן מודולים בחלקים?
כן, עדכון המודולים נעשה באופן סלקטיבי: קודם הליבה והמודולים הקריטיים, אחר כך השאר. עם רכיבים מותאמים זה מאפשר לחזור אחורה משלב בודד, בלי להחזיר את כל האתר.
נדבר על המשימה: מה נדרש מכם להתחלה
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם שאלות הבהרה, מספיקה לנו הודעה אחת עם נתוני הפתיחה של הפרויקט. ככל שמתארים בצורה מדויקת יותר את סביבת הרישוי הנוכחית, כך נדייק יותר בהרכב השלבים ובזמנים של כל אחד מהם.
- סוג ומהדורת הרישיון: רישיון אחד או רישיון מרובה, קישור לדומיין או למוצר, והאם יש מפתח עדכונים פעיל.
- הצגת המשימה: הפעלה, העברה לדומיין או לשרת אחר, איחוד כמה אתרים תחת רישיון אחד, חידוש, טיפול במצב של כפילויות מפתחות.
- תשתית: היכן מתארח הפרויקט, כמה סביבות יש — ייצור ובדיקה, תחת איזה שרת אינטרנט ומסד נתונים הוא עובד.
- הרשאות: מנהל בפאנל «1C-Bitrix», פרטי רישום אצל המפיץ, גישה לשרת או לאחסון — בשלב האבחון.
- מגבלות: חלון שבו העברה מותרת בלי לעצור את העבודה, דרישה לשמור על מיקומים בתוצאות החיפוש, וסביבה סגורה לחלק מהנתונים.
- נקודת קשר מצדכם: אדם שמאשר החלטות בנושא רישיונות ומקבל את התוצאה.
לפי נתוני הפתיחה האלה אנחנו מקבעים תוכנית עבודה והערכה: רצף השלבים, משך כל שלב, מה נעשה בצד שלנו ומה נדרש מכם. בנפרד מסכמים את סדר החזרה לאחור — אם בסביבת הייצור משהו ישתבש, נחזיר את תצורת הרישיונות הקודמת בלי לאבד גישה לעדכונים.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית. אם נוח יותר בשיחה קולית, נתאם שיחה עם מהנדס שמטפל במשימות כאלה.