Self-Healing Infrastructure — תשתית שמזהה ומתקנת תקלות בעצמה

מאת צוות מדיה דיל · 09.08.2026 · Technology · 8 דק׳

מעבר להתראה שמעירה מהנדס בלילה, אל תשתית שמזהה תבנית תקלה מוכרת ומתקנת אותה בעצמה — Restart, Scale, Failover. איך בונים את זה נכון בלי לאבד שליטה על המערכת.

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

מ-Auto-Scaling ל-Self-Healing: מה באמת השתנה

תשתיות ענן כבר מכילות שנים מנגנוני אוטומציה בסיסיים - Health Checks שמפעילים Restart אוטומטי לפוד תקוע, Auto-Scaling שמוסיף מופעים כשהעומס עולה. אלה כללי "אם-אז" נוקשים: אם Health Check נכשל שלוש פעמים ברצף, הפעל Restart. הכללים האלה עובדים היטב לתרחישים פשוטים וידועים מראש, אבל הם עיוורים לחלוטין לתרחישים שלא הוגדרו במפורש מראש.

ה-Self-Healing המבוסס AI מוסיף שכבה שמזהה תבניות מורכבות יותר - קורלציה בין כמה מדדים, השוואה להיסטוריית תקלות דומות, והבנה של הקשר רחב יותר לפני שמחליטים על פעולה. ההבדל המהותי הוא שבמקום כלל בודד וקשיח, יש שכבת ניתוח שמזהה "זה נראה כמו תקלת Memory Leak שראינו לפני שבועיים במודול הזה, והפתרון שעבד אז היה Restart מדורג" - זיהוי שדורש הבנה של הקשר היסטורי, לא רק בדיקת סף בודד.

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

אילו סוגי תקלות מתאימים לריפוי אוטומטי

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

דוגמאות טובות כוללות Restart של תהליך שנתקע (Memory Leak שמזוהה בביטחון גבוה), הגדלת מספר מופעים כשעומס חורג מהצפוי, ניתוב מחדש של תעבורה כשמופע ספציפי מפגין ביצועים ירודים לעומת אחיו, וניקוי Cache שהתמלא. כל אלה פעולות שגם אם מתבצעות "בטעות" כשלא צריך, הנזק מוגבל - במקרה הגרוע ביותר יש בזבוז משאבים קטן או הפרעה זמנית קלה, לא אובדן נתונים או פגיעה בלתי הפיכה.

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

ארכיטקטורת ההחלטה: מ-Detect ל-Act

מנגנון Self-Healing בשל בנוי משלושה שלבים נפרדים בבירור. שלב ה-Detect מזהה חריגה מהנורמה - זה יכול להיות סף פשוט או, במימושים מתקדמים, מודל שלומד את הדפוס הרגיל של המערכת ומזהה סטייה ממנו. שלב ה-Diagnose מנסה להבין מה מקור החריגה - האם זה תואם תבנית ידועה, ואם כן, איזו. שלב ה-Act מבצע את הפעולה המתקנת שהוגדרה מראש עבור התבנית שזוהתה.

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

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

מעגל הבטיחות: Circuit Breakers לאוטומציה עצמה

אחד הסיכונים המשמעותיים ביותר במערכת Self-Healing הוא לולאת פעולה שמזיקה יותר משהיא עוזרת - למשל, מערכת שמבצעת Restart שוב ושוב לשירות שלא באמת תקוע, אלא סובל מבעיה עמוקה יותר שה-Restart לא פותר, וכתוצאה מכך יוצרת downtime נוסף במקום למנוע אותו. ההגנה המרכזית מפני התרחיש הזה היא הגבלת תדירות - אם פעולה מסוימת בוצעה כבר N פעמים בחלון זמן נתון בלי שהתקלה נפתרה, המערכת עוצרת ומסלימה לאדם במקום להמשיך לנסות.

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

למה זה שונה מ-Auto-Scaling רגיל

