מה זה בעצם DevOps?

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

ככל שהזמן עובר, שומעים בעולם יותר ויותר את המושג/תרבות – DevOps. במאמר הזה, נבין ביחד מה זה DevOps, איזה בעיות הוא בא לפתור ועוד.

מה זה DevOps?

DevOps זה בעצם חיבור של המילים dev ו-ops, מה זה אומר?

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

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

אפשר להתייחס לתרבות הזאת כמערכת היחסים בין צוותי ה-dev לצוותי ה-ops.

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

איזה בעיות DevOps בא לפתור לנו?

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

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

איך בפועל אפשר לפתח את התרבות הזאת?

בהמשך, נראה איך תפקיד של איש DevOps נראה ביום יום ומה העיסוק שלו.

אבל כעת, נבין מהן אבני הבניין בדרך לתרבות הזאת (שמבוסס על the three ways – מוזמנים להרחיב בעצמכם כאן):

חשיבה סיסטמית

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

אסביר למה חשוב לשפר את כל ה-flow עם דוגמא ממפעל:

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

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

פידבקים

כדי להשתפר (כמו בכל דבר) צריך לקבל פידבקים, ורצוי לקבל מהם כמה שיותר. ממי אנחנו צריכים לקבל פידבק? מהלקוחות שלנו, שהם אנשי ה-ops וה-dev ולפעמים גם משתמשי הקצה.

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

דוגמאות לשאלות עבור לקוחות:

1. האם אתם מקבלים תמיכה מהירה ואיכותית מצוותי ה-DevOps?
2. האם יש לכם רעיונות חדשים/מוצרים חדשים שתרצו לספר לנו עליהם?

דוגמאות לשאלות עבור עצמנו:

1. האם אנחנו מספיק קשובים לצרכים של הלקוחות?
2. האם אנחנו מבינים איך המערכות שלנו עובדות בצורה מספקת?
3. בדיקה עם עצמנו – אנחנו מספיק מאתגרים את המערכות שלנו?

למידה תמידית בשילוב עם ניסויים מתמשכים

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

דוגמא מעניינת בנושא של ניסויים ולמידה נמצאת בחברה Google: הם מקצים הרבה מאוד זמן בניסיון לאתגר את המערכות שלהם בניסיון לתפוס את כל “הבאגים” מראש ולתקן אותם. למה זה עדיף? כי יש הבדל עצום בין מצב ששני אנשים מאתגרים את המערכת ומוכנים לזה שהיא אולי תקרוס לבין זה שיתקשרו אליהם ב-3 בלילה כי משהו לא עובד ולא ברור למה.

מה המטרה של אנשי DevOps?

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

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

איך נעזור מעשית לארגון כאנשי Devops?

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

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

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

במאמר הבא, נדבר על ה-CAMS Model – מודל פרקטי שיעזור לנו להבין בצורה עמוקה יותר את התרבות הזאת.

DevOps כולל בתוכו הרבה דברים והרבה נישות. אל דאגה, ניגע בכל הנושאים ?.