מאחורי הקלעים. איך נוצרים קורסים?

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

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

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

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

הוא ראה את הבטן כמובן הבריאה - מורכבויות ומגרפות קוצניות, תובנות ופתרונות בלתי צפויים. וה-Kubernetes אינטנסיביים המוכרים כבר, כמו Slurm Basic ו-Slurm Mega. וקורס חדש, מתוקן במידה רבה Slurm DevOps: כלים וצ'יטים, שמתקרב ללא הרף ויתחיל ב-19 באוגוסט.

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

מה יש מאחורי הקלעים?

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

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

כך מופיע רעיון.

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

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

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

ואז מתחילה העבודה השגרתית הפשוטה:

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

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

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

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

כך מופיעים קורסים.

איך נולד קורס דוקר

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

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

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

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

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

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

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

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

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

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

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

זו בחירה מודעת - וזה מאוד מגניב.

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

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

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

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

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

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

אם ננסח אילו יתרונות יש לקורס שלנו, אז:

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

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

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

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

במובנים רבים, docker עוסק בסטנדרטים.

גם תקנים עוברים ל-Kubernetes - ויש בדיוק אותם תקנים; אם אתה יודע להריץ את האפליקציה שלך היטב ב-Docker, אז 99% מהמקרים זה יעבוד באותה מידה בתוך Kubernetes.

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

נשמח לראותכם!

מקור: www.habr.com