DevOps וכאוס: אספקת תוכנה בעולם מבוזר

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

הכנו גרסת טקסט של הדו"ח.

הבוקר טוב!

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

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

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

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

אנחנו אנשים יצירתיים, אנחנו לא רק נרגעים. אנחנו אומרים: DevOps היא לא מילה מקיפה מספיק; עדיין חסרים בה כל מיני אלמנטים שונים ומעניינים. ואנחנו הולכים למעבדות הסודיות שלנו ומתחילים לייצר מוטציות מעניינות: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.

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

אז אני קורא לגישה הזו - "אופס, והבעיה נפתרה."

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

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

מהי מערכת?

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

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

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

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

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

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

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

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

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

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

תורת הכאוס

אנשים שחוקרים כאוס קוראים לעצמם כאוסולוגים.

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

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

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

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

יש עוד שני ממצאים מעניינים.


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

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

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

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

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

חיכית למילה הזו, אני מבין. אנחנו בכנס DevOps, היום המילה הזו תישמע כמאה אלף פעם ואז נחלום עליה בלילה.

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

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

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

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

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

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

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

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

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

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

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

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

אגב, מי יודע איזה סוג של לוגו יש על המסך? זה Hyperledger. מדובר בפרויקט שמפותח בחסות The Linux Foundation וכולל מערך טכנולוגיות בלוקצ'יין. זה באמת הכוח של קהילת הקוד הפתוח שלנו.

הנדסת כאוס

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

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

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

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

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

פרוטוקולי שילוב מערכות מבוזרות

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

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

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

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

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

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

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

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

יש נפלא книга הסופרת הבריטית רייצ'ל בוטמן, שבה היא כותבת על התפתחות האמון לאורך ההיסטוריה האנושית. היא אומרת שבתחילה, בחברות פרימיטיביות, האמון היה מקומי, כלומר בטחנו רק באלה שאנו מכירים באופן אישי.

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

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

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

יסודות ארגון DevOps

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

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

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

שְׁחִיקָה

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

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

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

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

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

מה מלבד כאוס קוף?

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

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

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

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

אז בפילוסופיית DevOps, שירותי מיקרו הם לא דבר כל כך טוב?

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

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

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

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

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

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

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

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

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

הכנס השנה DevOpsDays מוסקבה יתקיים ב-7 בדצמבר בטכנופוליס. אנו מקבלים בקשות לדוחות עד ה-11 בנובמבר. כתוב לי אותנו אם תרצה לדבר.

ההרשמה למשתתפים פתוחה, כרטיסים עולים 7000 רובל. הצטרף אלינו!

מקור: www.habr.com