פשרות של מצוינות תפעולית עבור Power Platform עומסי עבודה
מצוינות תפעולית מספקת איכות עומס עבודה באמצעות יישום של סטנדרטים ברורים של צוות, הבנת תחומי אחריות, תשומת לב לתוצאות הלקוחות ולכידות הצוות. היישום של יעדים אלו מושרש ב-DevOps, הממליץ למזער את שונות התהליכים, לצמצם טעויות אנוש, ובסופו של דבר להגדיל את החזר הערך לעומס העבודה. הערך הזה לא נמדד רק מול הדרישות הפונקציונליות שאותן ממלאים מרכיבי עומס העבודה. הוא גם נמדד לפי הערך שהצוות מספק בשאיפה לשיפור.
במהלך שלב התכנון של עומס עבודה ולאורך מחזור חייו, כאשר ננקטים צעדי שיפור מתמידים, חשוב לשקול כיצד החלטות המבוססות על עקרונות התכנון של מצוינות תפעולית וההמלצות המפורטות ברשימת משימות לביצוע לבדיקת התכנון של מצוינות תפעולית עשויות להשפיע על היעדים והאופטימיזציות של עמודי תווך אחרים. החלטות מסוימות עשויות להועיל לחלק מעמודי התווך, אך הן מהוות פשרות מבחינת עמודי תווך אחרים. מאמר זה מתאר פשרות לדוגמה שצוות עומס עבודה עלול להיתקל בהן בעת תכנון ארכיטקטורה של עומס עבודה ותפעול.
פשרות של מצוינות תפעולית עם מהימנות
הפשרה: מורכבות רבה יותר. מהימנות מתעדפת פשטות, מכיוון שעיצוב פשוט ממזער תצורה שגויה ומפחית אינטראקציות בלתי צפויות.
אסטרטגיות פריסה בטוחה דורשות לעתים קרובות מידה מסוימת של תאימות לפנים ולאחור בין לוגיקה של אפליקציה לנתונים בעומס העבודה. המורכבות הנוספת הזו מגבירה את עומס הבדיקות ויכולה להוביל למורכבות או לבעיות שלמות בנתוני עומס העבודה.
מבנים בעלי מספר רב של שכבות, מודולים או פרמטרים יכולים להגביר את הסיכוי לתצורה שגויה שלא במכוון עקב המורכבות של האינטראקציה בין מרכיבי עומס העבודה.
דפוסי עיצוב בענן המועילים לתפעול מחייבים לפעמים להוסיף רכיבים נוספים, למשל, שימוש במאגר סודות או יצירת יחס תלות ב- Application Insights. הרכיבים הנוספים מגדילים את נקודות האינטראקציה במערכת ומגדילים מגדילים את שטח הפנים המאפשר תקלה או תצורה שגויה.
פריסת שינויים קטנים ומצטברים היא טכניקה להפחתת סיכונים, אך השינויים הקטנים הללו צפויים גם לעבור לייצור בתדירות גבוהה יותר. פריסות יכולות לערער את היציבות של מערכת, ולכן ככל שקצב הפריסה עולה, כך גם הסיכון הזה עולה.
תרבות שמודדת את עצמה עם מדדי מהירות כמו מספר פריסות בשבוע ומשתמשת באוטומציה שיכולה להקל על הוספת שינויים בקצב מהיר יותר, צפויה גם לבצע פריסות נוספות בתקופה קצרה יותר.
הגדלת הצפיפות כדי לפשט את הפעולות על-ידי הפחתת מספר משטחי הבקרה והצפייה יכולה להוביל גם לסיכון מוגבר לזמינות מכיוון שתקלה או תצורה שגויה מגדילים את רדיוס ההשפעה של אירוע שמערער יציבות.
פשרות מצוינות תפעולית עם אבטחה
רכיבים שמקיפים את עומס העבודה ותומכים בפעולות שלו, כמו אוטומציה או מישור בקרה מותאם אישית, חייבים להיות גם בטווח של בדיקות והקשחה קבועות של אבטחה.
פעולות שגרתיות, אד-הוק ופעולות חירום מגדילות את נקודות המגע עם עומס העבודה. גישת 'אפס אמון' מחייבת שתהליכים אלו ייחשבו לווקטורי התקפה ויש לכלול אותם בבקרות האבטחה ובאימות עומס העבודה.
פלטפורמת יכולת הצפייה של המערכת אוספת יומנים ומדדים על עומס העבודה, שיכולים להוות מקור רב ערך לחשיפת מידע. לכן, האבטחה של עומס העבודה צריכה להתרחב כדי להגן על קולטי הנתונים מפני איומים פנימיים וחיצוניים.
סוכני בנייה, תצורה חיצונית והחלפת תכונות מגדילים את שטח פני האפליקציה הדורשת אבטחה.
תדירות פריסה גבוהה יותר הנגרמת על-ידי שינויים קטנים ומצטברים או על-ידי פעולות 'התעדכן והישאר מעודכן' מביאה לבדיקות אבטחה נוספות במחזור החיים של פיתוח התוכנה.
פלטפורמות של יכולת צפייה קולטות נתונים מכל הסוגים כדי לקבל תובנות לגבי התקינות של עומס העבודה והתנהגותו. כאשר צוותים מנסים להשיג רמת מהימנות גבוהה יותר בנתוני יכולת צפייה, קיים סיכון מוגבר לכך שבקרות סיווג נתונים, כמו מיסוך נתונים, של מערכות המקור אינן חלות על היומנים ועל קולטי היומנים של פלטפורמת יכולת הצפייה.
מיקום משותף של רכיבי יישומים שונים בסביבות משותפות ומשאבי נתונים כדי להקל על הניהול מבטל את החלוקה למקטעים או מקשה על ביצוע חלוקה למקטעים על בסיס תפקידים. ייתכן שגם רכיבים הממוקמים יחד יצטרכו לחלוק זהות של עומס עבודה, מה שעלול להוביל להקצאת יתר של הרשאות או לחוסר יכולת מעקב.
איסוף כל היומנים מרחבי המערכת בקולט יומני רישום מאוחד יכול להקל על שאילתות ובניית התראות. עם זאת, פעולה זו יכולה גם להפוך את האבטחה המבוססת שורות לקשה יותר או לבלתי אפשרית על מנת לטפל בנתונים רגישים עם בקרות הביקורת הנדרשות.
פישוט הניהול של אבטחה המבוססת על תכונות או תפקידים על-ידי הפחתת הפירוט של התפקידים וההקצאות שלהם עלול להוביל להרשאות רחבות באופן בלתי הולם.
פשרות של מצוינות תפעולית עם מיטוב של חוויה
פיתוח חווית משתמש הדורש משאבים משמעותיים עשוי לרדת בסולם העדיפויות. המצב הזה עשוי לפגוע בשימושיות, באינטראקציות ובעיצוב החזותי של החוויה, הנדרשים למשתמשים בעומס העבודה.
פיתוח של ממשק משתמש נעשה לרוב באיטרציות ובמחזורי משלוח מהירים יותר, מה שעלול להעמיס על תהליכי ה- SDLC (מחזור החיים של פיתוח תוכנה) של הצוות.
פשרות בין מצוינות תפעולית לבין יעילות ביצועים
- מסגרת הניטור של עומס עבודה דורשת מהרכיבים בארכיטקטורה להקצות זמן ומשאבים כדי ליצור, לאסוף ולהזרים יומנים ומדדים. נקודות נתונים אלו מסייעות להבטיח שהתראה וניטור יעילים אפשריים עבור אמינות, אבטחה וביצועים. ככל שרמת המכשור עולה, העומס על משאבי המערכת עשוי גם לגדול.
- כמה דפוסי עיצוב בענן התומכים בגישות "שינוי עצמאי לאורך זמן" לתמיכה באידיאלים של שיפור מצטבר יכולים להכניס חביון עקב מעבר של רכיבים נוספים.
למידע נוסף
משוב
בקרוב: במהלך 2024, נפתור בעיות GitHub כמנגנון המשוב לתוכן ונחליף אותו במערכת משוב חדשה. לקבלת מידע נוסף, ראה: https://aka.ms/ContentUserFeedback.
שלח והצג משוב עבור