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