על מנהלי מערכת, devops, בלבול אינסופי ושינוי DevOps בתוך החברה

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

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

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

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

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

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

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

מי הם DevOps? Devops הם בחורים שמדברים על האינטראקציה של פיתוח תוכנה עם תשתית חיצונית. ליתר דיוק, devops מודרניים מעורבים בתהליכי הפיתוח והפריסה הרבה יותר עמוקים מאשר היו מעורבים אי פעם מנהלי מערכת שפשוט העלו עדכונים ל-ftp. אחת המשימות המרכזיות של מהנדס DevOps כעת היא להבטיח תהליך נוח ומובנה ביעילות של אינטראקציה בין צוותי פיתוח ותשתית המוצר. האנשים האלה הם שאחראים על פריסת מערכות החזרה והפריסה; האנשים האלה הם אלה שמורידים חלק מהעומס מהמפתחים ומתרכזים ככל האפשר במשימה החשובה ביותר שלהם. יחד עם זאת, devops לעולם לא תפעיל כבל חדש או תנפיק מחשב נייד חדש מהחדר האחורי (ג) KO

מה הקאץ?

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

אבל מה זה אומר לעסקים?

גיוס עובדים, זה הכל.

אתה פותח משרה ל"מנהל מערכת", והדרישות המפורטות שם הן "אינטראקציה עם פיתוח ולקוחות", "מערכת אספקת CI/CD", "תחזוקת שרתי וציוד החברה", "ניהול מערכות פנימיות" וכדומה. עַל; אתה מבין שהמעסיק מדבר שטויות. הקאץ' הוא שבמקום "מנהל מערכת" כותרת המשרה הפנויה צריכה להיות "DevOps Engineer", ואם הכותרת הזו תשתנה, אז הכל יסתדר.

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

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

לא לא ועוד פעם לא. מנהלי תשתית, שינהלו את השרתים הפנימיים של החברה, או יתפסו עמדות תמיכה L2/L3 ויעזרו לעובדים אחרים, לא נעלמו ולא הולכים להיעלם.

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

בעיה נוספת של DevOps

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

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

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

מַצָב. DevOps נדרש לפרוס מערכת החזרת גרסאות מבלי להתעמק באמת כיצד היא תעבוד. נניח שבתוך מערכת Users ישנם שדות נפרדים לשם פרטי, שם משפחה וסיסמה. גרסה חדשה של המוצר יוצאת, אבל עבור מפתחים, "החזרה" היא רק שרביט קסמים שיתקן הכל, והם אפילו לא יודעים איך זה עובד. כך, למשל, בתיקון הבא המפתחים שילבו את שדות השם הפרטי ושדות המשפחה, גלגלו אותו לייצור, אבל הגרסה איטית משום מה. מה קורה? ההנהלה מגיעה ל-devops ואומרת "Pull the switch!", כלומר מבקשת ממנו לחזור לגרסה הקודמת. מה עושה devops? זה חוזר לגרסה הקודמת, אבל מכיוון שהמפתחים לא רצו להבין איך החזרה זו בוצעה, אף אחד לא אמר לצוות devops שצריך גם להחזיר את מסד הנתונים לאחור. כתוצאה מכך, הכל קורס לנו, ובמקום אתר איטי, המשתמשים רואים שגיאת "500", מכיוון שהגרסה הישנה לא עובדת עם השדות של מסד הנתונים החדש. Devops לא יודע על זה. המפתחים שותקים. ההנהלה מתחילה לאבד את העצבים והכסף וזוכרת את הגיבויים, מציעה לחזור מהם כדי ש"לפחות משהו יעבוד". כתוצאה מכך, משתמשים מאבדים את כל הנתונים שלהם במשך תקופה מסוימת.

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

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

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

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

מקור: www.habr.com