🥇 למנהל מערכת מתחיל: איך לעשות סדר בכאוס

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

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

עמודי התווך של מנהל המערכת

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

תיעוד
תבנית
אופטימיזציה
אוטומציה

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

רשומות

רשומות לא אומר לקרוא תיעוד (אם כי אי אפשר בלעדיו), אלא גם לשמור עליו.

כיצד לשמור תיעוד:

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

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

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

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

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

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

תבנית

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

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

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

אופטימיזציה

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

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

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

אוטומציה

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

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

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

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

חינוך עצמי למנהל מערכת

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

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

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

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

10 מצוות מנהל המערכת

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

כמה מעמיתיי מאמינים שהכלל הראשון הוא "אל תזיק". אבל אני נוטה לא להסכים. כשאתה מנסה לא להזיק, אתה לא יכול לעשות כלום - יותר מדי פעולות עלולות להיות הרסניות. אני חושב שהכלל הכי חשוב הוא - "עשה גיבוי". גם אם אתה עושה קצת נזק, אתה תמיד יכול להתהפך והכל לא יהיה כל כך גרוע.
עליך תמיד לגבות כאשר הזמן והמקום מאפשרים זאת. אתה צריך לגבות את מה שתשנה ומה אתה מסתכן לאבד עקב פעולה שעלולה להיות הרסנית. רצוי לבדוק את תקינות הגיבוי ונוכחות כל הנתונים הדרושים. אין למחוק את הגיבוי מיד לאחר שבדקת הכל, אלא אם כן עליך לפנות מקום בדיסק. אם המיקום דורש זאת, גבה אותו לשרת האישי שלך ומחק אותו לאחר שבוע.
הכלל השני בחשיבותו (שאני בעצמי שוברת לעיתים קרובות) הוא "אל תסתיר". אם עשית גיבוי, כתוב איפה, כדי שהקולגות שלך לא יצטרכו לחפש אותו. אם עשית כמה פעולות לא ברורות או מורכבות, רשום את זה: אתה תחזור הביתה, והבעיה עלולה לחזור על עצמה או להתעורר אצל מישהו אחר, והפתרון שלך יימצא באמצעות מילות מפתח. גם אם אתה עושה משהו שאתה יודע היטב, ייתכן שהקולגות שלך לא.
אין צורך להסביר את הכלל השלישי: "לעולם אל תעשה משהו שאת ההשלכות שלו אתה לא יודע, מדמיין או מבין". אל תעתיק פקודות מהאינטרנט אם אתה לא יודע מה הן עושות, התקשר לאדם ונתח אותן קודם. אל תשתמש בפתרונות מוכנים אם אתה לא יכול להבין מה הם עושים. שמור על ביצוע של קוד מעורפל למינימום מוחלט. אם אין לך זמן להבין את זה, אז אתה עושה משהו לא בסדר וכדאי לקרוא את הנקודה הבאה.
"מִבְחָן". יש לבחון סקריפטים, כלים, קווים ופקודות חדשים בסביבה מבוקרת, לא במחשב הלקוח, אם יש אפילו פוטנציאל מינימלי לפעולות הרסניות. גם אם גיבית את הכל (ועשית), זמן השבתה הוא לא הדבר הכי מגניב. צור שרת/וירטואלי/ chroot נפרד עבור זה ובדוק שם. משהו נשבר? אז אתה יכול להפעיל אותו ב"קרב".
"לִשְׁלוֹט". צמצם את כל הפעולות שאינך שולט בהן. עקומת תלות אחת בחבילה יכולה לגרור מטה חצי מהמערכת, ודגל -y שהוגדר עבור yum remove נותן לך את ההזדמנות לתרגל את כישורי שחזור המערכת שלך מאפס. אם לפעולה אין חלופות בלתי מבוקרות, הנקודה הבאה היא גיבוי מוכן.
"חשבון". בדוק את ההשלכות של פעולותיך והאם עליך לחזור לגיבוי. בדוק אם הבעיה באמת נפתרה. בדוק אם השגיאה משוכפלת ובאילו תנאים. בדוק מה אתה יכול לשבור עם המעשים שלך. מיותר לסמוך על העבודה שלנו, אבל לעולם לא לבדוק.
"לתקשר". אם אינך יכול לפתור את הבעיה, שאל את עמיתיך אם הם נתקלו בכך. אם אתה רוצה להחיל החלטה שנויה במחלוקת, גלה את דעתם של עמיתיך. אולי הם יציעו פתרון טוב יותר. אם אינך בטוח במעשיך, שוחח עליהם עם עמיתיך. גם אם זה תחום ההתמחות שלך, מבט חדש על המצב יכול להבהיר הרבה. אל תתבייש בבורות שלך. עדיף לשאול שאלה טיפשית, להיראות כמו טיפש ולקבל תשובה, מאשר לא לשאול את השאלה, לא לקבל תשובה ולגמור להיות טיפש.
"אל תסרב לעזרה בצורה בלתי סבירה". נקודה זו היא ההפך מקודמתה. אם שואלים אותך שאלה טיפשית, הבהירו והסבירו. הם מבקשים את הבלתי אפשרי – מסבירים שזה בלתי אפשרי ולמה, מציעים אלטרנטיבות. אם אין לך זמן (באמת אין זמן, אין חשק) - תגיד שיש לך שאלה דחופה, כמות גדולה של עבודה, אבל אתה תסדר את זה מאוחר יותר. אם לקולגות אין משימות דחופות, הציעו ליצור איתם קשר ולהאציל את השאלה.
"תן משוב". האם אחד מעמיתיך החל להשתמש בטכניקה חדשה או בתסריט חדש, והאם אתה נתקל בתוצאות שליליות של החלטה זו? דווח על זה. אולי ניתן לפתור את הבעיה בשלוש שורות קוד או חמש דקות של חידוד הטכניקה. נתקלתם בבאג בתוכנה שלכם? דווח על באג. אם ניתן לשחזר או אין צורך לשחזר אותו, סביר להניח שהוא יתוקן. השמיעו את רצונותיכם, ההצעות והביקורת הבונה שלכם, והעלו שאלות לדיון אם הן נראות רלוונטיות.
"בקש משוב". כולנו לא מושלמים, בדיוק כמו ההחלטות שלנו, והדרך הטובה ביותר לבדוק את נכונות ההחלטה שלך היא להעלות אותה לדיון. אם ביצעת אופטימיזציה של משהו עבור לקוח, בקש ממנו לעקוב אחר העבודה; אולי צוואר הבקבוק במערכת אינו המקום שחיפשת. כתבת תסריט עזרה - הצג אותו לעמיתיך, אולי הם ימצאו דרך לשפר אותו.

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

