החל ה"מרדף" אחר החלפת הדיסקים קשיחים שלכם

כמעט בכל חברה גדולה בארץ יש שרתים ואם נסתכל בשרתים – ברוב המקרים נמצא דיסקים קשיחים מכניים. הם לא מהירים כמו דיסקים SSD, אבל הם "סוסי עבודה" שעושים עבודה טובה. אני די בטוח שהיו למנמר"ים או אנשי IT הצעות להחליף את הדיסקים האלו ב-SSD ובוודאי בחלק מהמקרים הדיסקים המכניים הוחלפו ב-SSD, אבל בד"כ חברות לא ממהרות להחליף – בגלל המחיר. אחרי הכל, מחיר ממוצע של SSD ל-Enterprise עולה הרבה יותר מאשר דיסק מכני SAS או NL-SAS ל-Enterprise.

מי שקורא את הפוסטים בבלוג זה, אולי קרא את הפוסט הזה שכתבתי על סוגי SSD וגם כתבתי על סוג שבבי NAND חדש עם תאי QLC (כלומר ניתן לכתוב 4 ביטים בתא אחד, בניגוד ל-SLC שבו ניתן לכתוב רק ביט אחד, אבל בהשוואה ל-QLC הוא הרבה יותר מהיר בכתיבה). החסרון הגדול של QLC זו הכתיבה האיטית ולכן דיסקים SSD מבוססי QLC NAND Flash לא מיועדים להתחרות מול SSD רגיל.

הם מיועדים להתחרות בדיסקים הקשיחים שיש לכם בשרתים.

הבה נודה על האמת: דיסקים מכניים בגודל 2.5" לא התקדמו כמעט בשנים האחרונות. ברוב המקרים הדיסק הכי גדול ל-2.5" ל-Enterprise הוא בגודל 2 טרהבייט (יש כמובן גם 5 טרהבייט אם כי הם אינם מיועדים ל-Enterprise ובכל מקרה לא בטוח הם יוכלו להיכנס לשרת שלכם אם השרת הוא של HP לדוגמא – המערכת פשוט תקפיץ הודעה שזה לא נתמך והיא לא תציג התראות מדיסק כזה). המהירות שלהם אינה גבוהה (בין 200-270 מגהבייט ב-Sequencial Read).

חברת Micron, בשיתוף פעולה עם אינטל, הציגו אתמול את ה-SSD מבוסס QLC הראשון שלהם. עדיין אין הרבה פרטים ציבוריים עליו ובאתר Toms Hardware כתבו כמה מילים לגביו.

טכנית, הדיסקים הללו, כפי שציינתי לעיל, מיועדים להיות "באמצע" – בין כוננים מכניים ל-SSD שכולם מכירים ל-Enterprise. הכתיבה שלו לא מהירה בהשוואה לשום SSD שקיים בשוק (כן, גם בהשוואה ל-SSD שעולה 1000 שקל בחנות מחשבים), אולם מהירות הקריאה שלו היא כמו מהירות קריאה של SSD ל-Enterprise, כלומר אתם תקבלו מהירות של 550 מגהבייט לשניה (שוב, ב-Sequencial Read, ב-Random התוצאה תהיה מעט שונה ואם משתמשים ב-Queue Depth התוצאות יהיו לא רעות .. הייתי מרחיב אבל יש אמברגו עד לסתיו הקרוב).

הגדלים של הדיסקים הללו יהיו שונים מגדלים של דיסקים מכניים. ה-5210 ION יהיה זמין בגדלים החל מ-2 טרהבייט ועד 8 טרהבייט (אני מעגל את המספרים), כך שתיאורתית דיסקים כאלו יכולים להחליף גם דיסקים מכניים בגודל 3.5" (ניתן לאכסן תיאורתית בשרת בגודל 1U עם 10 כניסות דיסקים – כמעט 80 טרהבייט של DATA).

