מדריך

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

→החלת מגבלות של Organization Policy (לדוגמה, `constraints/gcp.resourceLocations`, `constraints/iam.disableServiceAccountKeyCreation`) ברמת הארגון או התיקייה.

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

מקור↗

בניית ארגון רב-מחלקתי ורב-סביבתי לניהול יעיל של מדיניות ובקרת גישה.

→תכנון היררכיית תיקיות, בדרך כלל: Organization > Business Unit (תיקייה) > Environment (לדוגמה, prod, staging) (תיקיית משנה) > Projects.

למה: מבנה זה מאפשר ירושה מפורטת של מדיניות. מדיניות נפוצה נקבעת ברמת ה-BU, בעוד שמדיניות ספציפית לסביבה (לדוגמה, מגבילה יותר עבור `prod`) נקבעת ברמת הסביבה.

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

→יצירת sink יומן מצטבר ברמת הארגון. ניתוב יומנים למספר יעדים בהתאם לצורך: BigQuery לניתוח, Cloud Storage (Coldline/Archive) לארכיון ארוך טווח/בעלות נמוכה, ו-Pub/Sub לסטרימינג בזמן אמת ל-SIEM.

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

מקור↗

מניעת דליפת נתונים משירותים מנוהלים כמו BigQuery ו-Cloud Storage, והתרה גישה רק מרשתות או זהויות מורשות.

→יצירת היקף VPC Service Controls סביב פרויקטים המכילים נתונים רגישים. הגדרת רמות גישה כדי לאפשר גישה מטווחים ספציפיים של IP (רשת ארגונית) או מכשירים.

למה: VPC Service Controls יוצר היקף וירטואלי סביב שירותים מבוססי API, ומפחית סיכונים הנובעים מאישורי גישה גנובים או מדיניות IAM שהוגדרה באופן שגוי על ידי חסימת גישה מחוץ להיקף.

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

→יישום מדיניות IAM Deny ברמת הארגון או התיקייה. מדיניות זו שוללת הרשאות באופן מפורש, והיא תמיד גוברת על כל מדיניות `allow`.

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

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

→שימוש ב-Infrastructure as Code (לדוגמה, Terraform עם Cloud Build) ליצירת "Landing Zone". אוטומציה של יצירת פרויקטים ותצורה באמצעות Pipeline.

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

אפשרות למערכות חיצוניות (כמו GitHub Actions או CI/CD מקומי) לגשת למשאבי GCP ללא שימוש במפתחות חשבונות שירות ארוכי טווח.

→הגדרת Workload Identity Federation. יצירת ספק שסומך על IdP חיצוני (לדוגמה, GitHub OIDC) ומיפוי זהויות חיצוניות לחשבון שירות של GCP. שימוש בתנאי תכונות להגבלת גישה למאגרים/ענפים ספציפיים.

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

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

→יישום Shared VPC. יצירת "פרויקט מארח" עבור משאבי רשת ו"פרויקטים של שירות" עבור עומסי עבודה של יישומים. הענקת `roles/compute.networkUser` לזהויות פרויקט שירות.

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

ניהול תצורות ואפליקציות של אשכולות GKE באופן הצהרתי ממאגר Git.

→שימוש במאגר Git כמקור האמת היחיד עבור manifests. התקנת Config Sync באשכולות GKE כדי ליישב באופן רציף את מצב האשכול עם התצורה במאגר.

למה: GitOps מספק דרך ניתנת לביקורת, מבוקרת גרסאות ואוטומטית לניהול Kubernetes. הוא מפריד בין CI (בניית חפצים) לבין CD (סנכרון מצב).

מניעת פריסה של תמונות קונטיינר עם חולשות קריטיות.

→הפעלת סריקת פגיעויות אוטומטית ב-Artifact Registry. ב-Pipeline של Cloud Build, הוספת שלב המשתמש ב-Container Analysis API כדי לבדוק פגיעויות ולגרום לכישלון הבנייה אם נמצאו בעיות קריטיות.

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

אכיפה בזמן ריצה שרק תמונות קונטיינר מהימנות וחתימות יכולות להיפרס ל-GKE או Cloud Run.

→יישום Binary Authorization. יצירת attestors (לדוגמה, עבור מעבר סריקות פגיעות, אישור QA). הגדרת ה-CI Pipeline ליצירת אישורים. אכיפת מדיניות ב-GKE/Cloud Run הדורשת אישורים ספציפיים לפריסה.

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

מקור↗

גישה למידע רגיש כמו מפתחות API או סיסמאות במהלך הפעלת Cloud Build מבלי לחשוף אותם ביומנים או בקוד המקור.

