אנחנו עוקבים אחר ספורטמאסטר - איך ועם מה

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

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

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

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

הפלטפורמה שבה פועלות החנויות המקוונות שלנו נראית כך:

• חזית
• משרד אמצעי
• משרד אחורי

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

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

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

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

מבנה מערכת וערימה

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

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

לכן, הם החליטו לאכול את הפיל בחלקים.

המערכת שלנו מורכבת מ:

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

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

אז לגבי המחסנית.

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

שילבנו את Zabbix עם Telegram Messenger ו-Microsoft Teams, שנמצאים בשימוש פעיל בצוותים. Zabbix מכסה את השכבה של הרשת בפועל, החומרה ותוכנות מסוימות, אבל זה לא תרופת פלא. אנו מעשירים את הנתונים הללו מכמה שירותים אחרים. לדוגמה, ברמת החומרה, אנו מתחברים ישירות דרך API למערכת הוירטואליזציה שלנו ואוספים נתונים.

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

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

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

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

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

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

לבסוף, שלישית, מקור הנתונים הוא מערכת רישום מרכזית. אנו משתמשים ב- Elastic Stack עבור יומנים, ואז נוכל למשוך את הנתונים הללו למערכת הניטור שלנו עבור מדדים עסקיים. בנוסף לכל זה, יש לנו שירות Monitoring API משלנו, כתוב ב-Python, אשר מבצע שאילתות לכל שירות דרך API ואוסף מהם נתונים לתוך Zabbix.

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

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

נקודה חשובה נוספת היא ששכבת היישום מורכבת על ידי פרומתאוס. הוא עצמו גם משולב עם Zabbix. ויש לנו גם sitespeed, שירות שמאפשר לנו לראות פרמטרים כמו מהירות טעינת העמוד שלנו, צווארי בקבוק, עיבוד עמודים, טעינת סקריפטים וכו', הוא גם משולב API. אז המדדים שלנו נאספים ב-Zabix, ובהתאם, אנחנו גם מתריעים משם. כל ההתראות נשלחות כרגע לשיטות השליחה העיקריות (בינתיים זה דואר אלקטרוני ומברק, גם MS Teams התחבר לאחרונה). ישנן תוכניות לשדרג את ההתראה למצב כזה שבוטים חכמים פועלים כשירות ומספקים מידע ניטור לכל צוותי המוצר המתעניינים.

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

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

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

סיכויים

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

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

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

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

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

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

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

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

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

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

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

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

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

מקור: www.habr.com