דרושים רשתות (לא).

בזמן כתיבת מאמר זה, חיפוש באתר עבודה פופולרי אחר הביטוי "מהנדס רשת" החזיר כשלוש מאות משרות פנויות ברחבי רוסיה. לשם השוואה, חיפוש אחר הביטוי "מנהל מערכת" מחזיר כמעט 2.5 אלף משרות פנויות ו"מהנדס DevOps" - כמעט 800.

האם זה אומר שאין עוד צורך באנשי רשת בתקופות של עננים מנצחים, Docker, Kubernetes ו-Wi-Fi ציבורי בכל מקום?
בוא נבין את זה (ג)

בואו להכיר. שמי אלכסיי, ואני איש רשת.

אני מעורב ברשתות כבר יותר מ-10 שנים ועובד עם מערכות *nix שונות כבר יותר מ-15 שנה (היתה לי הזדמנות להתעסק עם לינוקס וגם עם FreeBSD). עבדתי במפעילי טלקום, חברות גדולות שנחשבות ל"יזמות", ולאחרונה עבדתי בפינטק "צעיר ונועז", שם עננים, דיבופס, kubernetes ועוד מילים מפחידות שבהחלט יהפכו אותי ואת הקולגות שלי למיותרים . ביום מן הימים. אולי.

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

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

ברוכים הבאים לעולם שלי.

איפה אפשר בכלל לפגוש אנשי רשת?

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

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

2. "מיזם" מותנה. זה לא משנה אם הפעילות העיקרית שלו קשורה ל-IT או לא. העיקר שיש לה מחלקת IT משלה, המבטיחה את תפעול המערכות הפנימיות של החברה, לרבות הרשת במשרדים, ערוצי תקשורת לסניפים וכו'. תפקידו של מהנדס רשת בחברות כאלה יכול להתבצע "במשרה חלקית" על ידי מנהל מערכת (אם תשתית הרשת קטנה או מטופלת על ידי קבלן חיצוני), ומומחה רשת, אם קיים, יכול ב- באותו הזמן לטפל בטלפוניה ו-SAN (לא טוב). הם משלמים אחרת – זה מאוד תלוי ברווחיות העסק, בגודל החברה ובמבנה. עבדתי עם חברות שבהן מערכות סיסקו "הועמסו בחביות" באופן קבוע, ועם חברות בהן הרשת נבנתה מצואה, מקלות וסרט כחול, והשרתים מעולם לא עודכנו (מיותר לציין שגם לא סופקו רזרבות). יש כאן הרבה פחות ניסיון, וכמעט בטוח שזה יהיה בתחום של נעילת ספקים קפדנית, או "איך לעשות משהו יש מאין". באופן אישי, מצאתי את זה משעמם בטירוף, למרות שהרבה אנשים אוהבים את זה - הכל די מדוד וצפוי (אם אנחנו מדברים על חברות גדולות), "dorakha-bahato" וכו'. לפחות פעם בשנה, איזה ספק גדול אומר שהם המציאו עוד מערכת מגה-סופר-דופר שתהפוך הכל לאוטומטית עכשיו וניתן לפזר את כל מנהלי המערכת ואנשי הרשת, ולהשאיר זוג ללחוץ על כפתורים בממשק יפהפה. המציאות היא שגם אם נתעלם מהעלות של הפתרון, אנשי רשת לא ילכו משם לשום מקום. כן, אולי במקום הקונסולה יהיה שוב ממשק אינטרנט (אבל לא חומרה ספציפית, אלא מערכת גדולה שמנהלת עשרות ומאות רכיבי חומרה כאלה), אבל הידע על "איך הכל עובד בפנים" עדיין ימשיך לְהִדָרֵשׁ.

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

במה שונה מנהל רשת ממנהל מערכת?

בהבנה של אנשים לא מ-IT - כלום. שניהם מסתכלים על המסך השחור וכותבים כמה לחשים, לפעמים מקללים בשקט.

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

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

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

אבל למה אתה צריך רשת אם יש לך מארח?

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

הבעיה העיקרית היא שמרכז הנתונים הוא לא מחלקת ה-IT שלך, זו חברה נפרדת שמטרתה להרוויח. כולל על חשבוןך כלקוח. מרכז הנתונים מספק מתלים, מספק להם חשמל וקור, וגם מספק קישוריות "ברירת מחדל" לאינטרנט. בהתבסס על תשתית זו, מרכז הנתונים יכול לארח את הציוד שלך (colocation), להשכיר לך שרת (שרת ייעודי), או לספק שירות מנוהל (לדוגמה, OpenStack או K8s). אבל העסק של מרכז נתונים (בדרך כלל) הוא לא ניהול תשתית לקוח, כי התהליך הזה הוא די עתיר עבודה, אוטומטי גרוע (ובמרכז נתונים רגיל כל מה שאפשר הוא אוטומטי), מאוחד אפילו גרוע יותר (כל לקוח הוא אינדיבידואלי) ובדרך כלל עמוס בתלונות ("אתה אומר לי שהשרת הוגדר, אבל עכשיו הוא קרס, הכל באשמתך!!!111"). לכן, אם המארח יעזור לכם במשהו, הוא ינסה לעשות את זה כמה שיותר פשוט ונוח. כי לעשות את זה קשה זה לא משתלם, לפחות מנקודת המבט של עלויות העבודה של המהנדסים של אותו מארח (אבל המצבים שונים, ראה ויתור). זה לא אומר שהמארח בהכרח יעשה הכל רע. אבל זה בכלל לא עובדה שהוא יעשה בדיוק את מה שאתה באמת צריך.

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

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

