fbpx

3 שיעורים על DevOps שלמדתי ממרוצי סבב פורמולה 1 (וגם על אלוף העולם סבסטיאן וטל)

זמן קריאה כ- 4 דקות

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

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

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

עבורי, זוהי אנלוגיה נהדרת לאתגרים שעמם מתמודדים היום העסקים - הצורך בזריזות (agile) ומסירה רציפה (Continuous Delivery) .

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

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

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

נקודות העצירה לשיפור (PIT STOPS) הם אף פעם לא מושלמים – הפיט סטופס השתכללו בצורה משמעותית לעומת השנים הקודמות. אם בעבר לצוותים לקח כמעט דקה להחליף צמיגים (הנהג אפילו היה צריך לצאת לשם כך מהרכב). כיום עצירה בפיט סטופ מעבר ל-3 שניות נחשבת לכישלון של הצוות הטכני. אותו הדבר נוגע לתוכנה. כשצוותים שעסקו בעבר בעדכון תוכנות החברה בקצב מתון צריכים עכשיו לספק תהליך מסירה רציפה (Continuous) Delivery)).

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

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

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

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

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

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

אודות המחבר :

Yariv

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

יריב הוא גם המייסד והבעלים של חברת Extreme group, חברה מובילה בתחום אספקת פתרונות IT . החברה מעסיקה יותר מ-200 מומחי IT. בין לקוחותיה נמנים יותר מ50 חברות מובילות בישראל. לפני  DBmaestro, יריב היה המייסד המשותף של חברת byUMan Inc, שסיפקה פתרונות חדשניים לניהול מרכזי קשר מבוססי רשת. יריב התחיל את דרכו ביחידת ממר"מ בה מילא שורה של תפקידים טכניים וניהוליים.

ליריב תואר ראשון B.Sc במנהל עסקים מאוניברסיטת בר-אילן. מחוץ לעבודתו בDBmaestro, יריב עוסק בשחייה, טיולים רגליים ונהנה משתיית בירה.

צרו קשר עם יריב ב linkedin_logo_small1

היכנסו עכשיו לדף המשרות שלנו ותשלחו עוד היום קורות חיים למשרות הפנויות שלנו בענף הIT

אין תגובות עד כה

כתיבת תגובה

שלחו קו"ח
שלחו קורות חיים

    צרף קורות חיים:
    סוג הארגון המבוקש?
    היקף משרה מבוקשת?
    מיקום גיאוגרפי מבוקש?
    סוג העסקה מבוקש?

    רגע... לפני שאתם הולכים, את קורות החיים שלכם כבר שלחתם?

    תנו לנו לדאוג לכם למשרה מעולה!

      צרף קורות חיים:
      סוג הארגון המבוקש?
      היקף משרה מבוקשת?
      מיקום גיאוגרפי מבוקש?
      סוג העסקה מבוקש?