My Partner

האתגר

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

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

הפתרון

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

גבול הראיות

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

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

האתר מתעד בנפרד SDK אבטחת מובייל שמובלרס פיתחה עבור Reblaze. המידע הציבורי על My Partner אינו מזהה את Reblaze כתלות, mobile SDK, ‏API gateway או WAF בפרויקט זה. אין להציג אותו כאינטגרציה ללא אישור בכתב.

מחסנית טכנולוגית ושירותי צד שלישי

גבול טכנולוגי מאומת

• אפליקציית מובייל ללקוחות.
• הנדסת backend בהתאמה לתשתיות Partner.
• פיתוח frontend/UI ואפליקציה.
• התחברות בטביעת אצבע, זיהוי פנים וקוד חד־פעמי.
• דרישות אופטימיזציית שרתים ואיזון עומסים.

לא פורסם

• גישת ושפות המובייל: iOS/Android native, ‏Swift, ‏Kotlin, ‏React Native, ‏Flutter או stack אחר.
• שפת/runtime/framework של backend: ‏Node.js/Express, ‏Java/Spring, ‏.NET או אחר.
• API ותעבורה: REST, ‏GraphQL, ‏gRPC או ממשק אחר.
• מסד נתונים ראשי, cache, אחסון אובייקטים, תורים וסנכרון offline.
• ספק ענן/hosting ומודל deployment: ‏VM, קונטיינרים, Kubernetes, ‏serverless או אחר.
• API gateway, ‏CDN, מוצר load balancing ותצורת autoscaling.
• אנליטיקה, APM, לוגים, crash reporting, ניטור והתראות.
• ספקי push, ‏SMS/OTP, תשלומים, billing, ‏CRM, ‏OSS/BSS, ‏provisioning ורומינג.
• כלי CI/CD, ‏build, בדיקות אוטומטיות, release ו־IaC.

אין להוסיף שם framework או ספק רק משום שהוא סביר לאפליקציית טלקום.

ארכיטקטורה ואינטגרציות

 מנוי Partner
      │
      ▼
 ┌──────────── אפליקציית My Partner ──────────────┐
 │ חשבון/שירותים │ שירות עצמי │ authentication   │
 └──────────────────────┬─────────────────────────┘
                        │ API/protocol לא פורסמו
                        ▼
 ┌──────── גבול אינטגרציה / backend ──────────────┐
 │ אופטימיזציית שרת ואיזון עומסים צוינו          │
 │ הטופולוגיה והרכיבים בפועל לא פורסמו           │
 └──────────────┬──────────────────────┬──────────┘
                │                      │
                ▼                      ▼
      מערכות חשבון ושירות       תהליכי אופרטור
      של Partner                 SIM / רומינג / טכנאי
      (שמות לא פורסמו)

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

התנהגות מימוש מאומתת

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

פרטי מימוש שלא פורסמו

• טופולוגיית monolith, ‏microservices, ‏serverless או hybrid.
• סכמות REST/GraphQL/gRPC, אימות API, ‏OAuth2/JWT ומחזור חיי session/token.
• אינטגרציה ישירה, middleware, ‏message bus, אירועים או batch files.
• שמות מערכות billing, ‏CRM, ‏provisioning, ‏OSS/BSS, שותפי רומינג, תשלום וטכנאים.
• Cache, ‏CDN, תורים, background jobs, ‏load balancer, ‏autoscaling ו־failover.
• לוגים, מדדים, traces, ‏SIEM, כוננות ותגובה לאירועים.

אימות ואבטחה

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

המידע הציבורי אינו קובע אם התאמת הביומטריה השתמשה ב־API מקומי של המכשיר, SDK צד שלישי או בדיקות זהות בצד השרת. הוא גם אינו מפרסם ספק OTP או ערוץ מסירה.

הפרטים הבאים לא פורסמו:

• SDK זהות/אימות ומימוש API ביומטרי.
• יצירת OTP, מסירה, תפוגה, retry, מניעת abuse וספק.
• גרסת TLS, ‏certificate pinning, הצפנה במנוחה, אחסון מפתחות וניהול secrets.
• Obfuscation, ‏anti-tamper, זיהוי jailbreak/root והגנה בזמן ריצה.
• אינטגרציית או גרסת Reblaze ב־My Partner.
• WAF/API protection, תוצאות bot detection, בקרות הונאה ו־rate limiting.
• SAST, ‏DAST, סריקת תלויות, penetration testing, תקינה ותוצאות audit.
• פרטיות, data residency, ‏retention, הסכמה, מחיקה ושיתוף צד שלישי.

