Well-Architected Framework מציע המלצות לאדריכלים, למפתחים, לאדמינים ולגורמים אחרים בתחום הענן איך לתכנן ולהפעיל טופולוגיה מאובטחת, יעילה, עמידה, בעלת ביצועים גבוהים, חסכונית ובת קיימא בענן.
צוות מומחים רב-תחומי ב-Google מאמת את ההמלצות ב-Well-Architected Framework. הצוות אוצר את Well-Architected Framework כדי לשקף את היכולות המתרחבות של Google Cloud, שיטות מומלצות בתחום, ידע קהילתי ומשוב מכם. סיכום של השינויים המשמעותיים ב-Well-Architected Framework זמין במאמר מה חדש.
ה-Well-Architected Framework רלוונטי לאפליקציות שנוצרו לענן ולעומסי עבודה שהועברו משרתים מקומיים אל Google Cloud, פריסות בענן היברידי וסביבות מרובות עננים (multi-cloud).
העקרונות והנקודות המרכזיות של Well-Architected Framework
ההמלצות ב-Well-Architected Framework מאורגנות לפי עקרונות ונקודות מבט חוצות-עקרונות, כמו שמוצג בתרשים הבא.
עמוד תווך ב-Well-Architected Framework מספק עקרונות והמלצות לתחום התמקדות ספציפי שאינו פונקציונלי: אבטחה, אמינות, ביצועים, עלות, תפעול או קיימוּת.
נקודת מבט ב-Well-Architected Framework היא תצוגה של המלצות לטכנולוגיה, לתחום או למגזר ספציפיים, שחוצה את עמודי התווך. ההמלצות בפרספקטיבה מסוימת תואמות לעקרונות הכלליים ולהמלצות שמופיעות ב-pillars.
לדוגמה, בנקודת המבט של שירותים פיננסיים (FS) מומלצת אסטרטגיית התאוששות מאסון שעומדת בדרישות הרגולטוריות לגבי מיקום אחסון הנתונים. ההמלצה הזו ספציפית לשירותים פיננסיים, והיא תואמת לעיקרון של יעדים ריאליים בעמוד התווך של האמינות, כי הדרישות לגבי מיקום אחסון הנתונים משפיעות על בחירת האזור לגיבוי, וכתוצאה מכך על יעדי השחזור.
עמודים
- מצוינות תפעולית
- פריסה, הפעלה, מעקב וניהול של עומסי העבודה בענן בצורה יעילה.
- אבטחה, פרטיות ותאימות
- אבטחה מקסימלית של הנתונים ועומסי העבודה בענן, תכנון לפרטיות ועמידה בדרישות ובתקנים רגולטוריים.
- אמינות
- תכנון והפעלה של עומסי עבודה עמידים וזמינים מאוד בענן.
- אופטימיזציה של עלויות
- מקסום הערך העסקי של ההשקעה ב- Google Cloud.
- אופטימיזציה של הביצועים
- תכנון ושיפור של משאבי הענן לביצועים אופטימליים.
- eco קיימוּת
- פיתוח וניהול של עומסי עבודה בענן באופן בר-קיימא.
נקודות מבט חוצות-עמודים
- AI ו-ML
- תצוגה רוחבית של המלצות ספציפיות לטכנולוגיה של עומסי עבודה (workloads) של AI ו-ML.
- שירותים פיננסיים
- תצוגה של המלצות לעומסי עבודה של FS בכל העמודים.
סקילים אג'נטיים
כדי לאפשר לסוכני AI להעריך את עומסי העבודה בענן בהתאם לעקרונות ולהמלצות בכל אחד מהעמודים של Well-Architected Framework, צריך להשתמש בgoogle-cloud-waf-* מיומנויות הסוכן1 שזמינות במאגר מיומנויות הסוכן של Google ב-GitHub.
כדי להתקין מיומנות ספציפית של Well-Architected Framework, מריצים את הפקודה הבאה בטרמינל או בלקוח של הנציג. כשמופיעה בקשה, מציינים את סוכני ה-AI שרוצים להתקין להם את הסקיל ומגדירים את היקף ההתקנה (פרויקט או גלובלי).
npx skills add google/skills --skill SKILL_NAME
בפקודה הקודמת, מחליפים את SKILL_NAME בשם המיומנות שרוצים להתקין, מתוך הטבלה הבאה.
| Pillar, וקישור לסקיל ב-GitHub | SKILL_NAME |
|---|---|
| מצוינות תפעולית | google-cloud-waf-operational-excellence |
| אבטחה, פרטיות ותאימות |
google-cloud-waf-security
|
| אמינות | google-cloud-waf-reliability |
| הוזלת עלויות | google-cloud-waf-cost-optimization |
| אופטימיזציה של הביצועים | google-cloud-waf-performance-optimization |
| קיימוּת | google-cloud-waf-sustainability |
כל מיומנות ב-Well-Architected Framework כוללת את המידע הבא לגבי עקרון ספציפי:
- סקירה כללית של העיקרון, עקרונות הליבה שלו וקישורים למסמכי תיעוד שמותאמים ל-AI לכל עיקרון.
- דוגמאות למוצרים ולתכונות של Google Cloud שרלוונטיים לעמוד התווך.
- שאלות הערכה שהסוכנים יכולים לשאול כדי להבין את הדרישות של עומס העבודה.
- רשימת משימות לאימות שבה הנציגים יכולים להשתמש כדי להעריך את ההתאמה של הארכיטקטורה לעקרונות ולהמלצות שבעמוד התווך.
עקרונות מרכזיים
לפני שאתם בודקים את ההמלצות בכל אחד מעמודי התווך של Well-Architected Framework, כדאי שתקראו את עקרונות הליבה הבאים:
תכנון לשינוי
אין מערכת סטטית. הצרכים של המשתמשים, היעדים של הצוות שבנה את המערכת והמערכת עצמה משתנים כל הזמן. כדי להטמיע שינויים, צריך לבנות תהליך פיתוח וייצור שמאפשר לצוותים להטמיע שינויים קטנים באופן קבוע ולקבל משוב מהיר על השינויים האלה. היכולת להטמיע שינויים באופן עקבי עוזרת לבנות אמון עם בעלי העניין, כולל הצוותים שאחראים על המערכת והמשתמשים במערכת. השימוש במדדים של DORA להכנת תוכנה להפצה יכול לעזור לצוות שלכם לעקוב אחרי המהירות, הקלות והבטיחות של ביצוע שינויים במערכת.
תיעוד הארכיטקטורה
כשמתחילים להעביר את עומסי העבודה לענן או לפתח אפליקציות, היעדר תיעוד של המערכת יכול להיות מכשול משמעותי. תיעוד חשוב במיוחד כדי להמחיש בצורה נכונה את הארכיטקטורה של הפריסות הנוכחיות.
תיעוד איכותי לא נמדד בכמות, אלא במידת הבהירות והתועלת של התוכן, ובאופן שבו הוא מתעדכן כשהמערכת משתנה.
ארכיטקטורת ענן שמתועדת בצורה נכונה יוצרת שפה משותפת ותקנים, ומאפשרת לצוותים חוצי-תחומים לתקשר ולשתף פעולה בצורה יעילה. במסמכים מופיע גם המידע שנדרש כדי לזהות את ההחלטות העיצוביות העתידיות ולתת להן כיוון. המסמכים צריכים להיכתב בהתאם לתרחישי השימוש שלכם, כדי לספק הקשר להחלטות העיצוביות.
עם הזמן, ההחלטות שלכם לגבי העיצוב ישתנו ויתפתחו. היסטוריית השינויים מספקת את ההקשר שהצוותים שלכם צריכים כדי לתאם יוזמות, להימנע מכפילויות ולמדוד ביעילות את השינויים בביצועים לאורך זמן. יומני שינויים הם כלי חשוב במיוחד כשמצרפים Cloud Architect חדש שעדיין לא מכיר את העיצוב, האסטרטגיה או ההיסטוריה הנוכחיים שלכם.
ניתוח של DORA מצא קשר ברור בין איכות התיעוד לבין הביצועים של הארגון – היכולת של הארגון לעמוד ביעדי הביצועים והרווחיות שלו.
פישוט העיצוב ושימוש בשירותים שמנוהלים במלואם
הפשטות היא קריטית לעיצוב. אם הארכיטקטורה מורכבת מדי, יהיה קשה להבין אותה, להטמיע את העיצוב ולנהל אותה לאורך זמן. במידת האפשר, השתמשו בשירותים שמנוהלים באופן מלא כדי לצמצם את הסיכונים, הזמן והמאמץ שקשורים לניהול ולתחזוקה של מערכות בסיסיות.
אם אתם כבר מפעילים את עומסי העבודה בסביבת ייצור, כדאי לבדוק את השירותים המנוהלים כדי לראות איך הם יכולים לעזור לכם לצמצם את המורכבות התפעולית. אם אתם מפתחים עומסי עבודה חדשים, התחילו בקטן, צרו מוצר מינימלי בר-קיימא (MVP) ואל תתפתו להנדס יותר מדי. אתם יכולים לזהות תרחישים חריגים לדוגמה, לחזור על התהליך ולשפר את המערכות בהדרגה לאורך זמן.
הפרדה בין רכיבים בארכיטקטורה
מחקר של DORA מראה שארכיטקטורה היא גורם חיזוי חשוב להשגת העברה רציפה (CD). הפרדה היא שיטה שמשמשת להפרדת האפליקציות ורכיבי השירות לרכיבים קטנים יותר שיכולים לפעול באופן עצמאי. לדוגמה, אפשר להפריד בין מחסנית של אפליקציה מונוליתית לרכיבי שירות נפרדים. בארכיטקטורה עם צימוד חלש, אפליקציה יכולה להפעיל את הפונקציות שלה באופן עצמאי, ללא קשר לתלות השונות.
ארכיטקטורה מנותקת מאפשרת לכם גמישות רבה יותר לבצע את הפעולות הבאות:
- מחילים שדרוגים עצמאיים.
- לאכוף אמצעי בקרה ספציפיים לאבטחה.
- הגדירו יעדי אמינות לכל תת-מערכת.
- מעקב אחר הבריאות.
- שליטה פרטנית בפרמטרים של ביצועים ועלויות.
אפשר להתחיל את תהליך ההפרדה בשלב מוקדם של התכנון, או לשלב אותו כחלק משדרוגי המערכת ככל שמתרחבים.
שימוש בארכיטקטורה ללא שמירת מצב (stateless)
ארכיטקטורה ללא שמירת מצב יכולה לשפר את האמינות ואת יכולת ההתאמה לעומס של האפליקציות.
אפליקציות עם שמירת מצב מסתמכות על יחסי תלות שונים כדי לבצע משימות, כמו שמירת נתונים במטמון מקומי. אפליקציות עם שמירת מצב דורשות לעתים קרובות מנגנונים נוספים כדי לתעד את ההתקדמות ולהפעיל מחדש בצורה חלקה. אפליקציות בלי שמירת מצב יכולות לבצע משימות בלי תלות משמעותית ברמה המקומית, באמצעות שימוש בנפח אחסון משותף או בשירותים שנשמרו במטמון. ארכיטקטורה ללא שמירת מצב מאפשרת לאפליקציות להתרחב במהירות עם מינימום יחסי תלות באתחול. האפליקציות יכולות לעמוד בפני הפעלה מחדש, יש להן זמן השבתה קצר יותר והן מספקות ביצועים טובים יותר למשתמשי הקצה.
-
מידע נוסף על תקן מיומנויות הנציגים זמין במאמר סקירה כללית על מיומנויות הנציגים. ↩