מדוע יתירות משחקים נכשלת: סיכונים ופתרונות אמיתיים בתקן ISO 27001 A.8.14

מדוע "יתירות" לעתים קרובות נכשלת ראשונה בהפסקות משחקים?

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

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

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

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

אשליית היתירות במשחקים חיים

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

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

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

איך הפסקות באמת מתפשטות בפלטפורמות משחקים

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

שלב 1 - מופיעה תקלה ברמה נמוכה

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

שלב 2 - שירות ליבה מתחיל להתנדנד

שידוכים, לובי או שער ה-API שלך מתחילים להפסיק את פעולתם, לווסת או לנתק ניסיונות חיבור.

שלב 3 – גיבוי של שירותי תמיכה

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

שלב 4 - חוויית השחקן קורסת

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

שלב 5 – צפיפות סיכונים עסקיים ורגולטוריים

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

יתירות שמכסה רק את הקפיצה הראשונה (צמתים נוספים) אך לא את הזרימה מקצה לקצה אינה מספקת את השחקנים, השותפים או את תקן ISO 27001.

למידה מאירועים כמעט בלתי צפויים, לא רק מאסונות

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

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

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

הזמן הדגמה

מה בעצם דורש תקן ISO 27001 A.8.14 מפלטפורמות משחקים?

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

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

ברמה המעשית, A.8.14 מבקש ממך לעשות ארבעה דברים:

שלב 1 – הגדרת דרישות זמינות

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

שלב 2 – הסרה או צמצום נקודות כשל בודדות

זהה וצמצם תלות שבהן כישלון אחד יכול להפיל מסע שלם.

שלב 3 – הטמעת יתירות מתאימה

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

שלב 4 - בדיקה ותחזוקה של יתירות זו

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

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

מה נחשב כ"מתקן עיבוד מידע" במשחק?

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

עבור כותרים מקוונים ושירותים חיים, זה בדרך כלל כולל:

רכיבים בזמן אמת כגון שרתי משחקים, שרדים, ערימות "יתרון משחק" אזוריות, שידוכים, לוביים וממשקי API;
שירותי פלטפורמה הכוללים אימות, חשבונות, פרופילים, זכאויות, מלאי ולוחות הישגים;
ערימות מסחר עבור שערי תשלום, ספרי רכישות ובקרות הונאה;
שירותי נתונים ואנליטיקה המכסים אחסון מצבי שחקנים, טלמטריה, רישום, מדדים וצנרת נתונים;
תשתית תומכת כגון DNS, CDN, רשתות קצה, רשתות אנטי-DDoS, VPN וספקי זהויות;
משטחי בקרה הכוללים פלטפורמות תזמור, שירותי תצורה וסימון תכונות, וזרימות פריסה של CI/CD.

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

לא ניתן למשא ומתן לעומת חופש עיצובי

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

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

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

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

היכן סעיף A.8.14 נעצר ומתחילים בקרות אחרות

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

דרך פשוטה להפריד ביניהם היא:

A.8.13 (גיבוי מידע) ובקרות המשכיות עסקית עוסקות בערך שחזור שירות ונתונים לאחר אירועים חמורים או אסונות;
A.8.14 הוא בערך להישאר ער דרך כשלים "רגילים" - צמתים גוססים, קישורים שבורים, שירותים מתקלקלים, אפילו אזור זמינות שנעלם.

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

פערים אופייניים ב-A.8.14 בחברות משחקים

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

כאשר A.8.14 משתבש בביקורות עבור פלטפורמות משחקים או SaaS, הממצאים נראים לעתים קרובות כך:

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

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

ISMS.online מעניק לך יתרון של 81% מרגע הכניסה

ISO 27001 בקלות

עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.

התחל כאן

איך הופכים את A.8.14 ליעדי זמינות, RTO ו-RPO עבור משחקים?

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

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

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

דרג את עומסי העבודה של הגיימינג שלך

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

נקודת התחלה מעשית היא לסווג את השירותים שלך לרמות פשוטות המבוססות על השפעה ודחיפות. לדוגמה:

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

עבור כל רמה, הגדירו:

