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

היי!

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

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

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

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

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

תפעול שירותים מקוונים

קולסניקוב סרגיי, אחראי על תפעול החנות המקוונת ושירותי המיקרו

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

מספר ההזמנות מ-18 במרץ עד 31 במרץמספר הבקשות למיקרו-שירותי תשלום מקווניםמספר ההזמנות שבוצעו באתר

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

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

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

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

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

בשלב מסוים חשבנו והחלטנו שנמאס לנו לסבול את זה - אנחנו צריכים מערכת מאוחדת כדי לראות את כל התמונה במלואה. הטכנולוגיות העיקריות הכלולות במחסנית שלנו הן Zabbix כמרכז התראה ואחסון מדדים, Prometheus לאיסוף ואחסון מדדי אפליקציה, Stack ELK לרישום ואחסון נתונים מכל מערכת הניטור וכן Grafana להדמיה, Swagger, Docker ועוד שימושי ודברים שמוכרים לכם.

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

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

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

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

בדיקות טכניות 

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

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

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

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

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

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

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

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

והנה רשימת הבדיקה

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

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

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

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

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

קשי

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

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

בנוסף, שינוי הסדרה ל-Krio ב-Hazelcast נתן לנו דחיפה טובה. והמעבר מ-ReplicedMap ל-IMap + Near Cache ב-Hazelcast אפשר לנו למזער את תנועת הנתונים ברחבי האשכול. 

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

מחסנית ריאקטיבית

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

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

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

Elasticsearch

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

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

השתמש בפעולות בכמות גדולה במידת הצורך.

API

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

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

טרנספורמציה ארגונית

Eroshkina Elena, סגנית מנהל IT

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

חלק מהמבנה שלנו הועבר לעבודה על פי העקרונות והפרקטיקות של גישת המוצר. הוקמו צוותים שאחראים כעת על התפעול והפיתוח של כל מוצר. עובדים בצוותים כאלה מעורבים ב-100% ומבנים את עבודתם באמצעות Scrum או Kanban, בהתאם למה שעדיף עליהם, הקמת צינור פריסה, יישום שיטות טכניות, שיטות אבטחת איכות ועוד ועוד.

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

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

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

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

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

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

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

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

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

ממצאים

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

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

Технология. הכרחי שהחברה תנקוט בגישה בוגרת לעבודה עם מחסנית הטכנולוגיה שלה ותבנה מיומנויות היכן שהיא באמת נחוצה. זה נשמע מאוד פשוט ומובן מאליו. ולעתים קרובות מאוד התעלמו.

Процессы. חשוב לארגן נכון את העבודה של צוותי מוצר ומרכזי יכולת, ליצור אינטראקציה עם העסק על מנת לעבוד איתו כשותף.

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

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

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

מקור: www.habr.com