DevOps LEGO: איך הנחתנו את הצינור לקוביות

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

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

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

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

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

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

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

יצירת בנאי DevOps

ל-Agile יש מניפסט משלו. ל-ITIL יש מתודולוגיה משלה. ל-DevOps יש פחות מזל - הוא עדיין לא רכש תבניות וסטנדרטים. למרות ש כמה לְנַסוֹת לקבוע את בשלותן של חברות על סמך הערכת הפיתוח והפרקטיקות התפעוליות שלהן.

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

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

Процессы

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

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

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

תרבות

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

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

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

אנשים

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

טכנולוגיה

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

תשתית כקוד

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

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

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

משלוח וניטור רציפים

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

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

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

מי יצטרך שלנו מעצב DevOps?

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

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

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

מקור: www.habr.com