קורא ותיק בתחום עשוי לשאול - "יש לנו כבר Kubernetes עם Auto-Scaling, מה בדיוק חדש כאן". התשובה היא שכללי Auto-Scaling מגיבים למדד יחיד (למשל שימוש ב-CPU) בלי הקשר. מערכת Self-Healing מבוססת AI יכולה להבחין בין עלייה בעומס שדורשת Scale-Up אמיתי, לבין עלייה בזמן תגובה שנובעת מ-Memory Leak שבו הוספת עוד מופעים רק תדחה את הקריסה ולא תמנע אותה - ותבחר בפעולה הנכונה (Restart מדורג) במקום בפעולה הכללית (הוספת מופעים) שלא באמת פותרת את הבעיה.

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

מי מגדיר את הפעולות המותרות - ואיך זה מתעדכן

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

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

טעויות נפוצות

• הרשאה גורפת לפעולות מתקנות מהיום הראשון - צריך להתחיל מרשימה סגורה וקצרה של פעולות מותרות (Restart, Scale) ולהרחיב רק אחרי שנבנה אמון מוכח.
• אין הגבלת תדירות לפעולות חוזרות - מערכת שמנסה שוב ושוב אותה פעולה בלי שהיא פותרת את הבעיה בפועל מזיקה יותר מהתקלה המקורית.
• חוסר באימות אחרי הפעולה - ביצוע פעולה בלי לבדוק שהיא באמת פתרה את הבעיה מייצר תחושת ביטחון שווא.
• יישום זהה לכל סוגי המערכות - שירות פנימי לא קריטי יכול לקבל אוטונומיה רחבה יותר משירות שנוגע בכספי לקוחות.
• הזנחת יומן הפעולות - בלי תיעוד מלא של כל פעולה אוטונומית, אי אפשר לבדוג בעיות או לבנות אמון עם הצוות לאורך זמן.

דוגמה מהשטח: תקלת Memory Leak שנפתרה בלי מעורבות אדם

שירות שמעבד בקשות API סבל מדליפת זיכרון הדרגתית שהתבטאה בירידה איטית בביצועים לאורך כמה שעות, עד שהמופע היה צריך Restart. הצוות זיהה את התבנית הזו כבר כמה פעמים בעבר וידע שהפתרון הזמני - עד שהדליפה עצמה תתוקן בקוד - הוא Restart מדורג של המופעים לפני שהם מגיעים לנקודת קריסה. הם הגדירו כלל Self-Healing ספציפי: כשצריכת הזיכרון של מופע עוברת סף מסוים תוך כדי שהוא עדיין מקבל תעבורה תקינה (כדי לוודא שזו לא תקלה אחרת), המערכת מבצעת Restart מדורג - מוציאה את המופע מרוטציה, ממתינה לסיום הבקשות הפעילות, ומפעילה אותו מחדש.

המנגנון הזה פעל במשך כחודשיים בלי מעורבות אדם, עד שהצוות תיקן את דליפת הזיכרון בפועל בשחרור נפרד. הערך המרכזי לא היה "לפתור" את הבעיה השורשית - זה עדיין דרש עבודת מפתחים - אלא למנוע השפעה על משתמשים תוך כדי שהפתרון האמיתי היה בתהליך. זה ההבדל בין Self-Healing למה שהוא לא: כלי שקונה זמן ומונע נזק, לא תחליף לתיקון אמיתי בקוד.

שאלות נפוצות

האם Self-Healing מייתר את הצורך בצוות On-Call?

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

איך בונים את הרשימה הראשונית של פעולות מותרות?

מומלץ להתחיל מתקלות שכבר קרו בעבר וידוע בבירור מה הפתרון שלהן, ושהפעולה המתקנת הפיכה וקלה יחסית - כמו Restart. הרשימה מתרחבת בהדרגה ככל שנצבר ניסיון.

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

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

האם צריך ניסיון קודם עם AIOps כדי להתחיל עם Self-Healing?

לא הכרחי, אבל מומלץ. ארגון שכבר עבד עם ניתוח אוטומטי של תקלות (ראו AI Incident Response) נמצא בעמדה טובה יותר להגדיר בביטחון אילו תבניות מתאימות לטיפול אוטונומי מלא.

איזה סוג מערכות הכי מתאים להתחיל בו?

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

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

תגיות: Self-Healing Infrastructure · תשתית עצמאית · אוטומציה בתשתיות · Auto Remediation · AIOps · ניהול תקלות אוטומטי

← חזרה לבלוג · צור קשר