באילו מקרים יש צורך ב-Networker?

בהמשך נדבר ספציפית על חברות מזון מודרניות. עם מפעילים וארגונים, הכל ברור, פלוס מינוס - מעט השתנה שם בשנים האחרונות, ואנשי רשת היו צריכים שם בעבר, והם נחוצים עכשיו. אבל עם אותם "צעירים ונועזים" הדברים לא כל כך ברורים. לעתים קרובות הם ממקמים את כל התשתית שלהם בעננים, כך שהם אפילו לא באמת צריכים אדמינים - מלבד המנהלים של אותם עננים, כמובן. התשתית, מצד אחד, די פשוטה בעיצובה, מצד שני, היא אוטומטית היטב (אנסible/puppet, terraform, ci/cd... נו, אתם יודעים). אבל גם כאן יש מצבים שבהם אתה לא יכול בלי מהנדס רשת.

דוגמה 1, קלאסית

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

המארח מוסיף כרטיסי רשת נוספים לשרתים וכולל אותם במתגים שלהם ב-Vlan נפרד. אזור מקומי "שטוח" מופיע בין שרתים. נוֹחַ!

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

מה לעשות?

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

דוגמה 1, המשך

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

מה לעשות?

חבר את השרתים באמצעות LAG (Link Aggregation Group) עם שני כבלים למתגים במדף (גם הם צריכים להיות מיותרים). שמרו את החיבורים בין המתלים והמירו אותם ל"כוכב" (או ל-CLOS האופנתי כעת), כך שאובדן מתלה אחד לא ישפיע על האחרים. בחר מתלים "מרכזיים" שבהם תמוקם ליבת הרשת והיכן יחוברו מתלים אחרים. במקביל, עשו סדר בכתובת, קחו מהמארח (או מ-RIR, אם אפשר) תת-רשת, שאתם בעצמכם (או דרך המארח) מודיעים לעולם.

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

דוגמה 2: ענן

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

מה לעשות?

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

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

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

מה עובד ברשת צריך לדעת?

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

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

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

• להיות מסוגל לא רק לעבוד בלינוקס כמשתמש, אלא גם לנהל אותו, לפחות ברמת sysadmin-jun: התקן את התוכנה הדרושה, הפעל מחדש שירות כושל, כתוב יחידת systemd-unit פשוטה.
• הבינו (לפחות במונחים כלליים) כיצד פועלת מחסנית הרשת בלינוקס, כיצד פועלת הרשת בהיפרוויזורים ובקונטיינרים (lxc / docker / kubernetes).
• כמובן, להיות מסוגל לעבוד עם אנסיב/שף/בובות או מערכת SCM אחרת.
• יש לכתוב שורה נפרדת על SDN ורשתות עבור עננים פרטיים (לדוגמה, TungstenFabric או OpenvSwitch). זהו עוד רובד עצום של ידע.

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

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

מסקנות, או סתם TL;DR

1. מנהל רשת (כמו מהנדס DBA או VoIP) הוא מומחה עם פרופיל צר למדי (בניגוד למנהלי מערכות/מפתחים/SRE), שהצורך בו לא מתעורר מיד (ואולי לא יתעורר במשך זמן רב, למעשה) . אבל אם היא אכן תתעורר, סביר להניח שלא יוחלף במומחיות חיצונית (מנהלי מיקור חוץ או מנהלים למטרות כלליות רגילות, "שגם דואגים לרשת"). מה שקצת יותר עצוב הוא שהצורך במומחים כאלה קטן, ובתנאי, בחברה עם 800 מתכנתים ו-30 מפתחים/מנהלים, אולי יהיו רק שני אנשי רשת שעושים עבודה מצוינת באחריות שלהם. הָהֵן. השוק היה והינו מאוד מאוד קטן, ועם משכורת טובה - אפילו פחות.
2. מצד שני, איש רשת טוב בעולם המודרני חייב להכיר לא רק את הרשתות עצמן (ואיך להפוך את התצורה שלהן לאוטומטית), אלא גם איך מערכות ההפעלה והתוכנות הפועלות על גבי הרשתות הללו מתקשרות איתן. בלי זה, יהיה קשה ביותר להבין מה עמיתיך מבקשים ממך ולהעביר אליהם (באופן סביר) את רצונותיך/דרישותיך.
3. אין ענן, זה רק מחשב של מישהו אחר. אתה צריך להבין ששימוש בעננים ציבוריים/פרטיים או בשירותים של ספק אחסון "שעושה עבורך הכל על בסיס Turnkey" לא משנה את העובדה שהאפליקציה שלך עדיין משתמשת ברשת, ובעיות בה ישפיעו על תפעול האפליקציה שלך. בחירתכם היא היכן ימוקם מרכז הכשירות, אשר יהיה אחראי על הרשת של הפרויקט שלכם.

מקור: www.habr.com