לקצר דרכים – ולסבול מאוחר יותר

כיועצת עצמאית, יוצא לי במקרים רבים לתת יעוץ לגבי תשתיות קיימות בענן או On Prem או במעבר מתשתיות מקומיות לעננים ציבוריים. לשמחתי אני יכולה לאמר ממה שראיתי – זה שחברות רבות נוהגות בתבונה ולא מעבירות בצורה מיידית את כל התשתיות שלהן מ-On Prem לענן אלא בצורה מדורגת, וגם אז – רק מה שצריך.

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

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

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

אחד הנזקים, לדוגמא, קשור לשדרוג. אם מישהו הקים מערכת Kubernetes והוא ינסה לשדרג אותה – סביר להניח שהוא יתקל במספר שגיאות, שאם הוא לא מבין בתחזוקה והקמת הפלטפורמה, יכולים פשוט להשבית לו את המערכת, וכנ"ל לגבי הרצה של כל מיני קונטיינרים חיצוניים תוך שימוש בקבצי YAML שאיש מהחברה לא עבר עליהם: צריך לזכור שקוברנטיס לא שואל יותר מדי שאלות לפני הטמעה של קבצים כאלו (kubectl apply -f something.yaml).

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

חג שמח.

Exit mobile version