פתרון אבחון וניהול

פתרון התרגיל הראשון

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

נוסיף לכלי ההרצאה את הפונקציה הבאה ואת הheaders הנדרשים. נחליף את חתימת main לint main(int argc, char** argv), נקרא לפונקציה בתחילת הtry, ובתנאי הלולאה נשתמש בערך שקיבלנו במקום 10.

#include <charconv>
#include <string_view>
#include <system_error>

unsigned read_limit(int argc, char** argv) {
    if (argc == 1) return 10;
    if (argc != 2) throw std::invalid_argument("use: events [1..100]");
    std::string_view text(argv[1]);
    unsigned value = 0;
    auto [end, error] = std::from_chars(text.data(), text.data() + text.size(), value);
    if (error != std::errc{} || end != text.data() + text.size() ||
        value < 1 || value > 100)
        throw std::invalid_argument("limit must be 1..100");
    return value;
}

הבדיקה של end מונעת קבלה של 12abc כאילו נכתב 12. הגבול העליון אינו עניין של parsing בלבד; הוא חלק מתקציב העבודה של כלי האבחון.

פתרון התרגיל השני

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

למשל, עבודה 41 התקבלה בהרצה א, התחילה בניסיון 1 ולא נצפה סיום. בהרצה ב נמצא record מתמשך שלה ונוצר אירוע recovery, ואז התחיל ניסיון 2. כלי החקירה מחבר לפי מזהה העבודה היציב, ומחזיק את ההרצות והניסיונות כשדות נפרדים. הוא לא מסיק שהניסיון הראשון לא ביצע דבר רק מפני שחסר אירוע סיום.

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

פתרון התרגיל השלישי

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

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

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