אנו הופכים את התמיכה לזולה יותר, ומשתדלים לא לאבד איכות

מצב Fallback (המכונה גם IPKVM), המאפשר להתחבר ל-VPS ללא RDP ישירות משכבת ​​ה-Hypervisor, חוסך 15-20 דקות בשבוע.

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

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

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

אל תעצבן אנשים מס' 1

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

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

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

אל תעצבן אנשים מס' 2

הדבר השני שפותח באותה מידה את הראש הוא כשאף אחד לא מגיב לכרטיס מספיק זמן. באירופה התנהגות התמיכה הזו נורמלית: שלושה ימים לפני קבלת אירוע לעבודה זה יותר מהמקובל. גם אם אתה מאוד דחוף ומשהו בוער - בלי רשתות חברתיות, בלי טלפון, בלי מסנג'ר, פשוט מייל וחכו לתורכם. ברוסיה זה הרבה פחות נפוץ, אבל כמה כרטיסים עדיין "נשכחים". ממש בתחילת העבודה, קבענו SLA לתגובה ראשונה של 15 דקות. וזה כנה 24/7. ברור שכאשר אירוח VDS הופך לגדול, זה מופיע. אבל לנותני שירותים מפוקפקים אין את זה. ורק היינו בספק בהתחלה ורק אז הפכנו לגדולים יותר או פחות. בסדר, פחות או יותר ממוצע.

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

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

צמצם את מספר הבקשות

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

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

התכונה השנייה, שחוסכת זמן רב, היא הזמן הארוך שלוקח למילוי מאגר הידע. אם למשתמש יש בעיה שאינה כלולה ברשימת הפעולות הנתמכות (לרוב אלו הן שאלות ברמה של "איך להתקין שרת Minecraft" או "היכן להגדיר VPS ב-Win Server"), אז המאמר כתוב במאגר הידע. אותו מאמר מפורט נכתב לכל הבקשות המוזרות. לדוגמה, אם משתמש מבקש מתמיכה להסיר את חומת האש המובנית של Windows Server, אנו שולחים אותו לקרוא על מה יקרה אם היא באמת מושבתת, וכיצד לשנות הרשאות רק עבור תוכנות נבחרות. כי הבעיה היא בדרך כלל בעובדה שמשהו לא יכול להתחבר בגלל ההגדרות, ולא עם חומת האש עצמה. אבל קשה מאוד להסביר זאת בכל פעם בדיאלוג. אבל איכשהו אני לא רוצה להשבית את חומת האש, כי די מהר נאבד או את המכונה הוירטואלית או את הלקוח.

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

מצב חירום

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

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

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

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

בעיות שנותרו

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

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

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

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

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

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

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

יש כאלה שפשוט ספאם, שלי או מפרים את ההצעה בדרך אחרת. ואז הוא דופק לתמיכה ושואל מה השתבש ולמה המכונית חסומה. אם התהליך בכרטיס בצילום המסך נקרא "spam sender.exe", כנראה שמשהו משתבש. בערך אחת לשבועיים אנו מקבלים תלונות מסוני או מלוקאספילם (כיום דיסני) על כך שמישהו מהמכונה הוירטואלית שלנו ממגוון כתובות ה-IP שלנו מפיץ סרט צרוב. לשם כך מיד תחסמו ותחזירו את הכסף שנותר בחשבון לפי ההצעה (להזכירכם: הקוונטיזציה שלנו היא לשנייה, כלומר תמיד תהיה יתרה בטוחה). וכדי לקבל את הכסף בחזרה, על פי החוק, צריך להראות דרכון: מדובר באיסור הלבנת הון. משום מה, במקום להציג דרכון, כותבים הפיראטים שסחטנו מהם כסף, שוכחים להבהיר חלק מהנסיבות.

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

סך הכל

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

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

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

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

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

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

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

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

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

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

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

מקור: www.habr.com