פיתוח פלטפורמת וובינרים מקצה לקצה: WebRTC, SFU, CDN

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

פיתוח ותחזוקה של כל סוגי האתרים:

אתרי מידע או יישומי אינטרנט
אתרי תדמית, דפי נחיתה, אתרי חברה, קטלוגים מקוונים, חידונים, אתרי קידום, בלוגים, מקורות חדשות, פורטלי מידע, פורומים, אגרגטורים
אתרי מסחר אלקטרוני או יישומי אינטרנט
חנויות מקוונות, פורטלי B2B, שווקים, בורסות מקוונות, אתרי קאשבק, בורסות, פלטפורמות דרופשיפינג, מנתחי מוצרים
יישומי אינטרנט לניהול תהליכים עסקיים
מערכות CRM, מערכות ERP, פורטלים ארגוניים, מערכות ניהול ייצור, מנתחי מידע
אתרי שירות אלקטרוני או יישומי אינטרנט
פלטפורמות מודעות, בתי ספר מקוונים, בתי קולנוע מקוונים, בוני אתרים, פורטלים לשירותים אלקטרוניים, פלטפורמות אירוח וידאו, פורטלים נושאיים

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

השירותים שאנו מציעים
מציג 1 מתוך 1כל 2062 השירותים
פיתוח פלטפורמת וובינרים מקצה לקצה: WebRTC, SFU, CDN
מורכב
מ- 2 שבועות עד 3 חודשים
שאלות נפוצות

פיתוח פלטפורמת וובינרים: היכן השידור נשבר

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

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

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

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

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

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

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

מה נותנת ארכיטקטורת וובינרים מנוהלת בשיא

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

עומס שיא: כמה צופים מחזיק שידור אחד

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

עמידות לתקלות: מה קורה כשצומת הפצה נופל

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

עמידות השידור ב-WebRTC נבנית בדיוק על חיבור מחדש, ולא על הפעלה ידנית מחדש של השידור: זמן השחזור נמדד בשניות במקום בעשרות דקות.

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

השוואת סכמות שידור: עמית-לעמית, שרת מדיה, היברידי

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

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

חיבור ישיר בין המשתתפים

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

שרת מדיה והפצה דרך רשת הפצה

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

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

שלבי הטמעה: מסכמת עומס ועד להשקת שידור

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

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

בדיקת עומס: איך מדמים שיא

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

חבילת מסירה: קונפיגורציות, סכמות זרימה, נהלים

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

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

מדיניות גישה והפרדת תפקידים

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

מקרה בוחן: גידול בצופים בו-זמנית בלי לאבד איכות

הלקוח הגיע עם שידורים של 800–1000 צופים בו-זמנית: שרת אחד קיבל את הזרם והפיץ אותו ישירות. בשיא של כ-2,000 חיבורים התחיל חוסר סנכרון בין שמע לתמונה, חלק מהצופים נזרקו עם שגיאה, ושיעור הסשנים הקטועים הגיע ל-7%. הקלטות נאספו ידנית — בעומס יתר מקטעים אבדו, והיה צריך לבדוק את הארכיון עבור כל וובינר.

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

מה שינינו בסכמת ההפצה

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

שלושה שבועות אחרי המיתוג השידור החזיק בביטחון 12,000 צופים בו-זמנית, שיעור הסשנים הקטועים ירד ל-0.4%, זמן העלייה לשידור הצטמצם מ-15 דקות ל-2, ושיעור ההקלטות ללא אובדן עמד על 99.7%. איכות התמונה כבר לא צנחה בשיא: צומתי ההפצה הופעלו מראש, לפי תחזית ההרשמות.

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

מה לעשות אם השידור כבר עובד, אבל לא סוחב את העומס?

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

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

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

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

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

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

ספקות טכניים: השהיה, הקלטה, גישה, תמיכה

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

איזו השהיה ריאלית וממה היא תלויה?

שני מצבי עבודה. אינטראקטיבי — המרצה והצופים בדיאלוג אחד: השהיה של 0.3–1 שניות, אבל הוא כבד יותר בעומס על השרתים ותובעני יותר כלפי הערוץ של המרצה. המוני — 5–20 שניות בהפצה מפולחת דרך רשת הפצה: מחזיק עשרות אלפי צופים בו-זמנית.

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

מה קורה כשלצופה יש ערוץ חלש?

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

איך להטמיע את הנגן באתר או באפליקציה שלכם?

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

מה נשאר אחרי השידור ומה כלול בתמיכה אחרי ההשקה?

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

נדון במשימה: נאסוף דרישות ונחזור עם תוכנית

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

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

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

הכישורים שלנו:

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1393
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1368
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1139
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1152
  • פיתוח אתר עבור SBH Partners
    פיתוח אתר עבור SBH Partners
    1231
  • פיתוח אתר עבור Red Pear
    פיתוח אתר עבור Red Pear
    641