כשל: פרפקציוניזם ו... עצלות הורסים אותנו

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

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

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

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

שטוש (ג) אנחנו לוקחים את האתר השני, בונים מערכת זהה... המורכבות נעשית גדולה פי שניים - יש לנו שתי ישויות. אנחנו גם מגלגלים היגיון מסוים להעברת נתונים מאתר אחד לאחר - כלומר שכפול נתונים, העתקת נתונים סטטיים וכו'. אז, היגיון השכפול הוא בדרך כלל מאוד מורכב, ולכן, המורכבות הכוללת של המערכת יכולה להיות לא גדולה פי 2, אלא פי 3, 5, 10.

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

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

הגיע הזמן ל"סיפורים מ-w"... מהחיים, כמובן.

דוגמה מספר אחת

דמיינו לעצמכם אתר כרטיס ביקור למפעל גלגול צינור מס' 1 בעיר נ' כתוב באותיות ענק - PIPE ROLLING PLANT מס' 1. ממש מתחת הסיסמה: "הצינורות שלנו הם הצינורות העגולים ביותר ב-N." ולהלן מספר הטלפון של המנכ"ל ושמו. אנחנו מבינים שצריך להזמין מקום - זה דבר מאוד חשוב! בואו נתחיל להבין ממה זה מורכב. Html-statics - כלומר, כמה תמונות שבהן המנהל הכללי, למעשה, דן בסוג של עסקה הבאה ליד השולחן בבית המרחץ עם שותפו. אנחנו מתחילים לחשוב על זמן השבתה. זה עולה לי לראש: אתה צריך לשכב שם חמש דקות, לא יותר. ואז נשאלת השאלה: כמה מכירות היו בכלל מהאתר הזה שלנו? כמה-כמה? מה המשמעות של "אפס"? וזה אומר: כי הגנרל עשה בשנה שעברה את כל ארבע העסקאות באותו שולחן, עם אותם אנשים שעמם הולכים לבית המרחץ ויושבים ליד השולחן. ואנחנו מבינים שגם אם האתר יישאר יום, שום דבר נורא לא יקרה.

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

דוגמה מספר שתיים

בלוג חברה: אנשים שעברו הכשרה מיוחדים כותבים שם חדשות, השתתפנו בתערוכה כזו ואחרת, אבל הוצאנו עוד מוצר חדש וכו'. נניח שזה PHP סטנדרטי עם וורדפרס, מסד נתונים קטן וקצת סטטי. כמובן, שוב עולה לראש שבשום פנים ואופן אסור לשכב - "לא יותר מחמש דקות!" זה הכל. אבל בואו נחשוב יותר. מה הבלוג הזה עושה? אנשים מגיעים לשם מיאנדקס, מגוגל בהתבסס על כמה שאילתות, באופן אורגני. גדול. האם יש קשר למכירות? התגלות: לא ממש. תעבורת הפרסום עוברת לאתר הראשי, שנמצא במכונה אחרת. בואו נתחיל לחשוב על תוכנית הזמנות. במובן טוב, צריך להעלות אותו תוך כמה שעות, וזה יהיה נחמד להתכונן לזה. זה יהיה הגיוני לקחת מכונה ממרכז נתונים אחר, לגלגל עליה את הסביבה, כלומר שרת אינטרנט, PHP, WordPress, MySQL, ולהשאיר אותה שם. ברגע שאנחנו מבינים שהכל מקולקל צריך לעשות שני דברים - לגלגל את dump mysql 50 מטר, הוא יטוס לשם תוך דקה, ולגלגל שם מספר מסוים של תמונות מהגיבוי. זה גם לא שם כי אלוהים יודע כמה זמן. כך, תוך חצי שעה כל העניין עולה. אין שכפול, או אלוהים יסלח לי, כשל אוטומטי. מסקנה: אין צורך לגבות את מה שאנו יכולים לגלגל במהירות מגיבוי.

דוגמה מספר שלוש, יותר מסובכת

