Well-Architected Framework מציע המלצות לאדריכלים, למפתחים, לאדמינים ולגורמים אחרים בתחום הענן איך לתכנן ולהפעיל טופולוגיה מאובטחת, יעילה, עמידה, בעלת ביצועים גבוהים, חסכונית ובת קיימא בענן.
צוות רב-תחומי של מומחים ב-Google מאמת את ההמלצות ב-Well-Architected Framework. הצוות אוצר את Well-Architected Framework כדי לשקף את היכולות המתרחבות של Google Cloud, שיטות מומלצות בתחום, ידע קהילתי ומשוב מכם. במאמר מה חדש מפורטים השינויים המשמעותיים ב-Well-Architected Framework.
ה-Well-Architected Framework רלוונטי לאפליקציות שנוצרו לענן וגם לעומסי עבודה שהועברו מסביבה מקומית ל- Google Cloud, לפריסות של ענן היברידי ולסביבות מרובות עננים.
עקרונות ונקודות מבט של Well-Architected Framework
ההמלצות ב-Well-Architected Framework מאורגנות לפי עקרונות ונקודות מבט חוצות-עקרונות, כמו שמוצג בתרשים הבא.
עמוד תווך ב-Well-Architected Framework מספק עקרונות והמלצות לתחום התמקדות ספציפי שאינו פונקציונלי: אבטחה, אמינות, ביצועים, עלות, תפעול או קיימוּת.
נקודת מבט ב-Well-Architected Framework היא תצוגה של המלצות לטכנולוגיה, לתחום או למגזר ספציפיים, שחוצה את עמודי התווך. ההמלצות בנקודת המבט תואמות לעקרונות הכלליים ולהמלצות בעמודי התווך.
לדוגמה, בנקודת המבט של שירותים פיננסיים (FS) מומלצת אסטרטגיית התאוששות מאסון שעומדת בדרישות הרגולטוריות לגבי מיקום אחסון הנתונים. ההמלצה הזו ספציפית לשירותים פיננסיים, והיא תואמת לעיקרון של יעדים ריאליים בעמוד התווך של האמינות, כי הדרישות לגבי מיקום אחסון הנתונים משפיעות על בחירת האזור לגיבוי, וכתוצאה מכך על יעדי השחזור.
עמודים
- מצוינות תפעולית
- פריסה, הפעלה, מעקב וניהול של עומסי העבודה בענן בצורה יעילה.
- אבטחה, פרטיות ותאימות
- אבטחה מקסימלית של הנתונים ועומסי העבודה בענן, תכנון לפרטיות ועמידה בדרישות ובתקנים רגולטוריים.
- אמינות
- תכנון והפעלה של עומסי עבודה עמידים וזמינים בענן.
- אופטימיזציה של עלויות
- ממקסמים את הערך העסקי של ההשקעה ב- Google Cloud.
- אופטימיזציה של הביצועים
- תכנון והתאמה של משאבי הענן לביצועים אופטימליים.
- eco קיימוּת
- ליצור ולנהל עומסי עבודה בענן ששומרים על קיימוּת סביבתית.
נקודות מבט חוצות-עמודים
- AI ו-ML
- תצוגה רוחבית של המלצות ספציפיות לטכנולוגיה של עומסי עבודה (workloads) של AI ו-ML.
- שירותים פיננסיים
- תצוגה של המלצות לעומסי עבודה של FS בכל העמודים.
סקילים אג'נטיים
כדי לאפשר לסוכני AI להעריך את עומסי העבודה בענן בהתאם לעקרונות ולהמלצות בכל אחד מעמודי התווך של Well-Architected Framework, אתם יכולים להשתמש במיומנויות של סוכני google-cloud-waf-* שזמינות במאגר המיומנויות של סוכני Google ב-GitHub.
כדי להתקין מיומנות ספציפית של Well-Architected Framework, מריצים את הפקודה הבאה בטרמינל או בלקוח של הנציג. כשמופיעה בקשה, מציינים את סוכני ה-AI שרוצים להתקין להם את הסקיל ומגדירים את היקף ההתקנה (פרויקט או גלובלי).
npx skills add google/skills --skill SKILL_NAME
בפקודה הקודמת, מחליפים את SKILL_NAME בשם המיומנות שרוצים להתקין, מהטבלה הבאה.
אם כבר התקנתם מיומנויות, אתם יכולים לעדכן אותן לגרסה העדכנית ביותר על ידי הפעלת הפקודה הבאה:
npx skills update
| עמודה, וקישור למיומנות ב-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)
ארכיטקטורה ללא שמירת מצב יכולה לשפר את האמינות ואת יכולת ההתאמה לעומס של האפליקציות.
אפליקציות עם שמירת מצב מסתמכות על יחסי תלות שונים כדי לבצע משימות, כמו שמירת נתונים במטמון מקומי. אפליקציות עם שמירת מצב דורשות לעתים קרובות מנגנונים נוספים כדי לתעד את ההתקדמות ולהפעיל מחדש בצורה חלקה. אפליקציות בלי שמירת מצב יכולות לבצע משימות בלי תלות משמעותית ברמה המקומית, באמצעות שימוש בנפח אחסון משותף או בשירותים שנשמרו במטמון. ארכיטקטורה ללא שמירת מצב מאפשרת לאפליקציות להתרחב במהירות עם מינימום יחסי תלות באתחול. האפליקציות יכולות לעמוד בהפעלות מחדש קשות, יש להן פחות זמן השבתה והן מספקות ביצועים טובים יותר למשתמשי הקצה.
-
למידע נוסף על מיומנויות רגילות של נציגים, קראו את הסקירה הכללית על מיומנויות של נציגים. ↩