Bitrix24: "מה שהועלה במהירות לא נחשב לנפל"

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

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

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

Bitrix.24 בתור SaaS

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

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

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

יצרנו תמיכה ברמת המוצר עבור אחסון אובייקטים בענן שונים: google storage, amazon s3, בתוספת תמיכה ב-Open stack swift. לכן, זה היה נוח גם לנו כשירות וגם למפתחים שעובדים עם פתרון ארוז: אם הם רק משתמשים ב-API שלנו לעבודה, הם לא חושבים איפה הקובץ יישמר בסופו של דבר, מקומית במערכת הקבצים או באחסון קבצי האובייקט.

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

מה שהם רצו זה מה שהם קיבלו...

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

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

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

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

שמרנו הכל?

יש לנו לקוחות רבים מארה"ב, לקוחות רבים מאירופה, לקוחות רבים הקרובים יותר למזרח - יפן, סינגפור וכן הלאה. כמובן, חלק עצום של לקוחות נמצאים ברוסיה. כלומר, העבודה אינה באזור אחד. המשתמשים רוצים תגובה מהירה, יש דרישות לעמידה בחוקים מקומיים שונים, ובתוך כל אזור אנחנו שומרים שני מרכזי נתונים, בנוסף יש כמה שירותים נוספים, ששוב נוח למקם אותם באזור אחד - עבור לקוחות שנמצאים ב האזור הזה עובד. מטפלי REST, שרתי הרשאות, הם פחות קריטיים לתפעול של הלקוח בכללותו, ניתן לעבור דרכם בהשהיה מקובלת קטנה, אך אינך רוצה להמציא מחדש את הגלגל כיצד לנטר אותם ומה לעשות איתם. לכן, אנו מנסים להשתמש בפתרונות הקיימים בצורה המקסימלית, במקום לפתח איזושהי יכולת במוצרים נוספים. ובאיזשהו מקום אנו משתמשים באופן טריוויאלי במיתוג ברמת ה-DNS, ואנחנו קובעים את חיוניות השירות לפי אותו DNS. לאמזון יש שירות Route 53, אבל זה לא רק DNS שאפשר להכניס אליו וזהו - זה הרבה יותר גמיש ונוח. באמצעותו תוכלו לבנות שירותים מבוזרים גיאוגרפיים עם מיקומים גיאוגרפיים, כאשר אתם משתמשים בו כדי לקבוע מהיכן הגיע הלקוח ולתת לו רשומות מסוימות – בעזרתו תוכלו לבנות ארכיטקטורות failover. אותן בדיקות בריאות מוגדרות בכביש 53 עצמו, אתה מגדיר את נקודות הקצה המנוטרות, קובע מדדים, קובע אילו פרוטוקולים לקבוע את "חיות" השירות - tcp, http, https; להגדיר את תדירות הבדיקות הקובעות אם השירות חי או לא. וב-DNS עצמו אתה מציין מה יהיה ראשי, מה יהיה משני, איפה להחליף אם בדיקת הבריאות מופעלת בתוך כביש 53. כל זה יכול להיעשות עם כמה כלים אחרים, אבל למה זה נוח - אנחנו מגדירים את זה פעם אחת ואז אל תחשוב על זה בכלל איך אנחנו עושים בדיקות, איך אנחנו מחליפים: הכל עובד לבד.

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

"אבל" שני: מה בתמונה הזו עדיין לא שמור? המאזן עצמו! חלוקת הלקוחות שלנו לפי אזור נעשית מאוד פשוטה. יש לנו את הדומיינים bitrix24.ru, bitrix24.com, .de - כעת ישנם 13 דומיינים שונים, הפועלים במגוון אזורים. הגענו לדברים הבאים: לכל אזור יש את האיזונים שלו. זה הופך אותו לנוח יותר להפצה על פני אזורים, תלוי היכן נמצא עומס השיא ברשת. אם מדובר בכשל ברמה של איזון בודד, אז פשוט מוציאים אותו משירות ומוציאים אותו מה-dns. אם יש בעיה כלשהי עם קבוצת מאזנים, אז הם מגובים באתרים אחרים, והמעבר ביניהם מתבצע באמצעות אותו route53, כי בגלל ה-TTL הקצר, המעבר מתרחש תוך מקסימום 2, 3, 5 דקות .

"אבל" שלישי: מה עדיין לא שמור? S3, נכון. כשהנחנו את הקבצים שאנו מאחסנים למשתמשים ב-s3, האמנו באמת ובתמים שזה חודר שריון ואין צורך לשמור שם שום דבר. אבל ההיסטוריה מראה שדברים קורים אחרת. באופן כללי, אמזון מתארת ​​את S3 כשירות בסיסי, מכיוון שאמזון עצמה משתמשת ב-S3 לאחסון תמונות מכונות, הגדרות, תמונות AMI, תמונות... ואם s3 קורס, כפי שקרה פעם אחת במהלך 7 השנים הללו, כל עוד אנו משתמשים bitrix24, הוא עוקב אחריו כמו מעריץ יש הרבה דברים שצצים - חוסר יכולת להפעיל מכונות וירטואליות, כשל ב-API וכו'.

