מי הם DevOps?

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

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

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

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

אז מי הם מהנדסי DevOps?

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

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

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

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

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

מהנדס בנייה/מהנדס שחרור

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

אופציות כל כך שונות

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

• TechOps - מנהלי מערכות של enikey aka HelpDesk Engineer
• LiveOps - מנהלי מערכות האחראים בעיקר על סביבות ייצור
• CloudOps - מנהלי מערכת המתמחים בעננים ציבוריים Azure, AWS, GCP וכו'.
• PlatOps/InfraOps/SysOps - מנהלי מערכות תשתית.
• NetOps - מנהלי רשת
• SecOps - מנהלי מערכת המתמחים באבטחת מידע - תאימות PCI, תאימות CIS, תיקון וכו'.

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

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

האם זה נכון בחברה שלך? - אני בספק. ברוב המקרים, מדובר ב-IT או במו"פ.

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

שוק המשאבים של DevOps

בואו נסתכל על כמה משרות פנויות לתפקידי DevOps מחברות שונות.

אנו מוכנים להיפגש איתך אם אתה:

1. אתה הבעלים של Zabbix ויודע מה זה פרומתאוס;
2. Iptables;
3. סטודנט לדוקטורט BASH;
4. פרופסור אנסיבל;
5. לינוקס גורו;
6. לדעת כיצד להשתמש באגים ולמצוא בעיות באפליקציות יחד עם מפתחים (php/java/python);
7. ניתוב לא הופך אותך להיסטרי;
8. שימו לב משמעותית לאבטחת המערכת;
9. גיבוי "הכל והכל", וגם לשחזר בהצלחה את "הכל והכל" הזה;
10. אתה יודע להגדיר את המערכת בצורה כזו שתפיק את המקסימום מהמינימום;
11. הגדר שכפול לפני השינה ב-Postgres וב-MySQL;
12. הגדרה והתאמת CI/CD היא הכרחית עבורך כמו ארוחת בוקר/צהריים/ערב.
13. בעל ניסיון עם AWS;
14. מוכן להתפתח עם החברה;

אז:

• מ-1 עד 6 - מנהל מערכת
• 7 - קצת ניהול רשת, שמתאים גם למנהל המערכת, רמה בינונית
• 8 - מעט אבטחה, שהיא חובה למנהל מערכת ברמה בינונית
• 9-11 - מנהל מערכת אמצעית
• 12 - בהתאם למשימות שהוקצו, מנהל מערכת אמצעית או מהנדס בנייה
• 13 - וירטואליזציה - מנהל מערכת אמצעית, או מה שנקרא CloudOps, ידע מתקדם בשירותי אתר אירוח ספציפי, לצורך שימוש יעיל בכספים והפחתת העומס על תחזוקה

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

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

בואו נבחן משרה פנויה נוספת:

1. ניסיון בבניית מערכות עומס גבוה;
2. ידע מצוין במערכת ההפעלה לינוקס, תוכנת מערכת כללית ו-web stack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. ניסיון במערכות וירטואליזציה (KVM, VMWare, LXC/Docker);
4. שליטה בשפות סקריפטים;
5. הבנת עקרונות הפעולה של רשתות פרוטוקול רשת;
6. הבנת העקרונות של בניית מערכות סבילות לתקלות;
7. עצמאות ויוזמה;

בוא נסתכל על:

• 1 - מנהל מערכת בכיר
• 2 - בהתאם למשמעות שהוכנסה למחסנית זו - מנהל מערכת בינוני/בכיר
• 3 - ניסיון בעבודה, כולל, עשוי להיות - "האשכול לא העלה, אלא יצר וניהל מכונות וירטואליות, היה מארח Docker אחד, גישה לקונטיינרים לא הייתה זמינה" - מנהל מערכת אמצעית
• 4 - מנהל מערכת ג'וניור - כן, אדמין שלא יודע לכתוב סקריפטים אוטומציה בסיסיים, ללא קשר לשפה, לא אדמין - enikey.
• 5 - מנהל מערכת אמצעית
• 6 - מנהל מערכת בכיר

