רשימת משימות להשקה של Spanner

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

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

עיצוב, פיתוח, בדיקה ואופטימיזציה

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

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

העברה (אופציונלי)

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

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

פריסה

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

תיבת סימון פעילות
❑  
מוודאים שהגדרת המופע של Spanner (אזורית, דו-אזורית או רב-אזורית) תואמת לזמינות של עומס העבודה של האפליקציה ולדרישות ההשהיה, וגם לשיקולים גיאוגרפיים. חישוב קיבולת המחשוב של היעד על סמך גדלי האחסון הצפויים, דפוסי התנועה ומגבלות השימוש המומלצות, כדי להבטיח קיבולת מספקת להפסקות חשמל אזוריות או אזוריות. כדי להתמודד עם שיאי תנועה, מומלץ להפעיל התאמה אוטומטית לעומס. אפשר להגדיר מגבלה עליונה לקיבולת החישוב כדי להגביל את העלויות. מידע נוסף זמין במאמר בנושא קיבולת מחשוב, צמתים ויחידות עיבוד.
❑  
אם אתם משתמשים בהגדרת מופע של שני אזורים או של כמה אזורים, בחרו אזור ראשי שממזער את זמן האחזור של פעולות כתיבה באפליקציה משירותים שנפרסו במיקומים שבהם זמן האחזור הוא הכי קריטי. בודקים את ההשלכות של אזורים שונים של שרתים ראשיים על זמן האחזור של הפעולה, ומבצעים שינויים כדי לשפר את ביצועי האפליקציה. כדאי לתכנן תרחישים של מעבר לגיבוי (failover) על ידי וידוא שטופולוגיית האפליקציה יכולה להסתגל לשינויים באזור הראשי במהלך הפסקות חשמל אזוריות. מידע נוסף מופיע במאמר שינוי האזור הראשי של מסד נתונים.
❑  
הגדרת תגים ותוויות בצורה מתאימה כדי להשיג שקיפות תפעולית ולעקוב אחרי משאבים ב-Google Cloud. משתמשים בתגים כדי לקבץ מופעים לפי סביבה או סוג עומס עבודה. שימוש בתוויות למטא-נתונים שעוזרים בניתוח עלויות ובניהול הרשאות. מידע נוסף זמין במאמר בנושא שליטה בגישה וארגון של מופעים באמצעות תגים.
❑  
כדאי להעריך אם יש צורך בהפעלה במצב ביניים (warm up) של Spanner, במיוחד בשירותים שצפוי בהם נפח תנועה גבוה ופתאומי עם ההשקה. בדיקת זמן האחזור בעומסים ראשוניים גבוהים עשויה להראות שיש צורך בחימום לפני ההשקה כדי להבטיח ביצועים אופטימליים. אם נדרש חימום מוקדם, צריך ליצור עומס מלאכותי. מידע נוסף זמין במאמר בנושא חימום מסד הנתונים לפני הפעלת האפליקציה.
❑  
לפני הפריסה, כדאי לעיין במגבלות ובמכסות של Spanner. במקרה הצורך, כדאי לבקש הגדלות של המכסות במסוף Google Cloud כדי למנוע מגבלות בתקופות השיא. חשוב לשים לב למגבלות קשיחות (לדוגמה, מספר הטבלאות המקסימלי לכל מסד נתונים) כדי למנוע בעיות אחרי הפריסה. מידע נוסף זמין במאמר מכסות ומגבלות.
❑  
משתמשים בכלי אוטומציה כמו Terraform כדי להקצות ולנהל את מופעי Spanner, וכך לוודא שההגדרות יעילות ונטולות שגיאות. לניהול סכימות, מומלץ להשתמש בכלים כמו Liquibase כדי למנוע מחיקה לא מכוונת של סכימות במהלך עדכונים. מידע נוסף מופיע במאמר שימוש ב-Terraform עם Spanner.

תוכנית התאוששות מאסון (DR)

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