יעד זמן פעולה שמתאים לציפיות השחקן והשותף שלך;
RTO - כמה זמן ניתן לסבול שיבושים; ו
RPO – כמה אובדן נתונים או החזרה למצב קודם אתה יכול לקבל.

דוגמה קונקרטית עוזרת. אתם יכולים לסווג "שידוכים מדורגים באירופה" כדרגה 1 עם זמן פעולה של 99.95%, RTO של 10 דקות ו-RPO של התאמה אחת. משימת ETL של אנליטיקה אזורית עשויה להיות דרגה 3 עם RTO ארוך בהרבה וסבילות לעיבוד חוזר. כתיבת קביעה זו מאלצת דיונים ברורים בין לידים למוצר, לתפעול ולמסחר.

חיבור יעדים ל-SLO ותקציבי שגיאות

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

באולפנים ובמוציאים לאור רבים, צוותי SRE כבר מנהלים יעדי רמת שירות ותקציבי שגיאות עבור כותרים חיים. במקום ליצור שפה חדשה, פנו את יעדי ה-ISO שלכם ל-SLOs הקיימים:

אם רמת הזמינות (SLO) שלכם לשידוכים היא 99.95% זמן פעולה חודשי ושיעור ניתוק מקסימלי, זוהי דרישת הזמינות שלכם ברמה 1; ו-
תקציב השגיאות שלך מגדיר כמה זמן השבתה או ירידה בביצועים אתה יכול "לבזבז" לפני שתפר את הציפיות הפנימיות שלך ואת הציפיות של ה-ISO.

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

החלט היכן נדרשת ריבוי אזורים באמת

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

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

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

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

השתמש במודל ניקוד פשוט כדי להשוות עיצובים

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

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

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

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

אילו תבניות ארכיטקטורה יתירותיות מתאימות ביותר למשחקים בשידור חי?

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

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

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

אקטיבי-אקטיבי לעומת אקטיבי-פאסיבי עבור שירותי ליבה

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

למשחקיות בזמן אמת ולשידוכים:

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

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

גיבוי לגיבוי עקב הפעלה

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

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

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

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

שירותים תומכים כאזרחים מהשורה הראשונה

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

דוגמאות כוללות:

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

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

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

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

תזמור, תצורה וסודות

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

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

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

הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.

הזמן את ההדגמה שלך

כיצד ממפים ישירות עיצובי ענן מרובי אזורים ל-A.8.14?

אתם ממפים תכנוני ענן מרובי אזורים לתקן A.8.14 על ידי הסבר אילו כשלים כל עיצוב בנוי לסבול וכיצד זה תומך ביעדי הזמינות, ה-RTO וה-RPO שלכם. ספקי ענן מספקים לכם תכונות עוצמתיות, אך ISO 27001 אכפת יותר מהאופן שבו אתם משלבים אותם מאשר משמות שירותים, ובעלי עניין שאינם טכניים זקוקים לסיפור בשפה פשוטה שהם יכולים לעקוב אחריו.

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

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

מיפוי תכונות ענן כדי לשלוט ביעדים

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

התחילו ברישום תכונות הענן עליהן אתם מסתמכים לזמינות:

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

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

באיזו מבין התכונות הללו הוא משתמש;
אילו כשלים הם נועדו לסבול; ו
כיצד זה מתאמת ליעדי הזמינות, ה-RTO וה-RPO שלך.

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

חשבו על מצבי כשל, לא רק על תכונות

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

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

כשל בצומת או פוד בודד;
אזור זמינות מאבד חשמל או קישוריות רשת;
בעיה במישור הבקרה האזורי המונעת שינויי קנה מידה או תצורה; ו-
אירוע כלל-ספקי המשפיע על שירות מנוהל.

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

תכנון והוכחת גיבוי אזורי לגיבוי בעת כשל

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

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

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

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

יש לקחת בחשבון אילוצים משפטיים ורגולטוריים

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

חוקי אחסון נתונים, תקנות תשלום והנחיות לגבי שירותים חיוניים - כולם יכולים להשפיע על אופן עיצוב יתירות:

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

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

