אני חושבת שכבר סיפרתי שחיפוש העבודה הקודם שלי היה בתחילת תקופת הקורונה – תקופה שהיתה משבר כלכלי, שתוך פחות משנה הפכה להיות תקופה מאוד טובה כלכלית להייטק.
אבל החיפוש שלי היה בדיוק בתקופה הקשה ביותר – זו שבה הרבה עובדים פוטרו או יצאו לחל״ת, חברות מסוימות ניסו לקצץ באחוזי משרה (למשל החברה שממנה פוטרתי שכנראה לא רצתה לפטר עוד עובדים אבל רצתה לחסוך בעלויות ולכן הציעה לאנשים להוריד אחוזי משרה, מה שיכול היה לקסום אז למשל להורים שהיו צריכים להשאר עם הילדים בבית ולנהל להם את הלימודים בזום) – והרבה חברות שגייסו הקפיאו גיוסים או אפילו ביטלו אותם.
החיפוש כמובן היה קשה ולא נעים, אבל אחרי חצי שנה הצלחתי למצוא עבודה. ולמרות שכמובן חיפשתי בכל ערוץ אפשרי – אני חושבת שרוב הראיונות שהגעתי אליהם היו דרך חברות השמה. אמנם היו פעמיים או שלוש תקופה של שבוע או שבועיים שבהם לא היו לי ראיונות, בכל שאר הזמן היה לי לפחות ראיון אחד בשבוע.
בדיעבד יצא לי לשוחח עם הקואצ׳רית שאני עובדת איתה כיום, והיא אמרה לי שאמנם היה בתחילת תקופת הקורונה משבר כלכלי שהשפיע גם על ההייטק, אבל היא טענה שאחרי כמה חודשים הוא נעלם והתעשייה לא רק התאוששה אלא גם התחילה שוב לפרוח. לא הסכמנו מתי השינוי הזה ממשבר לפריחה בדיוק התרחש, ובכל מקרה כנראה שהוא היה הדרגתי, אבל אני עדיין מרגישה שחיפוש העבודה שלי היה בתקופת המשבר. למרות שבעצם בהסתכלות אחורנית בשבועיים שלושה האחרונים של החיפוש שלי בעצם התחילו להיות לי קצת יותר תהליכים – וכשקיבלתי את התפקיד, בדיוק קיבלתי סירוב מחברה אחרת שמאוד רציתי לעבוד בה, והיו שני תהליכים אחרים שהיו לי פעילים ונאלצתי לסרב להם כי הם היו פחות טובים מהתפקיד שהוצע לי.
לכן כשפוטרתי במרץ הרגשתי שאני מכירה כבר את התהליך של חיפוש עבודה במשבר, ושהתרגול הקודם שלי יכול רק לעזור לי. רק כדי לגלות שטעיתי – ובגדול.
קודם כל, נראה שחברות רבות הפסיקו לעבוד עם חברות השמה, שעולות להן הרבה כסף, ומנסות למשוך מועמדים בכל דרך אחרת – אבל בעצם זה מאוד מקשה עלי להגיע למשרות האלו, כי אני לא תמיד יודעת איפה לחפש אותן כדי להגיש מועמדות מספיק מוקדם כדי שיחזרו אלי – בין השאר כי השוק מוצף במועמדים שמחפשים עבודה וכל חברה מקבלת המון קורות חיים לכל משרה.
ובמצב כזה, גם החברה יכולה לדרוש יותר מהמועמדים, כך שמשרות שכנראה הייתי מקבלת זימון לראיון בהן במצב כלכלי טוב יותר – עכשיו דוחים אותי באופן אוטומאטי בלי אפילו לדבר איתי.
במצבים הבודדים שבהם כן הצלחתי להגיע לשיחה עם המגייסת לתפקיד – לרוב הצלחתי להגיע הלאה לראיון הטכני הראשון, אלא אם גילינו פער טכני לא צפוי. לצערי בחברה שמאוד רציתי לעבוד בה המגייסת כן חשבה שיש לי פוטנציאל אבל היה לי חוסר טכני מסוים כך שלצערי למרות שהיא עצמה מאוד התלהבה ממני – המנהלים הטכניים העדיפו שלא להשקיע זמן בלראיין אותי.
והיתה לי גם שיחה עם חברה פיננסית בירושלים שמשום מה גם מנסה לגייס עובדים מאיזור ת״א, שהראיון בה היה בעיקר באנגלית ואיכשהו לא ממש היה דומה לראיונות סטנדרטיים של מגייסות. המגייסת פשוט נתנה לי לדבר על עצמי בעיקר ובלי שאלות מנחות שלה לא ממש היה לי ברור מה היא מחפשת, וכנראה בגלל זה לא הצלחתי לענות על הדרישות שלה.
הגעתי לבערך 4 – 5 ראיונות טכניים, אבל איכשהו לא הצלחתי לעבור אף אחד מהם.
הקטע המוזר הוא שהחלקים בראיונות שדומים לראיונות שהיו לי בעבר הולכים לי הרבה יותר טוב מחלק משמעותי מהראיונות שלי בחיפוש הקודם שלי. בחיפוש הקודם היו הרבה מאוד ראיונות שלא הצלחתי בהם בצורה מאוד קיצונית – נתנו לי שאלה, ולא ממש הצלחתי לענות עליה בלי רמזים או עזרה. אבל בתהליכים שבהם כן הצלחתי להתמודד בצורה יותר טובה עם השאלות האלו, לא פעם עברתי לשלבים מתקדמים יותר בראיונות גם אם התשובות שלי לא תמיד היו מושלמות.
הפעם אני לא ממש נכשלת בשאלות – אולי אני מתקשה מידי פעם ולא בהכרח עולה על התשובה האידאלית מיד, אבל אני לרוב מצליחה לענות. אבל עדיין תשובות שהיו מתקבלות על הדעת כדי לפחות לתת לי צ׳אנס לעבור לשלב הבא בסבב הקודם שלי (והיו מקרים שאפילו עניתי פחות טוב והועברתי לשלב הבא) – נפסלות עכשיו די מיד.
אם הייתי מתכנתת יחסית חדשה, הייתי מבינה את ההבדל ביחס כי במקרה כזה ארבע שנים של ניסיון היו באמת זמן מאוד משמעותי מבחינת רמת היכולת שמצפים ממני, אבל למישהי ותיקה כמוני זה הרבה פחות משמעותי ולכן מוזר לי ששופטים אותי בצורה הרבה יותר מחמירה הפעם.
אבל מעבר לזה, אני שמה לב שיש בראיונות שעברתי רכיב נוסף. פעם היו נותנים לי בעיה ומבקשים ממני לפתור אותה ואז לכתוב קוד שיממש את זה. עכשיו יש בכל ראיון גם שאלה שבודקת גם את היכולת שלי לתכנן מערכת בצורה יעילה.
דוגמא לזה יכול למשל להיות ראיון לתכנן את נטפליקס בצורה יעילה: איך למשל בונים מערכת שאמורה לשדר סרטים למחשבים בכל העולם פחות או יותר, להחזיק מבחר מאוד גדול של סרטים אבל כזה שיכול להיות שונה ממדינה למדינה לפי איך שנטפליקס צריכה לרכוש את הרישיון שלהם – והשירות של נטפליקס צריך להיות מהיר מאוד, וגם שכל סרט שהם משדרים ישודר באופן רציף ולא יקטע ככל עוד למשתמש יש רשת וכל התשתיות של החברה לא מתרסקות לגמרי.
לנו בתור משתמשים זה ברור מאליו שהאתר פועל כך, אבל מי שמתכנן את המערכת צריך לתכנן את המערכת כך שהיא תפעל כמו שצריך וזה דורש המון שיקולים מבחינת תכנון של התוכנה מהרבה היבטים שלה.
הבעיה היא שתמיד עבדתי בחברות גדולות שבהן המוצר היה כבר כתוב, ואני פשוט הייתי חלק מצוותים שהרחיבו את המוצר – ולמרות שבתפקיד האחרון שלי היו פעם פעמיים שבהם הייתי צריכה לעבוד על בעיה שקשורה לאחד המנגנונים האלו, אין לי בהם בגלל ניסיון.
קודם כל, אני חושבת שזה קשור לעובדה שתמיד עבדתי בחברות מאוד גדולות, על תוכנות שכבר היו כתובות ואפילו מבוססות בשוק, כלומר כאלו עם הרבה מאוד משתמשים. במצב כזה, הבסיס שמנהל את התוכנה ביעילות לא רק כתוב וממומש – אלא כבר נבחן לא מעט בתנאי שטח ואם היו בבסיס הזה בעיות, כנראה שרובן המכריע כבר התגלו ונפתרו. מעבר לזה, כשיש לקוח חדש שמוכרים לו את התוכנה והוא צריך להתקין אותה – יש כבר אנשי תמיכה בלקוח שיודעים להנחות אותו איך להתקין את הדברים בצורה יעילה מהצד שלו, וגם ידעו לעזור לו במקרה שעולות בעיות כי ההתקנה לא היתה טובה.
חלק אחר של הבעיה שקרה בתפקיד האחרון שלי אולי נובע ממערכת היחסים הגרועה שלי עם המנהלת שלי שבגלל שהיא לא ממש אהבה אותי (בלשון המעטה) קיבלתי ממנה כל הזמן משימות קלות ופשוטות יחסית, ומשימות כאלו נוטות לא לכלול נגיעה במנגנונים עמוקים, מורכבים וחשובים. אבל כשאני חושבת גם על המשימות של המתכנתים האחרים בצוות שלי – אני חושבת שגם הם בקושי עסקו בדברים האלו. בעצם יש רק היבט מאוד ספציפי של הנושא שעליו יצא לנו לעבוד, וגם זה באופן מאוד נדיר. אני יכולה לחשוב רק על בעיה אחת שפתרנו ואולי פרוייקט קטן אחד שכתב אחת המתכנתים שהיה צריך להתחשב במנגנון הזה. כלומר שני דברים מתוך עשרות ואולי אפילו מאות בעיות שפתרנו או תוספות שהוספנו במשך שלוש שנים וחצי.
זה לא אומר שלא עבדתי על משימות מורכבות – או שלא הייתי צריכה להבין תשתיות מורכבות. זה גם לא אומר שלא הייתי צריכה לחשוב על איך המערכת שלי תעבוד עם הרבה נתונים – אבל השיקולים שלי של ״לעבוד עם הרבה נתונים״ השפיעו על רמה הרבה יותר מקומית של יעילות ולא על תכנון המערכת השלמה.
השאלה היא באמת האם יש לי פה חוסר שלמתכנתים אחרים בתחום אין אותו – או שבעצם יש אותו רק לחלק מהם, והאחרים משלימים את הידע באופן תיאורטי?
התיירת המקרית 
באמת שאלה קשה. את יודעת לזהות מהו אותו חלק שחסר לך? האם אפשר להשלים אותו בדרך כלשהי? [אני מדבר מתוך חוסר הבנה מלא של העולם המקצועי שלך.]
אהבתיLiked by 1 person
אני בהחלט מזהה את החלק החסר, אבל זה בדיוק מה שאני שואלת גם את עצמי – האם אפשר להשלים את הרקע הזה בעזרת תיאוריה בלבד?
אהבתיLiked by 1 person
כיון שאת מתכנתת וותיקה וברור מהקו"ח שלך שעברת במערכות גדולות, לא סביר שדורשים ממך לפתור ולקודד ולהקים מאפס או לפחןת לתכנן מאפס מערכות כמו נטפליקס… ולכן זה באמת נשמע מוזר.
הסבר אפשרי הוא שהשוק כיום הוא הרבה יותר בררני, יש פחות גיוסים והחברות יכולות לדרוש הרבה יותר מהעובדים מאשר קודם
עוד אפשרות היא לבקש ממך משהו שהוא באמת גדול מדי, מסובך מדי או לא הגיוני, ולבחון איך את מתמודדת עם מצבים כאלה.
מצטערת בכל מקרה שזו החוויה שלך עכשיו ושאת מתקשה לשוב לשוק העבודה. מאחלת שפתאום הכל יסתדר והרי צריך שיהיה רק מקום אחד שכן ירצה אותך…. אז הלוואי שזה יקרה ומהר
אהבתיLiked by 1 person
תודה!
אני חושבת שהמטרה של השאלות האלו היא קודם כל להראות שאני מבינה איך בנויה מערכת שמספקת שירותי אינטרנט שלרוב בנויות בצורה מסוימת ודומה בכל המקומות, משהו שאפשר לצפות שמתכנת בכיר יכיר. אבל מעבר לזה, זה גם מראה יכולת חשיבה והתמודדות עם בעיות שיכולות לעלות בעתיד מצד לקוחות.
למען האמת בפברואר האחרון כשהייתי בתורנות האחרונה שלי לעבודה מול לקוחות בתפקיד הקודם – עלתה בעיה דחופה כזו שבאמת נגרמה מעבודה מול לקוח שהיו לו הרבה מאוד נתונים ברמה שלא ציפינו לה, אבל מי שהתמודד עם הגדלת התשתיות שלו היו אנשי התמיכה, ואנחנו רק היינו צריכים לבדוק איך האפליקציה שלנו יכולה לשפר את היכולת שלה להתמודד עם כמות כזו של נתונים.
אהבתיאהבתי
באמת מוזר ששואלים אותך שאלות שאין להן הרבה קשר לתפקיד של תכניתן. אני מניח שזה יותר בכוונה לבדוק את דרך החשיבה שלך – כמו שפעם היו נוהגים לשאול חידות הגיון מוזרות, או "כמה תחנות דלק יש בפלורידה".
באחד הראיונות האחרונים שאני התראיינתי (לפני די הרבה שנים) ביקשו ממני לתכנן מערכת מעליות – אבל זה היה לתפקיד מנהל מוצר אז זה קצת יותר הגיוני.
שיהיה בהצלחה! מקווה שבקרוב תמצאי משרה טובה.
אהבתיLiked by 1 person
גם ממני ביקשו בזמנו לתכנן מערכת מעליות כדי לבחון את יכולת החשיבה.
וכן זה דומה לשאלות של להעריך כמה תחנות דלק יש בפלורידה, ודורש כנראה אימון כדי להגיע לתשובות הגיוניות לזה.
אהבתיLiked by 1 person
אמנם אני לא מחפשת עבודה כרגע, אבל המשבר שנוצר בישראל כתוצאה מהמלחמה הוא שונה לגמרי מהמשבר (העולמי) שהיה בתקופה של הקורונה. עכשיו כל המשק מושפע מהמלחמה, אין ענפים שלא נפגעים מזה גם הייטק נפגע.
בתקופה של הקורונה למדו לנוע תוך כדי המשבר שהיה אז, וכן היו גיוסים לצד פיטורים והוצאה לחל"ת. מה שכן שמתי לב שהמון חברות הפסיקו להעסיק עובדים במיקור חוץ ומעדיפות העסקה ישירה.
מה שכן זה שיש לי X שנים ניסיון מעולם לא גרם לכך שלא יעשו לי מבחנים טכניים מקיפים. ככה זה בכל חברה, הם רוצים לראות שאת מדלוורת את מה שאת אומרת שאת מסוגלת לעשות.
בתחום העיסוק שלי לפחות (אני מומחית תשתיות) השוק תמיד היה בררני והמבחנים תמיד נועדו כדי לעשות סלקציה כדי לבחור את המועמדים היותר טובים ומתאימים מבחינה טכנית (כי בתחום שלי הצד הטכני הוא הצד הדומיננטי).
זה באמת נראה שיש מצב שבגלל המשבר שנוצר כתוצאה מהמלחמה השוק נעשה יותר בררני בגיוסים של מתכנתים. אבל אני תוהה אם אפשר היה באמת לאשר את זה ע"י מגייסות מהתחום.
בתחום שלי תמיד נדרשתי לדעת לעשות את העבודה ברמת המיקרו והמאקרו. לא משנה אם הכרתי בכלל את המערכת לפני כן. ואת רוב המערכות כמובן שלא הכרתי לפני, והייתי צריכה ללמוד תוך כדי תנועה.
ויש לי הרגשה שזה גם מה שמבקשים ממך במבחנים שעושים לך אם כי נראה לי שזה לא מעט עבודה להקים מאפס מערכת כמו נטפליקס למשל. אם כי יש לי הרגשה שהם מחפשים לראות שאת יכולה להקים מאפס מוצר שלא היה קיים, כדי לראות את דפוס החשיבה שלך ולא בהכרח מוצר שצריך עכשיו לשרת מערכת מידע של big data, אלא לראות שיש לך את זה, שאת מבינה איך להקים מוצר כזה ואת איך שהוא אמור לעבוד.
אני לא מכירה את הצורה שזה עובד מהצד של מי שמתכנת.
מאחלת לך המון הצלחה בראיונות הבאים!
אהבתיLiked by 1 person
בגלל הידע הטכני שלך, בואי ואתאתר לך בפרטים יותר טכניים מה מבקשים.
נניח יש לך שירות ווב כמו למשל פייסבוק. אז עקרונית הקליינט הוא בצד של הלקוחות שקוראים עם בקשות להעלות את העמוד עם הפרטים שלהם עם תוכן של החברים והקבוצות שלהם. אז עקרונית יש סרבר, אבל בגלל היקף המידע סרבר אחד יכול מהר מאוד להיות מוצף בבקשות ולא לתפקד מספיק מהר, אז את צריכה בעצם כמה סרברים שיהיה לך load balancer שהוא יקבל לך את הקריאות ויחלק אותן בין הסרברים.
וכמובן שאם הלקול מבצע כמה קריאות, בכל קריאה הוא יכול להגיע לסרבר אחר, אז כל קריאה צריכה להיות עצמאית לחלוטין ולא להסתמך על זה שבסרבר נשמר מידע של הלקוח מהקריאות האחרונות שלו.
אז יש לך את נקודת התורפה הבאה: הדאטה בייס. גם יש לך המון נתונים, וגם יש לך צורך בגישה מהירה אליו, אז את בעצם קודם כל צריכה לבחור דאטה בייס – יש לך דאטה בייס קלאסי שבנוי מטבלאות שהם מאוד מבוססים וחזקים ויציבים ונבדקו המון שנים בשוק, אבל הבעיה שלהם הוא שיש תמיד תלות בין הטבלאות ולכן קשה מאוד לחלק את הנתונים בהם לכמה מכונות אם וכשכמות הנתונים הופכת להיות גדולה מידי בשביל מכונה אחת. מצד שני כיום יש לך כיום כל מיני אלטרנטיבות mongo db למשל שבעצם מאכסן לך מסמכים שלמים או כל מיני דאטה בייסים אחרים ששומרים לך דאטה לא מאורגן, שהיתרון הגדול שלהן שקל מאוד לחלק את הנתונים בין כמה מחשבים כדי שכל אחד מהם יטפל בחלק אחר של המידע, אבל אז לשתף מידע בין כמה גורמים הוא הרבה יותר קשה עד בלתי אפשרי.
ואז כמובן שאת צריכה גם לחשוב על איך את מוודאת שאם דאטה בייס אחד נופל את יכולה להמשיך לתת שירות. אז יהיו לך כמה עותקים של אותו דאטה בייס, כשאחד לרואב יהיה master ויהיו כמה שיהיו slaves, וזה נותן גם אפשרות ליתרון מסוים לכך שבעצם אם ה master הוא זה שמעדכן נתונים בטבלאות, אז את יכולה להגיע למצב שבו ה slaves בעצם מהווים סרברים שמהם את יכולה לקרוא נתונים עם סיכון מסוים שהמדיע לא תמיד יהיה 100% עדכני, כתלות בכמה עדכונים יש לך במערכת (במערכת שבקושי יש בה עדכונים למשל זה די בטוח, במערכת שבה העדכונית מתבצעים בקצב מהיר זה לא). אם זה בר ביצוע, אז בעצם אחד היתרונות הגדולים של המצב הוא שיש קריאה מלא מעט דאטה בייסים מה שמקטין את העומס על כל אחד מהם – ואז אם אחד נכשל עדיין אפשר להמשיך לעבוד.
וכמובן שיש עוד דרך לחסוך קריאות לדאטה בייס שהן יקרות בזה שמבצעים caching מסוים של הנתונים, שזה נושא רגיש כי בעצם הרבה קריאות מהדאטה בייס הופכות את המנגנון הזה למיותר אבל מעט מידי קריאות יגרמו לזה שהנתונים יתישנו. ואת גם צריכה לחשוב על זה שהמקום עצמו מצומצם ואז איך את בוחרת אילו נתונים להשאיר ומאילו להפטר עם מבקשים ממך יותר מידי נתונים?
וכמובן שיש עוד הרבה שיקולים. אז אני מכירה אותם באופן מאוד כללי, ובתפקיד האחרון שלי היו לי כמה באגים שהיו קשורים ל caching – אבל בעצם אף פעם לא הייתי צריכה להפעיל שיקולים על איך למלא אותו במידע או לסלק ממנו מידע, ואם היו בו באגים אז היה צוות אחר היה מטפל בהם ולכן אני מכירה רק דברים בתיאוריה – וכשאני עונה על שאלות זה די ברור.
אהבתיאהבתי
אני אנסה להסביר איך אני רואה את זה מנקודת המבט שלי כאשת תשתיות.
אז קודם כל הdata base צריך להיות שמור על storage.
מערכי storage יודעים לתת שירות לאלפי פניות בו זמנית (וגם יותר מזה, תלוי במערכת עצמה). ואם לצורך העניין צריך יותר מ-storage אחד יש צורך על מנת שה-database שלהם יהיה זהה שהם יתרפלקו כל הזמן אחד עם השני. רפליקציה זה משהו שלוקח פחות משניה (כמה מילישניות בודדות וכן גם אם storage אחד נמצא בניו יורק והשני בLA והשלישי בישראל) זה לא מורגש ע"י הלקוח. וקורה כל הזמן כך שה-database נשאר זהה כל הזמן גם אם הוא נמצא על כמה מערכי אחסון (storage) ולא על אחד בלבד.
היום מבחינת תשתיות תקשורת, מה שאנחנו מקבלים בבתים שלנו למשל לא דומה בשום דבר למה שיש בחברות גדולות (או יותר נכון בחוות שרתים שלהן), יש רוחב פס עצום במיוחד בכל מה שקשור לשירות של שרת-לקוח ולא נוצר מצב שבו יש דיליי בכל מה שקשור להעברת מידע לסוגיו השונים. פעולות קורות במילישניות וזה לא מורגש מהצד של הלקוח (אקא הצד האנושי).
המערכת עצמה שהיא מהצד של החברה שנותנת שירות נמצאת על שרתים. השרתים צריכים להיות זהים 1:1. מבחינת ההתקנות שיש עליהן והגדרות הקונפיגורציה של המערכת שאת בונה. אל השרתים האלה הלקוח פונה דרך תוכנה או כמו שכתבת פה אתר וובי.
המערכת צריכה להיות בנויה כך שהיא יודעת לפנות לstorage בפורטים המתאימים כדי לשאוב מידע ולהחזיר מידע שהלקוח רוצה לראות או לשמור ולעשות שינויים במידע שיש במערכת.
כאשר יש load balance שמנתב את הפניות מהשרתים למערכי הdatabase שיושבים על הstorage או הstorage-ים (אם יש יותר מאחד).
מהצד של הלקוח יש לו תוכנה שמותקנת על המחשב שלו או במקרה כפי שתיארת אתה web-י שדרכו הוא מבצע פעולות, שדרכה הוא מבצע את התהליכים שהוא צריך. התוכנה או האתר יודעים לתקשר עם השרתים (כך שיכול להיות שבכל פעולה אפילו הפניה תהיה לשרת אחר – מי שפנוי). משהו שהלקוח בכלל לא רואה או מרגיש. והפניה נעשית דרך פורטים מוגדרים מראש.
דאטה בייס זה פחות התחום שלי, אבל אני יודעת שאפשר לעשות כל מיני מניפולציות כדי להעלות את היעילות של זה ע"י חלוקה לנושאים ותתי נושאים וכך הלאה כך.
והאמת שעשיתי איזה קורס בדאטה בייס באוניברסיטה אבל זה היה כ"כ מזמן שאני לא זוכרת מזה יותר מדיי, בטח לא את האלגוריתמים שלימדו אותנו על יעילות של הדאטה בייס (וגם פה זה היה עם איזו מערכת שאף אחד נראה לי לא משתמש בה).
זה בעיני חלק שאני לא יכולה להגיד לך משהו שיכול להועיל, כי אין לי מספיק ידע קונרקטי בתחום הזה.
אהבתיאהבתי
זה יותר בקטע של להבין – האם אנחנו רוצים לבחור דאטה בייס של אורקל או של מונגו, ואם כן למה.
או איך אני שומרת על הגודל של ה cache של נתונים שאני מעלה מהדאטה בייס אחרי שהוא מתמלא – איך אני בוחרת איזה מידע לשמור? יש כל מיני אלגוריתמים שהפשוט ביותר אומר לזרוק את המידע הישן ביותר, והיותר מתוחכמים למשל מדברים על לזרוק את המידע שהיה הכי פחות בשימוש, או שהיה בשימוש הכי מזמן.
יש פחו עיסוק ברוחב פס או בנתונים של הרשת.
ודרך אגב, גם כשעדכונים נעשים מהר מאוד, עקרונית יכולה להגיע שאילתא בדיוק בשלה שלפני העדכון כי המערכות מאוד מהירות – וזה מעבר לעובדה שמדברים על זה שצריך לפזר את המכונות בכל מיני מיקומים בעולם כדי לאפשר לא רק זמינות מהירה יותר אלא גם לתת זמינות אם קורה משהו במיקום אחד שמונע מהמחשבים לעבוד – למשל פייסבוק לא תרצה שכל המחשבים שלה יהיו בישראל במקרה שבו החיזבאללה יחליט לשתק פה את כל רשת החשמל.
אהבתיאהבתי
במערכי אחסון למשל יש פונקציה שומרת העתק של השינויים היומיים שנעשים בדאטה בייס (בעצם בכל סוג של מידע שנמצא עליו), הזמן שהמערכת שומרת את זה תלויה בנפח של הדיסק שהוקצה. אבל מקובל שבין שבועיים לארבעה שבועות.
זה לא שהדאטה הישן נמחק, השינויים שנעשו ונשמרו נמחקים בשלב מסויים – נגיד אחרי שבועיים.
ככה שהדאטה הישן נשאר, אם נעשה שינוי, המידע החדש נשמר והמידע הישן (השינוי שהיה) נשמר לX זמן מוגדר מראש. אחרי שהזמן הזה עובר השנוי שנעשה נמחק כי הוא כבר לא רלוונטי יותר.
דאטה אמור להישאר כל הזמן אלא עם הוחלט ע"י המשתמש או הלקוח למחוק את הדאטה הזה, אחרת אין סיבה שהמערכת תחליט בעצמה למחוק מידע ישן אחרי X זמן גם אם לא השתמשו בו.
במקום האחרון שעבדתי בו (חברת פינטק) היו לנו שרתים בשני אתרים (לא בארץ), אחד מהם היה ראשי והשני היה DR. בשני האתרים שרתים זהים לחלוטין והיינו אחת לכמה זמן עוברים לDR לבדוק שהכל עובד תקין עובדים ככה שבוע וחוזרים לעבוד באתר הראשי.
אבל מאוד מקובל ש"לא שמים את כל הביצים בסל אחד" והמון חברות גדולות עובדות עם שרתים ומערכות זהות שנמצאות באתרים שונים בעולם בו זמנית ונותנות שירות מכל העולם בו זמנית ואת לא יודעת אם התחברת לשרת שנמצא במדינה X או במדינה Y כי השירות שאת מקבלת הוא זהה בשני המקומות.
בארץ יש חוות שרתים אחת גדולה מאוד מוכרת שנמצאת בעיר במרכז הארץ, ולא נראה לי שגם אם תהיה התקפת טילים השרתים שנמצאים שם יפלו. גם אל תשכחי שבמקומות כאלה יש גנרטורים שנכנסים לפעולה אם יש הפסקת חשמל.
וחברות ששמות שם את השרתים שלהן יכולות לדאוג אל פסק חזק שיחזיק את המערכות שלהם אם צריך. או לשירותים של גנרטור של החוות שרתים עצמה.
בנוסף, היום יש אופציה להקים שרתים בענן, מה שחוסך לך כחברה את הצורך בלהחזיק שרתים פיזיים במקום מסויים. נכון שזה עולה כסף (יש עלות חודשית לפי הקונפיגורציה) אבל זה משהו קיים שלפני עשור + לא היה למשל.
אהבתיLiked by 1 person
״שׁרתים בענן״ הם עדיין שרתים פיזיים שנמצאים איפשהו, הם רק של חברה אחרת. וגם אם יש גנרטורים בחוות שרתים – הזמן שבו הם יכולים לפעות הוא מוגבל לכמה שעות עד יום יומיים לכל היותר, ואם רשת החשמל תסבול מתקלה שבגללה לא יהיה חשמל לשלושה או ארבעה ימים רצוף, הדלק לגנרטורים לא יספיק.
וברור שיש סרברים בכל העולם שיש בהם העתקים של המידע, ושלמערכות אחסון יש גיבוי שאפשר לחזור למידע של כמה טרנסאקציות אחורה. אבל לא פעם הגיבויים האלו הם חלק מהתוכנה של מערכות הגיבוי, בראיונות מתייחסים בעיקר למנגנונים של המערכות שאנחנו מייצרים.
אהבתיאהבתי
שרתים בענן הם ממש לא שרתים פיזיים שנמצאים איפשהו, אלה שרתים שנבנים על מערכות אחסון גדולות ומורכבות. הבניה שלהם דומה מאוד לאיך ש"בונים" מכונות וירטואליות. את בוחרת נפח אחסון, מעבדים + כמה ליבות יש להם, כמה זיכרון את רוצה. את יכולה בכל שלב בהמשך הדרך לשנות את הנתונים האלה בהתאם לצרכים שלך. מה שאי אפשר ממש לעשות בשרתים פיזיים שנמצאים איפשהו (בטח לא בלחיצת כפתור, וגם כי יש הגבלות חומרה שאת לא בהכרח מודעת אליהן).
זה כמו לבנות משהו בלגו, את בוחרת את החלקים שאת רוצה ומרכיבה. אבל זה לא פיזי, זה ויריטואלי. אם את בוחרת למשל 4 מעבדים שלכל אחד 8 ליבות, זה לא שיש לך את המעבדים האלה פיזית. אותו כנ"ל לגבי כל בחירה של רכיב חומרתי אחר.
מהיכרות שלי עם גנרטורים במקומות כאלה הם יכולים להחזיק הרבה יותר זמן, תלוי כמה דלק יש לך (בניגוד לאל פסק שניזון מחשמל, פה את יכולה למלא דלק).
באחד ממקומות העבודה שעבדתי בהם לפני כמה שנים טובות היה אל פסק שיכל להחזיק את כל השרתים של החברה במקרה של הפסקת חשמל למשך שלושה ימים. וזה היה בסך הכל אל פסק לא גנרטור שיכול להחזיק הרבה יותר מזה ואפשר למלא בו דלק.
במערכות אחסון יש לך אופציה כחלק מהשירות שאת קונה גם להריץ תהליך ששומר את השינויים של הדאטה שקיים בשרת את כל השינויים שנעשים במהלך היום. זה תהליך שרץ בדר"כ מספר פעמים ביום ושומר את השינויים שנעשו בקבצים. זה חלק ממערך האחסון ולא קשור בשום דרך או צורה למערך הגיבויים שעושים לדאטה שנמצא שם. שזה תהליך נפרד לגמרי שנעשה במכונה נפרדת (רובוט גיבוי) ויורד לגמרי לקלטות ו/או דיסקים שנפרדים לגמרי ממערך האחסון עליו נשמר הדאטה.
קוראים לזה shadow copy וזה קיים במערכי אחסון של כל החברות הגדולות כמו IBM, EMC, ISILON (שEMC רכשה אותם), NETAPP. וזה ממש שומר את הדלתאות של השינויים שנעשים בקבצים עצמם.
זה לא מערך גיבוי ולא אמורים להסתמך על זה כגיבוי זה פשוט תהליך שרץ ושומר שינויים שנעשו במהלך היום, בהתאם לכמות הפעמים שהוגדר במערכת לעשות אותם ואפשר להגדיר כל כמה זמן התהליך הזה ירוץ ושוב הוא שומר רק את השינויים שנעשו.
כשעושים גיבויים לדאטה, עושים אותן על קלטות או דיסקים נפרדים, שאותם שולחים למקום אחר שהוא לא במקום שבו יושבים השרתים עצמם או בחברה עצמה (לרוב חברות כמו data bank בישראל) בהתאם לרעיון שלא שומרים את כל הביצים בסל אחד.
מה שכן, במקרה הצורך אפשר להשתמש בפונקציה של ה shadow copy כדי לשחזר מידע יותר עדכני.
ואם אני זוכרת נכון גם במערכות דאטה בייס למיניהן יש אופציה לעשות גיבוי.
אבל כמו שאמרתי אני לא מבינה בזה יותר מדיי, כי זה לא שייך לתחום שלי (תשתיות).
אהבתיאהבתי