כנס לחובבי גישת DevOps

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

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

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

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

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

• מהנדסים בכירים;
• מפתחים;
• מובילי צוות;
• CTO.

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

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

קטעי הכנס יישארו כמו ב פעם אחרונה.

• פלטפורמת תשתית.
• תשתית כקוד.
• משלוח רציף.
• משוב.
• ארכיטקטורה ב-DevOps, DevOps עבור CTO.
• שיטות SRE.
• הדרכה וניהול ידע.
• אבטחה, DevSecOps.
• טרנספורמציה של DevOps.

Call for Papers: איזה סוג של דוחות אנחנו מחפשים

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

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

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

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

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

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

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

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

איך אנחנו רואים את DevOps

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

DevOps היא מערכת מורכבת, היא חייבת לכלול:

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

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

ניתן לצפות בסרטון הדיווח כאן.

ועכשיו יהיה בונוס: מספר סרטונים מ- RIT++ 2019, הנוגעים לנושאים הכלליים ביותר של טרנספורמציה של DevOps.

תשתית חברה כמוצר

Artyom Naumenko מוביל את צוות DevOps ב-Skyeng ודואג לפיתוח התשתית של החברה שלו. הוא סיפר כיצד תשתית משפיעה על תהליכים עסקיים ב-SkyEng: כיצד לחשב עבורה ROI, אילו מדדים יש לבחור לחישוב וכיצד לעבוד לשיפורם.

בדרך לשירותי מיקרו

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

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

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

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

אוטומציה של שחרורים או איך לספק במהירות וללא כאבים

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

איך תאונות עוזרות לך ללמוד?

Alexey Kirpichnikov מיישם DevOps ותשתית ב-SKB Kontur כבר 5 שנים. במהלך שלוש שנים התרחשו בחברתו כ-1000 פאקאפים בדרגות שונות של אפיניות. מביניהם, למשל, 36% נגרמו כתוצאה מהפצת מהדורה באיכות נמוכה לייצור, ו-14% נגרמו מעבודות תחזוקה של החומרה במרכז הנתונים.

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

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

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

אילו דוחות כבר קיבלנו לתוכנית?

השבוע אימצה ועדת התוכנית 4 דוחות: על אבטחה, תשתיות ונהלי SRE.

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

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

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

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

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

• כיצד להבין האם נעשה שימוש יעיל בשטח האחסון;
• כיצד כמה מאות משתמשים יכולים לקבל תוכן של 10 TB אם נעשה שימוש באחסון של 20 TB בלבד;
• כיצד לדחוס נתונים 5 פעמים ולספק אותם למשתמשים בזמן אמת;
• כיצד לסנכרן נתונים תוך כדי תנועה בין מספר מרכזי נתונים;
• כיצד לבטל כל השפעה של משתמשים זה על זה בעת שימוש במכונה וירטואלית אחת ברצף.

סוד הקסם הזה הוא הטכנולוגיה ZFS עבור FreeBSD והמזלג הטרי שלו ZFS בלינוקס. ולדימיר ישתף מקרים מ-Playkey.

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

שוב אני מפציר בכם לא להיות חמדנים ולשתף בחוויה שלכם כסמוראי DevOps. לְשָׁרֵת בקשה לדוח, ולך ולי יהיו 2,5 חודשים להכין נאום מצוין. אם אתה רוצה להיות מאזין, להירשם לניוזלטר עם עדכוני תוכנית ולחשוב ברצינות על הזמנת כרטיסים מבעוד מועד, כי הם יתייקרו קרוב יותר לתאריכי הכנס.

מקור: www.habr.com