הסט הוצאות IT מרכישות חומרה גדולות מראש למודל תשלום לפי שימוש.
השתמש בשירותי ענן כדי להמיר הוצאות הון (CapEx) להוצאות תפעוליות (OpEx).
למה: הענן מספק גמישות פיננסית, מוריד חסמי כניסה, ומיישר עלויות ישירות עם השימוש, ובכך מונע הקצאת יתר.
Google Cloud Digital Leader
נבדק לאחרונה: מאי 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן CDL בודק. קראו מלמעלה למטה, או דלגו לסעיף.
הסט הוצאות IT מרכישות חומרה גדולות מראש למודל תשלום לפי שימוש.
השתמש בשירותי ענן כדי להמיר הוצאות הון (CapEx) להוצאות תפעוליות (OpEx).
למה: הענן מספק גמישות פיננסית, מוריד חסמי כניסה, ומיישר עלויות ישירות עם השימוש, ובכך מונע הקצאת יתר.
הבהר את בעלות האבטחה בין ספק הענן ללקוח.
Google מאבטחת את תשתית הענן (חומרה, רשת). הלקוח מאבטח את מה שהוא שם בענן (נתונים, IAM, קוד יישום).
למה: הלקוח תמיד אחראי לנתונים שלו ולבקרות הגישה, ללא קשר למודל השירות (IaaS, PaaS, SaaS).
אמץ ענן תוך שמירה על גמישות להשתמש בפלטפורמות או טכנולוגיות אחרות.
תעדף שירותים הבנויים על טכנולוגיות קוד פתוח כמו Kubernetes (GKE), TensorFlow ו-Apache Beam (Dataflow).
למה: תקני קוד פתוח מגבירים את ניידות עומסי העבודה, מונעים נעילה ל-APIs קנייניים ומאפשרים אסטרטגיות ענן היברידי/רב-ענני.
הפחת את טביעת הרגל הפחמנית של פעולות IT כדי לעמוד ביעדי קיימות תאגידיים.
ארח עומסי עבודה ב-Google Cloud, תוך מינוף התאמת האנרגיה המתחדשת ב-100% שלו. השתמש בכלי Carbon Footprint כדי לנטר ולבחור אזורים עם פליטת פחמן נמוכה.
למה: Google Cloud מפעילה אחד מהעננים הנקיים ביותר, ומאפשרת לעסקים לרשת את יתרונות הקיימות שלה.
שלב תשתית מקומית עם שירותי ענן עקב רגולציה או ריבונות נתונים.
השתמש ב-Anthos עבור פלטפורמה מבוססת Kubernetes עקבית ברחבי המערכות המקומיות וב-Google Cloud.
למה: Anthos מספקת מישור ניהול ובקרה אחיד ליישומים, ללא קשר למקום שבו הם פועלים, ומפשטת פעולות היברידיות.
נתח פטה-בייטים של נתונים מובנים עם שאילתות SQL מורכבות ללא צורך בניהול תשתית.
השתמש ב-BigQuery.
למה: BigQuery הוא מחסן נתונים ללא שרתים, מנוהל באופן מלא, המותאם לשאילתות אנליטיות בקנה מידה גדול.
צריך מסד נתונים יחסי מבוזר גלובלית עם עקביות חזקה ויכולת התרחבות אופקית.
השתמש ב-Cloud Spanner.
למה: Spanner משלבת סמנטיקה יחסית (ACID, SQL) עם יכולת התרחבות לא יחסית, אידיאלית ליישומים גלובליים קריטיים כמו פיננסים.
אחסן ואחזר כמויות גדולות של נתוני מפתח-ערך פשוטים (לדוגמה, IoT, פרופילי משתמשים) עם זמן אחזור של מילי-שניות בודדות.
השתמש ב-Cloud Bigtable.
למה: Bigtable הוא מסד נתונים NoSQL מסוג Wide-Column המותאם לעומסי עבודה תפעוליים ואנליטיים בעלי תפוקה גבוהה וזמן אחזור נמוך.
בנה אפליקציית מובייל או ווב הדורשת סנכרון נתונים בזמן אמת ופונקציונליות לא מקוונת.
השתמש ב-Firestore.
למה: Firestore הוא מסד נתונים מסוג NoSQL Document עם סנכרון מובנה בזמן אמת ושמירה לא מקוונת, שתוכנן לפיתוח יישומים מודרניים.
העבר מסד נתונים מסורתי מקומי של MySQL, PostgreSQL או SQL Server לשירות ענן מנוהל עם שינויים מינימליים.
השתמש ב-Cloud SQL.
למה: Cloud SQL הוא שירות מסדי נתונים יחסיים מנוהל באופן מלא המספק תאימות למנועי מסדי נתונים סטנדרטיים, וממכן גיבויים, תיקונים ושכפול.
קלוט ועיבד זרם נתונים בנפח גבוה ובזמן אמת (לדוגמה, IoT, clickstreams) לצורך ניתוח מיידי.
השתמש ב-Pub/Sub לקליטה, ב-Dataflow לעיבוד זרם נתונים וב-BigQuery לניתוח.
למה: זוהי התבנית השרתית הקנונית לניתוח בזמן אמת וניתן להרחבה ב-Google Cloud.
אחסן נתונים עם דפוסי גישה משתנים (תדירים, לא תדירים, ארכיון) בצורה חסכונית.
השתמש ב-Cloud Storage עם מדיניות מחזור חיים כדי להעביר נתונים אוטומטית בין סוגי Standard, Nearline, Coldline ו-Archive.
למה: מדיניות מחזור חיים ממכנת את דירוג הנתונים, ומתאימה את עלות האחסון לתדירות הגישה ללא התערבות ידנית.
אחסן כמויות עצומות של נתונים גולמיים, לא מובנים וחצי מובנים לעיבוד וניתוח עתידיים.
השתמש ב-Cloud Storage כמאגר המרכזי (אגם נתונים).
למה: Cloud Storage מציע אחסון אובייקטים עמיד ובעלות נמוכה, המשתלב עם כל שירותי עיבוד הנתונים של GCP (BigQuery, Dataproc, Dataflow).
הפעל עבודות עיבוד נתונים בקנה מידה גדול באמצעות מסגרות קוד פתוח כמו Apache Spark ו-Hadoop.
השתמש ב-Dataproc.
למה: Dataproc מספק אשכולות Spark ו-Hadoop מנוהלים באופן מלא, ממכן יצירה וניהול אשכולות, ומאפשר לצוותים להתמקד בעבודתם.
הוסף יכולות AI כמו זיהוי תמונה, ניתוח סנטימנטים או תמלול דיבור לאפליקציה ללא מומחיות בלמידת מכונה (ML).
השתמש ב-APIs מאומנים מראש: Vision AI, Natural Language AI, Speech-to-Text API, Translation API.
למה: ממשקי API אלו מספקים את המודלים המתקדמים ביותר של Google למקרים נפוצים, ודורשים רק קריאת REST API פשוטה.
אמן מודל ML מותאם אישית באמצעות נתונים מתויגים משלך (לדוגמה, תמונות מוצר, טקסט של לקוחות) אך ללא ניסיון בקידוד ML.
השתמש ב-AutoML בתוך Vertex AI.
למה: AutoML ממכן את תהליך בניית המודלים, ומאפשר לצוותים ליצור מודלים מותאמים אישית באיכות גבוהה באמצעות ממשק גרפי פשוט.
צוות מדעי הנתונים זקוק לפלטפורמה מאוחדת לבנייה, אימון, פריסה וניהול מודלים מותאמים אישית של ML לאורך מחזור חייהם (MLOps).
השתמש ב-Vertex AI.
למה: Vertex AI היא פלטפורמת MLOps מקיפה המספקת כלים לכל שלב בזרימת העבודה של למידת מכונה בסביבה אחת.
חלץ מידע מובנה אוטומטית (לדוגמה, מספרי חשבוניות, פריטי שורה) ממסמכים סרוקים או קבצי PDF.
השתמש ב-Document AI.
למה: Document AI אומנה במיוחד להבנת פריסות מסמכים וחילוץ נתונים מובנים, ובכך מפחיתה את הזנת הנתונים הידנית.
בנה צ'אט בוט או סוכן וירטואלי מבוסס קול לטיפול בפניות שירות לקוחות.
השתמש ב-Dialogflow.
למה: Dialogflow היא פלטפורמת הבנת שפה טבעית שתוכננה לבניית ממשקי שיחה, ניהול כוונות, ישויות וזרימת שיחה.
בנה והפעל מודלים חיזויים ישירות על נתונים המאוחסנים במחסן נתונים תוך שימוש ב-SQL בלבד.
השתמש ב-BigQuery ML.
למה: BigQuery ML הופך את למידת המכונה לדמוקרטית בכך שהוא מאפשר לאנליסטים של נתונים ליצור מודלים באמצעות תחביר SQL מוכר, תוך הימנעות מהעברת נתונים.
בנה יישומים שיכולים לייצר תוכן חדש, כגון סיכומי טקסט, קוד או תמונות.
השתמש בפלטפורמת Vertex AI עבור Generative AI, בגישה למודלי יסוד כמו Gemini.
למה: Vertex AI מספק גישה מנוהלת למודלי יסוד רבי עוצמה באמצעות APIs, ומאפשר פיתוח מהיר של תכונות Generative AI.
העבר אפליקציית Legacy הפועלת על VM לענן עם שינויים מינימליים, הדורשת שליטה מלאה במערכת ההפעלה.
השתמש ב-Compute Engine.
למה: Compute Engine (IaaS) מספק מכונות וירטואליות, ומציע שליטה מרבית ונתיב הגירה ישיר לשרתים מקומיים.
פרוס יישום ווב מבוסס קונטיינרים ונטול מצב שחייב להתרחב אוטומטית בהתבסס על תעבורה, כולל התרחבות לאפס.
השתמש ב-Cloud Run.
למה: Cloud Run היא פלטפורמה ללא שרתים המנוהלת באופן מלא עבור קונטיינרים, המנטרלת את כל התשתית ומחייבת רק עבור זמן עיבוד בקשות פעיל.
הפעל ארכיטקטורת מיקרו-שירותים מורכבת באמצעות קונטיינרים, הדורשת תזמור ובקרה מדויקים.
השתמש ב-Google Kubernetes Engine (GKE).
למה: GKE מספק סביבת Kubernetes מנוהלת ומוכנה לייצור, המציעה יכולות תזמור מלאות תוך מיכון ניהול האשכולות.
הפעל קטע קוד קטן בתגובה לאירוע, כמו העלאת קובץ ל-Cloud Storage או הודעת Pub/Sub.
השתמש ב-Cloud Functions.
למה: Cloud Functions (FaaS) הוא שירות מחשוב ללא שרתים, מונחה אירועים, אידיאלי עבור פונקציות קצרות טווח וחד-מטרה ללא צורך בניהול שרתים.
פרוס יישום ווב והתמקד רק בכתיבת קוד, כשהפלטפורמה מטפלת בשרתים, בהתרחבות ובעדכונים.
השתמש ב-App Engine.
למה: App Engine (PaaS) היא פלטפורמה מנוהלת באופן מלא המנטרלת את כל התשתית, אידיאלית למפתחים שרוצים את הדרך המהירה ביותר לפרוס יישום.
הפעל עבודות עיבוד אצווה גדולות וסובלניות לתקלות או עבודות מחשוב עתירות ביצועים בעלות הנמוכה ביותר האפשרית.
השתמש ב-Spot VMs ב-Compute Engine.
למה: Spot VMs מציעות הנחות עמוקות (עד 91%) עבור עומסי עבודה הניתנים להפרעה, מה שהופך אותן לחסכוניות ביותר עבור עבודות אצווה שאינן קריטיות.
בסס חיבור פרטי, בעל רוחב פס גבוה וזמן אחזור נמוך, בין מרכז נתונים מקומי ל-Google Cloud.
השתמש ב-Cloud Interconnect.
למה: Cloud Interconnect מספק חיבור פיזי ייעודי, ומציע ביצועים אמינים ועקביים יותר מאשר VPN על גבי האינטרנט הציבורי.
ספק תוכן ווב או וידאו לבסיס משתמשים גלובלי עם זמן אחזור נמוך.
השתמש ב-Cloud CDN.
למה: Cloud CDN אוגר תוכן במיקומי קצה של Google המפוזרים גלובלית, ומשרת משתמשים מנקודת נוכחות קרובה אליהם.
אחסן ונהל תמונות קונטיינרים, חבילות מערכת הפעלה וחבילות שפה בצורה מאובטחת עם סריקת פגיעות.
השתמש ב-Artifact Registry.
למה: Artifact Registry הוא מאגר אוניברסלי ומנוהל המשתלב עם CI/CD ו-GKE כדי לספק ניהול חבילות מאובטח ומרכזי.
העבר עומסי עבודה קיימים של VMware ל-Google Cloud ללא תכנון מחדש של יישומים או שינוי כלי תפעול.
השתמש ב-Google Cloud VMware Engine.
למה: הוא מספק מרכז נתונים ייעודי של VMware מוגדר-תוכנה (SDDC) המנוהל באופן מלא הפועל ב-Google Cloud, ומאפשר "lift and shift" חלק עבור VMware.
נהל גישת משתמשים למשאבי ענן בהתבסס על תפקיד תעסוקתי, תוך שמירה על עקרון הפריבילגיה המינימלית.
הקצה תפקידי IAM מוגדרים מראש או מותאמים אישית לקבוצות Google, לא למשתמשים בודדים.
למה: ניהול הרשאות באמצעות קבוצות מפשט את הניהול ומבטיח שמשתמשים חדשים יירשו באופן אוטומטי את ההרשאות הנכונות והמינימליות.
קבל תצוגה מרכזית של פגיעויות אבטחה, איומים ותצורות שגויות ברחבי ארגון GCP כולו.
השתמש ב-Security Command Center.
למה: הוא משמש כנקודת מבט אחידה לאבטחה, מאגד ממצאים ממקורות מרובים ומספק תובנות ניתנות לפעולה.
הגן על יישומי ווב הפונים לציבור מפני התקפות DDoS וניצולים נפוצים של ווב (לדוגמה, SQL injection).
השתמש ב-Cloud Armor.
למה: Cloud Armor הוא ה-Web Application Firewall (WAF) ושירות מיתון DDoS של Google המשתלב עם מאזן העומסים הגלובלי.
הצפן נתונים בשירותי ענן תוך שמירה על שליטה מלאה על מפתחות ההצפנה.
השתמש ב-Cloud Key Management Service (Cloud KMS) כדי ליצור מפתחות הצפנה מנוהלים על ידי לקוח (CMEK).
למה: CMEK מאפשר לך לשלוט במחזור חיי המפתח (סיבוב, השמדה) מסיבות תאימות או מדיניות, בעוד ש-Google מנהלת את תשתית המפתחות.
גלה, סווג וטשטש נתונים רגישים (לדוגמה, מספרי כרטיסי אשראי, PII) המאוחסנים ב-Cloud Storage או ב-BigQuery.
השתמש ב-Cloud Data Loss Prevention (DLP).
למה: Cloud DLP מספקת כלים לסריקה אוטומטית וביצוע פעולות על נתונים רגישים כדי למנוע חשיפה מקרית.
ספק גישה מאובטחת ליישומי ווב פנימיים לעובדים ללא שימוש ב-VPN מסורתי.
השתמש ב-Identity-Aware Proxy (IAP).
למה: IAP אוכף מדיניות גישה המבוססת על זהות וקונטקסט של משתמש, ויוצר מודל אבטחה של "אפס אמון" עבור יישומים.
מנע דליפת נתונים על ידי יצירת מעטפת אבטחה סביב פרויקטים ושירותים רגישים ב-Google Cloud.
השתמש ב-VPC Service Controls.
למה: VPC Service Controls מבודד שירותים ונתונים, ומבטיח שלא ניתן להעביר נתונים מחוץ למעטפת המוגדרת, גם על ידי משתמש עם הרשאות IAM תקפות.
אחסן ונהל סודות יישומים כגון מפתחות API, סיסמאות ותעודות בצורה מאובטחת.
השתמש ב-Secret Manager.
למה: Secret Manager מספק מאגר מרכזי, מנוהל גרסאות ומבוקר לסודות עם הרשאות IAM פרטניות, מה שמאובטח יותר מאחסונם בקוד או בקבצי תצורה.
קבל נראות מקיפה לבריאות היישום והתשתית באמצעות מדדים, יומנים ועקבות.
השתמש בחבילת פעולות Google Cloud: Cloud Monitoring (מדדים/התראות), Cloud Logging (יומנים) ו-Cloud Trace (מעקב).
למה: חבילה משולבת זו מספקת תמונה מלאה של ביצועי המערכת לניטור יזום ופתרון תקלות מהיר יותר.
נהל באופן יזום את הוצאות הענן וקבל התראות לפני שהעלויות חורגות מהסכומים המתוכננים.
הגדר התראות תקציב של Cloud Billing.
למה: תקציבים מספקים התראות פרוגרמטיות כאשר ההוצאות מגיעות לספים מסוימים, ובכך מונעים חריגה בעלויות.
עקוב והקצה עלויות ענן לצוותים, פרויקטים או מרכזי עלות ספציפיים לצורך חיוב חוזר.
החל Labels על כל המשאבים והשתמש בדוחות Cloud Billing כדי לסנן ולקבץ עלויות לפי Label.
למה: Labels הם המנגנון העיקרי לארגון משאבים וייחוס עלויות לצורך ניהול פיננסי.
הפחת עלויות עבור עומסי עבודה יציבים וצפויים הפועלים ברציפות (לדוגמה, שרת מסד נתונים).
רכוש Committed Use Discounts (CUDs) לשנה או 3 שנים עבור Compute Engine או שירותים אחרים.
למה: CUDs מציעים חיסכון משמעותי לעומת תמחור לפי דרישה בתמורה להתחייבות לרמת שימוש עקבית במשאבים.
ארגן משאבי ענן כדי לשקף את מבנה החברה (לדוגמה, מחלקות, סביבות) והחל מדיניות היררכית.
השתמש בהיררכיית המשאבים Organization > Folders > Projects.
למה: מבנה זה מאפשר שליטה מרכזית, שכן מדיניות IAM ו-Organization עוברת בירושה במורד ההיררכיה, ומפשטת את הניהול בקנה מידה גדול.
הגדר, פרוס ונהל תשתית ענן באופן שניתן לחזור עליו, מבוקר גרסאות וממוכן.
השתמש בכלי Infrastructure as Code (IaC) כמו Terraform או Cloud Deployment Manager.
למה: IaC מפחית שגיאות ידניות, מגביר את מהירות הפריסה ומספק תיעוד מבוקר של שינויים בתשתית.
אזן בין הצורך באמינות שירות לבין הצורך לחדש ולשחרר תכונות חדשות.
הטמע עקרונות Site Reliability Engineering (SRE): הגדר Service Level Objectives (SLOs) והשתמש ב-Error Budget המתקבל.
למה: תקציב השגיאות מספק מסגרת מונחית נתונים להחלטה מתי לתעדף עבודת אמינות על פני פיתוח תכונות, ובכך להגן על חווית המשתמש.