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