המלצות לעיצוב לפשטות ויעילות

חלות על המלצה זו של רשימת משימות לביצוע של Well Architected Framework Reliability של Power Platform:

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

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

הגדרות

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

אסטרטגיות מרכזיות בתכנון

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

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

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

תרגילי עיצוב משותפים

שתפו פעולה עם בעלי עניין כדי:

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

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

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

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

  למידע נוסף, עיין במודול ההדרכה בשם עבודה עם דרישות עבור Microsoft Power Platform ו- Dynamics 365.

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

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

• הגדירו יעדי זמינות ושחזור עבור עומס העבודה כדי לקבל החלטות לגבי הארכיטקטורה. מדדים עסקיים כוללים יעדי רמת שירות (SLO), הסכמי רמת שירות (SLA), זמן ממוצע להתאוששות (MTTR), זמן ממוצע בין כשל (MTBF), יעדי זמן התאוששות (RTO) ויעדי נקודת התאוששות (RPO). הגדירו ערכי יעד עבור מדדים אלה. תרגיל זה עשוי לדרוש פשרה והבנה הדדית בין צוותי טכנולוגיה ועסקים כדי להבטיח שהמטרות של כל צוות עומדות ביעדים העסקיים ושהן מציאותיות. למידע נוסף ראה ‏‫המלצות להגדרת יעדי מהימנות‬. הסכמי SLA של Power Platform מספקים את ההתחייבויות של Microsoft עבור זמן פעולה וקישוריות. לשירותים שונים יש הסכמי SLA שונים, ולפעמים לפריטי SKU בתוך שירות יש הסכמי SLA שונים. לקבלת מידע נוסף, ראה הסכמי רמת שירות לשירותים מקוונים.

המלצות עיצוב נוספות

אפשר לבצע את ההמלצות הבאות ללא מעורבות של בעלי עניין:

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

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

  • אם תפתרו דרישה הפונה למשתמש באמצעות Power Apps, יישום בד ציור מונוליטי גדול עם פקדים רבים עלול להשפיע לרעה על הביצועים. פירוק זה לאפליקציות בודדות או לדפים מותאמים אישית עשוי להקשות על הבדיקה, אך עשויה להיות לו השפעה חיובית משמעותית על הביצועים.

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

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

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

מומלץ לפתח מספיק קוד

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

• השתמשו ביכולות הפלטפורמה כשהן עומדות בדרישות העסקיות שלכם. לדוגמה:

  • השתמשו בפקדים מודרניים במקום לפתח רכיבי קוד משלכם כדי להשיג תקן עיצוב של Fluent 2.
  • השתמשו במחברים מקוריים במקום לפתח מחברים מותאמים אישית כדי להפחית את הקוד המותאם אישית.
  • השתמשו בתשובות גנרטיביות ב- Microsoft Copilot Studio כדי לאפשר לסוכן שלכם למצוא ולהציג מידע ממקורות מרובים, פנימיים או חיצוניים, ללא נושאים שנוצרו באופן ידני.

• היעזרו במפגשי סקירת קוד ייעודיים כתרגול פיתוח.

• יישמו גישה לזיהוי קוד לא פעיל. היו ספקניים לגבי הקוד שהבדיקות האוטומטיות שלכם לא מכסות.

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

שימו לב למיקום של הנתונים שלכם

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

• נתונים חדשים: אם האפליקציה שלכם יוצרת נתונים שאינם קיימים עדיין, כגון במצבים שבהם התהליך העסקי הקיים בוצע באמצעות נייר, מומלץ לאחסן את הנתונים ב- Microsoft Dataverse.

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

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

סיוע ל- Power Platform

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

לקבלת ייעוץ עיצובי מעשי, עיינו במאמרים הבאים:

• Power Apps:

  • לקבוע היכן למקם את הלוגיקה במערכת שלכם: יישומי בד ציור, יישומים מונחי דגמים, Microsoft Dataverse או זרימות של Power Automate
  • לקבוע איזה סוג אפליקציה ליצור: יישומים מונחי דגמים או יישומי בד ציור
  • מידול נתונים: עיצוב מבנה הנתונים
  • עיצוב נתונים: עבודה עם מערכות ארגוניות

• Power Automate:

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

• סטודיו Copilot

  • מדריך היישום של Microsoft Copilot Studio מספק מסגרת לביצוע סקירה מקיפה של הפרויקט שלכם. על-ידי הצגת שאלות, הוא מזהה סיכונים ופערים פוטנציאליים, מתאים את הפרוייקט למפת הדרכים של המוצר ומשתף הדרכה, שיטות עבודה מומלצות ודוגמאות לארכיטקטורת התייחסות.
  • תיעוד ההדרכה של Microsoft Copilot Studio מספק שיטות עבודה מומלצות, עצות ליישום והנחיות ארכיטקטורה מהצוות שמשתף פעולה עם הלקוחות הארגוניים שלנו.

מידע קשור

• הסכמי רמת שירות עבור שירותים מקוונים
• עבודה עם דרישות עבור Microsoft Power Platform ו- Dynamics 365
• תכנון פרוייקט של Power Apps
• תכנון פרוייקט של Power Automate
• תכנון פרויקט בינה מלאכותית שיחתית

רשימת פעולות לביצוע מבחינת מהימנות

עיין במכלול ההמלצות המלא.

רשימת פעולות לביצוע מבחינת מהימנות