תנועת DevOps

יותר מאשר רק לתת למפתחים גישה שורש!

או אפילו לא זה. הרעיון הגדול מאחורי “תנועה” לא רק לתת למפתחים יותר חבל; המטרה היא להבטיח קווי תקשורת טובים יותר בין המפתחים* לבין צוותי הפעולות בארגון. חלק גדול מזה אינו חדש, למעשה זה פריחה מחדש של תנועת “קאיזן” בתוך שרשראות האספקה התעשייתיות המסורתיות (מכונית אספנית) במהלך המאה הקודמת. לוחות Kanban הם רק השיפוץ האחרון של לוחות מחוונים עין הציפורים (הכפלה כמנהלי מלאי זרימת עבודה) המכסים את המאמץ היומיומי הקולקטיבי לשלוח מוצרים איכותיים המענגים לקוחות ושותפים עסקיים כאחד.

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

פיתוח מבוסס תא מטען

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

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

        Surgery on a patient must result
        in good outcomes (at all times) for
        that patient, not just for siblings
        or future generations.

צינורות עיבוד נתונים של CI / CD

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

קוד הוא חוק (פיתוח + תשתית + תצורה)

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

בחזרה ל-CFEngine ימים, קרן התוכנה אפאצ’י שמרה על כל קבצי תצורת ה- IT שלהם ותסריטי תמיכה ב- CVS, ולאחר מכן Subversion. בנוסף, כל שירות שניהלנו היה קשור. “ספר ריצה” להדריך מנהלי מערכת עם מטלות התחזוקה המעשיות שלהם.

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

כיום, הם שומרים הכל בתוך gitעץ מקור בובות מגובה, והקצאה / פריסה / הגדרת תצורה ישירות לענן באמצעות חבילות Ubuntu במעלה הזרם הגנרי, המהווה גישה מודרנית במקצת לעבודה IT-ops שלהם, מאז מתוכנן git משיכות על ידי מאסטר בובות בסופו של דבר לפרוס עדכונים כמו סוכני בובות צ’ק-אין. אבל CI/CD הוא עבודה בתהליך, אפילו עד היום.

מצד שני, יוזמה מוקדמת ופורצת דרך דמוית CI ב-ASF (לפרויקטים בפועל של תוכנת אפאצ’י TLP) הייתה אפאצ’י גאמפזה היה פרי מחשבתם של עמיתים מבריקים כמו סם רובי וחברה. מה שעשה גאמפ היה מעת לעת קופה, לבנות ולבדוק HEAD (כולל HEAD of all deps) של תא המטען של כל בסיס קוד במאגר Subversion (אבל תאריכים חזרה CVS) עבור כל פרויקט זה יכול להבין בהצלחה איך לבנות (שהיה על ידי וגדול מוגבל לפרויקטים של ג’אווה במקור). דוחות נשלחו באופן אוטומטי לכל קהילת פיתוח והועברו לארכיב לצורך דורות קודמים. זה תובנה אוטומציה של שירותים הפעילות עדיין נמשכת (עם git) עד היום! כל קהילת פיתוח בגודל ארגוני שלא מפעילה שרת Gump משלהם היא 20y מאחורי מצב האמנות ב- ASF (IMO; אל תתחילו אותי על יחסי תלות של מודול תוכנה עם צמד גרסאות בקוד פתוח ב- /trunk|master/ …).

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

וירטואליזציה לעומת מיכל

א חיות מחמד נגד בקר רדו.

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

שינוי גודל אנכי לעומת אופקי

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

למדוד, לרסן ולשלוט מאמצי כיבוי אש, הן אמיתי והן מעשי

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

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

אחד משיעורי החיסול העיקריים של COVID-19 בתחילת 2020, כקיבולת בית החולים במונחים של IT, הוא שיש דבר כזה כמו להיות רזה מדי, לפחות כשמדובר באיוש devops (חומרה היא סיפור אחר). תכנון התניה ליום גשום, או עם “מיותר” צוות או יוזמות אימון צולב, בשילוב עם תרגילי הכנה קבועים, לא רק שמרחיקים את הרופא, אלא למעשה משימה קריטית.

להגיע עם התוכנית

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

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