חמש בעיות בתהליכי תפעול ותמיכה במערכות Highload IT

שלום, הבר! אני תומך במערכות IT של Highload כבר עשר שנים. לא אכתוב במאמר זה על הבעיות של הגדרת nginx לעבוד במצב 1000+ RPS או דברים טכניים אחרים. אשתף בתצפיות שלי לגבי הבעיות בתהליכים המתעוררים בתמיכה ובהפעלה של מערכות כאלה.

ניטור

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

מה לעשות עם המצב שבו שאר הסחורה של חנות מקוונת כבר לא מגיעה ממערכת ה-ERP? או שמערכת ה-CRM שמחשבת הנחות ללקוחות הפסיקה להגיב? נראה שהאתר עובד. Zabbix מותנה מקבלת תגובת 200. המשמרת לא קיבלה שום הודעות מהניטור והיא צופה בשמחה בפרק הראשון של העונה החדשה של משחקי הכס.

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

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

אינטראקציה עם מערכות חיצוניות

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

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

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

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

איש צוואר בקבוק

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

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

כשירות ואחריות של צוות תמיכה

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

אם אנחנו מדברים על חנות מקוונת גדולה, אז כל שעה של השבתה עולה יותר מהשכר החודשי של מנהל Enikey. בואו ניקח 1 מיליארד רובל של מחזור שנתי כנקודת התחלה. זהו המחזור המינימלי של כל חנות מקוונת מהדירוג הטופ 100 לשנת 2018. חלק את הסכום הזה במספר השעות בשנה וקבל יותר מ-100 רובל של הפסדים נטו. ואם לא סופרים את שעות הלילה, אפשר להכפיל את הכמות בבטחה.

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

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

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

אינטראקציה עם צוות הפיתוח

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

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

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

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

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

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

מקור: www.habr.com