DevOps – כשהפיתוח פוגש את הייצור
DevOps – כשהפיתוח פוגש את הייצור
דמי גולדברג –CTO, ALM Division ,Experis
לאחרונה אנו נתקלים יותר ויותר במושג DevOps ודרישות לאנשי DevOps כשלרוב הדרישות למשרה מסוג זה לא רחוקה מסופרמן
(או סופרוואמן) שיודע ומבין פיתוח, מומחה ב-IT, במערכות הפעלה
ואדמיניסטרציה שלהם , מומחה בכלים לניהול תצורה, בילדים, פריסת תוכנה, כלי בקרה
וניטור, כתיבת סקריפטים, פיתוח כלים, ומבין אם לא מומחה בבסיסי הנתונים הנפוצים
בשוק – ממש חברת הייטק מהלכת על שתיים ואיש רב יכולות.
אז בואו ננסה להבין מה זה DevOps ,איך זה
צמח, מי צריך את זה, ולמה צריך אנשים אם כל היכולות שתיארתי.
מה זה DevOps?
אז DevOps כהגדרה זו פרדיגמה, תפיסה, גישת עבודה שמטרתה לקרב את
הפיתוח בארגונים לאופרציה –הגוף שמנהל ומתחזק את מערכות הייצור של הארגון DevOps=Development+ Operations)).
כיצד נוצר הצורך ב-DevOps
ה- DevOps הוא תוצר
ישיר והמשך המגמה של שיטות הפיתוח המואץ (Agile) שבאו לתת מענה לצרכי
השוק – לא עוד אפיון ותכנון מדוקדק ורק אח"כ פיתוח ובסוף שחרור מוצר לפי מה
שתוכנן, אלא התחלת פיתוח המוצר והוספת\דחיפה של דרישות ושינויים למערכת בזמן
הפיתוח, וזאת כדי לתת מענה לדרישות המשתנות כל הזמן של השוק. מוצר שתוכנן ואפיון לפי
דרישות השוק עלול למצוא את עצמו לא רלוונטי בזמן שחרורו כי דרישות השוק השתנו מאז.
כדי לתת מענה לשיטות הפיתוח המואצות פותחו מתודולוגיות אג'ילויות כמו Scrum ,Kanban ועוד שאפשרו הוספת דרישות
חדשות למערכת בזמן פיתוח, ניהול משימות קפדני ותהליכי אינטגרציה תמידיים – כלומר
המוצר "חי ועובד" רוב הזמן גם אחרי הוספת שינוי. לצורך כך פותחו תהליכים
וכלים שתומכים ב- continuous integration כאשר המטרה לשמור על מוצר
חי ועובד תמיד ושום שינוי לא "שובר" את שלמותו.
אבל מה קורה באזור האופרציה וסביבות הייצור? האם גם שם אפשר להעביר
שינויים חדשים בתדירות גבוהה בלי לפגוע ביציבות המערכת ובלקוחות? ואם כן, איך
גורמים לזה לקרות בזמן סביר ולהיות בטוח, עד כמה שאפשר, שהשינוי לא יפגע במערכות
הייצור? איך מעבירים שינויים תכופים בין הפיתוח לייצור?
ברוב הארגונים יש חלוקה ברורה בין גוף הפיתוח לבין האופרציה – הגוף
שמנהל את מערכות הייצור, ויש ביניהם ניגוד אינטרסים:
הפיתוח מצדו מוסיף דרישות, מתקן באגים ומבצע בדיקות, ומוכן להעביר
לייצור באופן מידי, גוף האופרציה הרבה יותר זהיר, ומעדיף כמה שפחות שינויים שיסכנו
את יציבות סביבות הייצור, במיוחד כאשר פגיעה שכזו עלולה להשבית מערכות ולפגוע
באופן ישיר ברווחי החברה.
מה גם שתהליך העברת ה"מקל" בין פיתוח לאופרציה מתנהל
ע"י אנשים שונים – אנשי פיתוח ואנשי אופרציה שברוב המקרים גם משתמשים בכלים
ושיטות שונות להטמעת שינויים חדשים במערכות, הם תמיד בעלי הרשאות שונות במערכות
ובנוסף תמיד צריך לערב אנשי IT בעלי הידע במערכות ההפעלה השונות ,גיבויים
,בסיסי הנתונים ,תקשורת וכד 'שתמיד עסוקים בפעילויות שוטפות אחרות וכל התהליך הופך
את העסק למסורבל ,מייגע ולא יעיל.
מגמה נוספת של השנים האחרונות היא פיתוח מוצרים ושרותי תוכנה בענני
מחשוב מרכזיים, לא עוד פיתוח מוצר אפליקטיבי ללקוחות לפי דרישתו, אלא מוצר ברשת
שמשרת עשרות ואלפי משתמשים ולקוחות שונים בו זמנית עם דרישות שונות.
אם פעם הייתה לנו את הפריבילגיה לשחרר שינוים ותיקונים של מוצר ללקוח
בתיאום מולו ,ניהול מוצר בענן מחייב אותנו ברוב המקרים לדחוף את השינוי לכלל
המערכת, ולתת מענה מהיר ומידי לכל דרישות השוק. מצב זה חייב חברות שונות להקים
סביבות ייצור מרכזיות בענן ואת הצורך בהעברת שינויים באופן תדיר למערכות אלו.
תפקיד ה-DevOps
אז מה עושים ? כיצד מעבירים שינויים מפיתוח לייצור בתדירות גבוהה, באופן
חלק, עם סיכון נמוך, בלי קונפליקטים בין פיתוח לייצור, וכמה שפחות לערב ידיים נוספות כמו
אנשי IT או מומחים אחרים?
התשובה כנראה נמצאת ב-DevOps – גוף פנים
ארגוני מיומן שתפקידו ללוות את המוצר מתהליך הפיתוח עד שחרורו ללקוח ולסביבת
הייצור.
גוף זה יגשר על הפער בין פיתוח לייצור, יהיה מיומן, בעל יכולות
טכנולוגיות מכל העולמות (הבנה בפיתוח, במערכות הפעלה בסיסי נתונים, פריסת תוכנה פיתוח,
ביצוע אוטומציות וכד') .
גוף זה יהיה בעל 2 זרועות מרכזיות – אחת בפיתוח ואחת באופרציה, יעבוד צמוד עם הפיתוח ,ייתן מענה מלא לצרכיו –
תמיכה בתהליכי ניהול קוד, הרצת תהליכים אוטומטית, ניהול והקמת סביבות פיתוח, אינטגרציה
ובדיקות,פיתוח אוטומציות לבנייה ופריסת המוצר לסביבות השונות, ולבסוף המשך התהליך
ע"י אותם שיטות וכלים לסביבות הייצור.
אנשי ה- DevOps יצברו
ניסיון רב בסביבות הריצה, ויפתחו שיטות אמינות להעברת השינויים, וכך יקנו ביטחון
לאנשי האופרציה ויהפכו את התהליך למהיר ואמין.
על הדרך אנשי ה-DevOps יתבקשו לתמוך במערכות בסביבות הריצה השונות - פיתוח,
האינטגרציה בדיקות ,ביניים וכיוון שקבוצה זו "חייה" את המוצר ביום יום
(בניה ,התקנה ,הכרות טכנולוגית עם המוצר והסביבות) בחלק מהמקרים יתבקשו לתמוך
בסביבת הייצור.
במשפט מסכם – מהות ה-DevOps (וקבוצת האנשים מאחוריה) היא
לגרום להמשכיות בשחרור התוכנה ולייצור החל משלב הפיתוח ועד אישור העברה לייצור או
באנגלית Continuous Delivery/Continuous Deployment (ובקיצור CD).
אנשי –DevOps
או מי מתאים
חלק מהיכולות של אנשי DevOps (חוץ מהצורך לשלוט באופן
מעולה במערכות הפעלה שונות, בסיסי נתונים, שרתי ווב ועוד), עליהם להכיר כלים
מעולמות ניהול תצורה ו-ALM כמו כלים לניהול קוד כמו SVN,
Perforce,GIT,TFS כלים לניהול ומעקב אחרי
משימות באגים וכד' (RTC ,TFS ,Jira ,Bug Zilla וכד'), כלים להקמת סביבות
ולפריסת תוכנה על סביבות מרוחקות (Bladelogic ,Altiris
,Nolio, Puppet, Chef etc), כלים להרצת תהליכים אוטומטית (בנייה
,אריזה ופריסה של תוכנה) ותמיכה ב-Continuous integration Jenkins, Hudson, Cruise
Control etc.) ) הבנה מעמיקה בתקשורת
והכרות עם ציודי קצה כמו Firewall ,Load Balances, Switches וכד',הכרות עם כלי ניתור ובדיקה כמו Wireshark ,Nagios, SCOM, Zenoss, , וגם יכולת לפתח כלים
ייעודיים וסקריפטים שיבצעו את התהליכים בצורה אוטומטית עד כמה שאפשר כדי לזרז
ולמנוע טעויות בדרך.
תוסיפו את העובדה שאנשים אלה צריכים יכולות בין אישיות גבוהות, מכוון
שעליהם לעבוד באופן שוטף עם כל קצוות הארגון – אנשי פיתוח, בדיקות, ארכיטקטים, אנשי
תשתיות, מנהלי פרויקטים, ואנשי אופרציה.
אכן, מדובר באמת באנשים בעלי ידע רב מערכתי ויכולות בין אישיות גבוהות,
שנושאים על כתפיהם אחריות גדולה, להעביר באופן שוטף שינוים מפיתוח לייצור, וטיפול
בכל האספקטים מסביב עם כמה שפחות בעיות והשבתות.
באופן טבעי – אנשי ניהול התצורה ו-ALM הכי קרובים לפרופיל איש DevOps בשל העובדה
שאנשים אלו מלווים את המוצר מתחילתו עד סופו, מכירים כלים רבים, חלקם כותב סקריפטים
וקוד ועובדים עם מספר גופים בארגון, אבל ברור שיש צורך ביכולות רבות אחרות שלא
תמיד נמצאים אצל אנשי ה- ALM הקלאסיים כמו הבנה בתשתיות, יכולות דיאגנוזה
וניטור וכד' אבל עדין אנשים פוטנציאלים
להיות חלק מקבוצת DevOps בארגון. ניתן גם לשלב בקבוצה זו אנשי-ALM ואנשי תשתיות כדי שישלימו אחד את השני, משום שבהרבה
מקרים קשה למצוא אנשים בעלי ידע רחב.
לסיכום
תפיסת ה-DevOps הולכת ותופסת תאוצה
בארגונים וזאת כדי לתת מענה לצרכי השוק, ומאפשרת להם להיות תחרותיים ע"י זה
שהמוצר שלהם מגיע לשוק במהירות ומשתנה בהתאם באופן שוטף. בכל ארגון היא יכולה
להיות מוטמעת בהתאם לצרכי הארגון כאשר המטרה היא לקצר ולייעל תהליכים.
מקווה שהבהרתי קצת את הנושא ,האבולוציה והצורך של ה- DevOps כתפיסה.
תגובות
הוסף רשומת תגובה