המפתחים הם ממאדים, המנהלים הם מ- Venus

צירופי מקרים הם אקראיים, ואכן זה היה בכוכב אחר...

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

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

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

- אחריות גבוהה.
- סכנת שבירת ייצור.
- קשה להיות מומחה טוב בכל התחומים.

לא מעוניין, בוא נמשיך

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

• זמן פריסה ממוצע בייצור הוא 4-5 שעות
• זמן פריסה מרבי בייצור 9 שעות
• עבור מפתח, אפליקציה בייצור היא קופסה שחורה, בדיוק כמו שרת הייצור עצמו. כמה יש בסך הכל?
• איכות נמוכה של מהדורות, שגיאות תכופות
• המפתח אינו משתתף בתהליך השחרור

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

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

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

מערכה 3, קצרה
כרטיס דחוף, פונקציונליות מפתח לא עובדת עבור אחד המשתמשים בייצור. אנחנו מבלים כמה שעות בחטטנות ובודקים. בסביבת פיתוח הכל עובד. ישנה הבנה ברורה שזה יהיה רעיון טוב לעיין ביומני php-fpm. לא היו מערכות יומן כמו ELK או פרומתאוס בפרויקט באותה תקופה. אנחנו פותחים כרטיס למחלקת הניהול כדי שיתנו גישה ללוגי php-fpm בשרת. כאן אתה צריך להבין שאנחנו מבקשים גישה מסיבה כלשהי, אתה לא זוכר שהחור השחור והמנהלים עסוקים 24/7? אם אתה מבקש מהם להסתכל על היומנים עצמם, אז זו משימה עם עדיפות "לא בחיים האלה". הכרטיס נוצר, קיבלנו תשובה מיידית מראש מחלקת המינהל: "לא צריך גישה ליומני ייצור, כתוב בלי באגים." וילון.

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

הִשׁתַנוּת.
לאחר שסבלנו את כל זה די הרבה זמן, יחד עם הצוות התחלנו לנווט לכיוון שהיה יותר מוצלח עבורנו. לסיכום, עם אילו בעיות התמודדנו?

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

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

סיפור שלישי
סטארט - אפ. מנהל אחד, מחלקת פיתוח קטנה. עם ההגעה אני אפס מוחלט, כי... אין לי גישה לשום מקום מלבד מהדואר. אנו כותבים למנהל המערכת ומבקשים גישה. בנוסף, יש מידע שהוא מודע לעובד החדש ולצורך בהוצאת כניסות/סיסמאות. הם נותנים גישה מהמאגר ומה-VPN. למה לתת גישה ל-wiki, teamcity, rundesk? דברים חסרי תועלת לאדם שנקרא לכתוב את כל החלק האחורי. רק עם הזמן אנחנו מקבלים גישה לכלים מסוימים. ההגעה, כמובן, נתקלה בחוסר אמון. אני מנסה לאט לאט להרגיש איך פועלת התשתית של הפרויקט באמצעות צ'אטים ושאלות מובילות. בעיקרון אני לא מזהה כלום. הייצור הוא אותה קופסה שחורה כמו קודם. אבל יותר מזה, אפילו שרתי הבמה המשמשים לבדיקה הם קופסה שחורה. אנחנו לא יכולים לעשות שום דבר מלבד לפרוס שם סניף מ-Git. אנחנו גם לא יכולים להגדיר את היישום שלנו כמו קבצי .env. גישה לפעולות כאלה אינה ניתנת. אתה צריך להתחנן כדי לשנות שורה בתצורה של היישום שלך בשרת הבדיקה. (יש תיאוריה שחיוני שמנהלי מערכת ירגישו שהם חשובים בפרויקט; אם הם לא יתבקשו לשנות שורות בהגדרות, פשוט לא יהיה צורך בהם). ובכן, כמו תמיד, זה לא נוח? זה נהיה משעמם מהר, אחרי שיחה ישירה עם האדמין אנחנו מגלים שהמפתחים נולדו לכתוב קוד גרוע, הם מטבעם אנשים לא מוכשרים ועדיף להרחיק אותם מהייצור. אבל כאן גם משרתי בדיקה, ליתר בטחון. הסכסוך הולך ומחריף במהירות. אין תקשורת עם המנהל. המצב מחמיר בשל העובדה שהוא לבד. להלן תמונה טיפוסית. לְשַׁחְרֵר. פונקציונליות מסויימת לא עובדת. לוקח לנו הרבה זמן להבין מה קורה, רעיונות שונים ממפתחים נזרקים לצ'אט, אבל המנהל במצב כזה מניח בדרך כלל שהמפתחים הם האשמים. ואז הוא כותב בצ'אט, רגע, תיקנתי אותו. כשאנחנו מתבקשים להשאיר מאחור סיפור עם מידע על מה הייתה הבעיה, אנחנו מקבלים תירוצים רעילים. כאילו, אל תדביק את האף שלך במקום שהוא לא שייך. מפתחים חייבים לכתוב קוד. המצב שבו תנועות גוף רבות בפרויקט עוברות דרך אדם אחד ורק לו יש גישה לבצע את הפעולות שכולם צריכים הוא עצוב ביותר. אדם כזה הוא צוואר בקבוק נוראי. אם רעיונות Devops שואפים לצמצם את זמן היציאה לשוק, אז אנשים כאלה הם האויב הגרוע ביותר של רעיונות Devops. למרבה הצער, המסך נסגר כאן.

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

מקור: www.habr.com