כיצד עליכם לתעדף יתירות של רשת, מחשוב, מסד נתונים ומצב?

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

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

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

התמקדו קודם כל במה שהשחקנים מרגישים

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

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

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

בדרך כלל תגלו ש:

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

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

טבלה: דוגמה לסדרי עדיפויות לפי שכבה

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

שִׁכבָה	השפעה של השחקן העיקרי	מטרות ראשונות אופייניות
רשת	השהיה, ניתוקים, הפסקות אזוריות	ספקים כפולים, ניתוב גמיש, בקרת DDoS
לחשב	קריסות, לובי ריק, פסקי זמן של API	N+1 צמתים, אשכולות מרובי AZ, קנה מידה אוטומטי
מצב ההפעלה	משחקים אבודים, החזרות לאחור, אירועים לא הוגנים	מאגרי מצב חיצוניים, נתיבי חיבור מחדש מהירים
מאגרי מידע	אובדן התקדמות, רכישות תקועות	עותקים משולבים של AZ, גיבויים, RPOs ברורים
אנליטיקה/BI	תובנה מאוחרת, כוונון איטי יותר	גיבויים, תוכניות התאוששות מאסון, הסכמי רמת שירות מדורגים

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

בניית יתירות בתוך יכולת התצפית והקיבולת

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

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

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

ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.

הזמן את ההדגמה שלך

כיצד מבצעים פיקוח וראיות על סעיף A.8.14 עבור ביקורות בחברת משחקים?

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

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

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

הבהרת תפקידים וזכויות קבלת החלטות

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

התחל בכך שתבהיר:

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

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

דעו אילו ראיות רואה חשבון מצפה

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

עבור A.8.14, ראיות נפוצות כוללות:

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

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

אל תשכחו יתירות של צד שלישי וספקים

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

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

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

הזמן הדגמה עם ISMS.online עוד היום

ISMS.online מספק לכם דרך מעשית להפוך את עבודת היתירות שלכם ב-A.8.14 למערכת קוהרנטית ומוכנה לביקורת, המכסה סיכונים, תכנון, בדיקות וראיות עבור פלטפורמות המשחקים שלכם. במקום להתעסק עם גיליונות אלקטרוניים, מסמכים וידע שבטי, אתם מאחדים הכל לסביבה אחת התומכת הן במהנדסים והן במבקרים, תוך מתן נראות ברורה יותר למנהלים לגבי החוסן.

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

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

איחוד ארכיטקטורה, סיכונים ובקרות במקום אחד

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

בתוך ISMS.online תוכלו:

למדל את היקף פלטפורמת המשחקים שלך - כותרים, שירותי פלטפורמה משותפים ואזורים - ולקשר אותם לבקרות של נספח א', כולל A.8.14;
לצרף דיאגרמות ארכיטקטורה, ספרי ריצה והגדרות SLO לסיכונים ובקרות בודדים, במקום להשאיר אותם בוויקי או במצגות שקופיות; ו
למפות כל שירות קריטי ליעדי הזמינות, ה-RTO וה-RPO שלו ולהראות כיצד דפוסי יתירות תומכים בערכים אלה.

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

הפיכת ראיות לרציפות, לא אד-הוק

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

במקום להתאמץ לפני כל ביקורת, תוכלו:

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

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

הפחתת חיכוכים עבור מהנדסים ויועצים

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

הפניה לארטיפקטים ממאגרי הקוד שלכם, מחסנית התצפיות וממערכות הכרטיסים מבלי להעתיק כל פרט;
לספק לצוותי SRE, פלטפורמה ואבטחה תצוגות מותאמות אישית כך שיראו רק את החלקים שהם צריכים לתחזק;
עבור יועצים ומנהלי מערכות מידע וירטואליים, לעשות שימוש חוזר בספרי משחק ומבנים של A.8.14 על פני מספר לקוחות משחקים ו-SaaS, תוך שמירה על הפרדה ברורה של ראיות והחלטות מכל לקוח.

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

הזמן הדגמה

שאלות נפוצות

כיצד עלינו לפרש את תקן ISO 27001 A.8.14 עבור פלטפורמת משחקים או שירות חי?

