אנחנו מדברים על DevOps בשפה מובנת

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

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

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

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

מה זה DevOps: 6 הגדרות ואנלוגיות

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

1. DevOps היא תנועה תרבותית

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

2. DevOps עוסק בהעצמת מפתחים.

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

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

3. DevOps עוסק בשיתוף פעולה ביצירה ואספקה ​​של יישומים.

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

4. DevOps הוא צינור

"הרכבת מסוע אפשרית רק אם כל החלקים מתאימים זה לזה."

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

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

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

5. DevOps הוא השילוב הנכון של אנשים, תהליכים ואוטומציה

ג'יין גרול, מנכ"לית מכון DevOps, הציעה אנלוגיה מצוינת להסביר את DevOps. במילים שלה, "DevOps הוא כמו מתכון עם שלוש קטגוריות עיקריות של מרכיבים: אנשים, תהליך ואוטומציה. את רוב המרכיבים הללו ניתן לקחת מתחומים ומקורות אחרים: Lean, Agile, SRE, CI/CD, ITIL, מנהיגות, תרבות, כלים. הסוד של DevOps, כמו כל מתכון טוב, הוא איך להשיג את הפרופורציות והתערובת הנכונות של המרכיבים האלה כדי להגביר את המהירות והיעילות של יצירה ושחרור של יישומים."

6. DevOps זה כאשר מתכנתים עובדים כמו צוות פורמולה 1

"המרוץ לא מתוכנן מההתחלה ועד הסוף, אלא להיפך, מהסוף להתחלה".

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

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

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

כיצד להגדיל DevOps: 10 טיפים ממומחים

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

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

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

קל לראות שהתוצאה היא תרבות של חלוקה בין "אנחנו" ל"הם".

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

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

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

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

1. זכרו ששינוי תרבות לוקח זמן.

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

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

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

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

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

3. הוציאו את האשמה מאחריות.

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

4. נקה את הנתיב קדימה

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

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

5. דמוקרטיזציה של כלים

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

6. צרו תנאים אידיאליים לעבודת צוות

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

7. אל תשכח את חוק קונווי וקנבן

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

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

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

8. חפשו צלקות ישנות

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

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

9. אל תגדל אפשרויות DevOps

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

10. להטיף לערך העסקי של DevOps

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

בונוס

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

המהנדס שלנו מארק בירגר, שמפתח שירותי אוטומציה פנימית עבור קבוצות אחרות ברחבי הארגון, יספר את סיפורו שלו ברוסית ברורה - כיצד צוות Red Hat DevOps העביר יישומים מסביבות וירטואליות של Hat Virtualization המנוהלות על ידי Ansible לפורמט קונטיינר מלא ב- פלטפורמת OpenShift.

אבל זה לא הכל:

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

מקור: www.habr.com