אסטרטגיית תוויות יעילה עוזרת לארגן את המשאבים ב-Google Cloud ולעקוב אחריהם בכל הארגון. לפני שיוצרים תוויות, כדאי לקרוא את העקרונות הכלליים הבאים כדי לנהל את המשאבים באופן עקבי.
עקרונות כלליים לתוויות
תמיד להשתמש בתוויות
התוויות לא חובה, אבל הן עוזרות לארגן ולנהל את המשאבים ב-Google Cloud . אפשר להשתמש בתוויות כדי לעקוב אחרי עלויות ולזהות משאבים. כשמשתמשים בתוויות למשאבים, חשוב לפעול לפי הנחיות קפדניות בנושא תוויות. מומלץ ליצור מדיניות תיוג רשמית שתואמת לבעלי העניין העיקריים בארגון. בטבלה לדוגמה מוצגת מדיניות תיוג ברמת הארגון.
החלת תוויות באופן פרוגרמטי כדי לשמור על עקביות
אם אפשר, כדאי להחיל תוויות באופן פרוגרמטי. כלים כמו Script ו-Terraform מאפשרים לכם להפוך את תהליך יצירת התוויות לאוטומטי, ועוזרים לאכוף את מדיניות התיוג. הכלים האלה מבטיחים שהתוויות יוחלו באופן עקבי בכל המשאבים. השתמשו בפורמט תלוי אותיות רישיות (case-sensitive) לתוויות, והקפידו על עקביות בכל המשאבים.
סטנדרטיזציה של תוויות
השתמשו בקבוצה עקבית וסטנדרטית של תוויות לכל המשאבים. כך קל יותר לחפש, לסנן ולנהל את המשאבים. כדי לפשט את אסטרטגיית התוויות, כדאי לא להשתמש ביותר מ-10 תוויות. התאימו את התוויות לפי האופן שבו אתם רוצים לדווח על העלויות. מומלץ להשתמש בקבוצה סטנדרטית של מפתחות וערכים של תוויות שמתאימים לארגון שלכם. התוויות יכולות לכסות תרחישים עסקיים לדוגמה, כמו סביבה, סיווג נתונים, מרכז עלויות, צוות, רכיב, אפליקציה ותאימות.
חשוב לציין שכשמנהלים תוויות באופן מרכזי, חיוני להגדיר מדיניות תוויות אחידה ולעמוד בה. צוותי מוצר ומחלקות יכולים גם להוסיף תוויות בהתאמה אישית למשאבים כדי לשתף מידע ספציפי לצוות. מידע נוסף זמין במאמר החלת תוויות לא סטנדרטיות.
דוגמה להגדרה של קבוצת ערכים סטנדרטית לכל אחד מהמפתחות:
- סביבה:
prod/dev/staging - סיווג נתונים:
public/internal-only/confidential/restricted/na - מרכז עלות:
c23543 - קבוצה:
shopping-cart - רכיב:
frontend/cache/backend/database - אפליקציה:
shopping-cart-payments - תאימות:
pci-hipaa
הימנעו ממידע סודי
הגנה על פרטים אישיים מזהים (PII) היא קריטית לאבטחה. אל תאחסנו פרטים אישיים מזהים (PII) או מידע סודי אחר בתוויות.
הוספת תוויות לא סטנדרטיות
למרות שחשוב מאוד לפעול לפי מדיניות התוויות, אפשר להשתמש בתוויות גם כדי לשתף מידע שספציפי לצוות מוצר או למחלקה. במקרים כאלה, אם תאפשרו לבעלי המשאבים בצוותים השונים להוסיף תוויות לא סטנדרטיות לכל משאב, תוכלו לקבל יותר הקשר לגבי המשאב. כך קל יותר לחפש, לסנן ולשתף מידע שספציפי לצוותי המוצר או למחלקות האלה. לדוגמה, למשאב אחד יכולה להיות קבוצה של תוויות סטנדרטיות כמו environment:prod, data-classification:restricted, cost-center:c23543, team:shopping-cart, app:shopping-cart-payments, component:database, compliance: pci. בעלי המשאב יכולים להוסיף תוויות לא סטנדרטיות כמו version:5.0.1 ו-replica:primary כדי לציין את הגרסה של אשכול מסד הנתונים ואת סטטוס השכפול של הצומת.
חשבו על ההשלכות של השינוי
סביר להניח ששיטת התיוג שלכם תשתנה כשהדרישות העסקיות ישתנו. חשוב להיות מודעים להשלכות האפשריות של השינויים האלה. לדוגמה, הוספה של מרכזי עלות חדשים, מיקרו-שירותים או כלים חדשים יכולה להשפיע על אסטרטגיית התיוג.
סכמה ותבנית למתן שמות לתוויות
לכל ארגון יש דרך משלו לארגן את המשאבים. אתם יכולים להשתמש בתוויות כדי לסווג את המשאבים בהיררכיה בכמה דרכים, וכך לעזור למשתמשים לסנן את המשאבים שהם צריכים. כשאתם מגדירים את שיטת מתן השמות לתוויות, כדאי להביא בחשבון את הדברים הבאים:
- הסביבה, מרכז העלויות, הצוות, הרכיב, האפליקציות, התאימות והבעלות שמשויכים למשאב.
- סיווג של כל הנתונים שמאוחסנים במערכת. הדבר רלוונטי רק למערכות עם שמירת מצב.
- תוויות שצריך להחיל ברמת המשאב הספציפי, כמו Compute Engine, קטגוריה של Cloud Storage או ברמת הפרויקט.
- גמישות בשימוש בתוויות אופציונליות, לפי הצורך, כדי לספק מידע נוסף על המשאבים.
קידוד תוויות ותווים נתמכים
כל התווים של המפתחות והערכים חייבים להיות בקידוד UTF-8. אפשר להשתמש בתווים בינלאומיים. המפתחות צריכים להתחיל באות קטנה או בתו בינלאומי. המפתחות והערכים יכולים להכיל רק אותיות קטנות, ספרות, קווים תחתונים ומקפים.
דוגמה להגדרת תוויות
כדי להגדיר תוויות, צריך לזכור כמה מאפיינים.
| שדה | תיאור |
|---|---|
| מפתח התווית | מפתח התווית הוא מזהה ייחודי של תווית. הוא חייב להיות מחרוזת באורך של תו אחד לפחות ו-63 תווים לכל היותר. המפתח לא יכול להיות ריק. אתם יכולים להשתמש בקבוצה סטנדרטית של מפתחות תוויות שמתאימים לארגון שלכם, שמכסים תרחישים עסקיים כמו environment, data-classification, cost-center, team, component, application ו-compliance. |
| ערך התווית | ערך התווית הוא הנתונים שמשויכים למפתח. הוא יכול להיות מחרוזת, מספר או ערך בוליאני. מומלץ להגדיר קבוצת ערכים לכל מפתח תווית. כך הצוותים יכולים לבחור ולהקצות ערכים מתאימים לכל מפתח. לדוגמה, למפתח environment יכולים להיות ערכים כמו prod, staging, dev או tools. |
| מי צריך לטפל בזה | מזהים את המחלקה שצריכה את מפתח התווית כדי לסנן משאבים או ליצור דוחות. לדוגמה, מחלקת הכספים בארגון רוצה לדעת מה העלות של הפעלת סביבת prod. הם ישתמשו בצמד מפתח:ערך של התווית environment:prod. |
| המשאב שאליו תינתן גישה | לכל תווית, כדאי להגדיר משאב יעד Google Cloud שבו צריך להחיל את צמד המפתח:ערך של התווית. לדוגמה, מפתח התווית environment צריך להיות בכל משאב Google Cloud בסביבת הייצור של הארגון. |
| חריג | כדאי להגדיר אילו מפתחות של תוויות הם חובה בכל המשאבים ואילו מפתחות הם אופציונליים. בטבלה לדוגמה, יש כמה צמדים של תווית וkey:value שהם אופציונליים, כמו environment:tools. אפשר להתייחס למפתח התווית altostrat-team כאופציונלי כשהערך של התווית altostrat-environment מוגדר כ-tools. |
בדוגמה הבאה של תווית, altostrat הוא שם הארגון.
| מפתח התווית | ערך התווית | מי צריך לטפל בזה | המשאב שאליו תינתן גישה | חריג |
|---|---|---|---|---|
| altostrat-environment | prod, sb1, staging, dev, tools | כספים | Google Cloud משאבים | לא |
| altostrat-data-classification | ציבורי, פנימי בלבד, סודי, מוגבל, לא רלוונטי | אבטחה | קטגוריות, מסדי נתונים, דיסקים לאחסון מתמיד עם Compute Engine | לא |
| altostrat-cost-center | fin-us, mkt-eu, it-jp | כספים | Google Cloud משאבים | sandbox-folder |
| altostrat-team | עגלת הקניות | ראש צוות | Google Cloud משאבים | סביבות שאינן סביבות ייצור, רכיבים לא קריטיים |
| altostrat-component | חזית, מטמון, אפליקציה, מסד נתונים | כספים | Google Cloud משאבים | אופציונלי |
| altostrat-app | shopping-cart-payment | כספים | Google Cloud משאבים | לא. יש חריגה למשאבים עם כמה דיירים שאין להם מיפוי של 1:1 עם האפליקציה. |
| altostrat-compliance | pci, hipaa | אבטחה | Google Cloud משאבים | אופציונלי |