אפקט קסלר - מתי יותר מדי?

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

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

מה בעצם אפקט קסלר

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

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

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

מדוע זה צריך לדאוג לעומס מקיף

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

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

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

הפיזיקה של "יותר מדי היא יותר מדי"

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

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

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

הסביבה המודרנית: יותר קבוצות כוכבים, מורכבות יותר

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

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

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

מצבי כישלון שנראים מוכרים לצוותי IT

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

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

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

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

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

תזמון: התלות השקטה שקבוצות רבות מזלזלות

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

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

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

קישוריות: כאשר "קישורי גיבוי" הופכים לסיכון ראשוני

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

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

צוותי IT יכולים לתרגם זאת להחלטות אדריכלות. אם backhaul לוויין הוא חלק מתוכנית ההמשכיות שלך, לתעד אילו שירותים באמת דורשים את זה, אילו ביצועים אתה צריך תחת לחץ, ומה החלופות שלך אם קיבולת הלוויין מוגבלת. במקרים מסוימים, התשובה עשויה להיות תערובת של ספקיות אלחוטיות ארציות, מרובות, צ'נג, אוטונומיה מקומית בקצה, התנהגות יישום degraded-mode.

שיעורי אחריות: אתה לא יכול לתקן את מה שאתה לא יכול לראות

מפעילי חלל חיים בעולם של טלמטריה, מעקב וחיזוי. צוותי IT יכולים לאמץ את החשיבה גם אם מקורות הנתונים שונים. אם הארגון שלך תלוי בשירותים לווייניים, הוסף observability מפורשת עבור תלות אלה. מעקב אחר latency, jitter, נשירת חבילה, התנהגות כושלת ודפוסי שגיאות על ידי אזור וזמן של יום. צפה for anomalies התואמים עם הודעות שירות ידועות, תנאים גאומגנטיים, או חלונות תחזוקה.

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

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

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

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

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

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

ממשל ואחריות משותפת: מרחב מסלול הוא בעיה נפוצה

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

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

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

תרגום סיכון מעשי לתכנון ארגוני

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

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

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

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

תכנון מערכות שסובלות אי ודאות מתמדת

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

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

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

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

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

מה לשאול ספקים וספקים

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

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

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

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

המונחים: runbooks for the sky

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

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

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

האם אפקט קסלר בלתי נמנע?

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

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

סגירה פרגמטית: לטפל בחלל כמו פלטפורמה קריטית משותפת

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

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

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