והשאלה הכי חשובה לפני שחושבים לרכוש דבר כזה בעתיד: לאיזה עומסי עבודה זה מתאים? ובכן, התשובה היא במובהק לעבודות Read Intensive. זה לא מיועד לאכסן שרת SQL או נתונים של שרת SQL, זה לא מיועד לשמש כדיסקים לוקאליים עבור הרצת מכונות VM. זה מיועד יותר לאחסן תוכן סטטי, כך שאם אתם מריצים פורטל ארגוני גדול בחברה לדוגמא, דיסק כזה יכול לאחסן את התכנים עבור הפורטל (בנוסף לדיסק רגיל שיאחסן את השרת ה-Web ו/או ה-Application Server). חשוב לזכור: כמות הכתיבה/מחיקה על כל תא היא מוגבלת (בסביבות ה-1000 פעם, אבל בד"כ בקר ה-SSD עושה עבודה חכמה שלא תגיעו לזה)

חברת מיקרון היתה הראשונה להכריז על QLC, ותהיו בטוחים שבמהלך החודש הקרוב כל השאר יכריזו, כי כולם עבדו על יצור שבבים עם QLC: סמסונג, טושיבה, סאנדיסק/WD, אינטל (עם מיקרון), וגם SK Hynix. הרכישה תתאפשר החל מסביבות אוקטובר-נובמבר בשנה זו.

לסיכום: SSD עם תאים QLC מגיע לשוק. זה לא מתאים לכולם. כרגע יהיו הכרזות ל-Enterprise ובהמשך זה יזלוג לשוק הסמי-מקצועי ושוק הצרכנים. האם הייתי ממליץ לצרכן לרכוש דיסקים SSD כאלו? הפיתוי יהיה גדול הואיל והוא יהיה יותר זול מ-SSD מבוסס TLC או MLC (וצרכנים לא מודעים יקנו כאלו "כי זה SSD") – וזה יכול להתאים לשוק הביתי, אך לא לשוק המקצועי (במיוחד אם יש צורך לטפל בקבצים גדולים במהלך העבודה).

הקשחת שרתים במבט יותר עמוק

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

הדבר הראשון שצריך להבין לגבי ההקשחות זה שתלויות חיצוניות לא תמיד עוזרות או לא עוזרות הרבה. ה-Firewall שיש בחברה לדוגמא כמעט ולא רלוונטי לנושא. כן, הוא יכול לזהות שכתובת IP מסויימת מנסה להיכנס, דרך פורט מסוים, אבל ה-Firewall לא יודע ולא יכול לדעת אם הפורץ הצליח להיכנס, ואם הצליח, באיזה קבצים הוא נגע. בלינוקס יש דבר שנקרא access time לדוגמא שיכול לאמר איזה משתמש נגע באיזה קובץ ומתי, אבל אם הפורץ כבר יצא והמשתמש הלגטימי (עם אותו username) נכנס ועבר על הקבצים, אז הרבה פעולות פורנזיות לא יעזרו הרבה לדעת מי נכנס ובמה הוא נגע (מה עוד שבימינו פורצים רציניים משתמשים ב-VPN ושלל טריקים נוספים להחביא את זהותם כך שמאוד קשה לדעת מי בדיוק נכנס). ישנם כלים אחרים שעובדים עם חתימות שונות כדי לזהות כניסות דרך שיטות ידועות וזה עוזר, אבל שוב – לא תמיד זה יעזור ותיכף ארחיב על כך.

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

אחת העבודות היותר מורכבות לפני שמגיעים למימוש CIS Benchmark היא עניין החבילות תוכנה שמותקנות על השרת. התקנת גירסת CentOS 7 לדוגמא בתצורה מינימלית מתקינה בסביבות 300+ חבילות. זה שאני יכול לבטל שרותים זה נחמד, אבל פורץ רציני יכול להפעיל את השרותים מחדש ברגע שהוא נכנס, ולכן העבודה הראשונית היא "כיסוח" של החבילות המותקנות שאין צורך בהן ובמקרים מסויימים קימפול מחדש של חבילות מסויימות ויצירת חבילות חדשות יותר מצומצמות על מנת להקטין כמה שיותר את וקטור התקיפה, ביטול גישת אינטרנט להתקנת חבילות ועוד ועוד. רק לאחר מכן אפשר לעבור לשלב מימוש ה-CIS Benchmark.

עוד נקודה שרבים שוכחים היא פורטים 80 ו/או 443. בד"כ הם פתוחים לעולם, וכאן גם מתרכזת בעיה רצינית: קיימים לא מעט סקריפטים שיתנו מעין shell גם אם ל-user שמריץ את שרת ה-web אין בכלל גישת shell מכיוון שלמודולים שרצים תחת אותו שרת web יש אפשרות לבצע דברים שונים הקשורים ל-shell. דוגמא נפוצה עם PHP היא [email protected] ומשם אפשר לבצע נזקים רבים, ולכן צריך לקחת בחשבון מה רץ בשרת ה-web ומה רץ "מאחורה", והכי חשוב – בדיקת ההזנה של המידע המגיע מהאינטרנט אל שרת האפליקציות לדוגמא (זהו החלק שקשור לצוות הפיתוח או מי שמריץ pen-testing).

עוד נקודה חשובה היא היכולת לזהות פורנזית אם מישהו פרץ – במה הוא נוגע. נכון, סביר להניח שחברה רצינית תכניס פתרון IPS/IDS כלשהו, אבל פתרון כזה אינו מסייע אם הפורץ הצליח להיכנס ולפתרון ה-IDS/IPS אין מושג ירוק מה הפורץ עושה בשרת עצמו. אפשר כמובן לגלות עם ה-IPS/IDS אם הוא מעלה/מוריד קבצים לשרת שהוא פרץ, אבל מה אם הפורץ מחליט למחוק קבצים? לשם כך יש צורך בפתרון שהוא בעצם Host IDS (כלומר: HIDS) שיודע לזהות את הדברים ולרשום במה הוא נגע, איזה process הוא הפעיל ועוד ועוד. שילוב פתרון כזה אפשרי אבל מצד שני יכול גם להאיט את ביצועי השרת ולכן אם הלקוח רוצה בפתרון כזה, יש להיערך לכך מבחינת שרתים שנותנים שרות, היכן יאוחסן המידע מהניטור ועוד ועוד.

והדבר הכי חשוב: לא חשוב מי עושה הקשחה לשרת שלכם, לא מדובר בעבודה של "אי בודד" (כלומר האינטגרטור מקבל IMAGE ועושה עבודה משלו, מגיש את ה-IMAGE המעודכן ותיעוד, מקבל כסף ולהתראות), אלא מדובר ב"פינג פונג" בין האינטגרטור למחלקות שונות בחברה. אני יכול להקשיח שרת לעילא ולעילא אבל אם הקוד שרץ על השרת הוא קוד שאינו בודק מה הוא מקבל בצורה רצינית – אז הפורץ יכול להיכנס למערכת די בקלות. אם אין שום Penetration testing, אז שוב – הפורץ יכול להיכנס בקלות. יש גם צורך בלעבוד עם ה-IMAGE כדי לראות האם יש צורך לשנות על מנת לקבל ביצועים יותר גבוהים, כמות clients יותר גבוהה, ועוד ועוד, כך שזהו תהליך שיכול לקחת ימים או שבועות, לא יום או יומיים וזה שונה מחברה לחברה.

לסיכום: בכל הקשור ללינוקס, אפשר להקשיח שרת בצורה מעולה, אבל זה מצריך עבודה ולא איזה סקריפט שישנה דברים פה ושם. אצל כל לקוח הדברים שונים, ויש דגשים שונים בין הצרכים. חשוב לזכור ששרת אינו עובד כדבר עצמאי ולכן יש לדאוג לחלקים נוספים, בין אם השרת רץ כשרת פיזי או VM אצלכם בחברה או רץ כקונטיינר(ים). אם אתם עובדים בענן, אז אחד הדברים בנוסף להקשחות שצריך לדאוג לגביהם – זה Firewall וכלי שנותן גם IPS/IDS כי ספק הענן לא מגן על שום דבר שיש לכם בענן – ומה שהכי חשוב – זה שיתוף פעולה בין מי שמקשיח לבין הצוותים השונים, על זה דברים יפלו או יקומו.

סטארטאפים ואבטחת מידע בענן

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

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

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

וכאן בדרך כלל מתחילות הבעיות הקשורות לאבטחת מידע.

לא מעט אנשים שמתחילים סטארטאפים חושבים להם שאם יקימו את התשתית שלהם בענן, ספק הענן יגן עליהם בצורות כלשהן וזו כמובן טעות ענקית. לא חשוב מי ספק הענן, כמות ההגנה המסופקת ללקוח היא ברמה אפסית (אינני מדבר על הגנות בתוספת תשלום כמו נגד DDoS). אתה יכול להפעיל Multi Factor Authentication כדי למנוע כניסת אנשים לא מורשים לחשבון בענן, אבל זה לא אומר כלום לגבי ה-Instances שאתה משתמש. מהרגע שיש לך Instance חי ויש לו כתובת IP ציבורית, עשרות אלפי סקריפטים ינסו לחדור לשרת שלך בכל דרך. כל שרות שתפעיל באותו Instance ושאינו סגור לכתובת הציבורית (כמו שרבים נוטים להשאיר פורטים פתוחים לשרותי SQL/NOSQL, GUI, או SSH עם סיסמא (ללא מפתחות) – הסקריפטים ינסו להיכנס, ואם הם יצליחו, חלקם יעבירו את המידע חזרה מבלי לנגוע במידע בשרת וחלק אחר של סקריפטים פשוט "יגייסו" את המכונה להריץ BOT או תולעים או 1001 דברים מזיקים אחרים ויש כמובן גם סקריפטים שישמחו פשוט למחוק את המכונה.

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

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

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

  • אם מדובר במספר עובדים בסטארטאפ אחד שיושבים במשרד כלשהו, דאגו ל-VPN וחברו את ה-VPN כ-Site To Site לחשבון הענן שלכם. מי שרוצה להתחבר מהבית, יתכבד הבחור ויתחבר ל-VPN שלכם ומשם לתשתית.
  • עבודה עם סיסמאות לכניסה לשרתי לינוקס היא no no. השתמשו במפתחות בלבד והחליפו את קבצי ה-PEM שניתנו לכם ע"י שרות הענן שלכם במפתחות שלכם בחלוקה של פרטי/ציבורי (עדיף ליצור עבור כל מפתח מפתח, להכניס את החלק הציבורי לשרת ואת החלק הפרטי למכונה של המפתח כך שאפשר לדעת מי נכנס עם איזה מפתח), כך שמי שצריך להיכנס למכונה יהיה לו את החלק הפרטי של המפתח (החלק הציבורי נמצא בשרת). קבצי ה-PEM למיניהם קל "לדוג" אותם מכל מיני פורומים, אימיילים ושאר מקומות.
  • מקימים DB? ראשית יש להקשיח את ה-DB לפני שמכניסים אליו נתונים. אם זה mysql לדוגמא, יש להריץ קודם כל mysql_secure_install, ואם זה mongoDB יש למחוק משתמש דוגמא,  ובכל המקרים יש לוודא כניסה רק דרך IP מסוים פנימי.
  • משתמשים בשרותים שונים של ספק הענן? ודאו שאתם משתמשים בכתובות IP פנימיות בלבד. זה לא מצליח? יש לכם בעיה עם ה-VPC (במקרה של אמזון), כדאי לבדוק הגדרות.
  • שימוש ב-DB – לפני שכותבים נתונים ל-DB, כדאי "להמליח" דברים כמו סיסמאות ומידע חשוב (להלן לינק לוידאו המסביר איך לעשות זאת ב-MySQL לדוגמא), כך שמי שיצליח לגנוב את ה-DB, לא יוכל לעשות הרבה עם זה. אפשר כמובן לשפר את זה ולהשתמש בכל מיני שרותי Vault לשמור את המפתח להמלחה אך זה כבר עניין אחר.
  • גיבויים ל-S3 או כל מקום ששומר Object Storage – לאחר יצירת הגיבוי, יש להצפין אותו ורק אז להעלות אותו (כמובן שכדאי לוודא שהרשאות ה-S3 שלכם מוגדרות בצמצום).
  • לא לקחת כתובות IP ציבוריות עבור כל Instance (טריק שלצערי ראיתי פעמים רבות שנעשה בחברות שונות). אם אין אפשרות להקים ולהשתמש ב-VPN ויש צורך להתחבר ממקומות שונים עם IP שונה, מומלץ להשתמש בטריק שנקרא Linux Bastion, זו מכונת לינוקס קטנה שבה נשתמש כ"מקפצה" (להלן לינק למאמר שמסביר זאת) ולמכונה זו יש להגדיר Security Groups עם הכתובות שיכנסו אליה (חשוב: לא להוסיף כל פעם כתובות אלא לעדכן ב-SG).
  • תעודות SSL – אם המכונה פונה החוצה ואין לכם עדיין תעודות SSL מסודרות, אפשר להשתמש ב-Let's Encrypt כדי ליצור תעודות SSL תקינות זמניות (שניתנות להארכה בפקודה פשוטה) במקום להשתמש ב-Self Signed Certificates. באותה הזדמנות כדאי לבטל Ciphers ישנים ולאפשר אך ורק ל-TLS מהגירסא האחרונה להיכנס.

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

קצת על Windows ואוטומציה

תרשו לי להציג אבחנה אישית מעניינת: בחברות רבות שרוב השרתים הם שרתי לינוקס, סביר מאוד להניח שהוטמע בחברה פתרון אוטומציה כלשהו. בחברות אחרות שרוב השרתים הם שרתי Windows, הסיכוי למצוא אוטומציה כמעט מלאה כמו במקרים של לינוקס – הסיכוי הוא קטן עד בינוני. כמובן שברוב החברות יש סקריפטים שונים (ומשונים) לעשות עבודות כלשהן, אבל כשזה מגיע ל-Windows, בחברות רבות "נעולים" על ביצוע עבודה דרך GUI ורק אם אין ברירה – דרך סקריפטים (ב-Windows ברוב המוחץ של המקרים – PowerShell).

בלינוקס, קיימים מספר פתרונות האוטומציה מבוססי קוד פתוח כמו:

  • Chef
  • Puppet
  • Ansible
  • SALT

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

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

אחד היתרונות הגדולים בגירסה האחרונה (2.5) של Ansible היא פתרון מלא ל-Windows. צריכים לעדכן שרתים? צריכים להוסיף אתר ל-IIS? צריכים להעביר קבצים? מעתה כל מה שצריך זה ליצור קבצי Playbooks פשוטים (לא, לא צריך לדעת לתכנת בשביל לכתוב Playbooks) ופשוט להריץ אותם. Ansible ירוץ במקביל לכל המכונות שהגדרתם ויבצע את העבודה. בתוך Ansible יש חלקים שנקראים מודולים שהם בעצם הקוד שירוץ על השרתים (דרך WinRM) והם כתובים ב-Python ולכן חלוקת העבודה יכולה להיות שמי שמבין בפייתון יכתוב מודולים והשאר יכתבו Playbooks בהתאם לצורך. אגב, יש תמיכה במערכות הפעלה אחרות, וירטואליזציה וגם חומרה.

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

תכירו את Redfish

אני רוצה להכיר לכם את Redfish. בעקרון, Redfish זה API סטנדרטי לנהל כמעט כל דבר בתחום ה-IT, החל מ-SDDC (כלומר Software Defined Data Center) וכלה בשרתים, שרותים, מתגים ובקיצור כמעט כל דבר שניתן להתחבר אליו. Redfish משתמש בסטנדרטים קיימים (REST API, web services ופלט כ-JSON) על מנת לעשות את החיים הרבה יותר קלים למחלקת ה-IT בחברה.

אחד הדברים שצריך לדעת על Redfish שזה משהו ענק שמשתתפים בו כל המי ומי בתחומי הברזלים לדוגמא. לפוסט הזה, אני מעוניין להתרכז בתחום ה-OOB (שזה אומר כל ה-iDRAC/IMM/ILO/IMC למיניהם).

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

ועכשיו אשאל שאלה: כמה זמן יקח מהרגע שהשרתים יורדים מהמשאית עד שהם פועלים עם ה-OS/וירטואליזציה שבחרתם? אני מאמין שזה לא עניין של שעות, זה יהיה מינימום עניין של ימים עד שבועות. אחרי הכל, במקרים רבים יש צורך להכניס כרטיסים שונים לשרת, אולי לשנות את תצורת הזכרון, להתקין OS, להגדיר את ה-UEFI/BIOS, לחבר למתגים, להגדיר כתובות IP, VLAN וכו', , להגדיר RAID, לפרמט דיסקים, ועוד כמה וכמה דברים.

כשמדובר על כמות של 1-3 שרתים, זה לא כזה ביג דיל, אבל אם מדובר על פרויקט חדש והגיעו 20 שרתים.. אתם יכולים לדמיין את הכאב ראש.

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

איך? עם ה-API של Redfish. כאן לדוגמא תוכלו למצוא עבור שרתי Dell סקריפטים הן ב-Python או ב-PowerShell על מנת להשתמש עם ה-Redfish בחיבור ל-iDRAC לעשות כמעט הכל, החל מהגדרת UEFI/BIOS, שדרוגי קושחה, הגדרות iDRAC, הגדרות RAID ושלל ירקות נוספים.

הכל טוב, רק שיש בעיה אחת קטנה: יש לי 20 שרתים להקים, להתחיל לשנות כל פעם סקריפטים? לכתוב סקריפט wrapper שמריץ את הסקריפטים שניתנים באותו אתר? זה חתיכת כאב ראש.

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

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

לסיכום: Redfish נותן סוף סוף דרך "לדבר" בצורה מאובטחת עם הציודים שלכם דרך סקריפטים שונים שניתנים לשימוש באוטומציה. אפשר גם להגדיר כך הגדרות שונות וגם לקרוא לדוגמא מה-OOB את התקלות האחרונות מה-Log. אם נחכים להשתמש גם ב-PXE (אני דווקא ממליץ על IPXE במקום PXE, הוא הרבה יותר מהיר כי הוא עובד ב-HTTP ולא TFTP כך שניתן לעבוד מהר ובמקביל) נוכל גם להתקין בצורה אוטומטית תוך שימוש בכלים כמו kickstart או preseed להתקין מערכות הפעלה שונות בתצורה מינימלית ואת השאר לעשות עם Ansible (כן, כולל Windows, אסביר בפוסט הבא) ובכך לחתוך את הזמן להקמת השרתים בעשרות אחוזים וגם התחזוקה תהיה הרבה יותר מהירה ואוטומטית.

להלן וידאו הדגמה של Dell מכנס Red Hat Summit האחרון שנערך לפני ימים ספורים:

על לינוקס, VMWare וטעות הקשורה לחיישנים

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

עד לגירסה 5 (גם 5.5) ב-VMware השתמשו בד"כ בדרייברים מבוססי לינוקס כדי להפעיל ציודים, בין אם מדובר בציוד זול או בבקרים יקרים מאוד. בגירסה 6 החליטו ב-VMWare לעבור לדרייברים שהם כותבים (או שהיצרן כותב) עם שינויים מהותיים בקוד כך שלא כל כך קל לקחת דרייבר של לינוקס ולזרוק אותו לגירסה 6 (ולפי השמועות, זה הולך להשתנות שוב בגירסה 7, אבל בינתיים אלו רק שמועות).

אם יש לכם שרתים שמריצים VMWare, אחד הדברים החשובים שתרצו לדעת הוא מה מצב החיישנים במערכת. מה הטמפרטורה של המעבד, דיסקים, ספק כח, חום פנימי בשרת, מצב תקלות זכרון ודברים כאלו ואכן, עד גירסה 6 של vCenter קיבלתם את המידע כולו בתצורת עץ. המידע הזה חשוב (וגם ניתן לקריאה על ידי תוכנת הניטור שלכם דרך SNMP). עד גירסה 6 ה-vCenter עשה משהו פשוט מאוד: הוא פנה לכל שרת ESXi שרשום ב-vCenter וקרא ממנו את הערכים. איך ESXi קורא את הערכים? בעזרת חבילה שכלולה בכל הפצת לינוקס שנקראת lm-sesors והיא קיימת בכל התקנה של שרת ESXi. החבילה הזו מעודכנת כל הזמן וכל עוד הקרנל בלינוקס מעודכן, תוכל לקרוא את כל החיישנים במערכת, וזה רץ על כל מערכת, בין אם מדובר במחשב נייד, בדסקטופ, תחנת עבודה או שרת מפלצתי.

בגירסה 6.5 ל-VMware "קפץ הפיוז" והם החליטו שה-vCenter (בין בגירסת Windows או VCSA) לא יקרא יותר את החיישנים מה-ESXi (שכבר יש לו את הנתונים שמתעדכנים כל 90 שניות), אלא יפנה אל ה-IPMI. למי שלא מכיר – בכל לוח אם של שרת יש רכיבים שנותנים ניהול מרחוק, אתם אולי מכירים את זה בשמות כמו ILO, IMM, iDRAC – וכולם בעצם מממשים פחות או יותר את סטנדרט IPMI לשליטה מרחוק על המכונה. הבעיה, כמו תמיד, שיש לא מעט מקרים שהמימושים הם לא ממש משהו או שהיצרן החליט להתעלם מחלק מסטנדרט ה-IPMI. אחרי הכל, למשתמש יש גישת CLI או גישת Web לניהול מרחוק, אז אפשר להחביא את המימוש העקום מתחת לשטיח.

וזה משהו שב-VMWare לא ממש התעמקו כנראה. מבחינתם, החל מגירסה 6.5, יש שרות שנקרא wbem ויש API לפונקציה שנקראת HostConfigManager.healthStatusSystem והיצרן צריך לכלול (או לשחרר) VIB שכולל את הגישה לניהול מרחוק של השרת, כך שבתאוריה המנהל יצטרך רק להכניס פרטי התחברות ל-IMM/IDRAC/ILO והמערכת תתחיל לקרוא את החיישנים ישירות מהניהול הרחוק.

במציאות .. זה לא ממש עובד. כך לדוגמא אחד השרתים שלי (גם אחרי התקנת ה-VIB) מראה תצוגה של החיישנים בכל שרת (לחצו להגדלה):

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

אז מה קורה פה? מי שיקרא את המאמר הזה יבין שגם אם הוא יתאמץ וינדנד ליצרן לקבל VIB מתאים, יגלה שזה לא יעזור. יש באג, ועד כה (יצא כבר 6.7) זה לא תוקן. המסקנה: רוצה לנטר את המכונות ושדרגת ל-vCenter 6.5 ומעלה? תתחיל לנטר את המכונות עצמם. איך? קרא כאן.

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

על בעיה X ופתרון Y

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

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

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

  • מה הפונקציונאליות שהוא מחפש
  • מה הפונקציונאליות שמאוד חשובה לו, ומה הפונקציונאליות שבשבילו זה יהיה "נחמד" אם קיים אך אותה פונקציונאליות אינה קריטית.
  • האם הוא מחפש פתרון Scale Up או Scale Out
  • האם הוא מחפש פתרון שישולב כ-Hyper Converge או שהוא מחפש פתרון של ברזלים נפרדים
  • ויש עוד לא מעט שאלות…

ההבדלים ביני (וכמובן אחרים), כיועץ ואינטגרטור בלתי תלוי (כלומר אחד שהוא אינו בעצם Reseller של ברזלים ממותגים) הם דברים חשובים כגון:

  • אינטגריטי – אם מישהו יבוא אליי ויבקש לדוגמא פתרון סטורג' Scale Out והדבר הכי חשוב לו זה iSCSI לדוגמא, אז אני אומר לו בפשטות שכרגע אין פתרון Scale Out בקוד פתוח (גם כמוצר מסחרי) שיש לו פתרון iSCSI ל-Scale Out בצורה טובה והוא יצטרך פתרון קנייני.
  • על מה הפתרון אמור לענות? לקוח רוצה X על מנת לפתור את בעיית Y. נעזוב לרגע את X, ונשמע מהלקוח מהו אותו Y. אין ספק, דרישותיו של הלקוח הן חשובות, אולם ברגע שמספרים לי מהו אותו Y, אז ניתן להעלות מספר פתרונות שיכולים לענות על Y וגם להתחשב בצרכי הלקוח.
    לדוגמא: ללקוח יש 20 מכונות VM שמשמשות לפיתוח והלקוח רוצה פתרון סטורג' עבורם Scale Up. במקרה כזה אני יכול להציע לדוגמא פתרונות מבוססים ZFS, בין אם כקוד פתוח נטו או מוצרים מסחריים ובהצעה שאגיש לו יוסבר מדוע הפתרון הזה טוב ויוצעו ללקוח מספר פתרונות מבוססים ZFS, כך שבסופו של דבר ה-Y הם אותם 20 מכונות VM וה-X יהיה פתרון מבוסס ZFS.

וכאן בעצם מגיעה השאלה המרכזית שלי…

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

על עלויות תמיכה של מוצרי קוד פתוח

עולם הקוד פתוח כיום נותן מגוון מוצרים הקשורים לתשתיות שונות, Software Defined, וירטואליזציה ועוד, ובמקרים רבים חברות רבות מעוניינות באותם מוצרי פרויקטים בקוד פתוח, ומדוע לא? לבצע Download, להתקין ולעבוד עם זה, בלי עלויות של רשיונות פר שנה, פר שרת, פר חיבור ופר השד-יודע-מה…

להלן מס' דוגמאות של מוצרים:

  • GlusterFS
  • Ceph
  • oVirt
  • OpenStack
  • ManageIQ
  • Kubernetes
  • OpenShift Origin

2 המוצרים הראשונים הם Software Defined Storage, השלישי והרביעי הם מוצרי וירטואליזציה, והמוצר החמישי הוא מוצר לניהול מקיף של תשתיות וירטואליזציה ועוד – מקומית ובענן ו-2 האחרונים הם לניהול קונטיינרים לכל המוצרים הללו נלווית עלות של 0 שקלים כלומר אתה יכול להיכנס לאתרים, להוריד ולהשתמש.

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

כל המוצרים שתיארתי לעיל דורשים ידע והתמחות במוצרים. כמובן אם מדובר בחברה גדולה עם מחלקת IT גדולה (כך שיש מישהו או 2 שיכולים להתמקצע במוצר) אז העלות עצמה היא באמת אפסית, למעט כשיש תקלות או באגים שלא כתובים בתיעוד. מנסיון בתמיכה במוצרים לעיל, אני יכול לאמר שיש לא מעט מקרים שהפתרון היחיד במקרים של תקלות ובאגים זה לפנות ל-Mailing List (או ב-IRC) ולקוות שיש מישהו מהמפתחי מוצר שיכול לסייע, ולפעמים זה יכול לקחת זמן. קרו לי מקרים שקיבלתי פתרון רק לאחר יומיים בערך וקרו לי מקרים על פרויקטים אחרים (שהתקנתי אצלי בבית) שלקח שבוע וחצי עד שקיבלתי תשובה. בשבילי בבית, יומיים או שבועיים לא ממש משנים משהו כי אלו דברים שאני לא מריץ כ"פרודקשן", אבל מה לגבי לקוח שהרים את המערכות האלו ביצור או פרודקשן? זה כבר נהיה מצב לא נעים. יש כמובן אפשרות לפנות לאחת מהחברות שמשחררת את אותו מוצר קוד פתוח כמוצר מסחרי ולרכוש שרות תמיכה חד פעמי פר שעות, אבל אפשרות זו היא לא זולה. כמה לא זולה? זה יכול להסתכם בכמה אלפי דולרים וזה יכול לעלות יותר אם מושיבים מהנדס מאותה יצרנית תוכנה על הבעיה.

לכן, בדרך כלל כשמעוניינים באחד המוצרים הנ"ל לדוגמא, יש לקחת בחשבון שאם אין בחברה ידע מעמיק על המוצר או על מערכת ההפעלה (כמו במקרים שיש רק Windows ב-90% מהתשתית ואין שם אף אחד שמבין לעומק בלינוקס) – יהיה צורך ברכישת בנק שעות תמיכה שנתי על המוצר או על הפתרון ובד"כ מדובר על כמה עשרות אלפי שקלים (בין 15K ל-40K, תלוי במוצר, תלוי אם מדובר רק בתחזוקה או בהקמה, תלוי בכמות שעות ותלוי ממי רוכשים והאם יש באמת ידע לעסק שמציע פתרון או שמדובר בעסק שחותך מחירים ולוקח מישהו מהודו כך שרוב הרווח עובר אליו ולא להודי) כך שאם אין בחברה ידע – המוצר כבר לא ממש "חינם".

מצד שני, לאלו שכן רוצים לרכוש את המוצר המסחרי ומוכנים לשלם את המחיר, מומלץ לחלק את העבודה ל-2 ואת ההקמה/הטמעה להוציא למישהו חיצוני (ולא ליצרן, כמו במקרים של רד-האט, אלא אם בא לכם לשלם כמה מאות דולרים לשעה!) ואת התמיכה אתם תקבלו במסגרת רכישת התוכנה.

נקודה נוספת וחשובה כשניגשים למו"מ לגבי בנק שעות מול מי שיתן לכם שרותי תמיכה/תחזוקה/הטמעה – תוכנות כמו שציינתי לעיל משתנות מהר מאוד, בערך פעמיים בשנה אותם פרויקטים יוצאים בגירסה חדשה, ואם לא קיימת גירסת LTS (כלומר Long Term Support) או שיש פונקציות חדשות שאתם צריכים מהגירסה שיצאה זה עתה, תצטרכו לשקול שדרוג, ובד"כ מומלץ להכניס זאת בחוזה.

לסיכום: בין אם אתם בנק או חברת ביטוח או קופת חולים או אפילו סטארטאפ קטן שרץ על חצי שרת וירטואלי – תוכנות קוד פתוח עוזרות (ויכולות לסייע) המון ויכולות לחסוך המון כספים. יחד עם זאת, תוכנות כמו התוכנות שציינתי לעיל (והם דוגמאות ספורות, יש פרויקטים הרבה יותר מורכבים) מצריכים ידע רציני ונסיון כדי להקים אותם בין ב-PoC/פיילוט או הקמה לטסטים/פרודקשן/יצור. עלויות של יועץ/מטמיע חיצוני הן יותר זולות מרכישת המוצר הרשמי ואין צורך לשלם פר ציוד, אך יכולים להיווצר מצבים שהתמיכה תהיה פחותה במעט בכל הקשור לתקלות הקשורות לבאגים מכיוון שאין SLA מול יצרנית התוכנה עצמה וכדאי לקחת זאת בחשבון.

דעה: הפרויקט בוטל/נפל/מעוכב/סטטוס-לא-ידוע

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

הסיטואציה די ידועה: טכנולוגיה חדשה נכנסה לשוק בשנה שנתיים האחרונות (זה לא משנה אם מדובר בקונטיינרים, Application Servers חדשים, Hyper Converge, SDN ושלל פתרונות חדשים אחרים) והנהלות חברות בינוניות וגדולות מעוניינות להכניס את אחת מהטכנולוגיות לחברה. הם פונים לחברת אינטגרציה שהם מכירים ומתחילים לדון בנושא ומבקשים לקבל מידע גם על פתרונות מתחרים (לפעמים ישירות מחברות משווקות או מחברות אינטגרציה אחרות), מידע כמה הפתרון יציב, עלויות רשיון, עלויות הטמעה, TCO, ROI ושלל מספרים ונתונים אחרים. לאחר זמן מה, ההנהלה ואנשים טכניים של החברה מתכנסים לחדר ישיבות והם מקבלים מנציגים חיצוניים שונים הדגמות והסברים על הפתרונות. בד"כ לאחר זמן מה החברה מחליטה ללכת על פתרון מסוים ואותה חברת אינטגרציה שנבחרת מתבקשת להקים PoC (כלומר Proof of Concept) בתשתיות הפנימיות של החברה על מנת להתרשם ו"לשחק" עם הפתרון.

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

להלן מס' דוגמאות מדוע מתרחשת הנפילה:

  • אי תאימות: לפני ה-PoC (או ה-Pilot) אף אחד לא טרח להציג מה הולך לעבור ל-Pilot ועצם ההמרה עצמה מצריכה כמות שעות גדולה כדי להמיר את האפליקציה לעבוד בסביבה החדשה. אני מכיר לדוגמא מקרה שבו חברה מסויימת רצתה להריץ אפליקציה ב-JAVA בקונטיינר. אין שום בעיה לבצע זאת, רק שהאפליקציה בכלל כתובה ב-++C והלקוח מתעקש שהאפליקציה תהיה אפליקציית JAVA, כלומר מישהו צריך לבצע porting של הקוד מ-++C ל-JAVA, וכל מי שמכיר את השפות יודע שמדובר ברוב המקרים במאות אם לא אלפי שעות עבודה שכלל לא סוכמו מבחינת מי ימיר והעלויות הנלוות. מקרה אחר שאני מכיר הוא שאפליקציה רצה בכלל תחת DOS ומה לעשות.. קונטיינרים לא מריצים DOS (זה אפשרי אבל די מורכב, במיוחד אם האפליקציה מעוניינת ליצור קשר עם .. מודם חיצוני עבור קופות רושמות בודדות. כן, שמעתי על בקשה כזו)
  • התנגדות לא רשמית מהצוותים: ההנהלה מעוניינת בפרויקט כולל מחלקת IT, אבל כשזה מגיע למפתחים ולשאר צוותים שצריכים להשתתף בפרויקט, אז פתאום זה-לא-דחוף, "אין זמן", יש דברים אחרים בראש למנהלי צוותים ובקיצור – יורדים מכל העניין, רק לא רשמית. (כן, אני מכיר 2 חברות ששילמו מקדמה ועד היום לא בוצע מאומה).
  • עוד דבר שקשור הוא הקפאה של הדברים, לעיתים עוד ברמת ה-PoC. התקבלה החלטה לצאת ל-PoC ואז התקבלה החלטה הפוכה. מדוע? אף אחד לא אומר. את זה אפשר לראות במיוחד במוסדות גדולים כמו חברות ממשלתיות. הדבר הכי לא נעים זה לחברות האינטגרציה הגדולות ששכרו אנשים חיצוניים כדי לעמוד ב-PoC ובפרויקט ועכשיו הפרויקט קפוא.

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

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

לכן, אם רוצים לבצע PoC או פיילוט, כדאי, לעניות דעתי, לוודא את הדברים הבאים:

  • לבצע את הפיילוט על רפליקציה של משהו קיים, ולתת לחברת האינטגרציה/אינטגרטור לראות מה בדיוק הולך לרוץ, במה זה כתוב, איזו מערכת הפעלה, וכל פרט נוסף על מנת שלא יגיע מצב שמגיע ה-PoC ואז יש צורך לבצע עבודה מסויימת גדולה שאיש לא הכניס אותה בשיקול הערכת שעות והערכה כספית. אישית אני ממליץ לפני שמחליטים בכלל ללכת על משהו – לחשוף את הפרטים הללו.
  • "ליישר שורות" – ההנהלה מחליטה X? אז כולם מתיישרים לפי ההחלטה, בלי שיתוף פעולה מצד מפתחים ואנשים אחרים – שום PoC או פיילוט לא יצליח והדבר היחיד שיוצא מזה זה חילופי האשמות מרומזות. כמו כן כדאי לטפל בכל כיסי התנגדויות/אי הסכמה מצד כל הגורמים. בחברות גדולות יש פוליטיקה ופוליטיקה במקרים רבים היא האויב מס' 1 להטמעת טכנולוגיות.
  • עבודה רציפה עם חברת האינטגרציה או האינטגרטור. לי, בתפקיד האינטגרטור הכי קל להקים את הפרויקט על תשתית הלקוח, לתת הסברים, להוציא חשבונית ולסגור עניין. הבעיה היא שלצוות הפיתוח וצוותים אחרים אין את הנסיון והידע שיש לי (לדוגמא) ובד"כ לוקח זמן ללמוד ואז צצות 1001 משימות אחרות שדוחות את המימוש ו… לא עושים כלום עם הפרויקט. לכן בד"כ מומלץ לעבוד עם האינטגרטור להעביר חלק מהתשתית, כך שהאינטגרטור עושה חלק, הצוות לומד ועושה חלק אחר, האינטגרטור בודק ומסייע וכך ממשיכים עד שאין צורך בשרותיו של האינטגרטור.
  • שילוב של טכנולוגיות אחרות. אפשר "לנצל" את הפרויקט בכך שהמערכות החדשות עדיין אינן מוגדרות Production ולהטמיע טכנולוגיות סמוכות, כמו אוטומציה משופרת, תזרים עבודה ושאר דברים.

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

מוגש כחומר למחשבה.

חושבים לשדרג ציוד? תתכוננו לעליית מחירים

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

הסיפור די פשוט: דונאלד טראמפ צודק בטענה שלו (שאותה העלו גם נשיאים ושרים קודמים בממשלים הקודמים) על כך שסין פשוט מכריחה כל חברה שמעוניינת לעבוד עם סין, לעבוד עם "שותף מקומי" ובדרך להעביר את כל הקניין הרוחני (ה-IP בשפה המקצועית) ל"שותף המקומי". מכאן עד העתקה מוחלטת של כל הקניין הרוחני ויצירת "תואמים" וחיקויים זולים – המרחק קצר. בממשלים קודמים בארה"ב ניסו פה ושם למצוא הסכמות או פשרות כלשהם עם הסינים, הסינים מצידם פה ושם עשו קולות שהם מוכנים להתחשב ואולי קצת להעניש כל מיני מעתיקים. כמובן שכל זה נעשה טיפין טיפין ולא בצורה רצינית. בממשל הנוכחי (טראמפ) – הנשיא החליט לאחר שהוא החמיא מכאן ועד הודעה חדשה לנשיא סין – להיכנס למלחמת תעריפים עם סין, רק שהמלחמה הזו לא הגיעה עם מחשבה ארוכה, אלא פשוט ב"שלוף" לתשובות של עיתונאי סקרן בסיום איזו ישיבה שנערכה בבית הלבן. לאחר מכן הוחלט לשנות את כמות המיליארדים והתחומים/מוצרים שיהיה עליהם מסי יבוא. בהתחלה זה היה רק ברזל ואלומיניום, עכשיו נוספו לרשימה יותר מ-1300 מוצרים ותתי מוצרים. הסינים בתגובה גם פרסמו רשימות משלהם מה המוצרים מייבוא אמריקאי שעליהם ישולם מכס בגובה 20-25%.

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

ונחזור לטכנולוגיה.

כיום כל שרת, סוויצ', סטורג' מורכב (וחלקית מיוצר) בסין. בכל ציוד כזה יש עשרות, מאות ולפעמים אלפי רכיבים שנוצרים במדינות אחרות שאינן סין, אך אותם שבבים, לוחות, קבלים וכו' וכו' מגיעים אל סין אל אחת מהיצרניות המחשבים/שרתים/חומרה הגדולות (כמו Quanta, Pegasus, FoxConn, Lotes ואחרים) ושם הדברים מורכבים ברמות שונות (רוב ה-PCB באותם ציודים לדוגמא מודפס בסין ועליו מורכבים השבבים וכו'), נארז ונשלח לארה"ב או למדינות אחרות בהתאם לבקשת הלקוח.

עכשיו נחבר את הדברים: משרד המסחר האמריקאי הוציא מסמך (שהוא אינו סופי ונתון לשינויים במהלך ה-40 יום הקרובים) וניתן לקרוא את המסמך כאן. אלו שיציצו במסמך מוזמנים להיעזר במעט סבלנות – המסמך לא ממש מציין "שרתים", "סטורג'", "סוויצ'ים" וכו' – אלא מדבר על חלקים שונים, כמו לוחות אם או לוחות PCB, דיסקים קשיחים, קבלים ועוד אלפי פריטים – שעליהם יחול 25% מס יבוא.

אני משער שעתה יאמר קורא הבלוג "חץ, ציוד שקונים פה בארץ לא מגיע ישירות מארה"ב אלא מגיע מאירופה, בריטניה ולפעמים ישירות מסין כך שהמסים האלו לא ממש חלים על רכישת ציודים לישראל", וזה נכון .. חלקית. אני אתן דוגמא מהעבר: לפני מס' שנים הייתי צריך לרכוש עבור לקוח כמה מאות דיסקים קשיחים לטובת הקמת ארכיב. באותם ימים התרחש צונאמי גדול בטיוואן ואחד מהמפעלים של יצרן דיסקים קשיחים הושבת, מה שאוטומטית העלה את המחיר ב-35-50% (ואלו היו דיסקים SAS Enterprise, ממש לא זולים) וגם היבואן בארץ העלה את המחיר צ'יק צ'יק ב-46% לאותו סוג דיסקים ספציפי, רק שבמקרה זה הגיע לי מידע ממישהי אצל אותו יבואן שהדיסקים שהזמנתי – נמצאים בחיפה, ובקיצור מנסים לעשות עליי "שיטת מצליח". אחרי סידרת צעקות היבואן החליט לרדת מהתרגיל.

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

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

חג שמח 🙂