חשיבת מפתחים לטווח רחוק..

[katz]

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

מסתבר כי הסיבה לבאג הייתה בחוסר חשיבה של המפתחים לטווח הרחוק. היא נובעת משמירת התאריך כמשתנה int32, יכול לקבל ערך מרבי של 2,147,483,647, אבל הערך של השנה החדשה עומד על מספר גדול יותר – 2,201,010,001 לפחות. התוצאה הייתה שהסריקה של הדואר היוצא הייתה לא תקינה – וההודעות נחסמו.

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

[רפאל]

@katz אמר בחשיבת מפתחים לטווח רחוק..:

הערך של השנה החדשה עומד על 2,201,010,001

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

Date(year: 22, month: 01, day: 01, hour: 00, minute: 01)

אגב שימוש בUnsigned Int היה מאפשר עשרים שנה נוספות.

[ארכיטקט]

@katz אמר בחשיבת מפתחים לטווח רחוק..:

טיפה יותר זמן

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

[חגי]

@katz

ניסו פעם לשגר טיל לחלל, והיה להם overflow דומה שגרם להרס של הטיל אחרי 37 שניות מההמראה.
הנה הכתבה שמסבירה מה היה בדיוק.
https://www.bugsnag.com/blog/bug-day-ariane-5-disaster

בכתבה כתוב שהoverflow נגרם בגלל המרה בין float ל-short

[nigun]

@katz
אהבתי את הפתרון שלהם
פשוט להשאר בשנת 2021
ולשנות את השם של העדכון ל2112330001
דהיינו ה33 לדצמבר
והם כותבים

The scanning engine will continue to receive updates in this new sequence.

אז מסתבר שימשיכו לעדכן עד 2112990001
ואז יצטרכו לעבור לחודש ה13.....
אא"כ יחליטו לעדכן את המשתנה לUnsigned Int וידחו את הבעיה לעוד 20 שנה.

בכל אופן לא נראה שזה נובע מכך שלא חשבו קדימה
אלא פשוט מתכנת שלא ידע מה המגבלות של signed Int.

[יוסף בן שמעון]

@ארכיטקט אמר בחשיבת מפתחים לטווח רחוק..:

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

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

[aaron]

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

[רפאל]

@nigun אמר בחשיבת מפתחים לטווח רחוק..:

בכל אופן לא נראה שזה נובע מכך שלא חשבו קדימה, אלא פשוט מתכנת שלא ידע מה המגבלות של signed Int

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

[ארכיטקט]

@יוסף-בן-שמעון אמר בחשיבת מפתחים לטווח רחוק..:

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

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

[צדיק תמים]

@ארכיטקט אמר בחשיבת מפתחים לטווח רחוק..:

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

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

וכמו ש @יוסף-בן-שמעון אמר בחשיבת מפתחים לטווח רחוק..:

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

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

[ארכיטקט]

@צדיק-תמים אמר בחשיבת מפתחים לטווח רחוק..:

כמובן שאפשר לחלוק עליי...

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

[צדיק תמים]

@ארכיטקט לכן כתבתי שאפשר לחלוק, כדי שאף אחד לא ירגיש צורך להתנגד...