סופרמן, אנגלית, דקדקנות מיותרת והצפנות

אני מדבר שתי השפות

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

מחר אני מתחפש לסופרמן

עד לא מזמן היה ג'ו אוניסיק אושיית טוויטר בעולם ה IT. קצת הילד הרע של הטוויט-IT הוא צבר לעצמו שם של טרבל מייקר עד שיום אחד נעלם מהרשתות וירד למחתרת. באותם ימים הוא היה הפנים הקולניות יותר של Cisco ACI וחלק מהרעש שהיה מעורב בו הוא הקרב בין ACI ובין VMware NSX. לדעתי ברור מי ניצח, למרות האתגרים ולמרות שזה עדיין לא באמת פתרון קל ליישום כמו שזה יהיה בעתיד, NSX ניצח בגדול.

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

 

מכירים את הקלישאה של dress for the job you want? ובכן לא בכל מקום זה יתקבל בעין יפה אם תתחילו לבוא למשרד בגלימה של סופרמן אבל ההרחבה של הקלישאה הזו כמו שג'ו אוניסיק מציג בסרטון שלו היא שאתם יכולים להתחיל לעשות את התפקיד שאתם רוצים כבר עכשיו, בלי משא ומתן, בלי הגדרות תפקיד מחדש ובלי תארים מפוצצים, רואים משהו שצריך להיעשות בחברה או שצריך להיעשות טוב יותר? תתחילו לעשות אותו. ברוב המקומות, תחת רוב המנהלים, זה יעבוד ולא רק שזה יעבוד, אנשים מסביבכם יסתגלו מהר מאד ואם תיראו כאילו זה התפקיד שלכם לעשות משהו, אז הם פשוט יקבלו את זה כעובדה, זה התפקיד שלכם לעשות את מה שאתם עושים.

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

גדילה זה לא תמיד חיובי

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

takethemoneyandrun

זמינות חלפים ושאלות מיותרות

היום שאל אותי לקוח קוריאני מה ה MTBF של הדיסקים שלכם? זה הזכיר מקרה מלפני כמעט שמונה שנים כשהייתי יחסית חדש בחברת אנקור, לקוח מכפר נטר גרם למנהל המכירות של אנקור להתקשר אלי באחת עשרה וחצי בלילה, אתם מבינים EMC השתמשו אז בדיסקים מסוג eMLC אבל NetApp שאנחנו ייצגנו השתמשו רק ב MLC ובגלל זה אנחנו עומדים להפסיד את העיסקה. נו בחיאת. מצד אחד, יש ערך לירידה לפרטים ומצד שני יש חובה לדעת את ההבדל בין עיקר לתפל. אנחנו באינפינידט היחידים שמתחייבים בכתב לשבע תשיעיות של זמינות על המערכות שלנו, ואנחנו עושים את זה דווקא עם רכיבי החומרה הכי פשוטים שיש בעולם האנטרפרייז, אנחנו מספקים סדר גודל שלם מעל המתחרים הקרובים שמציגים שש תשיעיות בלי לזרוק כסף על חומרה יקרה ומורכבת מדי, שני סדרי גודל מעל הסטנדרט המקובל בתעשייה של חמש תשיעיות ושלושה סדרי גודל מעל ספקיות הענן הגדולות בלי להיגרר לטרנדים הכי חמים בתעשייה סתם ככה לשם הטרנדיות ועדיין מישהו רוצה לדעת שהדיסק הבודד שאמכור לו בתוך המערכת יכול להחזיק 2,000,000 שעות עבודה רציפות בממוצע. לך תבין. ואם הממוצע הוא רק 1,800,000 שעות עבודה רציפות לדיסק בודד איזה השלכה יש לזה על הביזנס שלך אדוני הלקוח?

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

המשמעות של תלות בחומרה והדרישה להצפנה לגבי מודלים עסקיים

