6 טעויות DevOps שעליכם להימנע מהן

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

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

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

‍
להקים צוות DevOps בודד

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

‍
להתמקד ביותר מדי כלים

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

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

‍

להתמקד במהירות יותר מאשר בבטיחות ובאיכות

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

‍


לאפשר יותר מדי גרסאות

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

‍
להשאיר את צוותי אבטחת המידע מחוץ לתמונה

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

‍
למעשה, סקר של CA Technologies  מצא שרוב (כ-38%) חששות האבטחה היו המכשול העיקרי לגבי DevOps. סקר נוסף של Puppet מצא שצוותי DevOps יעילים  מנצלים 50% פחות זמן בתיקון בעיות אבטחה מאשר צוותים שנחשבים פחות טובים. ברור מכך שהצוותים הללו מצאו דרכים יעילות לתקשר בין מטרות האבטחה ושילוב מוקדם של נושא האבטחה בשלבי הפיתוח השונים.
איש ה-DevOps צריך להבין את תהליכי העבודה, להעריך את הפיקוח ולזהות את הסיכונים. בסופו של יום, האבטחה היא תמיד חלק מתהליכי הפיתוח  (למשל DevSecOps). לדוגמא, אם יש לכם בעיות אבטחה בסביבות ה-production, אתם תמיד יכולים להעביר אותם דרך צינורות ה-DevOps ודרך הכלים שצוותי האבטחה כבר משתמשים בהם. שני העקרונות חייבים לעבוד ביחד בצורה חכמה, ואסור להתפשר על כך.
לא להתכונן לקראת השינוי בתרבות

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

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

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

‍
מסקנה

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

‍

מאת: מערכת IsraelClouds

‍