המבנה של פער הקלטה
פערים מופיעים בשלוש צורות. פערים מלאים: ההקלטה נעצרה לחלוטין למשך פרק זמן - שירות שקרס, דיסק מלא או מערכת הקלטה שביצעה אתחול. פערים חלקיים: ההקלטה נמשכה לסירוגין - זרם מצלמה לא יציב שנפל וחזר, או זיהוי תנועה שהחמיץ אירועים. פערי תקופת שמירה: הווידאו היה קיים אך נדרס מוקדם מהצפוי, ולכן הפער נמצא בקצה הישן של הארכיון ולא בקצה החדש.
שלושת הסוגים אינם נראים בניטור חי, והסוג השלישי אינו נראה אפילו בבדיקת Playback אקראית. אתמול מתנגן היטב, אך הווידאו החסר הוא מלפני שלושה שבועות, ואף אחד אינו בודק שם עד שזה חשוב.
מדוע פערים מתרכזים דווקא במקום שבו הם כואבים
אירועי חשמל ורשת
פערים מתרחשים במקביל לנפילות מתח ולהפסקות רשת באתר - אותם אירועים שמתרחשים לעיתים יחד עם פריצות ומחלוקות. דווקא פרקי הזמן שסביר שיידרשו לבדיקה הם לעיתים אלה שבהם נוצר הפער.
לילות וסופי שבוע
עומס האחסון עולה ואף אחד אינו צופה. תקלות שמתחילות ביום שישי בערב נמשכות ללא זיהוי עד יום שני - פער של 60 שעות מתקלה שביום שלישי הייתה יוצרת פער של שעתיים.
המצלמות העמוסות ביותר
סצנות עם תנועה רבה יוצרות את מספר אירועי התנועה הגבוה ביותר ואת קצבי הנתונים הגבוהים ביותר, ולכן פוגעות ראשונות במגבלות האחסון והמקודד - מצלמות כניסה ורציפי טעינה מפתחות פערים לפני מצלמת המסדרון שכמעט אין בו תנועה.
המשמעות התפעולית והמשפטית של פערי הקלטה
מבחינה תפעולית, פער הופך שאלה שניתן לענות עליה - מה קרה ברציף הטעינה בשעה 02:40 - לשאלה שתישאר ללא תשובה, יחד עם כל ההשלכות: מחלוקות שלא ניתן לפתור, תביעות ביטוח שמשולמות ללא ראיות וחקירות פנימיות שמסתיימות בחשד במקום בעובדות.
כאשר תקופת שמירת הקלטות נדרשת בחוזה או בחוק, ארכיון עם פערים הוא גם סיכון לציות: הדרישה כמעט אף פעם אינה "להקליט רוב הזמן". ובהקשר משפטי, פערים שיטתיים מזמינים את הפרשנות הגרועה ביותר - הצד השני אינו מניח שהדיסק שלכם התמלא במקרה.
כיצד פועל זיהוי רציף של פערים
- 01
בדיקת מקטעי ההקלטה בכל מצלמה
בכל מחזור בדיקה נשאלת מערכת ההקלטה אילו מקטעים קיימים בפועל בכל ערוץ - אותו מידע שמשמש את מנגנון ה־Playback, אך נקרא באופן תכנותי.
- 02
בדיקת עדכניות ורציפות
המקטע החדש ביותר חייב להיות עדכני, והרצף חייב להיות רציף בהתאם לדפוס ההקלטה הצפוי של הערוץ. רצף חסר מזוהה כפער מדוד עם זמן התחלה ומשך.
- 03
אירוע עם ראיות
הפער פותח אירוע עבור המצלמה המדויקת, מקושר לאחסון, לשעון ולאירועי התקן כדי להצביע על גורם השורש - ומנותב כקריאת שירות לגורם שאחראי על התיקון.
פערים מדודים משנים את השיחה
ברגע שפערים נמדדים במקום להיות רק חשד, השיחה התפעולית משתנה. "מצלמה 12 נראית לא אמינה" הופך ל"מצלמה 12 יצרה ארבעה פערים החודש, תמיד בזמן חלון הגיבוי של 22:00" - זו כבר בעיית QoS ברשת עם פתרון ברור, ולא בעיית מצלמה. היסטוריית פערים לכל מצלמה ואתר היא גם מדד אמיתי לספקי תחזוקה: לא כמה ביקורים בוצעו, אלא כמה רציפות סופקה.
זה המודל ש־IOSentra מיישמת: אימות מקטעים מתוזמן לכל מצלמה, רישום פערים מדודים, זיהוי גורם השורש ופתרון שמנותב לפי SLA - כך שפער הוא אירוע תחזוקה שנמשך שעות ולא גילוי שמתגלה רק כשכבר מאוחר מדי.