גם בזמן אסון תמיד יש זמן לכוס תה
DRP (תוכנית התאוששות מאסון) היא דבר שבאופן אידיאלי לעולם לא יהיה צורך בו. אבל אם לפתע בונים הנודדים במהלך עונת ההזדווגות מכרסמים את הסיב האופטי של עמוד השדרה או שמנהל זוטר מפיל את הבסיס היצרני, אתה בהחלט רוצה להיות בטוח שתהיה לך תוכנית מוכנה מראש מה לעשות עם כל הביזיון הזה.
בזמן שלקוחות בבהלה מתחילים לנתק טלפונים לתמיכה טכנית, הג'וניור מחפש ציאניד, אתה פותח בחוכמה את המעטפה האדומה ומתחיל לעשות סדר בהכל.
בפוסט הזה אני רוצה לשתף בהמלצות איך לכתוב DRP ומה הוא צריך להכיל. נבחן גם את הדברים הבאים:
- בואו נלמד לחשוב כמו נבל.
- בואו נסתכל על היתרונות של כוס תה במהלך האפוקליפסה.
- בואו נחשוב על מבנה DRP נוח
- בוא נראה איך לבדוק את זה
לאילו חברות זה יכול להיות שימושי?
קשה מאוד למתוח את הקו כאשר מחלקת ה-IT מתחילה להזדקק לדברים כאלה. הייתי אומר שאתה בהחלט צריך DRP אם:
- עצירת שרת, אפליקציה או איבוד מסד נתונים כלשהו יובילו להפסדים משמעותיים עבור העסק כולו.
- יש לך מחלקת IT מן המניין. במובן של מחלקה בדמות יחידה מן המניין של החברה, עם תקציב משלה, ולא רק כמה עובדים עייפים מניחים רשת, מנקים וירוסים וממלאים מדפסות.
- יש לך תקציב ריאלי עבור יתירות חלקית לפחות במקרה חירום.
כאשר מחלקת ה-IT מתחננת במשך חודשים לפחות של כמה כונני HDD לשרת ישן לצורך גיבויים, לא סביר שתצליח לארגן מהלך מלא של שירות כושל כדי לשמור קיבולת. למרות שכאן התיעוד לא יהיה מיותר.
תיעוד חשוב
התחל בתיעוד. נניח שהשירות שלך פועל על סקריפט של Perl שנכתב לפני שלושה דורות על ידי מנהלים, אבל אף אחד לא יודע איך זה עובד. החוב הטכני המצטבר וחוסר התיעוד יירה בך בהכרח לא רק בברך, אלא גם בגפיים אחרות, זה יותר עניין של זמן.
לאחר שיש לך תיאור טוב של מרכיבי השירות, חפש נתונים סטטיסטיים של תאונות. הם יהיו כמעט בוודאות אופייניים לחלוטין. לדוגמה, הדיסק שלך מתמלא מעת לעת, מה שגורם לצומת להיכשל עד לניקוי ידני. או ששירות הלקוחות הופך לבלתי זמין בגלל העובדה שמישהו שוב שכח לחדש את האישור, ו-Let's Encrypt לא הצליח או לא רצה להגדיר.
מחשבות כמו חבלן
החלק הקשה ביותר הוא בחיזוי תאונות שמעולם לא קרו בעבר, אך שעלולות לקרוס את השירות שלך לחלוטין. כאן אני והקולגות שלי בדרך כלל משחקים נבלים. קח הרבה קפה ומשהו טעים והסתגר בחדר ישיבות. רק תוודא שבאותו משא ומתן אתה נועל את אותם מהנדסים שבעצמם פיתחו את שירות היעד או עובדים איתו באופן קבוע. ואז, על הלוח או על הנייר, אתה מתחיל לצייר את כל הזוועות האפשריות שעלולות לקרות לשירות שלך. אין צורך לרדת לפרטים לעובדת ניקיון ספציפית ולשלוף כבלים; די לשקול את התרחיש של "הפרת שלמות הרשת המקומית".
בדרך כלל, רוב מצבי החירום האופייניים מתחלקים לסוגים הבאים:
- כשל ברשת
- כשל בשירותי מערכת ההפעלה
- כשל באפליקציה
- כשל ברזל
- כשל וירטואליזציה
פשוט עברו על כל תצוגה וראו מה חל על השירות שלכם. לדוגמה, הדמון Nginx עשוי ליפול ולא לעלות - זהו כשל מצד מערכת ההפעלה. מצב נדיר שמניע את יישום האינטרנט שלך למצב שאינו פועל הוא כשל בתוכנה. במהלך התפתחות שלב זה, חשוב לברר את אבחון הבעיה. כיצד להבחין בין ממשק תלוי על וירטואליזציה לבין סיסקו שנפל וקריסת רשת, למשל. זה חשוב כדי למצוא במהירות את האחראים ולהתחיל למשוך את הזנב שלהם עד לתיקון התאונה.
לאחר שבעיות טיפוסיות נרשמות, אנו מוזגים עוד קפה ומתחילים לשקול את התרחישים המוזרים ביותר, כאשר כמה פרמטרים מתחילים לחרוג הרבה מעבר לנורמה. לדוגמה:
- מה קורה אם הזמן בצומת הפעיל זז דקה אחורה ביחס לאחרים באשכול?
- מה אם הזמן יתקדם, מה אם ב-10 שנים?
- מה קורה אם צומת אשכול מאבד לפתע את הרשת שלו במהלך הסנכרון?
- מה יקרה אם שני צמתים לא יחלקו מנהיגות בגלל בידוד זמני זה של זה ברשת?
בשלב זה, הגישה ההפוכה מועילה מאוד. אתה לוקח את החבר הכי עקשן בצוות עם דמיון חולה ונותן לו את המשימה לארגן חבלה בזמן הקצר ביותר שתפיל את השירות. אם קשה לאבחן, אפילו טוב יותר. לא תאמינו איזה רעיונות מוזרים ומגניבים מעלים מהנדסים אם תתנו להם רעיון לשבור משהו. ואם אתה מבטיח להם ספסל מבחן בשביל זה, זה בסדר גמור.
מה זה ה-DRP הזה שלך?!
אז הגדרת את מודל האיום שלך. הם גם לקחו בחשבון תושבים מקומיים שחתכו כבלי סיבים אופטיים בחיפוש אחר נחושת, ומכ"ם צבאי שמפיל קו ממסר רדיו אך ורק בימי שישי בשעה 16:46. עכשיו אנחנו צריכים להבין מה לעשות עם כל זה.
המשימה שלך היא לכתוב את המעטפות האדומות מאוד שייפתחו במקרה חירום. צפו מיד שכאשר (לא אם!) הכל יסתיים, רק המתמחה הכי לא מנוסה יהיה בקרבת מקום, שידיו ירעדו בעוצמה מאימה מהמתרחש. ראה כיצד מיושמים שלטי חירום במשרדי רפואה. למשל, מה לעשות במקרה של הלם אנפילקטי. הצוות הרפואי יודע בעל פה את כל הפרוטוקולים, אבל כשאדם בקרבת מקום מתחיל למות, לעתים קרובות כולם נאחזים בחוסר אונים בכל מה שנראה לעין. לשם כך, יש הוראות ברורות על הקיר עם פריטים כמו "פתח את האריזה של כזה וכזה" ו"לנהל כל כך הרבה יחידות של התרופה דרך הווריד".
קשה לחשוב במצב חירום! צריכות להיות הוראות פשוטות לניתוח חוט השדרה.
DRP טוב מורכב מכמה בלוקים פשוטים:
- למי להודיע על תחילתה של תאונה. זה חשוב על מנת להקביל את תהליך החיסול ככל האפשר.
- איך לאבחן נכון - בצע מעקב, חפש ב-systemctl status servicename וכן הלאה.
- כמה זמן אפשר להשקיע בכל שלב. אם אין לך זמן לתקן את זה עם הידיים שלך בזמן SLA, המכונה הוירטואלית נהרגת ומתגלגלת מהגיבוי של אתמול.
- איך לוודא שהתאונה הסתיימה.
זכור כי DRP מתחיל כאשר השירות נכשל לחלוטין ומסתיים כאשר השירות משוחזר, אפילו ביעילות מופחתת. פשוט אובדן הזמנה לא אמור להפעיל DRP. אתה יכול גם לכתוב כוס תה ל-DRP. ברצינות. על פי הסטטיסטיקה, תאונות רבות הופכות מבלתי נעימות לקטסטרופליות בשל העובדה שהצוות בבהלה ממהר לתקן משהו, בו זמנית הורג את הצומת החי היחיד עם נתונים או סוף סוף מסיים את האשכול. ככלל, 5 דקות עם כוס תה יתנו לכם קצת זמן להירגע ולנתח מה קורה.
אל תבלבלו בין DRP ודרכון מערכת! אל תעמיס אותו בנתונים מיותרים. פשוט אפשר להשתמש במהירות ובנוחות בהיפר-קישורים כדי לעבור לקטע הרצוי בתיעוד ולקרוא בפורמט מורחב על הסעיפים הדרושים בארכיטקטורת השירות. וב-DRP עצמו יש רק הוראות ישירות לאן ואיך להתחבר עם פקודות ספציפיות להעתק-הדבק.
איך לבדוק נכון
ודא שכל עובד אחראי מסוגל להשלים את כל הפריטים. ברגע המכריע ביותר, עשוי להתברר כי למהנדס אין זכויות גישה למערכת הנדרשת, אין סיסמאות לחשבון הנדרש, או שאין לו מושג מה "התחבר למסוף ניהול השירות באמצעות פרוקסי ב- משרד ראשי" פירושו. כל נקודה צריכה להיות פשוטה ביותר.
טעות - "עבור לווירטואליזציה והפעל מחדש את הצומת המת"
נכון - "התחבר דרך ממשק האינטרנט ל-virt.example.com, בקטע הצמתים, הפעל מחדש את הצומת שגורם לשגיאה."
הימנע מאי בהירות. זכור את המתמחה המפוחד.
הקפד לבדוק DRP. זו לא רק תוכנית להצגה – זה משהו שיאפשר לך וללקוחות שלך לצאת במהירות ממצב קריטי. עדיף לעשות זאת מספר פעמים:
- מומחה אחד וכמה מתאמנים עובדים על ספסל מבחן המדמה שירות אמיתי עד כמה שניתן. המומחה שובר את השירות בדרכים שונות ומאפשר לחניכים לשחזר אותו לפי ה-DRP. כל הבעיות, אי בהירות התיעוד והטעויות מתועדות. לאחר הכשרת המתאמנים, ה-DRP מורחב ומפושט בתחומים לא ברורים.
- בדיקה על שירות אמיתי. למעשה, לעולם לא תוכל ליצור עותק מושלם של שירות אמיתי. לכן, מספר פעמים בשנה יש צורך לכבות באופן שוטף חלק מהשרתים, לנתק חיבורים ולגרום לאסונות נוספים מרשימת האיומים על מנת להעריך את סדר השחזור. תקלה מתוכננת למשך 10 דקות באמצע הלילה עדיפה על תקלה פתאומית למשך מספר שעות בזמן עומס שיא עם אובדן נתונים.
- פתרון תקלות אמיתי. כן, זה גם חלק מהבדיקה. אם מתרחשת תאונה שלא הייתה ברשימת האיומים, יש צורך להשלים ולסיים את ה-DRP על סמך תוצאות חקירתו.
נקודות מפתח
- אם חרא יכול לקרות, זה לא רק יקרה, אלא זה יעשה זאת בתרחיש הכי קטסטרופלי שאפשר.
- ודא שיש לך משאבים להעברת עומס חירום.
- ודא שיש לך גיבויים, הם נוצרים באופן אוטומטי ונבדקים באופן קבוע עבור עקביות.
- חשבו דרך תרחישי איום טיפוסיים.
- תן למהנדסים הזדמנות להמציא אפשרויות לא סטנדרטיות למתן השירות.
- DRP צריכה להיות הוראה פשוטה ובוטה. כל האבחון המורכב מתבצע רק לאחר ששירות הלקוחות שוחזר. גם אם בקיבולת מילואים.
- ספק מספרי טלפון ואנשי קשר מפתח ב-DRP.
- בדוק את ההבנה של העובדים ב-DRP באופן קבוע.
- ארגון תאונות מתוכננות באתרי ייצור. מעמדים לא יכולים להחליף הכל.
מקור: www.habr.com