לאחר לא מעט מחקר בכמה חודשים האחרונים החלטתי לסכם למה צריך אדם או צוות DevOps בכל ארגון שמעוניין לפתח אפליקציה כלשהי ולהנגיש אותה לקהל גדול. ניגש לעניין ונבין מה הוא ה-DevOps role. איש ה-DevOps אחראי על תהליך ה-DevOpsשהוא חלק גדול (שהפך לסטנדרט) מתהליך הפיתוח של המוצר.
תכנון
בזמן שהארכיטקט בונה את ארכיטקטורת התוכנה ומעצב אותה, איש ה-DevOps (במקרה של צוות, ה-DevOps architect) צריך להכווין אותו. משימוש ברכיבים שקל לתחזק ובכלל לארכיטקטורה נכונה תהליכית. על כן, הוא חייב להכיר כמה שיותר סוגים של …Databases, Message queues, Cache DBs, etc
רכיבים כאלו משתנים ומשתדרגים כל הזמן בשוק. יש להתעדכן באופן שוטף איך לתחזק אותם, איך הם בנויים מאחורי הקלעים, מה היתרונות והחסרונות של כל אחד ולהצליב מידע עם השפות שמתממשקות טוב יותר לאותו כלי (מבחינת סיפריות). כלים בשימוש בשלב זה הם:
…Jira, Trello, Monday.com, nTask
*בארגונים גדולים ומקומות עם סביבות פיתוח פנימיות צריך להקים ולתחזק אחד מכלים אלו בצורה תוך ארגונית. בנוסף לכך, כמו תפקיד ה-CTO ישנו התפקיד DevOps lead שתפקידו לבחון טכנולוגיות חדשות בתחום ולהחליט האם שווה לחברה לעבור להשתמש בהן או לא.
פיתוח
עוד תפקיד של איש ה-DevOps הוא לנהל את שרתי ה-source code כדוגמת …Gitlab/Github/Bitbucket צריך להכיר לעומק את המערכת ולתחזק אותה בצורה יעילה בטוחה ונכונה. בחלק מהחברות על איש ה-DevOps לשבת עם צוות הפיתוח ולעשות להם Code Review אופרטיבי מנקודת המבט התשתיתית (דוגמא לדבר נפוץ שעולה במהלך- CR מסוג זה הוא שימוש נכון באחסון). במקרים של סביבה פנימית זה כולל להקים שרתי חבילות לשפות בהם משתמשים כמו- PYPI ל- Python ו- NPM ל- Node וכו’. כלי שתפס מאוד חזק בהקשר הזה הינו ה-Artifactory של Jfrog שמאחד למעשה חבילות מכל הסוגים כולל אחסון docker images.
תחום נוסף שאסכם בקצרה הוא עניין ה-release. בחרתי להכניס אותו תחת סקשין זה מכיוון שלסקשין זה יש הכי הרבה השפעה עליו. כדי לעקוב אחרי שינויים ולדעת מה הגורם לבעיה במקרה של כשל, יש לעבוד בצורה מסודרת ושיטתית. אחרי כל שינוי , גרסת המערכת תשתנה בהתאם לסוג השינוי (major/ minor/ patch) והוא יתועד. על איש ה-DevOps לנסות לאכוף סטנדרט commit messages אחיד בכדי ליצור את ה-release הבא, לקריאה נוספת:
בניה
לכל שפה יש את הבנאים שלה, אם זה- Maven ל- Java או -GCC ל- C וכו’. היום יש כלים כמו Gradle שיודעים לבנות בצורה אוטומטית לפי זיהוי שינויים אפליקציות בשפות שונות. בשביל להשתמש בכלי הבניה חייבים להבין אותו ואיך להשתמש בו בצורה נכונה. כמובן שבכל רגע נתון יכול להיות שיהיה נכון להחליפו. חלק זה כבר נכנס לתהליך ה- CI שהוא למעשה הבסיס של דוופס (הרצת -Pipeline שיבנה ויבדוק את הקוד שנכתב).
בדיקות
חלק זה לפעמים מוטל על איש DevOps אחד ביחד עם- security checks בגלל המסה שלו. לא מדובר פה על unit tests שכותב המתכנת אלא על בדיקות כלל מערכתיות. לדוגמא, בניית probes לשירותים מסויימים ב-k8s או בניה של תרחישי קצה עם כלים כמו selenium או puppeteer. במקרים של בניית אתרים או אפליקציות cross platform רצוי להוסיף בדיקה שהכל רץ כמו שצריך מבחינת תפקוד ונראות בכל הסביבות. מבחינת security מדובר בעולם שלם של בדיקת חולשות בקוד ובתשתית. הבנה של איך לפתור בעיות כאלו עם שיתוף פעולה מצד צוות ה-security או הטמעת כלי third party שמקנה בדיקות וכמובן הפיכה של כל התהליך הזה לאוטומטי. אפשר לעשות זאת עם כלים כמו Black Duck שעוקב אחרי חולשות בקטעי open source בפרויקט שלך או dependencies checks.
חלק נוסף שראוי לציין הינו performance testing שמתחלק לשניים:
* בדיקות קצרות שהן בדיקות כחלק מתהליך ה-CI בו בודקים שביצועי הקוד שנכתב לא ירדו. לדוגמא במקרה של API לבדוק מה ה-latency, האם חזרו שגיאות וכמה, והאם עלה השימוש במעבד או בזכרון. צריך לסכם הכל להשפעה של קטע הקוד על האפליקציה ולסכם האם להעביר את ה-stage או לא. כלי חזק שמסמלץ בדיקות כאלו הוא k6 לדוגמא.
* בדיקות ארוכות עליהן ארכיב בחלק של ניטור.
נושא זה עצום (עברתי רק על חלק קטן מסוגי הבדיקות) לכן הוא יוצא לתפקיד נפרד (QA).לקריאה נוספת:
אהבתי את ה flow של הכתבה!
החלוקה לכותרות משנה שכל אחת היא שלב אחר בתהליך ממש טובה! וממש טוב שנתת דוגמאות למוצרים עבור כל אחת מהן.
תודה רבה על הfeedback 🙂
היי,
אני רוצה לאתגר קצת את מה שנאמר:
“איש ה-DevOps אחראי….”
על כמה שאני זוכר, מי שהגה את מונח ה DevOps ציין במפורש ש DevOps הוא לא תפקיד – אלא תרבות.
יש אנשי Operations (נקראים לעתים גם Production Engineers או SRE) – שלהם אנחנו קוראים בטעות “אנשי DevOps”
ויש אנשי פיתוח – Developers.
הרעיון של ה DevOps הוא ליצור תרבות משותפת בין שתי הקבוצות הללו, ולצמצם את הדינמקיה בה כל צד דואג לצרכים שהוא אחראי עליהם, ועושה להם אופטימיזציה.
המפתחים רוצים להתקדם מהר – והתקדמות מהירה יכולה לפגוע ביעדים של אנשי ה Operations – היציבות (להלן “throw over the wall”).
אנשי ה Operations רוצים להשיג יציבות – וכדי להשיג אותה, יכולים להקשות מאוד ולהאט את המפתחים.
כל עוד שתי הקבוצות הללו יעבדו על בסיס גבולות ברורים ומעט תקשורת / שיתוף פעולה – הם יבטלו עבודה אחת של השניה.
הרעיון של DevOps היא ליצור את השותפות העמוקה הזו, שבה אנשי פיתוח משתפים אנשי Operations בשיקולים ובעשייה שלהם – ולהיפך.
ניתן לטעון שדווקא הגדרת גבולות ברורה – היא ההיפך מ DevOps.
הנה רפרנס אקראי מהאינטרנט, לחזק שאני לא מדבר סתם שטויות:
https://neonrocket.medium.com/devops-is-a-culture-not-a-role-be1bed149b0
היי, תודה על האתגור, אני מסכים שDevOps זאת תרבות ובמקומות מסויימים אין אנשי דוופס אלא מפתחים או אנשי תשתית שלוקחים על עצמם את האחריות להכניס את התרבות ולהטמיע את התהליך שהיא מייצגת. אם זאת במקומות רבים הבינו שהתכולות שהתרבות מכניסה הם גדולים וקשה להוסיף אותן לאנשי התוכנה והתשתית. מסיבה זאת התפתחו תפקידים חדשים שנכנסו תחת הtitle הזה. במאמר לא התכוונתי לתת גבולות אלא לתת את נקודת המבט שלי על האחריות שיש לאנשי הדוופס בחברות. במאמר השלישי אתייחס גם לנקודת התרבות שהעלת. אגב מי שהציג את לראשונה את מתודולוגיית הפיתוח DevOps היה פטריק דבויס בכנס agile והרעיון היה להתאים את הגישה האג׳ילית לעולם התשתית ולאחר מכן לכל תחום אחר בתפיסה הכללית של תמיד יש bottleneck כלשהו ותמיד יש לו פתרון רק צריך לחשוב איך ולקחת אחריות על לפתור אותו.