שבעה ארכיטיפים של טרנספורמציה המבוססים על עקרונות DevOps

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

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

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

על הדובר:

יותר מ-35 שנים בניהול IT, השתתפו ביצירת קודמו של OpenCloud ב-Canonical, השתתפו ב-10 סטארט-אפים, שניים מהם נמכרו ל-Dell ו-Docker. כיום הוא סגן נשיא ל-DevOps ופרקטיקה דיגיטלית ב-SJ Technologies.

הבא הוא הסיפור מנקודת מבטו של ג'ון.

שמי ג'ון וויליס והמקום הכי קל למצוא אותי הוא בטוויטר, @botchagalupe. יש לי את אותו הכינוי ב-Gmail וב-GitHub. א קישור זה אתה יכול למצוא הקלטות וידאו של הדוחות והמצגות שלי עבורם.

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

מה זה DevOps?

ואכן, אם תשאלו 10 אנשים שונים, הם יתנו 10 תשובות שונות. אבל הנה הדבר המעניין: כל עשר התשובות הללו יהיו נכונות. אין כאן תשובה שגויה. הייתי די עמוק בתוך DevOps, בערך 10 שנים, והייתי האמריקאי הראשון ביום DevOpsDay הראשון. אני לא אגיד שאני חכם יותר מכל מי שמעורב ב-DevOps, אבל אין כמעט מישהו שהשקיע בזה כל כך הרבה מאמץ. אני מאמין ש-DevOps מתרחש כאשר הון אנושי וטכנולוגיה מתאחדים. לעתים קרובות אנו שוכחים את הממד האנושי, למרות שאנו מדברים הרבה על כל מיני תרבויות.

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

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

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

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

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

תרבות רעה אוכלת גישות טובות לארוחת בוקר

הרעיון המרכזי הוא זה: שום כמות של Lean, Agile, SAFE ו-DevOps לא תעזור אם התרבות של הארגון עצמו גרועה. זה כמו לצלול לעומקים ללא ציוד צלילה או לפעול ללא צילום רנטגן. במילים אחרות, בפרפראזה של דרוקר ודמינג: תרבות ארגונית גרועה תבלע כל מערכת טובה מבלי להיחנק ממנה.

כדי לפתור בעיה עיקרית זו, עליך לנקוט בצעדים הבאים:

1. הפוך את כל העבודה לגלויה: אתה צריך להפוך את כל העבודה לגלויה. לא במובן שהוא חייב בהכרח להיות מוצג על מסך כלשהו, ​​אלא במובן שהוא חייב להיות ניתן לצפייה.
2. מערכות ניהול עבודה מאוחדות: יש לאחד את מערכות הניהול. בבעיית הידע ה"שבטי" והידע המוסדי, ב-9 מקרים מתוך 10 צוואר הבקבוק הוא אנשים. בספר "פרויקט הפניקס" הבעיה הייתה עם אדם בודד אחד, ברנט, שגרם לפרויקט לפגר שלוש שנים בלוח הזמנים. ואני נתקל ב"ברנטים" האלה בכל מקום. כדי לפתור צווארי בקבוק אלה, אני משתמש בשני הפריטים הבאים ברשימה שלנו.
3. מתודולוגיה של תורת האילוצים: תיאוריית האילוצים.
4. פריצות לשיתוף פעולה: פריצות לשיתוף פעולה.
5. טויוטה קאטה (מאמנת קאטה): אני לא אדבר הרבה על טויוטה קאטה. אם מעוניין, ב-github שלי יש מצגות כמעט בכל אחד מהנושאים הללו.
6. ארגון מכוון שוק: ארגון מוכוון שוק.
7. מבקרי משמרת שמאלה: ביקורת בשלבים מוקדמים של המחזור.

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

(ניתן לצפות באיור זה בנפרד ראה קישור)

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

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

(ניתן לצפות באיור זה בנפרד ראה קישור)

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

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

(ניתן לצפות באיור זה בנפרד ראה קישור)

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

(ניתן לצפות באיור זה בנפרד ראה קישור)

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

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

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