→אחסון סודות ב-Secret Manager. ב-`cloudbuild.yaml`, שימוש בשדה `availableSecrets` כדי לטעון את הסוד כמשתנה סביבה או קובץ.

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

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

→שימוש ב-Cloud Build ליצירת אישורי provenance תואמי SLSA. אחסון אישורים אלה ב-Artifact Registry לצד התמונות. שימוש ב-Binary Authorization לאימות ה-provenance לפני הפריסה.

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

הפעלת משימות CI/CD שצריכות לגשת למשאבים ב-VPC פרטי, כמו Artifact Registry פרטי או מסד נתונים Cloud SQL.

→יצירת Cloud Build Private Pool והגדרת VPC peering בין רשת ה-pool ל-VPC היעד שלך. הגדרת בנייה להפעלה ב-pool זה.

למה: Private pools מספקים בידוד רשתי ומאפשרים לבנייה לגשת באופן מאובטח למשאבים ברשת פרטית מבלי לחשוף אותם לאינטרנט.

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

→הגדרת מדיניות ניקוי של Artifact Registry. שימוש במדיניות `keep` עבור תגים כמו `production` ו-`latest`. שימוש במדיניות `delete` המבוססת על גיל, דפוסי תגים וספירת גרסאות עבור תמונות אחרות.

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

אוטומציה של פריסה רב-שלבית מפיתוח ל-staging לייצור עם אישורים ואסטרטגיות שונות לכל סביבה.

→הגדרת Pipeline יחיד של Cloud Deploy עם התקדמות של יעדים (dev, staging, prod). הגדרת `requireApproval: true` ליעד הייצור וציון אסטרטגיות פריסה שונות (לדוגמה, canary) לכל יעד.

למה: Cloud Deploy מספק שירות אספקה רציפה מנוהל וניתן לביקורת. הוא מפשט דפוסי אספקה פרוגרסיביים כמו canary ו-blue-green עם אישורים ושחזורים משולבים.

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

→הגדרת Service Level Indicators (SLIs) המבוססים על חששות המשתמש: זמינות (אחוז בקשות מוצלחות), זמן אחזור (אחוז בקשות מהירות יותר מסף מסוים), ונכונות/עדכניות (אחוז נתונים שעובדו נכון או עדכניים).

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

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

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

למה: התראות קצב שריפה הן מנבאות. הן מתריעות על *קצב* הכישלון, מה שמצביע על בעיה אמיתית, ולא על בקשה אחת שנכשלה, מפחיתות עייפות התראות ומתמקדות במה שחשוב.

מקור↗

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

→הגדרת שירותים באמצעות OpenTelemetry SDKs וייצוא traces ל-Cloud Trace. הבטחת הפצת trace context על פני קריאות שירות (כולל דרך תורי הודעות כמו Pub/Sub).

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

הבטחת שיומני יישומים ב-GKE מנותחים כהלכה, ניתנים לחיפוש, ובעלי רמת חומרה מתאימה ב-Cloud Logging.

→הגדרת יישומים לכתוב יומנים ל-`stdout`/`stderr` בפורמט JSON. הכללת שדה `severity` התואם את הערכים הצפויים של Google Cloud (לדוגמה, "INFO", "ERROR").

למה: סוכן הרישום ברירת המחדל של GKE אוסף ומנתח אוטומטית יומני JSON מ-stdout, והופך אותם למבניים וניתנים לשאילתה ב-Cloud Logging ללא צורך ב-sidecar או בסוכן מותאם אישית.

מעקב, הדמיה והתראה על עמידה ב-SLO וצריכת תקציב שגיאות עבור שירות.

→שימוש בתכונת Service Monitoring של Cloud Monitoring. הגדרת שירות, יצירת SLIs (לדוגמה, זמינות ממאזן עומסים), הגדרת יעדי SLO, והגדרת מדיניות התראות קצב שריפה.

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

מציאת שורש הבעיה במהירות על ידי קישור מדדים, traces ויומנים.

→הבטחת הכללת מזהי trace ביומנים מובנים. שימוש בתכונות של Cloud Monitoring כמו trace exemplars בתרשימי מדדים כדי לקפוץ ל-trace ספציפי במהלך אנומליה של מדד, ולאחר מכן מאותו trace, לקפוץ ליומנים המתואמים.

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

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

→ב-Cloud Logging, יצירת מדד מבוסס יומן. הגדרת מסנן כדי להתאים לרשומות היומן הרלוונטיות והגדרת סוג המדד (מונה או התפלגות). שימוש במדד מותאם אישית זה בלוחות מחוונים ומדיניות התראות.

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

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

→הפעלת Cloud SQL Insights ו-Query Insights על מופע Cloud SQL. שימוש בלוח המחוונים לזיהוי שאילתות בעלות עומס גבוה, ניתוח תוכניות ביצוע, וצפייה במגמות ביצועים.

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

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

