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

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

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

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

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

ב-DevOps, כלים וגישות נועדו להבטיח שתהליכי פיתוח, בדיקות ותפעול יפעלו בו זמנית.

מה נובע מגישה זו?

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

  

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

  
  

• אם צוות משתמש ב-Kubernetes, Ansible, Prometheus, Mesosphere ו-Docker, זה לא אומר שהוטמעו שם שיטות DevOps.

  
  

החיים אחרי DevOps לעולם לא יהיו אותו הדבר

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

1. הגדרה עצמית

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

2. כלים ופרקטיקות

התלמידים שולטים בטכנולוגיות ספציפיות מנקודת המבט של שיטת DevOps.

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

אנחנו בתהליך קוּרס אתה תהיה שקוע בתהליך של פיתוח אפליקציה דומה ל-Reddit המפורסמת, החל מהגרסה המונוליטית שלה, עובר שלב אחר שלב לשירותי מיקרו. צעד אחר צעד נשלוט בכלים חדשים: Git, Ansible, Gitlab ונסיים עם Kubernetes ו-Prometheus.

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

מה נותן הידע הזה לכל אחד מהמומחים?

למנהלי מערכת

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

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

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

למפתחים

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

עבור בודקים

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

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

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

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

למדתי DevOps, מה הלאה?

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

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

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

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

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

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

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

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

אני חושב שאחד הטריקים קוּרס - שבמהלך ההכשרה כל תלמיד קובע לעצמו לאיזה כיוון הוא רוצה להתפתח. לעתים קרובות אנו רואים מעברים כאשר מפתח הופך למהנדס תשתית, ומנהל מערכת מבין שהוא מעוניין בכתיבת קוד - ואז הוא לומד את השפה בהמשך ומשלים אותה בכישורי ה-DevOps הנרכשים. לכן, אנו מברכים במיוחד את מי שמרגיש שהקריירה שלו תקועה בצומת דרכים. הקורס מתחיל ב-28 במאי, אך ניתן להצטרף שבועיים לאחר תחילת הלימודים. ניתן לצפות בתוכנית ולגשת למבחן по ссылке. נתראה ב-OTUS!

מקור: www.habr.com