תיבת סימון פעילות
❑  
הגדרת אסטרטגיה מקיפה להתאוששות מאסון (DR) עבור Spanner, שכוללת הגנה על נתונים, יעדי התאוששות ותרחישי כשל. קובעים יעדים ברורים לזמן ההתאוששות (RTO) ויעדים ברורים לנקודת ההתאוששות (RPO) בהתאם לדרישות של המשכיות עסקית. מציינים את תדירות הגיבוי, את מדיניות השמירה ומשתמשים בשחזור לנקודת זמן מסוימת (PITR) כדי לצמצם את אובדן הנתונים במקרה של כשלים. כדאי לעיין בסקירה הכללית של תוכנית התאוששות מאסון (DR) כדי לזהות את הכלים והטכניקות הנכונים שיבטיחו שהאפליקציה תעמוד בדרישות הזמינות, המהימנות והאבטחה. מידע נוסף זמין במסמך המידע פתרונות להגנה על נתונים ולשחזור נתונים ב-Spanner.
❑  
יצירת תיעוד מפורט של נהלי הגיבוי והשחזור, כולל מדריכים מפורטים לתרחישי שחזור שונים. חשוב לבדוק את התהליכים האלה באופן קבוע כדי לוודא שהם מוכנים לפעולה, וכדי לאמת את הדרישות של RTO ו-RPO. הבדיקות צריכות לדמות תרחישים ותנאי כשל מהעולם האמיתי כדי לזהות פערים ולשפר את תהליך השחזור. מידע נוסף מופיע במאמר סקירה כללית על שחזור.
❑  
מטמיעים תזמוני גיבוי אוטומטיים כדי להבטיח הגנה עקבית ומהימנה על הנתונים. הגדרת התדירות וההגדרות של שמירת הנתונים בהתאם לצרכים העסקיים ולחובות הרגולטוריות. אפשר להשתמש בתכונות של תזמון גיבוי ב-Spanner כדי להפוך את היצירה, הניהול והמעקב של גיבויים לאוטומטיים. מידע נוסף זמין במאמר בנושא יצירה וניהול של לוחות זמנים לגיבוי.
❑  
כדי למזער את ההשפעות של זמן האחזור במקרה של הפסקת שירות, צריך להתאים את נהלי המעבר לגיבוי (failover) לטופולוגיית ההגדרות של מופע האפליקציה. בודקים תרחישים של התאוששות מאסון כדי לוודא שהאפליקציה יכולה לפעול ביעילות תפעולית כשמעבירים את האזור הראשי לאזור יתירות כשל. מידע נוסף זמין במאמר שינוי האזור הראשי של מסד נתונים.

אופטימיזציה של שאילתות וניהול נתונים סטטיסטיים

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

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

אבטחה

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

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

רישום ביומן ומעקב

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

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

ניתוב היומנים האלה למאגר יומנים שהוגדר על ידי המשתמש מאפשר לכם לבצע אופטימיזציה של עלויות השמירה של היומנים (לא מחויבים על 30 הימים הראשונים) ולשלוט בגישה ליומנים ברמת פירוט גבוהה באמצעות תצוגות יומנים.
❑  
אוספים מדדים בצד הלקוח על ידי הוספת אינסטרומנטציה ללוגיקה של האפליקציה באמצעות OpenTelemetry כדי להפיץ מעקב וניראות. מגדירים מכשור OpenTelemetry כדי לתעד עקבות ומדדים מ-Spanner, וכך מקבלים תצוגה מקיפה של ביצועי האפליקציה והאינטראקציות עם מסד הנתונים. מידע נוסף זמין במאמר בנושא איסוף מדדים מותאמים אישית מצד הלקוח באמצעות OpenTelemetry.
❑  
יצירה והגדרה של מדדי מעקב כדי להציג חזותית את ביצועי השאילתות, זמן האחזור, השימוש במעבד ונפח האחסון הנדרש. אפשר להשתמש במדדים האלה למעקב בזמן אמת ולניתוח היסטורי של ביצועי מסד הנתונים. מידע נוסף זמין במאמר מעקב אחרי מופעים באמצעות Cloud Monitoring.
❑  
הגדרת התראות מעקב שמבוססות על ערכי סף למדדים קריטיים כדי לזהות בעיות ולטפל בהן באופן יזום. הגדרת התראות לגבי תנאים כמו זמן אחזור גבוה של שאילתות, זמינות נמוכה של נפח אחסון או עליות חדות לא צפויות בתנועה. כדאי לשלב את ההתראות האלה עם כלים לתגובה לאירועים כדי לפעול במהירות. מידע נוסף זמין במאמר יצירת התראות למדדים של Spanner.

ספריית לקוח

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

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

תמיכה

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

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

ניהול עלויות

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

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