השבוע נחשפה חולשה מובנית בהצפנה החומרתית של דיסקי SSD וכתוצאה מכך חולשה מובנית במנגנון ההצפנה BitLocker שמשתמש בהצפנה חומרתית כברירת מחדל. פועל יוצא מחולשות כאלו ולצדן חוקי הרגולציה  המחייבים הצפנת מידע, הוא הכורח להצפין ברמת האפליקציה ולא ברמת התשתית. נשאלת השאלה מה יקרה למודל הכלכלי של יצרניות ה All Flash כולו? עד לא מזמן, יצרניות כמו NetApp סיפקו יכולות Deduplication ככלי טכנולוגי, הלקוח שילם על נפח דיסק ואם בזכות ביטול כפילויות הצליח לכתוב על הנפח הזה יותר מידע, הוא הרוויח. היום המודל הפוך, בגלל העלויות הגבוהות של מערכות מבוססות פלאש, הלקוח משלם על נפח דיסק ולמעשה מקבל שליש, רבע או לפעמים אפילו חמישית מהנפח שקנה. היצרניות השונות מתחייבות לספק את כלל הנפח הנרכש באמצעות ביטול כפילויות ודחיסה וכך הכלי הטכנולוגי הפך להיות כורח כלכלי אבל מה יקרה אם המידע יוצפן במקור? הרי היכולת לדחוס מידע מוצפן או למצוא כפילויות בו יורדת לאפס?

כמו תמיד שמח לשמוע פידבק על מה שכתבתי אז אל תהיו ביישנים!

שלכם,

ניר מליק

מודעות פרסומת

פוקה-יוקה, קאיזן ומכרזים מחורבנים

סיפרתי לכם פעם כמה אני שונא מכרזים?

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

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

אצלנו, מאד מקובל לבצע תהליך אפיון מאד מפורט כולל שימוש בכלי אפיון כמו למשל VMware Capacity Planner או ניתוח קבצי NAR של מערכות EMC, Perfstat במערכות NetApp וכו'. אנחנו לאחרונה משתמשים קצת ב mitrend כדי לאסוף ולנתח ביצועים של מערכות שונות וליצר גראפים נוחים לשימוש.

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

במזרח נתקלתי לאחרונה בכמה מקרים שבהם אין שום דרישת ביצועים במכרז, כלום. נפח אחסון נדרש וזהו. עכשיו מתחיל החלק האומנותי, בחלק מהמקרים אין שום דבר אחר, ואז אני חושב לעצמי שמי שפרסם את המכרז פשוט לא מבין בסטורג', קורה. במקרים אחרים רואים משהו אחר, והוא מטריד הרבה יותר, מישהו מפרסם מכרז ללא דרישת ביצועים אבל עם מפרט מאד מדויק של מערכת האחסון שהוא דורש, כמו נניח דגם מעבדים ספציפי או יכולת גידול לכמות בקרים גדולה פי 20 ממה שהוא דורש ביום הראשון. במקרים כאלו ברורה כוונת המשורר, הרי אלא אם אתה יצרן מערכות אחסון בעצמך, אין לך דרך ריאלית לבדוק את ההשפעה על הביצועים בשימוש במעבד 3GHz לעומת שימוש במעבד 3.2GHz  וגם בואו נהיה הוגנים, בניגוד למה שמראים לנו במצגות בכנסים, הסיכוי שאנחנו נישאר עם אותה מערכת בדיוק גם בגידול פי 20 לא סביר כל כך, הרי גם אם אתה בר מזל והעסק שלך אכן גדל פי 20 בטווח הנראה לעין, הארכיטקטורה שלך תשתנה עוד מיליון פעמים בדרך כדי לתמוך בכזה גידול, שום דבר שעובד ב1 לא עובד ב 20 as is, אז למה לקשקש?!

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

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

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

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

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

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

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

עלו והפוקה-יוקו כולכם! קאיזן על בתיכם ומשפחותיכם ומועדים לשמחה!

שלכם,

ניר מליק

נגרי כדורגל ותיאום ציפיות

Yes I'm a vExpert!

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

צחוק בצד, זה נעים לקבל הכרה וכבוד להשתייך לרשימה מכובדת של מקצוענים. הצטרפו אלי גם אתם! ליצרנים רבים יש תוכניות דומות ואתם יכולים לבחור מי היצרן\טכנולוגיה הקרובים ללבכם, Veeam Vanguard, VMware vExpert, Cisco Champion, NetApp United  וכו'.

אגב, כל התוכניות האלו נקראות בלעז advocacy programs ואני לא בטוח איך לתרגם את זה לעברית, יש לכם רעיונות?

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