(ניתן לצפות באיור זה בנפרד ראה קישור)

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

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

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

1. הפוך את כל העבודה לגלויה: הפוך את העבודה לגלויה

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

• יותר מדי עבודה בתהליך (WIP)
• תלות לא ידועה
• עבודה לא מתוכננת
• סדרי עדיפויות סותרים
• עבודה מוזנחת

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

פרויקט הפניקס הוא סיפור נפלא על פרויקט שאיחר מדי שלוש שנים. אחת הדמויות עומדת בפני פיטורים בשל כך, והוא נפגש עם דמות אחרת שמוצגת כמעין סוקרטס. הוא עוזר להבין מה בדיוק השתבש. מסתבר שלחברה יש מנהל מערכת אחד, ששמו ברנט, וכל העבודה איכשהו עוברת דרכו. באחת הפגישות נשאל אחד הכפופים: מדוע כל מטלה של חצי שעה אורכת שבוע? התשובה היא הצגה מאוד פשוטה של ​​תורת התורים וחוק ליטל, ובמצגת זו מתברר שב-90% תפוסה כל שעת עבודה אורכת 9 שעות. כל משימה צריכה להישלח לשבעה אנשים אחרים, כך שהשעה הופכת ל-63 שעות, 7 כפול 9. מה שאני אומר זה שכדי להשתמש בחוק ליטל או בכל תיאוריית תורים מורכבת, לפחות צריך נתונים.

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

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

2. איחוד מערכות ניהול עבודה: ניהול משימות

הארכיטיפים שאני מדבר עליהם הם סוג של פירמידה. אם הראשון נעשה נכון, אז השני הוא כבר סוג של תוסף. רבים מאלה אינם עובדים עבור סטארטאפים, יש לזכור אותם עבור חברות גדולות יותר כמו Fortune 5000. לחברה האחרונה שעבדתי בה היו 10 מערכות כרטוס. לצוות אחד היה Remedy, אחר כתב איזושהי מערכת משלו, שלישי השתמש ב-Jira, וחלק הסתפק באימייל. אותה בעיה מתעוררת אם לחברה יש 30 צינורות שונים, אבל אין לי זמן לדון בכל המקרים האלה.

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

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

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

צינור שירותים

זה שוב חל רק על תאגידים גדולים. אם אתה חברה חדשה בתחום חדש, הפשיל שרוולים ועבוד עם ה-Travis CI או CircleCI שלך. כשזה מגיע לחברות Fortune 5000, מקרה שקרה בבנק שבו עבדתי. גוגל הגיעה אליהם והראו להם דיאגרמות של מערכות ישנות של IBM. החבר'ה מגוגל שאלו בבלבול - איפה קוד המקור לזה? אבל אין קוד מקור, אפילו לא GUI. זו המציאות איתה נאלצים להתמודד ארגונים גדולים: רשומות בנק בנות 40 שנה במיינפריים עתיק יומין. אחד מהלקוחות שלי משתמש בקונטיינרים של Kubernetes עם דפוסי מפסק מעגלים, בתוספת Chaos Monkey, הכל עבור אפליקציית KeyBank. אבל מיכלים אלה מתחברים בסופו של דבר לאפליקציית COBOL.

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

3. תורת האילוצים: תורת האילוצים

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

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

כדי לפתור בעיה מסוג זה, אני יכול, למשל, להציע להשתמש ב-Slack. במאי חכם ישאל - למה? בדרך כלל, במקרים כאלה, יועצי DevOps עונים: כי כולם עושים את זה. אם הבמאי באמת חכם, הוא יגיד: אז מה. וכאן מסתיים הדיאלוג. והתשובה שלי לזה היא: כי יש ארבעה צווארי בקבוק בחברה, פרד, לו, סוזי וג'יין. כדי למסד את הידע שלהם, צריך קודם להציג את Slack. כל הוויקים שלך הם שטויות מוחלטות כי אף אחד לא יודע על קיומם. אם צוות ההנדסה עוסק בפיתוח פרונט-אנד ו-back-end וכולם צריכים לדעת שהם יכולים לפנות לצוות הפיתוח הפרונט-אנד או לצוות התשתית בשאלות. אז כנראה שללו או פרד יהיה זמן להצטרף לויקי. ואז ב-Slack מישהו יכול לשאול למה, נגיד, שלב 5 לא עובד. ואז לו או פרד יתקנו את ההוראות בוויקי. אם תבססו את התהליך הזה, הרבה דברים יתייצבו מעצמם.