→שימוש ב-uptime checks של Cloud Monitoring לבדיקות HTTP/TCP פשוטות. עבור זרימות משתמש מרובות שלבים (לדוגמה, התחברות, הוספה לעגלה, תשלום), שימוש ב-Synthetic Monitors, המריצים סקריפטים מותאמים אישית (לדוגמה, Puppeteer) בסביבה מנוהלת.

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

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

→הגדרת Service Level Objective (SLO) (לדוגמה, 99.9% זמינות). ה-0.1% הנותרים הם תקציב השגיאות. אם התקציב כמעט שלם, שחרור תכונות. אם התקציב התרוקן, עצירת שחרור תכונות והתמקדות בשיפורי אמינות.

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

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

→ביצוע postmortems ללא האשמה לאחר אירועים. התמקדות בחקירה בגורמים מערכתיים, פערי תהליכים וכשלים בכלים, ולא בהטלת אשמה על יחידים. התוצאה צריכה להיות רשימה של פריטי שיפור מעשיים.

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

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

→יישום Incident Command System (ICS) עם תפקידים מוגדרים בבירור: מפקד אירוע (תיאום כללי), מנהל תפעול (חקירה/תיקון טכני), ומנהל תקשורת (עדכוני בעלי עניין).

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

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

→מעקב אחר ארבעת מדדי DORA המרכזיים: תדירות פריסה (כמה פעמים), זמן אספקה לשינויים (כמה מהר מ-commit לפריסה), שיעור כשל שינוי (איזה אחוז מהפריסות גורם לכשל), וזמן לשחזור שירות (MTTR).

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

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

→זיהוי וכימות ה-toil הגוזל זמן רב ביותר. תיעדוף ואוטומציה של משימות אלו (לדוגמה, הטמעת autoscaling במקום scaling ידני, auto-remediation להתראות נפוצות). הגבלת toil לפחות מ-50% מזמן המהנדס.

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

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

→יישום אסטרטגיית תיוג/תוויות עקבית. שימוש בתוויות אלו לסינון בדוחות חיוב של Cloud Billing. עבור GKE, הפעלת הקצאת עלויות GKE כדי לפרק עלויות לפי namespace או workload.

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

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

→התאמת עומס העבודה למודל התמחור. שימוש ב-Committed Use Discounts (CUDs) לעומסי עבודה יציבים, 24/7. שימוש ב-Spot VMs לעבודות עמידות לכשלים וניתנות להפרעה (לדוגמה, עיבוד אצווה). תזמון סביבות פיתוח/בדיקה לכיבוי מחוץ לשעות העבודה.

למה: גישה אחידה לתמחור מחשוב אינה יעילה. שימוש בכלי הנכון לעבודה יכול להוביל לחיסכון משמעותי (>70%) מבלי להשפיע על הביצועים.

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

→פריסת Vertical Pod Autoscaler (VPA) במצב `recommendation`. ניתוח ההצעות שלו להתאמת `requests` משאבי ה-pod. לאחר השגה ביטחון, מעבר למצב `auto` עבור התאמת גודל רציפה.

למה: הקצאת יתר של pods מבזבזת כסף, בעוד שהקצאת חסר גורמת לבעיות ביצועים (throttling, OOMKilled). VPA משתמש בנתוני שימוש בפועל כדי לתת המלצות מדויקות לגודל, ומשפר הן את היעילות והן את היציבות.

הפחתת זמן האחזור הנגרם על ידי cold starts עבור שירות Cloud Run.

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

למה: `min-instances` היא הדרך הישירה ביותר להפחתת cold starts, אך יש לה עלות. שילובו עם אופטימיזציה של קונטיינרים וקוד מספק גישה מאוזנת לביצועים ועלות.

אופטימיזציה של עלויות עבור עומס עבודה של BigQuery Analytics בקנה מידה גדול עם דפוסי שאילתות משתנים.

→מעבר מתמחור on-demand ל-BigQuery Editions (slots). רכישת התחייבות slots בסיסית לעומס צפוי והפעלת autoscaling עבור שיאים. בנוסף, אופטימיזציה של שאילתות על ידי שימוש בטבלאות מחולקות/מקובצות והימנעות מ-`SELECT *`.

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

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

→שימוש ב-Cloud CDN לשמירת תוכן סטטי במטמון בקצה הרשת, קרוב יותר למשתמשים. עבור תעבורה דינמית, בחירת Network Service Tier המתאים (Premium לביצועים, Standard לחיסכון בעלויות). עיבוד נתונים אזורי כדי למזער תעבורה בין-אזורית.

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