vexpert

נגרי כדורגל

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

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

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

Maradona_1986_vs_italy

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

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

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

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

תיאום ציפיות

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

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

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

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

ספרו לי מה דעתכם אני צמא למשוב!

שלכם כמו תמיד,

ניר מליק

זמינות, ביצועים, גיוסים ורכישות עצובות

זמינות

בפוסט הקודם דיברנו על Data Mobility כאחד המאפיינים של Neutrix Cloud והשבוע אפשר לדבר על מאפיין נוסף, Availability.

מערכות האחסון של Infinidat מספקות רמת זמינות של שבע תשיעיות המתורגמות לפחות משלוש שניות (3.16 אם רוצים לדייק) של השבתה לא מתוכננת בשנה. זה שיפור מאסיבי לעומת סטנדרט של חמש תשיעיות (5.26 דקות של השבתה בלתי מתוכננת) שמספקים מרבית המתחרים בדוק האחסון היום ובטח שמדובר בקפיצה לעומת ארבע תשיעיות (52.6 שעות) שמספקים ספקי הענן הגדולים.

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

*מי שרוצה לקרוא עוד על תשיעיות וזמינות מוזמן לקריאה נוספת בוויקיפדיה

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

azure sla

אבל אם שכבת האחסון שלכם מבוססת Neutrix, אתם מסוגלים להשתמש בו זמנית בשירותי המחשוב של AWS, Azure וגוגל, כן בו זמנית! זה אומר שאם יש בעיה עם תשתית המחשוב של אחד מהם, אתם מסוגלים להמשיך ולספק שירות ללקוחות שלכם!

neutrix sfd16

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

amazon cnet

amazon twitter

amazon verge

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

aws zednet

אגב התמונה של Neutrix היא צילום מסך מתוך מצגת שהעביר אריק קולברג שלנו במסגרת Storage FIeld Day 16 ואתם מוזמנים לצפות בה כאן אם אתם רוצים ללמוד עוד קצת על Neutrix

וסתם ככה כדרך אגב במסגרת SFD 16 בריאן קרמודי שלנו העביר מצגת עם neural Cache ואפשר לראות כאן מה חושב ריי לוקזי על היכולת שלנו לספק מעל 90% מה REad IOPS שלנו מתוך ה Cache

ביצועים או יש ביצועים ויש ביצועים

חברת NetApp שחררה לאחרונה תוצאות SPC-1 מאד מרשימות עבור מערכות ה A800 שלה.

בדו"ח שניתן לקרוא במלואו כאן, מספרת החברה כי הצליחו להגיע ל 2.4 מיליון פעולות בשנייה מה שמעמיד אותם במקום הרביעי אי פעם אחרי 3 מערכות של Huawei. מדובר בהישג טכנולוגי מאד מרשים עבור חברה שבעבר אמרו עליה שפספסה את רכבת ה All Flash אבל אני רוצה לשאול כאן, עד כמה ההישג הזה רלוונטי בכלל ללקוחות?

שימו לב למבנה המערכת. 12 בקרים של הסדרה הכי גבוה של היצרן בשביל לדחוף סה"כ 273 טרה ברוטו עם רמת ניצולת של 66% בלבד כלומר 182 טרה או 15 טרה לבקר. מכירים הרבה אפליקציות בחיים האמתיים שדורשות ארכיטקטורה כל כך מוזרה? שמסוגלות לחיות בכזו סביבה בכלל? מה גם שבשביל לקבל את הביצועים האלו היה צורך לכבות Inline Dedup, לכבות Aggr level Dedup ולא לבצע Snapshots בכלל.

netapp cluster spc-1

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

זו אגב הסיבה שאנחנו משתדלים להשתמש רק ב workload אמיתי של לקוחות כחלק מאתגר ה Faster Then All Flash שלנו עליו סיפרתי לכם כאן וכאן. בסופו של דבר, מרבית מערכות האחסון בעולם לא משרתות איזה כלי בדיקות כמו VDbench אלא מערכת אמיתית כמו MS-SQL, אורקל או SAP HANA וזה אמור להיות הרבה יותר מעניין עבור לקוחות מאשר מה תיאורטית המכונה היתה עושה במעבדה בתנאים אידיאליים. החיים לא אידיאליים.

