DevOps זה לא אוטומציה

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

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

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

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

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

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

לספק יותר מאוטומציית DevOps

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

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

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

אבל זה לא המקרה – ברוב החברות מעט מאוד בדיקות נעשות לקוד לאוטומציה ואלה שכן, מבוצעות בדרך כלל רק בשלב בדיקות היחידה (Unit test). קיימים אמנם כמה מאמצים להתאמת פיתוח מונחה בדיקות (Test Driven Development) לכלי אוטומציית DevOps, אבל בגלל התכונות הייחודיות של סביבת הייצור, לא מספיק לאמץ זאת, ורוב המאמצים הם בגדר מעט מדי ומאוחר מדי.

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

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

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

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

מהירות? לא על חשבון הזמינות!

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

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

הכותבים הם אנטולי שיין, ד"ר ג'ייקוב יוקלסון וד"ר אלכס קומן מ-Accera