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

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

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

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

התמונה הגדולה

- מה היה הרכב הצוות?

ניקולאי מולצ'אנוב: יש לנו אנליסט, מעצב, בוחן, שלושה פרונט-אנדרים ו-back-end. וכמובן, מומחה בצורת T!

- איך נראה התהליך באופן כללי?

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

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

- האם הצלחנו להשיג את מה שהתחייבנו אליו?

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

האתגר היה זה: תן לנו כלי שבעזרתו נוכל לשדר את הכנסים שלנו לבעלי הכרטיסים.

כל התכנון חולק למספר שלבים, וכל התכונות (כ-30 גלובליות) חולקו ל-4 קטגוריות:

• מה שבוודאי נעשה (איננו יכולים לחיות בלעדיהם),
• מה שנעשה שנית,
• מה שלעולם לא נעשה,
• ומה שלעולם, לעולם לא נעשה.

יצרנו את כל התכונות משתי הקטגוריות הראשונות.

- אני יודע שבסך הכל נוצרו 600 גיליונות JIRA. תוך שלושה חודשים יצרת 13 שירותי מיקרו, ואני חושד שהם נכתבו לא רק בג'אווה. השתמשת בטכנולוגיות שונות, יש לך שני אשכולות Kubernetes בשלושה אזורי זמינות ו-5 זרמי RTMP באמזון.

כעת נסתכל על כל רכיב של המערכת בנפרד.

נְהִירָה

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

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

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

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

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

דוגמה לפריסה ל-4 רמקולים

דוגמה לפריסה ל-4 רמקולים

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

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

לאחר מכן, הזרמים מהמחשבים עוברים לשרת מקומי, שיש לו שתי משימות: ניתוב זרמי RTMP והקלטת גיבויים. אז יש לנו מספר נקודות הקלטה. זרמי הווידאו נשלחים לאחר מכן לחלק של המערכת שלנו הבנוי על שירותי Amazon SaaS. אנו משתמשים MediaLive:,S3,CloudFront.

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

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

- האם אנחנו משתמשים ברזולוציית 1080p?

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

שחקן

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

ניקולאי: יש לנו נגן שכל צופי הוועידה יכולים לצפות בו.

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

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

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

דוגמה לציר זמן

- כפתור מובנה ישירות בנגן כדי להציג ציר זמן של כל הדוחות...

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

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

- האם היו קשיים טכניים עם זה?

ניקולאי: היה להם פס גלילה שעליו סומנו נקודות ההתחלה של דוחות שונים.

- בסופו של דבר, האם יישמת את הסימנים האלה בפס הגלילה לפני ש-YouTube עשתה משהו דומה?

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

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

חזיתי

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

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

כך רואה הדובר את הצינור

מערכת זו היא הפיתוח הפנימי שלנו.

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

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

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

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

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

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

- ואז כל זה נכנס לנגן באמצעות מערכת הקצה האחורית. יש לנו TypeScript, React, Next.JS בנגן שלנו. ובחלק האחורי יש לנו מספר שירותים ב-C#, Java, Spring Boot ו-Node.js. כל זה נפרס באמצעות Kubernetes באמצעות תשתית Yandex.Cloud.

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

אילוצים עסקיים ואנליטיקה

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

ניקולאי: בתחילה, התחלנו מדרישות וידאו. הדבר החשוב ביותר הוא אחסון וידאו מבוזר ברחבי העולם לאספקה ​​מהירה ללקוח. אחרים כוללים רזולוציית 1080p, כמו גם הרצה לאחור, שרבים אחרים אינם מיישמים במצב חי. בהמשך הוספנו את היכולת לאפשר מהירות פי 2, בעזרתה תוכלו "להדביק" את הלייב ולהמשיך לצפות בכנס בזמן אמת. ולאורך הדרך הופיעה פונקציונליות של סימון ציר זמן. בנוסף, היינו צריכים להיות סובלניים לתקלות ולעמוד בעומס של 10 חיבורים. מנקודת מבט עורפית, מדובר בכ-000 חיבורים כפול 10 בקשות עבור כל רענון עמוד. וזה כבר 000 RPS/sek. לא מעט.

— האם היו דרישות אחרות ל"תערוכה וירטואלית" עם דוכנים מקוונים של שותפים?

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

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

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

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

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

הונאה

- האם יש לנו מנגנונים נגד הונאה?

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

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

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

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

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

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

ולדימיר: מצד אחד, אנו מורידים את זה לעיבוד OLAP נוסף. ועבור OLTP, האפליקציה מורידה את כל העניין ל-Prometheus, Grafana והגרפים אפילו מתכנסים!

- זה המקרה כאשר הגרפים מתכנסים.

שינויים דינמיים

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

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

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

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

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

פְּרִיסָה

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

ניקולאי: מנקודת מבט טכנית, הייתה לנו בהתחלה דרישה שהמוצר יהיה מופשט ככל האפשר מכל ספק. בוא ל-AWS כדי ליצור סקריפטים של Terraform במיוחד מ-AWS, או ספציפית מ-Yandex, או מ-Azure וכו'. לא ממש התאים. היינו צריכים לעבור למקום כלשהו בשלב מסוים.

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

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

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

לגבי מבחנים

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

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

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

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

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

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

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

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

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

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

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

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

Оборудование

— אני זוכר איך לפני תחילת הכנסים רכשנו חלקית ציוד נוסף.

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

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

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

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

סקרנות ובעיות

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

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

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

ולדימיר קרסילשצ'יק אחרי 3 חודשים, כשאיזשהו משחק יצא ואף אחד לא הבין מה לעשות איתו

כל יום היה משהו כזה, כשהיה רגע כזה שבו אתה לוקח את זה ותולש את השיער שלך, או מבין שאין אף אחד אחר, ורק אתה יכול לעשות את זה. האירוע הגדול הראשון שלנו היה TechTrain. ב-6 ביוני בשעה 2:2.0 עדיין לא הוצאנו את סביבת הייצור, קוליה הוציאה אותה. והחשבון האישי לא עבד כשרת הרשאות באמצעות OAuth2.0. הפכנו אותו לספק OAuth18 כדי לחבר את הפלטפורמה אליו. עבדתי כנראה XNUMX שעות ברציפות, הסתכלתי על המחשב ולא ראיתי כלום, לא הבנתי למה זה לא עובד, וקוליה הסתכלה על הקוד שלי מרחוק, חיפשה באג בתצורת Spring , מצא אותו, וה-LC עבד, וגם בייצור.

ניקולאי: ושעה לפני TechTrain התרחשה השחרור.

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

לגבי ביצועים

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

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

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

ניקולאי: ניצור על כך מאמר מאוחר יותר.

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

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

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

ולדימיר: אתה יכול לקחת את זה ולחזור על זה.

- בעוד 3 חודשים.

סך הכל

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

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

- מה היה ברשימת המשימות הנוספות שלך כשכנסי הקיץ כבר התקיימו?

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

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

- חבר'ה, תודה רבה על התשובות!

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

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

מקור: www.habr.com