אין מהנדסי DevOps. מי אם כן קיים, ומה לעשות עם זה?

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

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

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

על תרבות ותהליכים

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

לדוגמה, תיאור ההבדל בין מנהל מערכת לבין גישת SRE לניהול שירות ספר Google SRE המפורסם מתחיל. מחקרים מעניינים בוצעו בפנים סקר DORA - ברור שהמפתחים הטובים ביותר מצליחים איכשהו לפרוס שינויים חדשים לייצור מהר יותר מפעם בשעה. הם בודקים עם הידיים שלהם לא יותר מ-10% (ניתן לראות זאת מתוך DORA של שנה שעברה). איך הם עושים את זה? "הצטיין או תמות" אומרת אחת מכותרות הדוח. לדיון מפורט בסטטיסטיקה זו בהקשר של בדיקות, ניתן להתייחס לנושא המרכזי של ברוך סדוגורסקי "יש לנו DevOps. בואו נפטר את כל הבוחנים". בכנס השני שלנו, Heisenbug.

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

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

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

מעגל קסמים

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

תאר לעצמך: אתמול עשית שווארמה בחימקי, והיום אתה כבר איש גדול, מגייס בכיר. יש תהליך שלם של חיפוש ובחירת מועמדים, הכל לא קל, צריך להבין. נניח שראש מחלקה אומר: מצא מומחה ב-X. אנחנו מקצים את המילה "מהנדס" ל-X, וסיימנו. צריך לינוקס? ובכן, זה בהחלט מהנדס לינוקס, אם אתה רוצה DevOps, אז מהנדס DevOps. המשרה הפנויה מורכבת לא רק מכותרת, אלא יש להזין טקסט כלשהו בפנים. הדרך הקלה ביותר היא להזין קבוצה של מילות מפתח מגוגל, בהתאם לדמיון שלך. DevOps מורכב משתי מילים - "Dev" ו- "Ops", מה שאומר שעלינו להדביק יחד מילות מפתח הקשורות למפתחים ומנהלי מערכת, הכל לערימה אחת. כך מופיעות משרות פנויות לגבי בקיאות ב-42 שפות תכנות ו-20 שנות שימוש בו-זמנית ב-Kubernetes וב-Swarm. תרשים עבודה.

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

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

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

כמובן, מלבד מנהלי המערכת ששינו את שמם ל"devops", ישנם משתתפים נוספים - למשל, SREs מקצועיים או מפתחי Infrastructure-as-Code.

מה אנשים עושים ב-DevOps (באמת)

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

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

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

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

יש גם חלק טכני בנושא, כמובן. אם הקוד החדש שלך ייבדק בעוד חודש, אך ישוחרר רק שנה לאחר מכן, וזה בלתי אפשרי פיזית להאיץ את הכל, ייתכן שלא תעמוד בשיטות עבודה טובות. שיטות עבודה טובות נתמכות בכלים טובים. לדוגמה, עם הרעיון של Infrastructure-as-Code, אתה יכול להשתמש בכל דבר מ-AWS CloudFormation ו- Terraform ועד Chef-Ansible-Puppet. אתה צריך לדעת ולהיות מסוגל לעשות את כל זה, וזו כבר דיסציפלינה הנדסית. חשוב לא לבלבל בין סיבה לתוצאה: תחילה עובדים על פי עקרונות SRE ורק לאחר מכן מיישמים את העקרונות הללו בצורה של כמה פתרונות טכניים ספציפיים. יחד עם זאת, SRE היא מתודולוגיה מקיפה מאוד שאינה אומרת לך כיצד להקים את ג'נקינס, אלא על חמישה עקרונות בסיסיים:

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

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

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

בתורו, פתרונות Cloud Native הפכו כעת לפופולריים מאוד. כפי שהוגדר על ידי קרן Cloud Native Computing כיום, טכנולוגיות Cloud Native מאפשרות לארגונים לפתח ולהריץ יישומים ניתנים להרחבה בסביבות דינמיות של ימינו, כגון עננים ציבוריים, פרטיים ועננים היברידיים. דוגמאות כוללות קונטיינרים, רשתות שירות, מיקרו-שירותים, תשתית בלתי ניתנת לשינוי וממשקי API הצהרתיים. כל הטכניקות הללו מאפשרות למערכות משולבות רופפות להישאר אלסטיות, ניתנות לניהול וניתנות לצפייה גבוהה. אוטומציה טובה מאפשרת למהנדסים לבצע שינויים גדולים בתדירות גבוהה ועם תוצאות צפויות מבלי להפוך זאת למטלה. כל זה נתמך על ידי ערימה של כלים ידועים כמו Docker ו-Kubernetes.

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

מה לעשות עם כל זה

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

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

• תהליכים ותרבות;
• הנדסת אמינות אתרים;
• Cloud Native;

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

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

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

• מפתחים שעובדים על תשתיות. קבוצות הדוחות על SRE ו-Cloud Native מתאימות לך ביותר.
• מנהלי מערכת. כאן זה יותר מסובך. DevOops לא עוסק בניהול מערכת. למרבה המזל, יש הרבה כנסים מצוינים, ספרים, מאמרים, סרטונים באינטרנט וכו' בנושא ניהול מערכת. מצד שני, אם אתם מעוניינים לפתח את עצמכם מבחינת הבנת תרבות ותהליכים, ללמוד על טכנולוגיות ענן ופרטי החיים עם Cloud Native, אז נשמח לראותכם! תחשוב על זה: אתה עושה אדמיניסטרציה, ואז מה תעשה? כדי לא למצוא את עצמך פתאום במצב לא נעים, כדאי ללמוד עכשיו.

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

החלק מ דו"ח של קונסטנטין דינר במינכן

DevOops 2020 מוסקבה יתקיים ב-29-30 באפריל במוסקבה, הכרטיסים כבר זמינים לקנות באתר הרשמי.

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

מקור: www.habr.com