שוב על DevOps ו-SRE

מבוסס על דיון בצ'אט קהילת AWS מינסק

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

פרהיסטוריה

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

הלידה של שיטות DevOps

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

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

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

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

שוב לא הכל טוב, תודה לאל

ברגע שהכל נרגע, ו"מתודולוגים" ערמומיים שונים החלו לכתוב ספרים עבים על שיטות DevOps, התלקחו בשקט מחלוקות לגבי מיהו המהנדס הידוע לשמצה של DevOps וש-DevOps היא תרבות ייצור, שוב התעוררה חוסר שביעות רצון. פתאום התברר שהעברת תוכנה היא משימה לא טריוויאלית לחלוטין. לכל תשתית פיתוח יש מחסנית משלה, איפשהו צריך להרכיב אותה, איפשהו צריך לפרוס את הסביבה, כאן צריך Tomcat, כאן צריך דרך ערמומית ומסובכת להשיק אותה – באופן כללי, הראש שלך דופק. והבעיה, באופן מוזר, התבררה בעיקר בארגון התהליכים - פונקציית המסירה הזו, כמו צוואר בקבוק, התחילה לחסום תהליכים. בנוסף, אף אחד לא ביטל את המבצעים. זה לא נראה בדגם V, אבל עדיין יש את כל מחזור החיים בצד ימין. כתוצאה מכך, יש צורך איכשהו לתחזק את התשתית, לפקח על ניטור, לפתור תקלות, וגם לטפל באספקה. הָהֵן. לשבת עם רגל אחת גם בפיתוח וגם בתפעול - ופתאום התברר שזה Development & Operations. ואז היה ההייפ הכללי לשירותי מיקרו. ואיתם, הפיתוח ממכונות מקומיות החל לעבור לענן - נסו לבצע ניפוי באגים מקומית, אם יש עשרות ומאות מיקרו-שירותים, אז אספקה ​​מתמדת הופכת לאמצעי הישרדות. עבור "חברה קטנה וצנועה" זה היה בסדר, אבל בכל זאת? וגוגל?

SRE מאת גוגל

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

פיתוח רעיונות DevOps

בדיוק אז הגיע Docker, שצמח מתוך lxc, ואז מערכות תזמור שונות כמו Docker Swarm ו-Kubernetes, ומהנדסי DevOps נשפו - איחוד הפרקטיקות פשט את האספקה. זה פישט את זה עד כדי כך שאפשר היה אפילו לבצע מיקור חוץ של משלוח למפתחים - מה זה deployment.yaml. מיכליות פותר את הבעיה. והבשלות של מערכות CI/CD כבר ברמה של כתיבת קובץ אחד ויוצאים לדרך - המפתחים יכולים לטפל בזה בעצמם. ואז אנחנו מתחילים לדבר על איך אנחנו יכולים ליצור SRE משלנו, עם... או לפחות עם מישהו.

SRE לא נמצא בגוגל

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

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

מקור: www.habr.com