בעוד שפתרונות PaaS (Platform as a Service) לבדם אינם יכולים לשנות את האופן שבו אנשים וצוותים מקיימים אינטראקציה, הם לרוב משמשים כזרז לשינוי ארגוני בתגובה לזריזות ה-IT המוגברת.
למעשה, תשואה מקסימלית על השקעות PaaS יכולה להיות מושגת לרוב רק על ידי שינוי תפקידים ארגוניים, אחריות (משימות) ומערכות יחסים. למרבה המזל, פתרונות PaaS כגון OpenShift Container Platform גמישים מספיק כדי לאפשר לכל ארגון IT לקבוע את המהירות והיקף השינוי ביחס לאנשים המעורבים ולתהליכים המתרחשים.
בשלב הראשון של קונטיינריזציה ארגונית, העדיפות העיקרית היא הטמעת פלטפורמת הקונטיינרים כמערכת פריסת יישומים חדשה. בשלב זה, ארגונים קושרים משרות מוכרות לתפקידים מוכרים כדי להגיב לבקשות סטנדרטיות של צוותי פיתוח בנושאים כמו מערכות אחסון, סביבות פריסה וכו'. בשלבים הבאים של קונטיינריזציה כבר מדברים על אוטומציה או מתן יכולות שירות עצמי למפתחים על מנת להפחית את העומס על מנהלי המערכת ולהביא את האוטונומיה והיעילות של המפתחים לרמה גבוהה יותר. כך ארגון מתחיל להתקדם לעבר DevOps. בשלב הסופי של קונטיינריזציה, הארגון מגיע למודל DevOps טהור וקנוני יותר, שבתוכו רבים מהמשימות והעבודות הקודמות נמצאות בשליטת צוותים חוצי תפקודיים המקובצים לא לפי פלטפורמות או טכנולוגיות, אלא מהנקודה של השקפה של הבטחת פעולתם של יישומים או שירותי יישומים.
בפוסט זה, נספק הנחיות כיצד לבצע את השינויים הארגוניים הדרושים וכיצד תפקידי IT מסורתיים משתנים עם אימוץ טכנולוגיות מיכל בארגון.
קישור בין משרות חדשות לתפקידים ישנים
בצורתו הבסיסית והראשונית, מודל הארגון PaaS נועד להקצות משאבי IT ליישומים בצורה גמישה ומהירה יותר כסביבת זמן ריצה. בעוד שזה מספק יתרונות מסוימים למנהלי מערכת, מפתחים בדרך כלל אינם מקבלים הטבות משמעותיות או יכולות חדשות, שכן בשלב זה, ארגון יכול להסתדר בקלות ללא אוטומציה, שירות עצמי או שיפור קיצוני של צינור הפריסה. בעוד ש-PaaS משפיעה באופן מינימלי על תהליכי הפיתוח בשלב זה, הוא בכל זאת מגביר את הגמישות של מערכת ה-IT, ומאפשר למנהלים לשרת טוב יותר את בקשות המפתחים. לדוגמה, בעוד שבעבר יצרו סביבת פיתוח מכמה... מכונות וירטואליות בעוד שיצירה ופריסה של אמצעי אחסון יכולים לקחת ימים או אפילו שבועות, ולדרוש מעורבות של מספר מנהלים שונים, ב-PaaS הכל נעשה הרבה יותר מהר ועל ידי מנהל אחד בלבד. במילים אחרות, צוותי פיתוח מגישים בקשות כמו בעבר, אך העבודה ליישום שלהן מתבצעת כעת על פי מודל חדש.
בדרך לארגון DevOps
על ידי השקת PaaS והעברת מומחי תפעול IT ומפתחי אפליקציות אליו, הארגון יכול להמשיך ליישם את מתודולוגיית DevOps, הכוללת בין היתר את עקרונות הליבה הבאים:
- חלקו את העבודה לצעדים קטניםלקבל משוב מוקדם, להפחית סיכונים ולהימנע משיתוק ניתוח;
- אוטומציה של פעולות מספיקכדי להימנע מיצירת מכשולים או צווארי בקבוק בתהליך פריסת האפליקציה;
- חילופי ידע – המפתח לבניית אמון;
- שלם באופן קבוע חובות טכניים, הקצאת זמן מסוים בכל מחזור עבודה לשיפורים שיטתיים.
בשלב השני של אימוץ טכנולוגיית המכולות, צוותי הפיתוח מתחילים לראות הזדמנויות לשיפור, והארגון נוטה לעבר מודל DevOps מסורתי יותר. המנגנון המסורתי של הגשת ומילוי בקשות שירות נתפס כיום כצוואר בקבוק, ולכן הארגון מחפש לבצע אוטומציה של פעולות חוזרות ונשנות ולספק יכולות שירות עצמי למפתחים. יתרה מכך, יכולות מפתח אלו בתוך אפליקציה נתונה נקבעות על ידי המאמצים המשותפים של מומחי IT המפעילים את הפלטפורמות והאחראים על אספקת יישומים. במילים אחרות, מנהלי מערכת, המבצעים פעולות לבקשת המפתחים, מוחלפים בשתי הקטגוריות הנ"ל של עובדים שאחראיות על תיאור ויישום מדיניות המסדירה מה בדיוק מותר למפתחים לעשות בעצמם. נהלים אוטומטיים עוזרים להבטיח עמידה בדרישות שצוינו ולתאם פעולות כאשר מצב נופל מחוץ לתחום המדיניות הקיימת.
מעבר ללוח זמנים איטרטיבי, שבו סביבת ה-IT ומודל התפעול עוברים שינויים איטרטיביים לאורך זמן, היא אבן דרך קריטית בהשגת ארגון DevOps בוגר. מידת האימוץ של מתודולוגיית DevOps תלויה בסובלנות של כל ארגון לשינויים ובאילו שינויים מביאים את התועלת הגדולה ביותר. לדוגמה, אם הצורך ליצור סביבות או יישומים חדשים מתרחש לעתים רחוקות, אז ייעול הפעילויות המתאימות יהיה פחות חשוב מהגברת השליטה של המפתחים על מחזור החיים של האפליקציה.
אתגרים חדשים שעולים בארגוני IT בעת ההגירה ל-OpenShift
בסעיף זה, נסקור את התפקידים והמשימות שבהם משתמשים בדרך כלל ארגונים שאימצו את OpenShift כדי להאיץ אוטומציה ושירות עצמי באמצעות טכנולוגיה ו-PaaS.
הטבלה שלהלן מפרטת את המשימות העיקריות ברמה העליונה הקיימות בכל ארגון שהטמיע את OpenShift, עם דוגמאות למשרות ומיומנויות קשורות. אין לבלבל את רשימת המשימות הזו עם מבנה פירוק עבודה או מבנה צוות, אלא קבוצה של משימות שחייבים להסתיים על ידי מי שאחראי על התמיכה בסביבת/ות ה-IT לצורך הטמעה מוצלחת של פלטפורמת קונטיינר. למעשה, עוד נראה שהכנסת טכנולוגיות מיכל יוצרת את התנאים המוקדמים ליצירת אסטרטגיית DevOps בוגרת יותר בארגון, אשר בתורה מגדילה את מידת הפונקציונליות הצולבת של הצוותים ומפחיתה את הסיכונים להתמחות צרה בארגון. ברמה של יחידים וצוותים כאחד.
טבלה 1. הגדרות משימות OpenShift
משימות
כישורים נדרשים
אוטומציה ואספקה של תשתיות IT
עובד:
- תכנון ובניית פתרונות חומרה
- ארגון ותמיכה באוטומציה של הגדרה ראשונית
- עיצוב ואוטומציה של VM והכנת מארח
- תכנון והטמעה של מרכזי נתונים
- ניהול המערכת Linux
- תרחישי אוטומציה
- ידע במערכות אחסון
- ידע בתכנון והטמעת רשת
- אבטחה
התקנה וניהול של פלטפורמת OpenShift
עובד:
- ביצוע התקנת אשכול
- ניהול שירותי תשתית
- ניהול קנה מידה של פלטפורמה
- אימות והרשאה ברמת הפלטפורמה
- ניהול המערכת Linux
- ידע בטכנולוגיות רשת
- סקריפטים אוטומציה (Ansible)
- ידע במערכות אחסון
- ידע בטכנולוגיות וארכיטקטורות קונטיינרים
- ידע בארכיטקטורות Kubernetes ו-OpenShift
- אבטחת פלטפורמה
- מעקב אחר אינטגרציה
ניהול הכנת סביבות לקוח (הקצאת דיירים), בידוד יכולות IT
עובד:
- יצירת משתמשים וצוותים בתוך הפלטפורמה
- עיצוב וניהול מכסות
- עיצוב ויישום RBAC
- ידע בארכיטקטורות Kubernetes ו-OpenShift
- ידע בטכנולוגיות וארכיטקטורות קונטיינרים
- תרחישי אוטומציה
- היכרות טובה עם פרויקטים, מכסות, הקצאת תפקידים ועבודה מול מתכננים
בנייה וניהול של תמונות בסיס
עובד:
- פיתוח זרימת עבודה לשינוי תמונה
- פיתוח תמונה מבוסס תקנים
- ניהול המערכת Linux
- תרחישי אוטומציה
- הגדרת רכיבי יישומי ריצה ותוכנות ביניים
- ידע בארכיטקטורות קונטיינרים
- מסגרות לבניית אפליקציות
- ידע טוב בתמונות, אימג'סטרים ותבניות
תכנון וניהול צינורות פריסה
עובד:
- עיצוב ותיעוד תקני מסועים
- פיתוח מדריכים מהירים ותבניות
- הכשרת מפתחים
- ניהול קוד מקור
- עיצוב ויישום אפליקציה
- תרחישי אוטומציה
- בדיקות אוטומטיות
- בדיקת איכות קוד
- ידע בארכיטקטורות קונטיינרים
- הכרת תשתיות בלתי ניתנות לשינוי
- אבטחה – ניהול גישה לשלבי צינור, אישור תהליכי עבודה וכו'.
- ידע טוב בתבניות OpenShift, רכיבי buildconfigs, deploymentconfigs, שירותים, מסלולים, מפות תצורה
פיתוח אפליקציות ובדיקות
עובד:
- קידוד יישומים
- פיתוח בדיקות אוטומטיות
- תגובה לכשלים בבדיקה במהלך צינור הפריסה
- תגובה לכשלים באפליקציה
- בדיקות קבלת משתמש
- עיצוב ויישום אפליקציה
- בדיקות אוטומטיות
- ניהול קוד מקור
- ניטור יישומים
- ידע בארכיטקטורות של יישומים מקוריים בענן
ניטור תפעולי וניהול יישומים
עובד:
- עיצוב יישומים בהקשר של ביצועים
- ניטור יישומים בזמן ריצה
- קנה מידה של יישום (או קנה מידה אוטומטי)
- ניהול זמינות יישומים
- בקש מכסות ומגבלות ניהול משאבים
- בדיקת ביצועים ויכולת IT
- עיצוב ויישום ביצועי אפליקציה
- ניטור ביצועי אפליקציה
- בדיקת ביצועים ועומסים
בדיקות קבלת משתמש
עובד:
- בדיקת ממשק משתמש (עיצוב וחווית משתמש)
- פיתוח בדיקות אוטומטיות
- עיצוב ובדיקת ממשקי משתמש
- דפוסי בדיקה אוטומטיים
- מסגרות בדיקה
- דפוסי עיצוב יישומים
תפקידים חדשים שעולים בארגון IT בעת ההגירה ל-OpenShift
ככל שעוברים למודל ארגוני המתמקד ב-DevOps, כמות ההתמחות בתפקידים נוטה להצטמצם, ומספר הצוותים והתפקידים הבין-תפקידים גדל בתורם כדי למקסם את יעילות שיתוף הפעולה. כך נראית לדעתנו רשימת תפקידי המפתח בארגון IT המשתמשים ב-OpenShift:
- מהנדס תפעול אפליקציות או מהנדס אמינות אתרים. בעבר, ייתכן שהתפקיד הזה נקרא "מנהל שרת יישומים".
- מפתח אפליקציות/מפתח תוכנה/מהנדס תוכנה.
- מנהל אשכול/פלטפורמת יישומים. בעבר, תפקיד זה היה נקרא "מנהל מערכת" או "מנהל". Linux"פלטפורמות".
- מנהל שחרור/מהנדס בנייה.
מטריצת התפקידים והמשימות של RACI
לבסוף, אנו ממשיכים להשוות בין התפקידים והמשימות שנדונו לעיל כדי לתת מושג כללי כיצד צריך להיראות המבנה של ארגון המיישם DevOps בפלטפורמת OpenShift. בתחילה, התפקידים הבאים עשויים להתמלא על ידי ענפים שונים של המבנה הארגוני הישן והמסורתי. אבל עם הזמן, איחוד מתרחש וצוותים חדשים נבנים סביב יישומים שלוקחים על עצמם את רוב או אפילו את כל המשימות המפורטות להלן.
משימות
תפקידים
מהנדס תפעול אפליקציות / מהנדס אמינות אתרים
מפתח אפליקציות / מפתח תוכנה / מהנדס תוכנה
מנהל אשכול/פלטפורמת יישומים
מנהל שחרור תוכנה/מהנדס הרכבה
אוטומציה ואספקה של תשתיות IT
I
I
R / A
C
התקנה וניהול של פלטפורמת OpenShift
C
I
R / A
C
תכנון וניהול צינורות פריסה
C
C
I
R / A
ניהול הקצאת דיירים, בידוד וקיבולת IT
C
I
R / A
I
בנייה וניהול של תמונות בסיס
R
C
R / A
C
פיתוח אפליקציות ובדיקות
C
R / A
I
I
ניטור תפעולי וניהול יישומים
R / A
C
C
I
בדיקות קבלת משתמש
C
R
I
I
מוסכמות במטריצת RACI
מקור:
- אחראי – המבצע הוא זה שעושה את הדרוש כדי להשלים את המשימה.
- אַחֲרַאִי – אחראי – עובד שאחראי בסופו של דבר לביצוע נכון ויסודי של משימה או השגת תוצאה; וגם היחיד שיכול להאציל עבודה למבצעים.
- התייעץ - יועצים - בדרך כלל אלו הם מומחים לנושא שנבקשו לקבל את עצתם; תקשורת דו כיוונית נשמרת איתם.
- הודיע – מודיעים – אנשים המתעדכנים באירועים (ולפעמים רק עם סיום משימה או השגת תוצאה); הם מקבלים מידע באופן חד צדדי.
כיצד צוותים עובדים יחד בארגון DevOps
רכישת משאבים מסורתית כוללת בדרך כלל מחזור של בקשות משאבים אשר מבוצעות לאחר מכן על ידי צוותים מרובים. בסופו של דבר, כל המשאבים הדרושים מוקצים ומאושרים על ידי הצד המבקש. לעתים קרובות, תהליכים אלה הם ידניים באופן חלקי או מלא ודורשים אינטראקציות תכופות ומרובות בין צוותים כדי לעבד בהצלחה כל בקשה.
איור 1. ארגון IT מסורתי
התרשים שלמעלה ממחיש מערכות יחסים אופייניות בין צוותים בארגון IT מסורתי. במסגרת זו, צוותים מסוימים יוצרים קשר עם צוותים אחרים עם בקשה לבצע את העבודה הדרושה, תוך שימוש באמצעי תקשורת פחות או יותר פורמליים, כגון מערכת כרטיסים או דואר אלקטרוני. לאחר מכן, בקשות אלו נכנסות לתור ומחכות בכנפיים, כאשר המתנה ממושכת מביאה לרוב להידרדרות, או אפילו להחמרה, ביחסים בין הצוותים. מה שמוסיף למתח היא העובדה שחברי צוותים שונים כמעט ולא נפגשים זה עם זה באופן אישי ונוטים לחלוק רק את המידע המינימלי הדרוש.
איור 2: ארגון ה-IT של DevOps
תרשים זה מראה כיצד פועל שיתוף הפעולה בארגון DevOps. כאן, אותם צוותים מהדיאגרמה הקודמת נטשו תקשורת לא יעילה שחיזקה ממגורות והחליפו אותן במגעים אישיים, ובכך יצרו ערוצי אינטראקציה קבועים בין צוותים. ערוצים אלה מטפחים מערך מיומנויות היברידי שעוזר לעובדים להבין ולראות טוב יותר את הצרכים, האתגרים וההזדמנויות של הצוותים שהם מייצגים. צוותים מחזקים זה את זה להשלים עבודה באמצעות פורטלי שירות עצמי אוטומטיים, במקום לטפל באופן ידני בבקשות שינוי של אנשים אחרים כפי שהיה נהוג בעבר. ובזכות נוכחותם של ערוצי אינטראקציה, מערכות השירות העצמי הללו יכולות להסתגל במהירות לצרכי הצוותים עבורם הם מיועדים. כדי להשיג הבנה ושיתוף ידע גדולים עוד יותר בתוך הארגון, חברי הצוות מחליפים תפקידים מעת לעת כדי לצבור ניסיון באינטראקציה עם צוותים שונים ולהבין טוב יותר את התמונה הגדולה של מערכות ה-IT שבהם הם תומכים, ובכך להגדיל את רמת הפונקציונליות והשימושיות שלהם.
הסתכמות
בפוסט זה, דנו כיצד אימוץ פתרונות PaaS יכול להניע ארגון לעבר DevOps, לשנות תפקידים ומשימות מסורתיות כחלק מהתהליך. זו הסיבה שמנינו את אתגרי ה-IT העיקריים איתם מתמודד ארגון בעת ההגירה ל-OpenShift, כמו גם את הכישורים הנדרשים להשלמתם. סיפקנו גם מערכת ליבה של תפקידים ארגוניים המתעוררים בעת בניית צוותי DevOps צולבים, ומטריצת RACI המקשרת בין תפקידים חדשים למשימות חדשות. לבסוף, דנו כיצד פלטפורמת OpenShift ומתודולוגיית ה-DevOps הקשורה לה יכולים לשנות את המבנה הארגוני של ארגונים כאשר הם עוברים מהיררכיות מסורתיות ומערכות כרטיסים לצוותים חוצי-פונקציות עם רמה גבוהה יותר של תקשורת אישית.
מקור: www.habr.com
