There is no I in Team

There is no I in Team

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

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

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

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

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

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

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

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

fa5168c4-0522-43c0-a4f6-bc7176cf4690

 

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

בכל אופן טיפה חדשות 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 על פני מרחק גיאוגרפי רב הם בדרך כלל בלתי סבירים לרוב מוחלט אם לא כל הארגונים.

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

 

שלכם,

ניר מליק