למה התקנת אפליקציות מ-Битрикс24 Маркет שוברת את הפרודקשן
אפליקציה מ-Битрикс24 Маркет כמעט אף פעם לא מותקנת בוואקום: היא מגיעה עם דרישות משלה לגרסת הליבה, המודולים והרשאות הגישה. התקנה על פורטל חי גוררת אחריה עדכון של הפלטפורמה, ואיתו — מטפלי אירועים ותבניות שנכתבו מחדש, שמישהו התאים לצורכי החברה.
בזמן העדכון הפורטל לא זמין חלקית: חלק מהטפסים והתהליכים העסקיים לא מופעלים, ופניות לא מגיעות לאחראי.
אחר כך מתחיל קונפליקט עדכונים. האפליקציה פורשת בלוקי מידע (infoblocks), מאפיינים מסוג רשימה וספרי עזר משלה, ואם כאלה כבר קיימים — יוצרת כפילויות.
הסנכרון עם 1С, שהוגדר לקודים ומפתחות חיצוניים מסוימים, מתחיל ליצור רשומות כפולות: במקום עסקה אחת מופיעות שלוש, והטיפול אורך לא שעה אלא כמה ימים.
אי-תאימות של הרחבות מתגלה בשקט יותר. רכיבים בכתיבה עצמית, רובוטים וכללי עיבוד מפסיקים לפעול אחרי שהאפליקציה החליפה קריאות מערכת, ושגיאות אינטגרציה צפות לא מיד — בייצוא הבא או ברגע סגירת החודש, כשהנתונים כבר לא תואמים. אין דרך לחזור אחורה, אם גיבוי נלקח לפני העריכה האחרונה ולא לפני ההתקנה.
השורש של כל התקלות אחד: מתקינים אפליקציה על סביבת הייצור בלי בדיקת תאימות ובלי תוכנית rollback. נפרט איך זה נסגר — מסביבת בדיקות ועד עדכון מבוקר.
מה משתנה בפורטל אחרי התקנה מנוהלת של אפליקציות
הרחבות מ-Битрикс24 Маркет — החלק הכי דינמי בפורטל: עדכון אפליקציה יכול להשפיע על הרשאות גישה, מטפלי אירועים ותהליכים עסקיים שתלויים בהם. כל עוד ההתקנה נעשית ידנית לפי פניות, אין תמונה מלאה לא למנהל המערכת ולא לתמיכה. אנו בודקים ארבעה מדדים מדידים.
- עדכונים מנוהלים. תאימות גרסת ההרחבה עם הפורטל מאושרת לפני היישום, סביבת הבדיקות עוברת ראשונה, וההתקנה מתבצעת בחלון מתוכנן. זמן העדכון מצטמצם משעות של תיאומים להליך שגרתי.
- סביבת אפליקציות אחידה. רישום הרחבות עם בעלים, הרשאות ונקודות אינטגרציה. לפני ניתוק רואים אילו רובוטים ותהליכים תלויים באפליקציה.
- יציבות הפורטל. נעלם סוג התקלות "ההרחבה עדכנה את עצמה ושברה תהליך": עדכונים לא מיושמים בעומס שיא, וקיימת חזרה לגרסה הקודמת.
- אוטומציה של פעולות ידניות. התקנה, הקצאת הרשאות וניתוק מתבצעים לפי תרחיש אחד — שיעור הפעולות "לפי הזיכרון" יורד כמעט לאפס.
האפקט נמדד לפני ואחרי: זמן העדכון, שיעור הפעולות הידניות, מספר הפניות לתמיכה אחרי התקנת הרחבות ושיעור התקלות הקשורות בהן. קטלוג האפליקציות מפסיק להיות אטום, והעבודה איתו מפסיקה להיות פעולה חד-פעמית.
אפשרויות חיבור אפליקציות מ-Битрикс24 Маркет
הבחירה בדרך החיבור נקבעת לפי הסביבה: בפורטל בענן האפליקציה פועלת מחוץ לתשתית שלכם, בגרסת ה-On-Premise יש לפרוס אותה על המשאבים שלכם. מכאן דרישות שונות להרשאות, עדכונים ולמיקום הפיזי של הנתונים. ההבדל מתגלה לא בהתחלה, אלא בעדכון הראשון של הפורטל או בהחלפת האחראי על האינטגרציה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אפליקציה מוכנה מ-Битрикс24 Маркет | תהליך טיפוסי — משימות, חשבוניות, דוחות, דיוורים — תואם את הלוגיקה של המוצר | אין משנים את הלוגיקה: שדה לא סטנדרטי או אישור עוקפים ידנית; העדכונים תלויים במפתח |
| התאמה אישית לתהליך | קיים נוהל משלכם: מסלול עסקה, סדר אישור, סנכרון עם מערכת הנהלת חשבונות | נדרש גישה לקוד ולתמיכה; אחרי עדכון הליבה בודקים את ההתאמה מחדש |
| פריסה על שרת משלכם | עובדים בגרסת On-Premise, והנתונים לא אמורים לצאת מהסביבה | התפעול כולו עליכם: גיבויים, עדכונים, זמינות מבחוץ |
בפועל משלבים בין האפשרויות: משימות טיפוסיות נסגרות באפליקציה מוכנה, ולצד תהליך מרכזי פורסים אפליקציה משלכם. לפני החיבור אנחנו בודקים אילו הרשאות האפליקציה מבקשת ומה יקרה לנתונים כשמנתקים אותה — מזה תלוי אם אפשר לחזור אחורה בלי לאבד מידע.
סדר ההטמעה: מביקורת הפורטל ועד מסירת הרשאות
התקנת אפליקציה מ-Маркет של Битрикс24 נראית כמו פעולה בקליק אחד — עד הרגע שבו הרחבה חדשה מתנגשת עם אלה שכבר פועלות או מבקשת הרשאות רחבות ממה שדרוש למשימה. אנחנו מובילים את ההטמעה בצעדים קבועים: התוצאה משוחזרת, ומצב הפורטל נשאר צפוי בכל שלב.
- ביקורת הפורטל. עורכים מלאי של האפליקציות המותקנות, התרחישים, הרובוטים והאינטגרציות; מתעדים את התצורה הנוכחית, את הבעלים של כל הרחבה ואת המשימות שהיא באמת סוגרת.
- מפת תלויות. מסמנים אילו אפליקציות ניגשות לאותן ישויות, היכן מתרחשות כפילויות בתרחישים ומה יפסיק לעבוד בעדכון, ניתוק או החלפה של הרחבה.
- הגדרה. מתקינים את האפליקציה, מצמצמים את מערך ההרשאות למינימום הנדרש למשימה, מקשרים לישויות הפורטל הנדרשות ומגדירים התראות לאחראים.
- בדיקה על עותק. מריצים תרחישי מפתח בפורטל בדיקות: הרשאות של תפקידים שונים, סנכרון נתונים, התנהגות בעבודה בו-זמנית של כמה עובדים.
- תוכנית rollback. קובעים נקודת חזרה: סדר הסרת האפליקציה, שחזור ההגדרות הקודמות ורשימת הנתונים שצריך לשמור לפני השינויים.
- מסירת הרשאות. מוסרים חשבונות ניהול, תרשים תלויות, נוהל עדכונים והוראות לעובדים — פעולות שגרה לא דורשות את השתתפות שלנו.
נהלים, תרשימים והרשאות גישה שנשארים אצלכם
הטמעה נחשבת סגורה לא כשהאפליקציות עובדות, אלא כשאפשר למסור את הפורטל למנהל מערכת או לקבלן אחר בלי הסברים בעל פה. להלן סט ארטיפקטים שאנחנו משאירים אחרי הגדרת Маркет: מהם רואים מה הותקן, למה, מי אחראי לכך ואיך לשנות תצורה בלי סיכון לתהליכי העבודה.
- רישום אפליקציות — רשימת המותקן עם הייעוד של כל אחת: איזו משימה היא סוגרת, מי הבעלים, לאילו מדורים, נתונים ומערכות חיצוניות יש לה גישה.
- תרשים תפקידים — התאמה בין תפקידים למערכי הרשאות: מה זמין למנהל, למנהל מכירות, להנהלת חשבונות, לקבלן ולמי האפליקציה בכלל לא מוצגת.
- מדיניות גישה — כללים להקצאה ולשלילה של הרשאות, סדר פעולות בעת העברה או פיטורי עובד, כדי שהגישה לא תישאר "תלויה" על חשבון שכבר לא פעיל.
- נוהל עדכונים — רצף בדיקת גרסאות חדשות: תחילה סביבת הבדיקות, אחר כך התקנה בחלון עבודה, עם תיעוד נקודת חזרה לגרסה הקודמת.
- סדר התקנה והסרה — מי מאשר הוספת אפליקציה, אילו בדיקות תאימות והרשאות מתבצעות לפני החיבור, מה עושים עם הנתונים המצטברים בעת ניתוק.
- מפת קשרים — עם אילו שירותים חיצוניים כל אפליקציה מחליפה נתונים ומה בדיוק מפסיק לעבוד כשהחיבור נשבר.
- הוראות לעובדים — תרחישים שלב-אחר-שלב לפעולות טיפוסיות עם דוגמאות וניתוח שגיאות נפוצות, בלי לפנות למנהל המערכת על כל דבר.
- יומן שינויים — מי, מתי ולמה שינה הגדרות, אילו הרשאות העניק; בניתוח תקלה זה חוסך שעות של אבחון.
סט כזה מסיר את התלות במבצע מסוים: שינויים לא שוברים תהליכים משיקים, ומנהל מערכת חדש מגיע לרמה תפעולית תוך ימים ולא תוך שבועות של התכתבות.
מקרה בוחן: פורטל עם התאמות בכתיבה עצמית ועדכון ליבה
פורטל על Битрикс24, שפותח במשך כמה שנים ברצף, התכסה בהתאמות בכתיבה עצמית: חלק מהלוגיקה ישב ישירות בליבה, וחלק — בתבניות וברכיבים שנכתבו מחדש.
עדכוני הליבה בגלל זה כל הזמן שברו פעם את הקטלוג ופעם את הסנכרון עם 1С, ולכן דחו אותם, ואת הפערים במלאי ובהזמנות סגרו בייצוא ידני — עשרות פעולות בחודש, כל אחת עם ההצלבה והבדיקה שלה.
תחילה הסרנו מפת התאמות: מה עובר למודול משלנו, מה — למטפלי אירועים, ומה משכפל יכולות מובנות וכבר לא נחוץ.
את הסנכרון עם 1С העברנו למנגנון המובנה לפי לוח זמנים עם תיעוד ביומן של כל הפעלה, ולצורך הבדיקה הרמנו סביבת בדיקות עם עותק של מסד הנתונים וסטים של פעולות טיפוסיות להרצה לפני עדכון.
מדדים לפני ואחרי
- ייצוא ידני: 30–40 בחודש → 0, הסנכרון עובד לפי לוח זמנים, ופערים נראים ביומן.
- עדכון ליבה: יומיים עם סיכון ל-rollback → 40–60 דקות בחלון לילה, כי אין יותר עריכות בליבה.
- פניות לתמיכה בנוסח "התקלקל אחרי עדכון": ירידה של כשני שלישים.
- חזרה למצב הקודם בעדכון שנכשל: 15 דקות במקום יממה וחצי של טיפול.
תופעת לוואי שהלקוח שם לב אליה ראשונה: עדכונים הפסיקו להיות אירוע עם תיאום חלון וצוות תורנות בסופי שבוע. הפורטל מתעדכן באופן שגרתי, וההתאמות חיות בנפרד מהליבה ומועברות לענף חדש בלי לכתוב הכול מחדש.
במה התקנה בענן שונה מהתקנה On-Premise
ב-Битрикс24 בענן האפליקציה פועלת בתוך סביבת הפלטפורמה: הרשאות ניתנות דרך בקשת הרשאות בזמן ההתקנה, ובקשות יוצאות מוגבלות לרשימת כתובות מורשות. בגרסת ה-On-Premise השרת וכללי הרשת הם שלכם — יחד עם האחריות על תעודות, פרוקסי וגרסת המפרש.
הפער המרכזי — מיקום הנתונים. בענן הקבצים ומסד הנתונים של האפליקציה נמצאים בתשתית של ספק הפלטפורמה, ואתם לא שולטים לא בגיאוגרפיה של האחסון ולא בגיבויים. ב-On-Premise הנתונים נשארים בתוך הסביבה שלכם — זה טיעון מכריע כשחל נוהל לוקליזציה של מידע אישי או דרישה לבודד את הרשת.
גם היכולת לעדכן שונה. בענן הליבה מתעדכנת מעצמה, והאפליקציה מ-Маркет מקבלת גרסאות חדשות בלי מעורבותכם — ולפעמים שוברת התאמות שנשענו על מבנים קודמים. ב-On-Premise עדכון האפליקציה קשור לעדכון הליבה, ולכן קודם מריצים את העדכון בסביבת בדיקות ורק אחר כך מעבירים אותו לסביבת הייצור.
גישה לשירותים חיצוניים — קו פרשת המים השלישי. הענן מוציא החוצה רק כתובות מהרשימה המאושרת, וקריאות נכנסות עוברות בערוצים רשמיים, ולכן חלק מהאינטגרציות עם מערכות פנימיות פשוט בלתי אפשריות.
On-Premise מאפשר לפתוח את המסלול הנדרש, להקים מנהרה מאובטחת ולחבר את האפליקציה לסביבת הנהלת החשבונות ברשת סגורה.
הבחירה מצטמצמת לשאלה אחת: האם יש לכם סביבה סגורה ודרישות מחמירות למיקום הנתונים. אם לא — הענן נותן פחות תפעול ועדכונים צפויים; אם כן — On-Premise נשאר האפשרות היחידה, אבל דורש סטנד בדיקות משלו ונוהל עדכונים. אנחנו בוחנים סט אפליקציות קונקרטי ומגבלות רשת — ולפיהם מציעים תרשים.
ספקות טכניים נפוצים לפני התקנת אפליקציות
לפני התקנת אפליקציה מ-Маркет לקוחות שואלים את אותן שאלות. הסיכון קשור לא כל כך לפתרון עצמו, אלא לאיך שהוא ישתלב עם פורטל שכבר הוגדר: תהליכים, הרשאות, עדכונים. להלן ספקות שאנחנו מסירים לפני ההתחלה.
מה עושים עם אפליקציות שהתמיכה בהן הופסקה?
משווים את רשימת המותקן לתאריכי העדכונים האחרונים ולעמידה בזרם הגרסאות הנוכחי של הפלטפורמה. אם המפתח הפסיק את התמיכה, מאתרים מחליף או מעבירים את הלוגיקה לתוך הפורטל — הפונקציה נשמרת, והתלות בצוות חיצוני נעלמת.
האם אפשר לבצע rollback להתקנה?
כן. לפני ההתקנה אנחנו שומרים עותק של הגדרות הפורטל, ואחריה מריצים תרחישי מפתח. ה-rollback מחזיר גם קבצים וגם הרשאות גישה; בנפרד מתארים אילו נתונים יישארו בטבלאות של האפליקציה אחרי הסרה.
האם האפליקציה לא תשבור עדכוני פלטפורמה?
קונפליקטים בעדכונים נוצרים במקום שבו האפליקציה משנה מנגנונים מובנים ישירות. בודקים נקודות הרחבה: מה מחובר בדרך נתמכת ומה — בעריכת ליבה. את השני כותבים מחדש לפני העלאה לסביבת הייצור.
האם תהליכים שהוגדרו ייפגעו?
בודקים רובוטים, תהליכים עסקיים והרשאות על עותק של הפורטל: האם טריגרים, תורים ותפקידים לא השתנו. פערים מתקנים לפני העברה לסביבת הייצור.
מי אחראי לקונפליקטים?
אנחנו אחראים לאבחון, התקנה, הגדרה ותאימות — זה התחום של הקבלן. אם התקלה בקוד של האפליקציה עצמה, פונים למפתח שלה בשמכם ומלווים את הנושא עד לתוצאה.
נדון במשימה ונחזור עם תוכנית הטמעה
כדי שהערכת ההטמעה תישען על עובדות ולא על הנחות, אנחנו צריכים גישה לפורטל — לבדיקות או לייצור עם הרשאות מוגבלות — ורשימת אפליקציות שאתם מתקינים מ-Маркет. הוסיפו לכך רשימת תהליכים, תפקידים והרשאות של מחלקות, וכן נקודות סנכרון עם 1С: איזה ספר עזר, באיזה כיוון ובאיזו תדירות מסתנכרן. זה מספיק כדי לראות צווארי בקבוק לפני תחילת העבודה.
בתגובה אנחנו שולחים תוכנית עבודה עם שלבים, הרכב צוות לכל שלב ולוחות זמנים — בלוח שנה, ולא "בהערכה גסה". את התוכנית מתאמים בחלקים: תחילה תרשים הרשאות וסדר החלפת נתונים, אחר כך רצף העלאה ונקודות rollback בכל שלב. כך שינויים בפורטל חי לא שוברים תהליכים קיימים.
מה נכלל בחבילת המסמכים:
- מפת אפליקציות: מה כבר מותקן, מה מתנגש זה עם זה ומה משכפל יכולות מובנות של הפורטל;
- תרשים תפקידים והרשאות: מי מהעובדים רואה מה ויכול לשנות אחרי ההתקנה;
- הרכב הצוות עם תחומי אחריות — אנליזה, הגדרה, קבלה;
- תוכנית בלוח שנה עם תאריכי הדגמות ביניים ונקודות אישור;
- נוהל עדכון אפליקציות וכלל rollback לגרסה הקודמת במקרה תקלה;
- סדר התמיכה אחרי ההרצה: לאן לפנות אם הסנכרון עם 1С נעצר.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית שבה רואים מה ומתי אתם מקבלים.