דלגו לתוכן
TECH

GitHub מסבירה את התקלה של כמעט 8 שעות: עומס שיא, ולא שינוי בקוד

ב-17 באוגוסט GitHub, Actions ו-Copilot השתבשו ל-7 שעות ו-47 דקות. סמנכ״ל הטכנולוגיות של החברה מסביר שרכיב קריטי לא עמד בעומס שיא, ומפרט את המעבר המואץ ל-Azure.

GitHub מסבירה את התקלה של כמעט 8 שעות: עומס שיא, ולא שינוי בקוד

TL;DR בקצרה

  • התקלה ב-17 באוגוסט נמשכה 7 שעות ו-47 דקות ופגעה באתר, בהתחברות, ב-Actions, ב-API וב-Copilot.
  • לפי GitHub, רכיב תשתית במרכז נתונים במרכז ארה״ב לא עמד בעומס שיא, וכשלי ההתחברות התפשטו לשירותים רבים.
  • מספר ה-commits החודשי עלה מ-1.4 ל-2.9 מיליארד מאז אפריל, ו-Azure משרתת כ-58% מהעומס לעומת 12% במאי.
  • GitHub מוסיפה קיבולת ומגבלות על ניסיונות חוזרים, אבל לא נתנה תאריכי יעד.

ב-17 באוגוסט סבלה GitHub מתקלה ארוכה של 7 שעות ו-47 דקות. התקלה פגעה באתר, בהתחברות, ב-GitHub Actions, ב-API, ב-Pull Requests ובכלי Copilot. ב-20 באוגוסט פרסם סמנכ״ל הטכנולוגיות של החברה, ולאד פדורוב, הסבר מלא על תקלת GitHub. לדבריו, הסיבה היא עומס שיא ולא שינוי בקוד. ״אכזבנו אתכם״, כתב.

מה גרם לתקלת GitHub

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

פדורוב מדגיש ששינוי בקוד או בהגדרות לא גרם לתקלה. זו גם לא הייתה התקלה הראשונה באוגוסט: ב-6 באוגוסט GitHub Actions קרסה. לדבריו, בשני המקרים הבעיה הייתה מחסור בקיבולת.

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

לפי CyberInsider, התקלה התחילה ב-13:40 שעון UTC, כלומר 16:40 שעון ישראל. GitHub הכריזה על סיום רק ב-21:15 UTC. בשיא, כ-20% מהבקשות לאתר ול-API החזירו שגיאה. בהורדות של ארכיונים וקבצים גולמיים, שיעור השגיאות הגיע לכ-50%. התקלה פגעה גם בהתחברות ארגונית ב-SAML וב-OIDC, וגם ב-SCIM וב-Team Sync.

הצמיחה שמאחורי תקלת GitHub

הרקע הוא צמיחה חדה בשימוש. לפי פדורוב, מספר ה-commits החודשי עלה מ-1.4 מיליארד ל-2.9 מיליארד מאז אפריל. לפי CyberInsider, פדורוב אמר שהחברה תכננה תחילה להגדיל את התשתית פי 10. אחר כך היא הבינה שהיא צריכה פי 30, כדי לעמוד בביקוש שכלי AI מייצרים.

GitHub כבר הוסיפה מעל 3 מיליון ליבות מעבד ו-120 פטה-בייט של אחסון מהיר. לדברי פדורוב, החברה התקינה כמה חומרה שהחשמל במרכזי הנתונים הקיימים מאפשר. במקביל, המעבר לענן Azure של Microsoft מתקדם מהר. נכון ל-20 באוגוסט, Azure משרתת כ-58% מהעומס על הפלטפורמה ומחצית מפעולות ה-Git. במאי הנתון עמד על 12% בלבד.

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

המקור המלא: הדיווח ב-GitHub Blog.

מה זה אומר עבורכם

  • הירשמו להתראות: בדף githubstatus.com אפשר להירשם לעדכונים על תקלות. כך תדעו מיד שהבעיה אצל GitHub ולא אצלכם.
  • העבודה המקומית ממשיכה: כל עותק מקומי של מאגר Git הוא עותק מלא. בזמן תקלה אפשר להמשיך לכתוב קוד ולבצע commits, ולדחוף אותם כשהשירות חוזר.
  • הכינו מסלול חלופי לפריסה: כל ה-deploy רץ דרך GitHub Actions? אז תקלה כזו עוצרת גם תיקון דחוף. תעדו דרך ידנית לפרוס גרסה בשעת חירום.
  • צמצמו הורדות ישירות מ-GitHub: תהליכי build רבים מורידים ארכיונים או קבצים גולמיים מ-GitHub. בתקלה הזו, כמחצית מההורדות האלה החזירו שגיאה. שמרו תלויות במטמון או במאגר פנימי.
  • למדו מלולאת ה-Copilot: ניסיונות חוזרים בלי מגבלה מחמירים עומס. במערכות שלכם, הגדירו מגבלה ומרווח הולך וגדל בין ניסיונות.

מה הלאה

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

מקורות והרחבה

  1. The August 17 outage, and the work aheadGitHub Blog
  2. GitHub suffers eight-hour outage affecting Actions, APIs, and CopilotCyberInsider

הכתבה נכתבה במקור בעברית על ידי מערכת GEEKLIK, על בסיס המקורות שלמעלה ובדיקת העובדות מולם.

מצאתם טעות? דווחו לנו

MORE FROM TECH

לכל הכתבות בטכנולוגיה
טכנולוגיה · 16 באוקטובר 2026

פריצת דרך קוונטית של Google: מה היא אומרת על ההצפנה שמגינה על העסק שלכם

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