חנות מקוונת. PhP עם לב פתוח הוא קצת מצומצם, mysql עם בסיס מוצק. די הרבה סטטי (בכל זאת, בחנות המקוונת יש תמונות HD יפות וכל הדברים האלה), Redis לסשן ו- Elasticsearch לחיפוש. אנחנו מתחילים לחשוב על זמן השבתה. וכאן, כמובן, ברור שחנות מקוונת לא יכולה לשכב ללא כאב במשך יממה. אחרי הכל, ככל שהוא שוכב זמן רב יותר, כך נפסיד יותר כסף. שווה להאיץ. כמה? אני חושב שאם נשכב שעה, אף אחד לא ישתגע. כן, נפסיד משהו, אבל אם נתחיל לעבוד קשה, זה רק יחמיר. אנו מגדירים סכימה של זמן השבתה מותר לשעה.

איך אפשר לשמור את כל זה? בכל מקרה צריך רכב: שעה של זמן היא די מעט. Mysql: כאן אנחנו כבר צריכים רפליקציה, רפליקציה חיה, כי בעוד שעה סביר להניח שלא יתווספו ל-dump 100 GB. סטטיקה, תמונות: שוב, בעוד שעה יתכן שלא יהיה זמן להוסיף ל-500 GB. לכן, עדיף להעתיק את התמונות מיד. Redis: זה המקום שבו הדברים הופכים מעניינים. ברדיס, הפעלות מאוחסנות - אנחנו לא יכולים פשוט לקחת את זה ולקבור את זה. כי זה לא יהיה טוב במיוחד: כל המשתמשים יתנתקו, הסלים שלהם יתרוקנו וכו'. אנשים ייאלצו להזין מחדש את שם המשתמש והסיסמה שלהם, ואנשים רבים עלולים להתנתק ולא להשלים את הרכישה. שוב, ההמרות ירדו. מצד שני, Redis מעודכן באופן ישיר, כאשר כנראה שגם המשתמשים האחרונים שנכנסו לחשבון אינם נחוצים. ופשרה טובה היא לקחת את Redis ולשחזר אותו מגיבוי מאתמול, או, אם אתה עושה את זה כל שעה, מלפני שעה. למרבה המזל, שחזורו מגיבוי פירושו העתקת קובץ אחד. והסיפור הכי מעניין הוא Elasticsearch. מי אי פעם הרים שכפול של MySQL? מי אי פעם הרים שכפול של Elasticsearch? ולמי זה עבד כרגיל אחרי? מה שאני מתכוון הוא שאנחנו רואים ישות מסוימת במערכת שלנו. זה נראה שימושי - אבל זה מורכב.
מורכב במובן שלחברינו המהנדסים אין ניסיון בעבודה איתו. או שיש חוויה שלילית. או שאנחנו מבינים שזו עדיין טכנולוגיה חדשה למדי עם ניואנסים או גולמיות. אנחנו חושבים... לעזאזל, אלסטי זה גם בריא, גם לוקח הרבה זמן לשחזר אותו מגיבוי, מה עלי לעשות? אנו מבינים כי אלסטי במקרה שלנו משמש לחיפוש. איך החנות המקוונת שלנו מוכרת? אנחנו הולכים למשווקים ושואלים מאיפה אנשים מגיעים. הם עונים: "90% משוק Yandex מגיעים ישירות לכרטיס המוצר." או שהם קונים את זה או שהם לא. לכן, 10% מהמשתמשים זקוקים לחיפוש. ולשמירה על שכפול אלסטי, במיוחד בין מרכזי נתונים שונים באזורים שונים, יש באמת הרבה ניואנסים. איזו יציאה? אנחנו לוקחים גומי מאתר שמור ולא עושים איתו כלום. אם העניין ייגרר, כנראה נעלה אותו מתישהו, אבל זה לא בטוח. למעשה, המסקנה היא זהה, פלוס מינוס: אנחנו, שוב, לא שומרים שירותים שאינם משפיעים על הכסף. כדי לשמור על התרשים פשוט יותר.

דוגמה מספר ארבע, קשה עוד יותר

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

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

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

דוגמה מספר חמש, הארדקור שלם

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

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

זה כנראה הכל. אל תתעצלו או תגזימו. ואולי זמן הפעילות יהיה איתך!

מקור: www.habr.com