Dreeze גייסה 33 מיליון דולר בסיד לשחזור יישומי ענן שלמים
Dreeze, שהוקמה בידי יוצאי Zerto, נחשפת עם גיוס של 33 מיליון דולר ומשיקה ב־AWS פלטפורמה לשחזור יישומים שלמים, כולל תשתיות, הגדרות והרשאות.
Dreeze, שהוקמה בידי יוצאי Zerto, נחשפה ב־10 בנובמבר 2026 עם גיוס סיד של 33 מיליון דולר בהובלת Norwest ו־Bessemer ובהשתתפות Claltech. לצד הגיוס הכריזה החברה על זמינות כללית של פלטפורמת Application Revival ב־AWS, שנועדה להחזיר לפעולה יישום שלם, כולל התשתיות, ההגדרות וההרשאות שלו. ההבטחה נוגעת לבעיה מוכרת בניהול מערכות: אפשר לשחזר את הנתונים ועדיין להישאר עם אפליקציה שלא עובדת.
מה הושק: שחזור היישום, לא רק המידע
נקודת המוצא של Dreeze היא שהיישום, ולא קובץ הגיבוי, צריך להיות יחידת ההתאוששות. מסד נתונים הוא רכיב חיוני, אבל השירות שהלקוח פוגש תלוי גם במשאבי מחשוב, בקישוריות, בהגדרות ובהרשאות גישה. אם אחד החיבורים האלה חסר או אינו מתאים לסביבה המשוחזרת, המידע יכול להיות זמין בלי שאפשר יהיה להשלים פעולה עסקית.
Application Revival נועדה לטפל במכלול הזה. לפי Bessemer, השימוש ב־AI הוא במיפוי התלויות בין משאבי הענן, כלומר בזיהוי הקשרים שצריך להביא בחשבון כדי להחזיר את המערכת לפעילות. זהו שימוש ממוקד יותר מהתיאור הכללי של כלי AI לתפעול: השאלה אינה רק מה נמצא בענן, אלא אילו רכיבים צריכים לפעול יחד ובאילו תנאים.
ההכרזה על זמינות כללית ב־AWS מבדילה את הסיפור מהודעת גיוס שמלווה רק בתוכנית למוצר עתידי. עם זאת, עצם הזמינות אינה מעידה שכל שירות ענן או כל ארכיטקטורה נתמכים. בחומר התחקיר לא נמסרו פרטי כיסוי מלאים, תמחור או מדדי ביצועים שמאפשרים לקבוע כמה מהר תתאושש מערכת מסוימת.
למה גיבוי תקין לא מבטיח עסק מתפקד
כדי להבין את הפער, אפשר לחשוב על דוגמה היפותטית של חברת מסחר ישראלית שמפעילה אתר ב־AWS. לאחר תקלה היא משחזרת את מסד ההזמנות, אבל רכיב התשלומים אינו מצליח לקבל הרשאת גישה, ושירות אחר עדיין מפנה לכתובת שאינה פעילה. מבחינת שחזור המידע הושגה התקדמות; מבחינת הלקוח שמנסה לשלם, התקלה נמשכת.
בתרחיש כזה, צוות התשתיות נדרש לשחזר גם את ההקשרים: מי פונה למי, אילו הרשאות נדרשות, ואילו הגדרות צריכות להתאים זו לזו. התיעוד יכול לעזור, אך בדיקת התאוששות צריכה להראות שהקשרים האלה אכן עובדים. זו הסיבה שמדידת הצלחה לפי עצם קיומו של גיבוי עלולה להחמיץ את מה שחשוב לעסק.
הנתונים חזרו הוא תיאור של שלב בשחזור. הלקוחות יכולים שוב לבצע פעולה הוא מבחן ההתאוששות.
אין בכך טענה שגיבויים מיותרים, או שכל כלי גיבוי עוסק רק בקבצים. ההבחנה היא בין שמירת המידע לבין היכולת להפעיל מחדש את השירות שתלוי בו. את ההבטחה של Dreeze צריך לבחון מול המשימה השנייה, ולא להסתפק בהדגמה של שחזור רכיב בודד.
הקשר לסוכני AI: גם סביבת השחזור משתנה
Bessemer קושרת את הצורך במיפוי התלויות גם לסביבות שמשתנות בעקבות פעולות של סוכני AI. כאשר סוכן מורשה לבצע שינויים בתשתית או בהגדרות, מצב המערכת שעליו התבססה תוכנית ההתאוששות עשוי להשתנות. הבעיה אינה עצם השימוש בסוכן, אלא השאלה אם תהליך השחזור משקף את המצב שאליו צריך לחזור.
מכאן נובע מבחן חשוב לכל מערכת שממפה סביבת ענן: לא רק עד כמה המפה מפורטת, אלא האם היא מתאימה לנקודת השחזור הרצויה. מיפוי של המצב הנוכחי אינו בהכרח תיאור של מצב תקין, במיוחד אם השינוי האחרון הוא שגרם לתקלה. זו שאלה מקצועית לבדיקת המוצר, ולא יכולת שאפשר להסיק מההכרזה לבדה.
AI למיפוי תלויות אינו הוכחה לשחזור אוטונומי מוצלח. בחומר התחקיר לא הוצגו תוצאות בדיקה עצמאית או התחייבויות לזמני התאוששות; את היכולת בפועל צריך לבדוק בסביבה שמייצגת את היישום הארגוני.
המשמעות לצוותי ענן ולעסקים בישראל
עבור חברת SaaS ישראלית שמשרתת לקוחות מחוץ לישראל, תקלה ביישום אינה מסתיימת כשהצוות המקומי מסיים לשחזר מידע. נדרשת חזרה לשירות שמאפשר ללקוחות להתחבר, לעבוד ולשמור שינויים. בצוות תשתיות קטן, התלות בעובד שמכיר בעל פה את החיבורים בין השירותים יכולה להפוך לחלק מהסיכון התפעולי.
לכן הזווית המקומית אינה רק זהות המייסדים או היקף הגיוס. היא האפשרות לבחון כלי שנועד לטפל בפער בין אחריותו של צוות התשתיות לבין התוצאה שהעסק צריך. מנהל טכנולוגיות שבוחן את Dreeze יצטרך לתרגם את ההבטחה לתרחיש כשל רלוונטי, עם קריטריונים ברורים להצלחה.
- כיסוי: אילו משאבים, הגדרות והרשאות ב־AWS נכללים בשחזור, ומה נשאר לטיפול ידני?
- הרשאות ובקרה: אילו הרשאות דורשת הפלטפורמה, ומי מאשר את פעולות השחזור?
- תלויות חיצוניות: כיצד מטפלים בשירותי תשלום, זהות או מערכות אחרות שאינם חלק מהסביבה המשוחזרת?
- מבחן עסקי: האם לאחר השחזור אפשר להשלים תהליך אמיתי, ולא רק לראות שהשרתים פעילים?
- תפעול ועלות: מה נדרש כדי להפעיל את הפלטפורמה באופן שוטף ולתרגל התאוששות?
בארגון ישראלי שמחזיק מידע אישי או מסחרי רגיש, חשוב לבדוק גם לאילו נתונים ולהגדרות נחשף מנגנון המיפוי. ההכרזה אינה מספקת בתחקיר תשובות על מיקום עיבוד המידע או תנאי הגישה אליו. אלה פרטים לבירור במסגרת בדיקת אבטחה והתקשרות, ולא מסקנות שאפשר לגזור מעצם הפעילות ב־AWS.
מה הלאה: ההוכחה תהיה בתרגיל ההתאוששות
הגיוס וההשקה מציבים את Dreeze בנקודה ברורה: יש מימון ויש מוצר שהוכרז כזמין, אך הערכתו דורשת יותר מהבנת הרעיון. הרקע של המייסדים ב־Zerto מעניק הקשר מקצועי לסיפור, בלי להחליף בדיקה של המערכת החדשה ושל התאמתה לסביבה של כל לקוח.
השלב הבא מבחינת ארגונים מתעניינים הוא לבחון התאוששות של יישום מייצג בתנאים מבוקרים. אם הפלטפורמה תצליח לצמצם את עבודת האיתור והתיקון שנשארת אחרי שחזור הנתונים, יהיה לכך ערך תפעולי מוחשי. עד אז, החדשות הן הצעה ממוקדת לשימוש ב־AI: לא לייצר עוד תוכן או קוד, אלא לעזור להחזיר תוכנה קיימת לעבודה.
שאלות נפוצות
מה עושה Dreeze ואיך היא משתמשת ב־AI?
Dreeze מפתחת פלטפורמת Application Revival שנועדה לשחזר יישום ענן שלם, כולל תשתיות, הגדרות והרשאות, ולא רק נתונים. לפי Bessemer, היא משתמשת ב־AI למיפוי התלויות בין משאבי הענן.
מה ההבדל בין גיבוי נתונים לשחזור יישום ענן?
גיבוי נתונים מאפשר להחזיר מידע שנשמר, אבל אינו מבטיח שהיישום יוכל לפעול. שחזור יישום דורש גם תשתיות תקינות, הגדרות מתאימות והרשאות שמאפשרות לרכיבים לתקשר זה עם זה.
האם הפלטפורמה של Dreeze זמינה ב־AWS?
Dreeze הכריזה ב־10 בנובמבר 2026 על זמינות כללית של Application Revival ב־AWS. ארגון שבוחן את הפלטפורמה צריך לבדוק בנפרד את הכיסוי לשירותים שבהם הוא משתמש ואת תנאי ההפעלה.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות