איך שינינו את המצב המחובר תמיד כדי למנוע שחיקה

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

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

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

להיות "תמיד דלוק" מחוץ לשעות העבודה משפיע לרעה על חייך.

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

היסטוריה של מצב "תמיד מחובר" באינטרקום

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

היו יותר מדי אנשים "כוננות" בכל רגע נתון.

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

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

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

מציאת מצב "תמיד פועל" הנכון

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

כתוצאה מכך, צוות התמיכה שלנו צומצם מ-30 אנשים ל-6 או 7 בלבד.

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

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

מה שלמדנו

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

מספר השיחות לאחר שעות העבודה ירד לפחות מ-10 בחודש.

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

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

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

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

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

מקור: www.habr.com