כיצד להשתלט על תשתית הרשת שלך. פרק ראשון. לְהַחזִיק

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

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

אז, התנאים הראשוניים.

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

המטרה האסטרטגית הראשונה שלך היא ללמוד להתנגד לאנטרופיה ולשמור על רמת השירות הניתן.

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

Оборудование

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

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

נניח, שיהיה ברור, שעדיין מדובר בהמשכיות של שירות (כך היה בכל החברות בהן עבדתי).

אז אתה צריך להתחיל עם הציוד. להלן רשימה של נושאים שכדאי לשים אליהם לב:

• סיווג הציוד לפי מידת הקריטיות
• גיבוי של ציוד קריטי
• תמיכה, רישיונות

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

דוגמה

נניח שאנחנו מדברים על מתג שורש במרכז נתונים.

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

חָשׁוּב! אתה לא צריך להחליט בעצמך בנושא הזה. עליך לתאר את הסיכונים, הפתרונות האפשריים והעלויות להנהלה או להנהלת החברה. הם חייבים לקבל החלטות.

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

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

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

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

לא יסלח לך אם תשכח לחדש את התמיכה שלך ויום לאחר סיום החומרה שלך נשבר.

עבודת חירום

לא משנה מה קורה ברשת שלך, באופן אידיאלי עליך לשמור על גישה לציוד הרשת שלך.

חָשׁוּב! חייבת להיות לך גישה למסוף לכל הציוד וגישה זו לא צריכה להיות תלויה במצב של רשת הנתונים של המשתמש.

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

חייב להיות

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

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

שותפים

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

• ספקי אינטרנט ונקודות חילופי תנועה (IX)
• ספקי ערוצי תקשורת

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

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

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

וכמובן, אתה צריך לא רק לשאול את השאלות האלה, אלא, שוב, בתמיכת ההנהלה, לתת מענה מקובל בכל מצב.

גיבוי

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

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

גרסאות תוכנה

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

כאן אתה צריך למצוא את האפשרות הטובה ביותר. כמה המלצות ברורות

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

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

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

מערכת כרטיסים

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

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

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

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

דוגמה

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

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

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

הדרישה השנייה היא זאת

• גישה זו חייבת להירשם (על ידי המחלקה הטכנית ממנה קיבלנו את הבקשה הזו) וכבקשה אנו מקבלים קישור לגישה שנרשמה זו

צורת הבקשה הזו חייבת להיות מובנת לנו, כלומר.

• הבקשה חייבת להכיל מידע לגבי איזו רשת משנה ולאיזו גישה לרשת משנה צריכה להיות פתוחה, וכן את הפרוטוקול ויציאות (במקרה של tcp/udp)

יש לציין גם שם

• תיאור מדוע גישה זו נפתחת
• זמני או קבוע (אם זמני, עד איזה תאריך)

ונקודה חשובה מאוד היא אישורים

• מראש המחלקה שיזם את הגישה (לדוגמה, הנהלת חשבונות)
• מאת ראש המחלקה הטכנית, משם הגיעה בקשה זו למחלקת הרשת (לדוגמה, Helpdesk)

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

רישום

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

להלן מספר המלצות מעשיות:

• אתה צריך לסקור את היומנים מדי יום
• במקרה של סקירה מתוכננת (ולא מצב חירום), אתה יכול להגביל את עצמך לרמות חומרה 0, 1, 2 ולהוסיף דפוסים נבחרים מרמות אחרות אם אתה רואה בכך צורך
• כתוב סקריפט שמנתח יומנים ומתעלם מאותם יומנים שאת התבניות שלהם הוספת לרשימת ההתעלמות

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

ניטור

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

שתי הדוגמאות הפופולריות ביותר בתרגול שלי:

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

חָשׁוּב! הגדר התראות SMS עבור האירועים הקריטיים ביותר. זה חל גם על ניטור וגם על רישום. אם אין לכם משמרת תורנית אז הודעות SMS אמורות להגיע גם מחוץ לשעות העבודה.

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

שנה שליטה

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

כמה טיפים:

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

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

Процессы

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

תהליכים יומיומיים:

• עבודה עם כרטיסים
• עבודה עם יומנים
• שנה שליטה
• גיליון המחאות יומי

תהליכים שנתיים:

• הארכת ערבויות, רישיונות

תהליכים אסינכרוניים:

• תגובה למצבי חירום שונים

מסקנה של החלק הראשון

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

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

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

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

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

מקור: www.habr.com