הכלים העיקריים שתצטרך לעבוד איתם יותר מ-50% מהזמן הם grep ו-vim. מה יכול להיות יותר פשוט? חיפוש טקסט ועריכת טקסט. עם זאת, גם grep וגם vim הם רב-כלים רבי עוצמה המאפשרים לך לחפש ולערוך טקסט ביעילות. אם פנקס רשימות כלשהו של Windows מאפשר לך פשוט לכתוב/למחוק שורה, ב-vim אתה יכול לעשות כמעט הכל עם טקסט. אם אתה לא מאמין לי, התקשר לפקודת vimtutor מהמסוף ותתחיל ללמוד. לגבי grep, החוזק העיקרי שלו הוא בביטויים רגולריים. כן, הכלי עצמו מאפשר לך להגדיר תנאי חיפוש ולהוציא נתונים בצורה גמישה למדי, אבל בלי RegExp זה לא הגיוני במיוחד. ואתה צריך לדעת ביטויים רגולריים! לפחות ברמה הבסיסית. מלכתחילה, הייתי ממליץ לך להסתכל על זה וידאו, הוא מכסה את היסודות של ביטויים רגולריים והשימוש בהם בשילוב עם grep. אה, כן, כשאתה משלב אותם עם vim, אתה מקבל את היכולת ULTIMATE POWER לעשות דברים עם טקסט שאתה צריך לתייג אותם עם 18+ סמלים.

מתוך 50% הנותרים, 40% מגיעים מערך הכלים של coreutils. עבור coreutils אתה יכול להסתכל ברשימה ב ויקיפדיה, והמדריך לרשימה כולה נמצא באתר גנה. מה שלא מכוסה בסט זה נמצא בשירותים POSIX. אתה לא צריך ללמוד את כל המפתחות בעל פה, אבל זה מועיל לפחות לדעת בערך מה הכלים הבסיסיים יכולים לעשות. לא צריך להמציא מחדש את הגלגל מקביים. איכשהו הייתי צריך להחליף את מעברי השורות ברווחים בפלט משירות כלשהו, והמוח החולה שלי הוליד בנייה כמו sed ':a;N;$!ba;s/n/ /g', עמית ניגש והרחיק אותי מהקונסולה עם מטאטא, ואז פתר את הבעיה על ידי כתיבה tr 'n' ' '.

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

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

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

מקור: www.habr.com

למנהל מערכת מתחיל: איך ליצור סדר מתוך כאוס