שתף באמצעות

פשרות בין יעילות ביצועים ל Power Platform עומסי עבודה

  • מאמר

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

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

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

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

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

פשרה: מורכבות מוגברת. אמינות נותנת עדיפות לפשטות.

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

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

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

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

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

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

פשרות בין יעילות ביצועים עם אבטחה

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

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

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

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

  • הסרת כללי חומת אש מתזרימי רשת כדי לשפר את זמן האחזור של הרשת עלולה לאפשר תקשורת לא רצויה.

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

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

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

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

  • הורדת עיבוד לעבודות רקע או אפילו מחשוב לקוח.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פשרות בין יעילות ביצועים עם אופטימיזציית חוויה

פשרה: ירידה במעורבות המשתמש. עמודת אופטימיזציית החוויה מעניק עדיפות לחוויות משתמש מרתקות יותר.

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

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

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

למידע נוסף