מה זה DevOps?

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

ההגדרה הפשוטה בויקיפדיה:

אז כן יש הגדרה פשוטה… אבל אני בטוח שזה לא ממש אומר למישהו משהו.

אחרי המאמר הקצר הזה (אני מקווה) תבינו לעומק מה זה DevOps? ומהי הסיבה שזה אחד הנושאים החמים היום בשוק?

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

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

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

דוגמא מוגזמת ומוזרה מאוד לצורך ההסבר:

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

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

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

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

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

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

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