תקן ISO 27001 A.8.14 מצפה ממך להוכיח ששירותים קריטיים נשארים זמינים גם לאחר כשלים סבירים, באופן שתואם את מערכות ה-ISMS, רישום הסיכונים וגישת BC/DR שלכם.עבור פלטפורמת משחקים או שירות חי, פירוש הדבר הוא להראות שאתם יכולים לאבד תשתית, אזור או ספק מרכזי ועדיין להישאר במסגרת החוויה וזמן הפעולה שהבטחתם לשחקנים, למוציאים לאור ולשותפים.

מה המשמעות המעשית של זה עבור שירותים חיים?

עבור רוב האולפנים והפלטפורמות, קומת A.8.14 חזקה כוללת ארבע שכבות גלויות:

1. הבטחות עסקיות הפכו ליעדים טכניים

אתה מתחיל בכך שתהפוך את הציפיות המסחריות והציפיות של השחקנים ליעדים מוחשיים:

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

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

2. נקודות כשל בודדות שזוהו לאורך המחסנית

לאחר מכן אתה מחפש מצבי כשל שישבשו את היעדים הללו:

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

אם בקרה, ניתוב או זהות הם "מכה אחת", חישוב יתיר לבדו לא יעמוד בדרישות A.8.14.

3. יתירות שתוכננה כדי להתאים לסיכון אמיתי

משם אתם מתאימים את העיצוב להשפעה בפועל:

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

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

4. ראיות לכך שיתירות עובדת תחת לחץ

לבסוף, אתה מראה שהעיצוב שלך מתנהג כמתוכנן:

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

אם בקשת רישום סיכונים, הצהרת תחולה, תוכניות BC/DR ותצוגות ארכיטקטורה - כולם מספרים את אותה קומת יתירות, A.8.14 הופך להיות קל יותר להגנה בביקורות ובסקירות של מפרסמים. שימוש ב-ISMS.online כמקום בו נפגשים סיכונים, עיצובים, בדיקות ורישומי ספקים עוזר לך לשמור על קוהרנטיות של הקומה מבלי לבקש מהמהנדסים לתחזק סט נוסף של מסמכים.

כיצד עלינו לתעדף יתירות ברשת, במחשוב, במסד הנתונים ובמצב השחקן עבור משחקים בזמן אמת?

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

אילו שכבות בדרך כלל יש לטפל בהן תחילה?

סדר מעשי למשחקי PvP מהירים, טורנירים או אירועים חיים הוא:

1. רשת וקצה

שחקנים מבחינים בבעיות קישוריות כמעט לפני כל דבר אחר:

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

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

2. מחשוב ותזמור

היכולת שלך חייבת לעמוד גם בכישלונות יומיומיים:

קיבולת של N+1 על פני לפחות שני אזורי AZ עבור שרתי משחקים וממשקי API קריטיים.
ניתוב מבוסס-תקינות וניקוזים חינניים, כך שבעיות בצמתים נראות כמו תקלות קצרות, לא כמו כשלים המוניים בלובי.
בידוד לניסויים, כלי פעולות לייב ואנליטיקה כדי שלא יוכלו להרעיב בשקט את שירותי המשחקיות.

דפוסים אלה שומרים על יציבות ההתאמות כאשר התשתית מתנדנדת או שאתם דוחפים בניינים חדשים.

3. מצב סשן ומצב חולף

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

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

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

4. התקדמות מתמשכת, מלאי וארנקים

מערכות אלו יכולות לעיתים לסבול RTO מעט גבוה יותר, אך שלמותן אינה ניתנת למשא ומתן:

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

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

כיצד ניתן להתאים עיצוב ענן קיים רב-אזורי ל-A.8.14 מבלי לבנות אותו מחדש?

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

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

גישת מיפוי מובנית עובדת היטב ובדרך כלל מהירה יותר מעיצוב מחדש:

1. קיבוץ עומסי עבודה לפי השפעה עסקית

תאר מערכות בשפת התוצאות ולא רק בשמות השירותים, לדוגמה:

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

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

