כדי להסביר למה צוותי התשתית או האפליקציה שלכם מקבלים החלטות עיצוב מסוימות, אתם יכולים להשתמש ברשומות של החלטות ארכיטקטורה (ADR). במסמך הזה מוסבר מתי ואיך להשתמש ב-ADR כשמפתחים ומריצים אפליקציות ב-Google Cloud.
מסמך ADR מתעד את האפשרויות העיקריות הזמינות, את הדרישות העיקריות שמשפיעות על ההחלטה ואת החלטות התכנון עצמן. לרוב, מסמכי ADR מאוחסנים בקובץ Markdown שקרוב לבסיס הקוד שרלוונטי להחלטה. אם מישהו צריך להבין את הרקע של החלטה אדריכלית ספציפית, למשל למה משתמשים באשכול אזורי של Google Kubernetes Engine (GKE), הוא יכול לעיין ב-ADR ואז בקוד שמשויך אליו.
בנוסף, ADR יכול לעזור לכם להפעיל אפליקציות ושירותים אמינים יותר. ה-ADR עוזר להבין את המצב הנוכחי ולפתור בעיות. בנוסף, ה-ADR יוצר אוסף של החלטות הנדסיות שיעזרו בעתיד לקבל החלטות ולבצע פריסות.
מתי כדאי להשתמש בהמלצות לשיפור הביצועים
אתם משתמשים ב-ADR כדי לעקוב אחרי התחומים העיקריים שלדעתכם חשובים לפריסה. ה-ADR עשוי לכלול את הקטגוריות הבאות:
- בחירות ספציפיות של מוצרים, כמו הבחירה בין Pub/Sub לבין Cloud Tasks.
- אפשרויות והגדרות ספציפיות של מוצרים, כמו שימוש באשכולות GKE אזוריים עם Multi Cluster Ingress (כניסה למספר אשכולות) עבור אפליקציות עם זמינות גבוהה.
- הנחיות כלליות לארכיטקטורה, כמו שיטות מומלצות למניפסטים של Dockerfile.
הנה כמה דוגמאות ספציפיות שיכולות לעודד אתכם ליצור מסמך ADR:
- איך ומדוע מגדירים זמינות גבוהה (HA) למופעים של Cloud SQL?
- מה הגישה שלכם לגבי זמן פעולה של אשכולות GKE? האם אתם משתמשים באשכולות אזוריים? האם אתם משתמשים בגרסאות קנריות? למה או למה לא?
כשאתם מעריכים את המוצרים שבהם כדאי להשתמש, ה-ADR עוזר להסביר כל אחת מההחלטות שלכם. אפשר לחזור ל-ADR ככל שהצוות מתפתח ולומד יותר על הסטאק, ולקבל או לשנות החלטות נוספות. אם אתם מבצעים שינויים, עליכם לכלול את ההחלטה הקודמת ולהסביר למה בוצע שינוי. ההיסטוריה הזו מתעדת את השינויים בארכיטקטורה ככל שהצרכים העסקיים מתפתחים, או כשמתעוררות דרישות טכניות חדשות או כשזמינים פתרונות חדשים.
ההנחיות הבאות יעזרו לכם לדעת מתי ליצור ADR:
- כשנתקלים באתגר טכני או שיש שאלה טכנית ואין בסיס קיים לקבלת החלטה, כמו פתרון מומלץ, נוהל פעולה סטנדרטי, תוכנית או בסיס קוד.
- כשאתם או הצוות שלכם מציעים פתרון שלא מתועד במקום כלשהו שהצוות יכול לגשת אליו.
- כשמוצגות שתי אפשרויות הנדסיות או יותר ואתם רוצים לתעד את המחשבות והסיבות שלכם לבחירה.
כשכותבים מסמך ADR, כדאי לחשוב על הקוראים הפוטנציאליים. הקוראים העיקריים הם חברי הצוות שעובדים על הטכנולוגיה שמכוסה ב-ADR. קבוצות רחבות יותר של קוראים פוטנציאליים של ה-ADR עשויות לכלול צוותים סמוכים שרוצים להבין את ההחלטות שלכם, כמו צוותי ארכיטקטורה ואבטחה.
כדאי גם לקחת בחשבון שהבעלים של האפליקציה עשוי להשתנות או שחברים חדשים יצטרפו לצוות. מסמך ADR עוזר למפתחים חדשים להבין את הרקע של הבחירות ההנדסיות שנעשו. בנוסף, מסמך ADR מקל על תכנון שינויים עתידיים.
הפורמט של ADR
דוח ADR טיפוסי כולל קבוצה של פרקים. מסמכי ה-ADR צריכים לעזור לכם לתעד את מה שלדעתכם חשוב לאפליקציה ולארגון. חלק מה-ADR יכולים להיות באורך של עמוד אחד, בעוד שאחרים דורשים הסבר ארוך יותר.
בדוגמה הבאה של מבנה ADR אפשר לראות איך לעצב ADR כך שיכלול את המידע שחשוב לסביבה שלכם:
- מחברים והצוות
- הקשר והבעיה שרוצים לפתור
- דרישות פונקציונליות ודרישות לא פונקציונליות שאתם רוצים לטפל בהן
- חוויית משתמש הכרחית (CUJ) שההחלטה משפיעה עליה
- סקירה כללית של האפשרויות העיקריות
- ההחלטה שלכם והסיבות לבחירה שהתקבלה
כדי לשמור תיעוד של ההחלטות, כדאי לכלול חותמת זמן לכל החלטה כדי לראות מתי היא התקבלה.
איך פועלות מודעות רספונסיביות
ה-ADR יעיל במיוחד כשהמהנדסים, המפתחים או בעלי האפליקציות יכולים לגשת בקלות למידע שהוא מכיל. אם יש להם שאלה לגבי הסיבה לכך שמשהו נעשה בצורה מסוימת, הם יכולים לעיין ב-ADR כדי למצוא את התשובה.
כדי להפוך את ה-ADR לנגיש, חלק מהצוותים מאחסנים אותו בוויקי מרכזי שנגיש גם לבעלי העסקים, במקום במאגר בקרת המקורות שלהם. כשמישהו רוצה לשאול שאלה לגבי החלטה הנדסית ספציפית, הוא יכול למצוא את התשובה ב-ADR.
מודעות דינמיות לרשת החיפוש מתאימות במיוחד לתרחישים הבאים:
- הדרכה: חברי צוות חדשים יכולים ללמוד בקלות על הפרויקט, ולעיין ב-ADR אם יש להם שאלות בזמן שהם לומדים codebase חדש.
- התפתחות הארכיטקטורה: אם יש העברה של סטאק תוכנות בין צוותים, הבעלים החדשים יכולים לבדוק החלטות קודמות כדי להבין את המצב הנוכחי. הצוות יכול גם לבדוק החלטות קודמות אם יש טכנולוגיה חדשה שזמינה לו. ה-ADR יכול לעזור לצוותים להימנע מחזרה על אותם נושאי דיון, והוא יכול לספק הקשר היסטורי כשצוותים חוזרים לנושאים מסוימים.
- שיתוף שיטות מומלצות: צוותים יכולים להגיע להסכמה לגבי שיטות מומלצות בכל הארגון כשמסמכי ADR מפרטים למה התקבלו החלטות מסוימות ולמה נדחו חלופות.
בדרך כלל, מסמך ADR נכתב בפורמט Markdown כדי לשמור על משקל קל ועל בסיס טקסט. אפשר לכלול קובצי Markdown במאגר של בקרת המקור עם קוד האפליקציה.
מומלץ לשמור את מסמכי ה-ADR קרוב לקוד האפליקציה, באופן אידיאלי באותה מערכת לניהול גרסאות. כשמבצעים שינויים ב-ADR, אפשר לבדוק גרסאות קודמות מניהול המקור לפי הצורך.
אפשר גם להשתמש באמצעי אחר כמו מסמך Google Docs משותף או ויקי פנימי. יכול להיות שהמיקומים החלופיים האלה יהיו נגישים יותר למשתמשים שלא נכללים בצוות של ADR. אפשרות נוספת היא ליצור את ה-ADR במאגר של מערכת לניהול גרסאות, אבל לשקף את ההחלטות העיקריות בוויקי נגיש יותר.
המאמרים הבאים
- במרכז הארכיטקטורה של Cloud ובGoogle Cloud Well-Architected Framework אפשר למצוא הנחיות ושיטות מומלצות נוספות.
- במאמר תבניות לאפליקציות עמידות שניתנות להרחבה מפורטים תחומים מסוימים שעשויים להיכלל ב-ADR.