ו-S3 יכול ליפול - זה קרה פעם אחת. לכן, הגענו לתכנית הבאה: לפני כמה שנים לא היו מתקני אחסון חפצים ציבוריים רציניים ברוסיה, ושקלנו את האופציה לעשות משהו משלנו... למרבה המזל, לא התחלנו לעשות זאת, כי היינו עושים זאת. חפרו במומחיות שאין לנו, וכנראה היו מתבלבלים. כעת ל-Mail.ru יש אחסון תואם s3, ל-Yandex יש את זה ולמספר ספקים אחרים יש את זה. בסופו של דבר הגענו לרעיון שאנחנו רוצים, ראשית, גיבוי, ושנית, יכולת לעבוד עם עותקים מקומיים. עבור האזור הרוסי במיוחד, אנו משתמשים בשירות Mail.ru Hotbox, אשר תואם API ל-s3. לא נזקקנו לשינויים גדולים בקוד בתוך האפליקציה, ועשינו את המנגנון הבא: ב-s3 יש טריגרים שמפעילים יצירה/מחיקה של אובייקטים, לאמזון יש שירות שנקרא Lambda - זו השקה ללא שרת של קוד שיבוצע בדיוק כאשר טריגרים מסוימים מופעלים.

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

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

אה, ואמזון ברחה...

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

אם החברה גלובלית ורוסיה היא פלח קטן מאוד עבורה, 3-5% - ובכן, כך או אחרת, אפשר להקריב אותם.

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

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

בסוף מרץ 2018, Roskomnadzor שלחה מכתב למפעילים הגדולים ביותר לפיו הם מתכננים לחסום כמה מיליוני כתובות IP של אמזון כדי לחסום את... השליח Zello. בזכות אותם ספקים - הם הדליפו בהצלחה את המכתב לכולם, והייתה הבנה שהקשר עם אמזון עלול להתפרק. זה היה יום שישי, רצנו בבהלה לעמיתינו מ-servers.ru, במילים: "חברים, אנחנו צריכים כמה שרתים שימוקמו לא ברוסיה, לא באמזון, אלא, למשל, איפשהו באמסטרדם," על מנת שנוכל לפחות איכשהו להתקין שם VPN ו-proxy משלנו עבור כמה נקודות קצה שאיננו יכולים להשפיע עליהן בשום אופן, למשל קצה של אותו s3 - אנחנו לא יכולים לנסות להעלות שירות חדש ולקבל שירות אחר ip, אנחנו אתה עדיין צריך להגיע לשם. תוך מספר ימים בלבד התקנו את השרתים הללו, הפעלנו אותם ובאופן כללי התכוננו לרגע תחילת החסימה. זה מוזר ש-RKN, מסתכל על המהומה והבהלה, אמר: "לא, אנחנו לא נחסום שום דבר עכשיו". (אבל זה בדיוק עד לרגע שבו החלה חסימה של טלגרם.) לאחר שהגדרנו את יכולות המעקף והבנו שהחסימה לא הוצגה, לעומת זאת, לא התחלנו לסדר את כל העניין. כן, ליתר ביטחון.

ובשנת 2019, אנחנו עדיין חיים בתנאים של חסימה. הסתכלתי אתמול בערב: כמיליון כתובות IP ממשיכות להיות חסומות. נכון, אמזון בוטלה כמעט לחלוטין חסימה, בשיאה הגיעה ל-20 מיליון כתובות... באופן כללי, המציאות היא שאולי אין קוהרנטיות, קוהרנטיות טובה. פִּתְאוֹם. יכול להיות שזה לא קיים מסיבות טכניות - שריפות, מחפרים, כל זה. או, כפי שראינו, לא לגמרי טכני. לכן, מישהו גדול וגדול, עם ASs משלו, יכול כנראה לנהל את זה בדרכים אחרות - חיבור ישיר ודברים אחרים נמצאים כבר ברמת l2. אבל בגרסה פשוטה, כמו שלנו או אפילו קטנה יותר, אתה יכול, למקרה הצורך, לקבל יתירות ברמה של שרתים שהועלו במקום אחר, מוגדר מראש vpn, proxy, עם יכולת להעביר אליהם במהירות את התצורה באותם מקטעים שהם קריטיים לקישוריות שלך. זה היה שימושי עבורנו יותר מפעם אחת, כאשר החלה החסימה של אמזון במקרה הגרוע, אפשרנו רק תעבורה של S3 דרכם, אבל בהדרגה כל זה נפתר.

איך להזמין... ספק שלם?

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

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

כמה מילים על אוטומציה

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

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

מסקנה

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

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

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

מקור: www.habr.com