2. לכידת פרטי פריסה ותלות

עבור כל עומס עבודה, סכם:

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

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

3. הכרזה על כשלים נסבלים וסיכונים מקובלים

ציין במפורש אילו כישלונות אתה מתכוון לשרוד:

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

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

4. קשרו הכל בחזרה למערכת ה-ISMS ולקומת BC/DR שלכם

עבור כל עומס עבודה, קישור:

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

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

כיצד אנו מתכננים ובודקים יתירות כך שתתנהג כראוי במהלך השקות, עונות ואירועים גדולים?

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

מה כוללת גישת בדיקת יתירות יעילה ממוקדת אירועים?

לגישה מוצקה שלושה שלבים: הגדרת סיפורים, ביצוע בדיקות, לכידת למידה.

1. הגדירו סיפורי כישלון ברורים

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

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

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

2. תכננו בדיקות המשקפות את הסיכונים הללו

עבור כל קומה, תכננו תרגילים מבוקרים:

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

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

3. סגרו את המעגל לעיצוב, ל-runbooks ול-ISMS שלכם

לאחר כל תרגיל:

החליטו אם עמדתם ביעדי רמת השירות שלכם וב-RTO/RPO עבור תרחיש זה.
לכדו את הגורמים שהלכו טוב ואת אלו שלא, בכל הנוגע לעיצוב, קיבולת, בהירות תוכנית הפעולות והתקשורת.
צור ועקבו אחר שינויים בארכיטקטורה, תצורה, ניטור, ספרי ריצה או נתיבי הסלמה.
עדכון רישומי סיכון קשורים, מסמכי BC/DR והפניות לראיות A.8.14.

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

אילו תיעוד וראיות עלינו להכין עבור A.8.14 בביקורת של משחק או שירות חי?

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

אילו חפצים נוטים להיות בעלי החשיבות הרבה ביותר בפועל?

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

1. ארכיטקטורה ותצוגות יתירות

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

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

2. יעדי זמינות והתאוששות

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

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

3. המשכיות ונהלים תפעוליים

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

מסמכים אלה מראים שיתירות אינה רק דיאגרמה; ישנם אנשים ותהליכים המוכנים להשתמש בה.

4. רישומי למידה מבדיקות ואירועים

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

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

5. מידע על חוסן ספקים ושותפים

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

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

כיצד פלטפורמת ISMS כמו ISMS.online יכולה לעזור לכם לנהל את A.8.14 מבלי להעמיס על המהנדסים?

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

כיצד נראה ממשל A.8.14 בעל חיכוך נמוך, באופן יומיומי?

בסביבת משחקים או שירות חי, ISMS תומך יכול:

1. הגדירו את ההיקף בשפה שצוותים מבינים

אתה ממפה:

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

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

2. איחוד תכנון, סיכון והמשכיות

אתה משייך:

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

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

3. איסוף ראיות מבצעיות כחלק מהעבודה הרגילה

במקום לתזמן "משימות ביקורת" נפרדות, אתם מצרףים פלטים מ:

ניסויי כאוס, תרגילי כשל ותרגילי DR.
רישומי כוננות, פניות לאירועים וניתוחים לאחר אירוע.
ביקורות ספקים ובדיקות SLA.

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

4. ניהול חוסן הספקים באותה תצוגה

אתה שומר:

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

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

5. שימוש חוזר בראיות בין מסגרות ובעלי עניין

לאחר שדיאגרמה, בדיקה או סקירת ספק מקושרים ל-A.8.14 ב-ISMS.online, ניתן:

השתמש בו שוב לצורך הסמכת ISO 27001 וביקורות מעקב.
ענו מהר יותר על סעיפי חוסן בפלטפורמה ובבדיקת נאותות של המוציאים לאור.
תמיכה ב-NIS 2, DORA או צורכי ניהול בינה מלאכותית עתידיים מאותו בסיס חוסן.
תדרוך למנהלים ולדירקטוריונים לגבי פיטורים והמשכיות עם מינימום עבודה נוספת.

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

ISO 27001 A.8.14 – תכנון תשתית יתירה עבור פלטפורמות משחקים