גם איגוד SNIA מסכים איתנו כנראה כי הם עובדים על תקן חדש שאמור לדמות עומסים אמיתיים יותר מהחיים כדי לבצע benchmark מקובל על כולם אבל עם ערך ישיר יותר למקבלי ההחלטות

* אני בכוונה כותב פעולות בשניה ולא IOPS כי פעולות SPC-1 הן לא IO טהור אלא מנסות לדמות טרנזקציה הכוללת כמה IO בכל טרנזקציה. אחרת אפשר היה לשאול מה בעצם כל כך מרשים ב 200K IOPS  לכל בקר בימינו

גיוסים

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

למי שלא מכיר SQream מייצרים Database מבוסס GPU  ככה שהשאילתות רצות על כמה אלפי ליבות ולא רק על 24 או 48 או כמה ליבות שיש ל CPU של השרת. הקונץ היפה הוא שמדובר ב Database העונה לשפת SQL סטנדרטית ככה שלא צריך ללמד DBA זקנים טריקים חדשים (כן כן SQL זו שפה ולא רק מוצר של מיקרוסופט מי היה מאמין).

בשדה התעופה בדרך הביתה פגשתי אותם שוב והיה לנו קצת יותר זמן לקשקש (אתם חייבים לי בירה!) ואז גיליתי ש SQream השלימה לא מזמן סיבוב גיוס מאליבבה שהשקיעה 24 מליון דולר בחברה בסדרה B. כל הכבוד חברים המשיכו ככה!

רכישות עצובות

בפוסט שנקרא there is no I in team סיפרתי לכם ש Tintri עומדת בפני פשיטת רגל ואכן בשבוע שעבר זה קרה, החברה הודיעה על סגירת פעילות וDDN הודיעו שהחלו משא ומתן לרכישת נכסי החברה. זה צעד מעניין מצד DDN כי אין להם מוצר שמתחרה בקטגוריה של production storage ויש כאן פוטנציאל להקפיץ אותם אל תוך הטבלה של הקטגוריה הזו אבל מצד שני גם בשיא כוחה טינרטי הייתה שחקן נישה קטן ועכשיו DDN צריכה לשחק בשוק חדש ולא מוכר לה עם מוצר שגורר אחריו שם בעייתי. ימים יגידו אם אכן הם ישלימו את הרכישה והאם היא השתלמה להם.

זה הכל להפעם,

כרגיל אשמח לשמוע מה דעתכם, אז תכתבו!

בונוס למצטיינים – באחת התמונות יש טעות, בין המזהים נכונה תוגרל תמונה שלי אוכל סרטן כבוש בסיאול

*ההשתתפות אסורה על ליאור קמרט שגילה לי את הטעות במקור

ניר מליק

Data mobility – Mark Watney, Homeland security and Dolores Abernathy

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

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

rurecieving

קרדיט תמלול

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

השבוע אני במרתון של העונה השנייה של ווסטוורלד. לדעתי הסדרה היא יצירת מופת ואני מאד מקווה שהיא לא תלך לאיבוד כמו שקרה לסדרה אבודים בזמנו. פתאום, באמצע פרק 4, זה קפץ לי לראש, הקשר בין מט דיימון, זיהוי פנים ודולורס היפה. צוות ה IT של דלוס לא דאגו לגיבוי Off Site כמו שצריך ובעצם כל עלילת העונה השנייה מתאפשרת רק בגלל שהם דחפו את כל המידע הקריטי שלהם אל הראש של אבא של דולורס, Old man Peter Abernathy, זו הסיבה היחידה שבעצם QA לא מכסחים את כל האתר בכוח (מעניין שדווקא QA הם כוח השיטור והאכיפה).

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

