מה זה DevOps

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

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

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

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

למה DevOps

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

— הייתה לנו אינטגרציה מתמשכת - זה אומר שכבר היו לנו DevOps, ולמה כל הדברים האלה צריכים? הם נהנים בחו"ל, אבל הם מונעים מאיתנו לעבוד!

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

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

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

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

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

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

מוצר זה נרכש על ידי יוניליוור תמורת מיליארד דולר. כעת היא מתחרה בג'ילט ולקחה ממנה נתח משמעותי מהצרכנים בשוק האמריקאי. One Box Shave אומר:

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

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

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

זמן יציאה לשוק עוסק במזעור הזמן מהרעיון ועד ליישום הסופי.

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

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

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

בשנת 1968, בחור בעל חזון, מלווין קונווי, ניסח את הרעיון הבא.

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

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

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

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

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

אז למה אתה צריך DevOps?

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

DevOps מתגבר על מגבלות המהירות של ייצור תוכנה רציף. בו כל התהליכים מתרחשים בו זמנית.

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

עם DevOps, הדברים רק יסתבכו.

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

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

שאלות למומחה

מה יש לך? שאלות שתוכלו לשאול את עצמכם תוך כדי עבודה בחברה והתפתחות כמומחה.

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

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

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

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

ארגון

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

הבעיה של "בארות"

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

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

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

שני גורמים מעכבים זאת.

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

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

- רק רצינו להשיק את CI, אבל התברר שההנהלה לא צריכה את זה.

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

כל משתתף בתהליך בחברה: מפתחי backend ו-frontend, בדיקות, DBA, תפעול, רשת, חופר לכיוון שלו, ולאף אחד אין מפה משותפת מלבד המנהל, שאיכשהו עוקב אחריהם ומנהל אותם באמצעות ה"חלוקה". ולכבוש” שיטת.

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

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

האם זה אותו דבר בחברה שלך?

כדי לבדוק זאת, אתה יכול לשאול את עצמך את השאלות הבאות.

האם צוותים משתמשים בכלים משותפים ותורמים לשינויים בכלים הנפוצים הללו?

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

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

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

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

תשתית כקוד

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

לרוב, תשתית כקוד נתפסת באופן הבא:

— בוא נעשה הכל ב-bash, נכסה את עצמנו בסקריפטים כדי שלמנהלים יהיה פחות עבודה ידנית!

אבל זה לא נכון.

תשתית כקוד פירושה שאתה מתאר את מערכת ה-IT איתה אתה עובד בצורה של קוד כדי להבין כל הזמן את מצבה.

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

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

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

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

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

קוד הופך לשפה משותפת לכל המהנדסים.

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

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

תשתית כקוד היא הפרדה של קוד תשתית לשכבות נפרדות.

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


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

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

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

שאלות בקרה

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

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

משלוח רציף

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

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

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

כל הזמן לספק אמצעים

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

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

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

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

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

"לספק בעקביות" נראה כך.

תהליך המסירה Dev, CI, Test, PreProd, Prod אינו סביבה נפרדת, אלו שלבים או תחנות עם סכומים חסיני אש שדרכם עובר החפץ שלך.

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

שאלות בדיקה עצמית

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

אם כל התשובות הן כן, אז אתה מגניב להפליא! כתבו את תשובותיכם בתגובות - אני אשמח).

משוב

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

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

- חבר'ה, למה אתם אנסים את השרת עם משהו לא ברור?

אבל אז התרחש מקרה שהראה שזו באמת אסטרטגיה מגניבה מאוד.

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

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

- חבר'ה, מה קרה לכם לפני שבוע וחצי?

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

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

אסוף את כל המידע על מה שקורה לחפץ בכל שלב בתהליך האספקה ​​- לא בייצור.

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

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

שאלות לשליטה עצמית

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

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

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

פלטפורמת תשתית

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

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

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

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

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

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

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

ערכתי

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

בואו נסתכל ממה זה מורכב.

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

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

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

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

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

יצירת הפלטפורמה

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

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

מה יש לך?

שוב, שאלות שאתה יכול לשאול את עצמך.

האם פלטפורמת התשתית ייעודית? מי אחראי על פיתוחו? האם אתה מבין את היתרונות התחרותיים של פלטפורמת התשתית שלך?

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

אז, DevOps...

... זוהי מערכת מורכבת, חייבת להיות לה:

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

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

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

מקור: www.habr.com