במאמר על CAMS Model דיברנו על עקרונות מנחים שצריכים להיות בראש שלנו כאנשי DevOps . היום נדבר על כל מיני דוגמאות מעשיות כדי שתוכלו לשפר בעצמכם את התרבות הארגונית ובעצם את כל ה-flow של הארגון.
הדבר הראשון שאני רוצה לדבר עליו הוא Service ownership. בחור חכם בשם Werner Vogels (ה-CTO של Amazon) אמר את המשפט הבא:
You wrote it, you run it
הוא התכוון לכך שאם מישהו רשם משהו, בין אם זה קוד שרץ על שרת בדיקות שאף אחד לא מכיר או שזה חלק מ-Service בסביבה המבצעית – הוא אחראי על זה ב-100%. אני מפרש את האמירה הזאת כך שאני חושב שאם מישהו כתב משהו – הוא חייב לתעד את זה בצורה ברורה ומקצועית. אנחנו לא חיים בעולם אידיאלי ולעיתים קרובים אחריות על קוד עוברת בין אנשים (וזה בסדר!). מה שלא בסדר הוא להעביר את זה בצורה לא מספיק טובה. עם זאת, עדיף לצמצם מקרים כאלה כמה שיותר.
ההשפעה החיובית של העיקרון הזה היא שיפור התרבות הארגונית. כשאנשים ירגישו על כתפיהם את תחושת האחריות, הם לא יעשו “חצי עבודה”. הם ידאגו לכתוב בדיקות, לתעד וחפוף אנשים אחרים על מה שכתבו. בטווח הארוך גם איכות הקוד בארגון תשתפר.
Hackaton events
אירועי האקתון הם הזדמנות מעולה ללמידת דברים חדשים, גיבוש והתאווררות מהשגרה היום יומית. כך אפשר ללמוד ביחד נושאים חדשים ולהתנסות בהם. זו הזדמנות מעולה לעבוד עם אנשים שלא עובדים איתם בשגרה וזה יכול להוות קרקע פוריה ליצירת קשרים חדשים, שיתופי פעולה ורעיונות חדשים חוצי צוותים.
חשוב לנסות לא להבטיח דברים באירועים מהסוג הזה. למה? כי הדגש צריך להיות על למידה עצמית, למידה מאחרים, יצירתיות וחשיבה מחוץ לקופסא. ההבטחה היחידה שצריכה להיות היא שהאירוע יהיה כיף ומעשיר. עם השאר צריך לזרום ?.
אורך של אירוע כזה הוא מאוד משתנה. אם זה משהו שחדש לארגון, עדיף להתחיל מקטן (כמה שעות). בעיניי, רצוי שאנשים בתפקידים ניהוליים בחברה לא ישתתפו באירוע. זה עלול להלחיץ אנשים ולגרום להם לרצות להרשים את הבוס, ואז – מפספסים את המטרה.
הרבה פעמים נרצה הנחייה כלשהי של האירוע, כדאי לעשות את זה עם מצגות. כשאדם מדבר מול קהל (בין אם זה בעזרת מצגת או לא) חשוב להקפיד על העברת המסר בצורה ברורה וקצרה. רוב המצגות הארוכות לא יהיו אפקטיביות באיזשהו שלב לכן כדאי לחשוב על הגבלת אורך ההצגה.
Destructive testing
כולנו רוצים להספיק כמה שיותר משימות ולהעביר את הסטטוס שלהם ל-done. אבל מתי אנחנו יודעים כשסיימנו? לדוגמא, אם חלק מהבקשות של nginx קיבלו 502 ואנחנו חושבים (לא בטוחים) שצריך להגדיל את ה-timeout שלו. החלטנו לנסות את זה, איך נדע שטעויות כאלה לא יחזרו יותר?
אז לא תמיד אפשר. אבל המטרה ב-destructive testing היא לנסות לאתגר את הפיתרון כדי לנסות לגלות unexpected behavior בשלב הכי מוקדם שאפשר (לפני ששלקוחות יתלוננו).
איך אפשר לחשוב על אתגור של המערכת? קבוצת הפיתוח וקבוצת ה-Operations יישבו ויחשבו איפה המערכת יכולה להיכשל, איך אפשר לדמות את זה, האם יש כלים חיצוניים שיכולים לעזור, על פי מה מודדים הצלחה/כישלון? בדוגמא של nginx timeout אפשר לשלוח בצורה אוטומטית הרבה בקשות לשרת כולל בקשות כבדות. נרשום לקובץ לוג כל פעם שמקבלים סטטוס קוד מסדרת ה-500.
בגדול המטרה היא לנסות להפיל דברים באופן יזום כדי שזה לא יפתיע אותנו וכדי שנוכל להמשיך להשתפר כל הזמן!
Cross functional teams
כאן מדובר על עיקרון מעניין כשמסתכלים על מבנה הצוותים ברמת המאקרו. כשמרכיבים צוות, הרבה פעמים נרצה שכולם יידעו בסיס כלשהו אבל לכל אחד יהיה התמקצעות בתחום אחר. לדוגמא, במקום שצוות DevOps יורכב רק מאנשים שמבינים CI, CD, Containers, Monitoring וכו’, יהיה צוות שכל אחד בו מכיר את הדברים האלה בצורה כללית ולכל אחד התמקצעות במשהו אחר. אחד מבין יותר באיזורי ה-CI\CD, אחד מבין יותר ב-K8s, Containers ואחד מבין יותר ב-Monitoring.
מה היתרונות של מבנה כזה?
כל חברי הצוות יושבים באותו הצוות כך שהעיסוק דומה. כשכל אחד מתקמצע במשהו אחר, היכולת של הצוות ליזום דברים, ללמוד אחד מהשני ולהשתפר גבוהה יותר. כשלמישהו מהצוות יש התייעצות בנושאי CI\CD הוא יידע למי לפנות וכך הלאה. זה משפר את האווירה בצוות ומהווה קרקע פורייה לשותפות מלאה בין כל חברי הצוות. אף בן אדם לא יכול להבין בכל הנושאים בצורה מספיק טובה, וכשמגדירים מראש מה התחום שכל אחד אמור להתעמק בו – מרגישים שיפור ברמה המקצועית בצוות.
לסיכום, דיברנו על עוד עקרונות חשובים שרלוונטיים מאוד לאנשי DevOps ולכל הארגון. הם יעזרו לכם לשפר את התרבות בארגון שלהם, לעבוד בצורה נכונה ומקצועית ולהשתפר.
אסיים בטיפ לינוקס: אם אתם רוצים לרשום שתי פקודות באותה שורה כך שהפקודה השנייה תתקיים רק אם הפקודה הראשונה הסתיימה בהצלחה הוסיפו && ביניהם. הקוד הבא ידפיס hi למסך:
true && echo "hi"
והקוד הבא לא ידפיס כלום:
false && echo "hi"