כשאנחנו מתחברים אל מערכת הניהול שלנו באמזון למשל, אנחנו יכולים להקים כמה עשרות שרתים כמה קליקים של עכבר. בעולמות של קונטיינרים אנחנו יודעים להרים כמה אלפי קונטיינרים בכמה שורות פקודה. מחשוב, Compute, בענן זה בדרך כלל באמת קל וזריז כמו שמספרים לנו. אבל מידע זה אחרת. כמה זמן ייקח להעביר 10 טרה אל הסביבה שהקמת באמזון? כמה זמן ייקח להעביר 100 טרה? כמה זמן ייקח להעביר פטה? כמה יעלה לכם להעביר 350 טרה מאמזון אל גוגל? כמה יעלה לכם להעביר 200 טרה מאז'ור אל חדר השרתים שלכם בחזרה? אתם יודעים בכלל איך לעשות זה?

INFINIDAT Neutrix

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

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

AWS SLA

ואותו הדבר גם ב Azure:

azure sla

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

aws latency

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

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

grego

שלכם כרגיל,

ניר מליק

 

There is no I in Team

There is no I in Team

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

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

תריצו את הקטע ותחזרו לקרוא:

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

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

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

_ עריכה _

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

https://open.spotify.com/episode/6gINYJEVjWwvZ0V90yxvtX

 

 

בעיה מטרידה בוורד

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

fa5168c4-0522-43c0-a4f6-bc7176cf4690

 

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

_ עריכה _

תודה לאלכס!

מצאתי את ה Add-In שהטריף אותי והסרתי אותו ובא לציון גואל!

addin

 

בכל אופן טיפה חדשות IT

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

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

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

נו טוב זה מספיק להיום, בפעם הבאה אכתוב על Neutrix כמו שהבטחתי

דברו אלי אם יש לכם תובנות על בעיית הוורד שהצגתי

ניר מליק

 

RPO Zero from downunder

RPO Zero from downunder

הפוסט הקודם נכתב מיפן, התחנה הראשונה בסיבוב של שבועיים שכללו את טוקיו, סידני, מלבורן ובריסביין. הנסיעה כולה תוכננה סביב כנס גרטנר בסידני (השם המלא של האירוע הוא IT Infrastructure, Operations Management and Data Center Summit אבל אף אחד לא משתמש בו) במסגרתו הרציתי על הפתרונות החדשים שהשקנו לאחרונה ביניהם דגם חדש למערכת האחסון הראשית שלנו, F6212 המספקת מעל 4PB נטו בארון אחד, מערכת ייעודית לגיבוי, אותה הזכרתי בקצרה בפוסט קודם אבל מאז הוכרזה רשמית וקיבלה את השם InfiniGuard, פתרון אחסון סמוך-ענן שנקרא Neutrix שאפרט עליו בפעם הבאה והפתרון עליו אני רוצה לפרט קצת היום, פתרון רפליקציה המספק RPO-0 ללא תלות במרחק או רוחב פס בשם InfiniSync.

 

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

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

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

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

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

פתרון InfiniSync בא לגשר על הפער בין הפשטות היחסית של רפליקציה א-סינכרונית ורמת ההגנה של רפליקציה סינכרונית. הוא בא להחליף את הצורף ב Bunker site ולאפשר ללקוח לבצע רפליקציה א-סינכרונית בלבד אל האתר המרוחק מבלי לוותר על רמת ההגנה.

מה שעשינו זה לבנות מערכת על בסיס העקרונות של קופסא שחורה, כמו במטוסים, מערכת מחשוב מוקשחת הכוללת דיסקים מקומיים מבוססי SSD, סוללה פנימית, אנטנת Wi-Fi ומודם סלולרי עצמאי. המערכת בנויה בתוך קופסא קשיחה העמידה, עטופה בציפוי מבודד המגן מפני אש וחום ומוכלת בתוך כלוב המגן מפני רעידות. המערכת נבדקה ומאושרת לעמידה בעומס משקל של 2.2 טון, אש ישירה בטמפרטורה של 945 מעלות מעל שעה, חום ישיר בטמפרטורה של 260 מעלות מעל חמש שעות, נפילה מגובה 5 מטר, רעידות של 50Hz ו 1.6G, אטומה למים בעומק עד 3 מטרים ואפילו חסינה מפני חדירה של מוט חודר (תמיד בסרטי אסונות מישהו משתפד על עמוד במקרה של רעידת אדמה או תאונה).

 

Showdown_in_Mega_City_Trinity_Death

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

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

ininisync

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

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

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

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

 

שלכם,

ניר מליק