לסיכום - מנהל מערכת בינוני/בכיר

עוד אחד:

1. מפזר ניסיון;
2. ניסיון בשימוש במוצר אחד או יותר ליצירת תהליכי CI/CD. Gitlab CI יהווה יתרון;
3. עבודה עם קונטיינרים ווירטואליזציה; אם השתמשת בדוקר, טוב, אבל אם השתמשת ב-k8s, נהדר!
4. ניסיון בעבודה בצוות זריז;
5. ידע בכל שפת תכנות;

בוא נראה:

• 1 - הממ... למה החבר'ה מתכוונים? =) סביר להניח שהם עצמם לא יודעים מה מסתתר מאחורי זה
• 2 - מהנדס בניין
• 3 - מנהל מערכת אמצעית
• 4 - מיומנות רכה, לא נשקול את זה לעת עתה, אם כי זריז הוא דבר נוסף שמתפרש בצורה נוחה.
• 5 - מילולי מדי - זו יכולה להיות שפת סקריפטים או שפת קומפילציה. מעניין אם כתיבה בפסקל ובייסיק בבית הספר תתאים להם? =)

ברצוני להשאיר הערה גם לגבי נקודה 3 על מנת לחזק את ההבנה מדוע נקודה זו מכוסה על ידי מנהל המערכת. Kubernetes הוא רק תזמור, כלי שעוטף פקודות ישירות למנהלי רשת ומארחי וירטואליזציה/בידוד בכמה פקודות ומאפשר לך להפוך את התקשורת איתם למופשטת, זה הכל. למשל, ניקח את 'בנה מסגרת' Make, שאני, אגב, לא מחשיב אותה כמסגרת. כן, אני מכיר את האופנה של לדחוף את Make לכל מקום, איפה שצריך ולא צריך - לעטוף את Maven in Make, למשל, ברצינות?
בעיקרו של דבר, Make הוא רק מעטפת מעל המעטפת, המפשטת את פקודות הקומפילציה, הקישור והקומפילציה, בדיוק כמו k8s.

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

בואו נסכם שוב - מנהל מערכת בינוני/בכיר יספיק להם.

כמה לתלות בגרמים

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

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

חוויה:

1. עד 3 שנים - ג'וניור
2. עד גיל 6 - בינוני
3. יותר מ-6 - בכיר

אתר חיפוש העובדים מציע:
מנהלי מערכת:

1. ג'וניור - שנתיים - 2 אלף שפשוף.
2. אמצע - 5 שנים - 70K לשפשף.
3. קשישים - 11 שנים - 100 אלף שפשוף.

מהנדסי DevOps:

1. ג'וניור - שנתיים - 2 אלף שפשוף.
2. אמצע - 3 שנים - 160 אלף שפשוף.
3. קשישים - 6 שנים - 220 אלף שפשוף.

על פי הניסיון של "DevOps", נעשה שימוש בניסיון שלפחות איכשהו השפיע על ה-SDLC.

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

תהליך ההכשרה של מהנדסי DevOps גם מוגבל רק לקבוצה של עבודות ספציפיות, כלי עזר, ואינו מספק הבנה כללית של התהליכים והתלות שלהם. זה בהחלט טוב כשאדם יכול לפרוס את AWS EKS באמצעות Terraform, בשילוב עם ה-Sidecar של Fluentd באשכול זה וערימת AWS ELK עבור מערכת הרישום תוך 10 דקות, באמצעות פקודה אחת בלבד בקונסולה, אבל אם הוא לא מבין את העיקרון של עיבוד יומני עצמו ולמה הם נחוצים, אם אתה לא יודע איך לאסוף עליהם מדדים ולעקוב אחר השפלה של השירות, אז זה עדיין יהיה אותו enikey שיודע להשתמש בכמה כלי עזר.

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

אז מי הם? DevOps או מנהלי מערכות חמדנים? =)

איך להמשיך לחיות?

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

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

מקור: www.habr.com