זו הנקודה העיקרית שלי: כדי להמליץ ​​על טכנולוגיות עילית כלשהן, צריך קודם כל לעשות סדר בבסיס שלהן, וניתן לעשות זאת עם פתרונות הלואו-טק שתוארו זה עתה. אם מתחילים עם טכנולוגיות גבוהות ולא מסבירים מדוע יש צורך בהן, אז, ככלל, זה לא נגמר טוב. אחד מלקוחותינו משתמש ב-Azure ML, פתרון זול ופשוט מאוד. כ-30% מהשאלות שלהם נענו על ידי מכונת הלמידה העצמית עצמה. והדבר הזה נכתב על ידי מפעילים שלא היו מעורבים במדעי הנתונים, סטטיסטיקה או מתמטיקה. זה משמעותי. העלות של פתרון כזה היא מינימלית.

4. פריצות לשיתוף פעולה: פריצות לשיתוף פעולה

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

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

5. אימון קאטה

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

יש גם הרצאה טובה על הנושא הזה ממייק רותר:

6. מכוון שוק: ארגון מכוון שוק

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

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

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

אנשים רבים מתארים את המבנה הזה בדרכים שונות, אני אוהב את הניסוח לבנות/להפעיל צוותים, באמזון קוראים לזה שני צוותי פיצה. במבנה זה, כל האנשים מסוג "I" מקובצים סביב שירות אחד, ובהדרגה הם מתקרבים לסוג "T", ואם ישנה ניהול נכון, הם יכולים אפילו להפוך ל-E. טענת הנגד הראשונה כאן היא שלמבנה כזה יש אלמנטים מיותרים. למה אתה צריך בודק בכל מחלקה אם אתה יכול להיות מחלקה מיוחדת של בודקים? על כך אני עונה: העלויות הנוספות במקרה זה הן המחיר עבור הארגון כולו להפוך לסוג "E" בעתיד. במבנה זה, הבוחן לומד בהדרגה על רשתות, ארכיטקטורה, עיצוב וכו'. כתוצאה מכך, כל משתתף בארגון מודע לחלוטין לכל מה שקורה בארגון. אם אתה רוצה לדעת איך תוכנית זו עובדת בתעשייה, קרא מייק רותר, טויוטה קאטה.

7. מבקרי משמרת שמאלה: ביקורת מוקדם במחזור. עמידה בכללי הבטיחות המוצגים

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

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

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

על פי להגיש תלונה, שנוצר ב-2018 על ידי Sonatype, היו 2017 מיליארד בקשות הורדה של OSS ב-87.

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

דוגמה לרצף זה:


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

ואין שום סיבה שלא נוכל לנקוט באותה גישה לאבטחה.

סך הכל

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

קישורים שימושיים

הנה כמה הרצאות מכנס DevOops שאולי תמצאו בהן שימושיות:

• סרגיי ברדניקוב, ארטיום קליצ'קין - סיפור הצלחה, או "Dev+DevOps+Ops" (וידאו, תמלול הדו"ח)
• ברוך סדוגורסקי, ליאוניד איגולניק - DevOps בקנה מידה: טרגדיה יוונית בשלוש מערכות (וידאו, תמלול הדו"ח)
• אלכסנדר טיטוב, קיריל טולקצ'וב - DevOps, מהנדסים וקהילה
• טימותי ליסטר - דמויות, קהילה ותרבות: גורמים חשובים לשגשוג

לִבדוֹק программу DevOops 2020 מוסקבה - יש שם גם הרבה דברים מעניינים.

מקור: www.habr.com