הביטוי ״התחברות מאובטחת״ מתאר את אפשרויות האימות שפורסמו; הוא אינו טענה שבקרה או תקינה שלא פורסמו אכן יושמו.

פלטפורמות, השקה ו־deployment

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

לא פורסם

• האם הגרסה שנמסרה תמכה ב־iOS, ‏Android או בשניהם.
• Native מול cross-platform.
• קישורי App Store ו־Google Play, מזהי bundle, גרסאות ואזורי rollout.
• תאריכי התחלה, beta, השקה וגרסאות המשך.
• Rollout הדרגתי מול השקה מלאה.
• כלי CI/CD, תהליך signing, בעלות deployment ואישורי release.
• אחריות תחזוקה, תפעול ותמיכה לאחר ההשקה.

יש להוסיף קישורי חנות רק לאחר אימות שהרישום הוא אותה גרסת מוצר שמובלרס מסרה וש־Partner מאשרת את הפרסום.

צוות מסירה ואחריות

תפקידים שפורסמו: הנדסת backend, פיתוח frontend, ‏UI ואפליקציה ועיצוב UX/UI של מובלרס, בעבודה מול המפרט ותשתיות הבקאנד של Partner.

לא פורסם: שמות; headcount לפי תפקיד; Product Owner, ‏Project Manager/Scrum Master, מובילי מובייל/backend, ‏QA ואוטומציה; תאריכי התחלה ואבני דרך; אחריות לכל אינטגרציה; בעלות תפעול ותנאי תמיכה לאחר ההשקה.

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

תוצאות ומדדים

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

לא פורסמו תקופת מדידה או מקור כמותי עבור:

• הורדות, התקנות, חשבונות שהצטרפו, MAU, ‏DAU או שיעור אימוץ.
• משך session, השלמת משימה, זמן activation, ‏retention או engagement.
• זמן תגובת API, ‏p95 latency, שיא concurrency, ‏throughput או capacity.
• Crash-free rate, ירידת שגיאות, uptime או SLA זמינות.
• ירידה בפניות תמיכה/מוקד ועלייה בפעולות self-service.
• ARPU, ‏churn, הכנסות, conversion או חיסכון בעלויות.
• אירועי אבטחה, מתקפות bot שנחסמו או הונאות שנמנעו.
• שיפור time-to-market מעבר למסירה שפורסמה בכארבעה חודשים.

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

מה פירוש ״ייחודית בזמנה״

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

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

רשימת אישורים לפרסום

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

1. מטריצת פלטפורמה ו־release: ‏iOS/Android, ‏native/cross-platform, קישורי חנות, אזורים, גרסאות ותאריכי השקה.
2. Stack וטופולוגיה: טכנולוגיות מובייל/backend, סגנון API, מסדי נתונים, ענן, scaling, תורים, cache ו־observability.
3. רשימת אינטגרציות: מערכות billing/CRM/OSS/BSS/provisioning/roaming של Partner וכל ספק/API.
4. הצהרת אבטחה: ספקי authentication, זרימת ביומטריה/OTP, הצפנה, app hardening, בדיקות, תקינה וכל קשר ל־Reblaze.
5. דוח תוצאות: adoption, ביצועים, יציבות, זמינות, תמיכה ו־KPI עסקיים עם מקורות ותאריכים.
6. תיעוד מסירה: headcount לפי תפקיד, milestones, חלוקת אחריות, מודל release ובעלות support/operations.

מגבלות ארכיטקטורה

• הדיאגרמה נותנת שמות רק לגבולות פונקציונליים שפורסמו; היא אינה חושפת services או network zones בפועל.
• ״איזון עומסים״ הוא אתגר פרויקט שפורסם, לא אישור ל־appliance, שירות ענן או אלגוריתם מסוים.
• התחברות בטביעת אצבע ובפנים אינה מוכיחה SDK ביומטרי או מודל אחסון מסוים.
• פרויקט ה־SDK הנפרד של Reblaze אינו ראיה ש־Reblaze הופעל ב־My Partner.