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

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

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

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

תכנון, פיתוח, בדיקה ואופטימיזציה

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

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

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

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

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

פריסה

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

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

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

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

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

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

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

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

אבטחה

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

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

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

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

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

ספריית לקוח

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

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

תמיכה

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

תיבת סימון

פעילות

❑

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

ניהול עלויות

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

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