AI SRE ו-AI DevOps בפרקטיקה: שימוש ב-PandaSi כדי ש-Agent ינהל באופן מרכזי מספר שרתים

ניהול מרכזי של מספר שרתים באמצעות PandaSi יכול להתחיל ממכונת ניהול מורשית אחת: מריצים במכונת הניהול את PandaPaw ואת ה-Agent, וה-Agent ניגש דרך SSH, VPN או שרת Bastion קיימים ליעדים המופיעים במלאי מפורש, מאמת זהות בכל שרת בנפרד, מבצע בדיקות קריאה בלבד בקבוצות ומרכז את התוצאות; כשצריך לבצע שינוי, מנסים קודם בשרת אחד, ואז מתקדמים בקבוצות בכפוף לאישור. AI SRE מתמקד בחקירת בעיות אמינות, AI DevOps מתמקד במסירה ובשינויי תשתית, ושניהם זקוקים לראיות ניתנות לבדיקה ולגבולות הרשאה.

PandaSi מספקת נקודת כניסה לשיחות ולאישורים חוצי-מכשירים, PandaPaw מתחבר למכונת ההרצה, והפקודות בפועל מבוצעות על ידי ה-Agent הנבחר והכלים שלו. השלמת החיבור אינה שווה לקבלת הרשאה לשרתי החברה, ואינה שווה לפריסה של ניטור 24/7, קבלת התראות אוטומטית או תיקון ללא השגחה. ההמשך מיועד למפתחים ולאנשי תפעול שכבר יש להם הרשאות תפעול שרתים ורוצים לעקוב אחרי העבודה מהטלפון או ממחשב אחר, ומלווה אותם דרך חיבור מכונת הניהול, אימות קריאה בלבד במספר מכונות, ריכוז תוצאות ותהליך שינוי מדורג. אפשר גם להתקין ישירות על כל שרת בנפרד, אך קו העבודה הרב-מכוני במאמר זה משתמש בגישת מכונת הניהול.

AI SRE ו-AI DevOps: במה ה-Agent עוזר בכל אחד מהם?

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

לדוגמה, שירות בדיקה שמחזיר 502 מיד לאחר שחרור: חקירת השאלה באיזה שלב נכשלת הבקשה נוטה ל-AI SRE; סקירת תצורת השחרור שגרמה לבעיה והכנת המסירה הבאה נוטה ל-AI DevOps. אותה שיחת Agent יכולה לבצע את שני סוגי העבודה; העיקר הוא היקף המשימה, הרשאות הכלים ותנאי הקבלה.

שלב ראשון: בחירת מקום ההרצה וקבלת אישור מהחברה

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

מסלול A: הרצה ישירה על השרת. יש לוודא תחילה שהחברה אישרה לא רק שירות Agent ברמת משתמש, אלא גם שינויי רשתות ושירותי רשת הכרוכים בתהליך ההתקנה המוגדר כברירת מחדל; סקריפט ההתקנה הנוכחי עשוי להפעיל sudo במארחי systemd מתאימים כדי לרשום שירות רשת ברמת המערכת. רק לאחר קבלת אישור להתקנה, להעלאת הרשאות ולשינוי רשת, ובכפוף לכך שהמארח עומד בתנאי התמיכה הנוכחיים, מתקינים PandaPaw על השרת. תיקיית העבודה, ה-shell והכלים שנבחרים לאחר מכן שייכים למכונת ההרצה הזאת. אין להשתמש כברירת מחדל ב-root רק מפני ש"זה נוח יותר לתפעול".

מסלול B: מעבר משרת ממכונת ניהול מורשית. אם אסור להתקין על השרת, מתקינים PandaPaw על מכונת ניהול שאושרה על ידי החברה, וה-Agent רץ גם שם. מכונת הניהול חייבת כבר להגיע לשרתי היעד דרך SSH, VPN או שרת Bastion שאושרו על ידי החברה, ועם הרשאות החשבון המתאימות. ה-Agent משתמש בערוץ הקיים הזה; PandaSi לא מאשרת גישה במקומך, לא עוקפת שרת Bastion ולא פותחת אוטומטית את הרשת הפנימית של החברה.

הנקודה המבלבלת ביותר בשני המסלולים היא "המכונה הנוכחית". בגישת מכונת הניהול, כשה-Agent מריץ כברירת מחדל pwd, הוא רואה תיקייה במכונת הניהול; רק פקודה שמופעלת במפורש דרך SSH מתרחשת בשרת היעד. הופעת שם שרת בשיחה אינה מחליפה אימות זהות.

שלב שני: התקנת PandaPaw במכונת ההרצה

נכנסים ל-PandaSi, פותחים את סביבת העבודה, מתחברים ופותחים את עמוד המכשירים /devices?add=1, בוחרים הוספת מכשיר ומעתיקים את פקודת ההתקנה החד-פעמית שהעמוד יוצר עבור מערכת ההפעלה הנוכחית. ההתקנה כברירת מחדל כוללת תצורת קישוריות בין מכשירים, ועשויה לדרוש העלאת הרשאות ולשנות שירותי רשת במערכת; קודם נותנים למנהל החברה לבדוק את תוכן ההתקנה ולאשר את ההרשאות המתאימות, ורק אחר כך מריצים את הפקודה במכונת ההרצה שנבחרה בשלב הקודם. אם אושרה רק גישה ברמת משתמש ולא אושרה קישוריות רשת בין מכשירים, אין להריץ ישירות את פקודת ההתקנה המוגדרת כברירת מחדל במאמר זה, ויש לברר עם המנהל מהי תוכנית ההתקנה המאושרת. אם נוסח הכניסה או המיתוג משתנה בין גרסאות, יש להסתמך על מה שמוצג בסביבת העבודה הנוכחית; אפשר גם לעיין בהתחלה מהירה לגבי תהליכי המארח הרלוונטיים.

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

אם לא משתמשים בפקודה עם פרטי זיהוי חד-פעמיים, נקודת הכניסה הבסיסית להתקנה ב-macOS / Linux היא:

curl -fsSL https://cos.pandanpc.com/pandapaw/install.sh | sh

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

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

pandapaw login

משלימים את הצימוד לפי תהליך הרשאת המכשיר שמוצג, ואז בודקים:

pandapaw status

אם הפקודה לא נמצאה, פותחים תחילה מסוף חדש כדי שה-shell יטען מחדש את PATH. אין להתקין שוב ושוב או לכפות התחברות מחדש רק "כדי לנסות"; קודם מבדילים בין שלושה מצבים: הקובץ הבינרי לא נמצא, החשבון לא קושר, או שירות הרקע תקול.

שלב שלישי: בחירת מכונה, מנוע ותיקיית עבודה

פותחים את סביבת העבודה /agent, בוחרים את מכונת ההרצה שחוברה זה עתה, ואז בוחרים Claude Code, Codex או PandaCode, ואת תיקיית העבודה המורשית. מתחילים בבדיקה בתיקיית בדיקה, כדי לא להיכנס מיד לתיקיית תצורת ייצור.

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

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

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

במשימה הראשונה אין לכתוב "תקן את השרת". שולחים קודם:

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

פקודות אימות הזהות הזמינות ב-Linux / macOS הן:

hostname
id -un
pwd

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

בגישת מכונת הניהול יש לאמת גם את שני הקצוות בנפרד. להלן מודגם רק שימוש בכינוי SSH שכבר הוגדר בחברה; company-test-server הוא דוגמה, ויש להחליפו ביעד שאושר על ידי המנהל:

ssh company-test-server 'hostname; id -un; pwd'

אין לפתור את הודעת החיבור הראשוני על ידי ביטול אימות מפתח המארח, ואין להדביק ל-Agent סיסמת SSH או מפתח פרטי. ייתכן ש-pwd המרוחק הוא תיקיית הבית של החשבון, ואין להסיק ממנו שהפרויקט כבר נבחר; פקודות המשך צריכות לכלול את הנתיב המוחלט של הפרויקט המרוחק.

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

שלב חמישי: בניית מלאי שרתים תחילה, ואז בדיקות קריאה בלבד בקבוצות

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

נעילת היעדים באמצעות כינויים וקיבוץ לפי סביבה

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

כינוי SSH הוא שם בתצורת ה-SSH הקיימת של מכונת הניהול, ולא שם מכשיר ב-PandaSi. המנהל מאמת את היעד, החשבון, הפורט ואת מתווך הגישה הנדרש שמתאימים לכינוי; אין להסתפק בשם שמכיל test כדי לקבוע שזו מכונת בדיקה. OpenSSH תומך בהתאמת תצורה לפי ערכי Host, ופקודה מרוחקת שמוגדרת בשורת הפקודה תרוץ במארח היעד; ראו מדריך תצורת לקוח SSH ומדריך פקודת SSH.

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

אימות סדרתי תחילה, ואז הגבלת פריטי הבדיקה

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

for target in test-web-01 test-worker-01; do
  printf '\nTARGET %s\n' "$target"
  if ssh -T -o BatchMode=yes -o ConnectTimeout=5 "$target" \
    'hostname && id -un && pwd'; then
    printf 'IDENTITY_COMMAND_COMPLETED %s\n' "$target"
  else
    result=$?
    printf 'IDENTITY_COMMAND_FAILED %s exit=%s\n' "$target" "$result" >&2
  fi
done

הפקודות משמשות רק להמחשת אופן הארגון, והמאמר לא הריץ אותן בשתי מכונות הדוגמה האלה. BatchMode=yes מונע המתנה לקלט אינטראקטיבי כאשר האימות נכשל; ConnectTimeout=5 מגביל את שלב יצירת החיבור, ולא את משך הפקודה המרוחקת כולה. יש להגדיר מגבלת זמן כוללת בנפרד באמצעות כלי או מריץ משימות מורשה. אין לבטל אימות מפתח מארח כדי להריץ בקבוצה; שרת Bastion שדורש MFA אינטראקטיבי צריך להשתמש בתהליך גישה מאושר על ידי החברה, ולא בדוגמה הלא-אינטראקטיבית הזאת.

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

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

ניסוח גבולות הביצוע באמצעות הנחיה אחת

אתה רץ במכונת הניהול. גש רק לפי מלאי השרתים המאושר לקבוצת test: test-web-01 ו-test-worker-01, ואל תסרוק כתובות חדשות ואל תיגש לקבוצת production. תחילה אמת באופן סדרתי בכל מארח את שם המארח, המשתמש ואת הנתיב המוחלט של הפרויקט המרוחק, וחסום את היעד אם הוא אינו תואם למלאי. לאחר מעבר, בדוק רק את מצב השירותים, הפורטים, הדיסק ובקשות הבריאות המפורטים במפורש בהרשאה; מתוך הלוגים קח רק קטעים ממוסכים בחלון הזמן הנקוב. לראשונה בצע הכול באופן סדרתי, אל תשנה תצורה, אל תפעיל מחדש, אל תתקין תלויות ואל תעלה הרשאות אוטומטית. אם חיבור ליעד אחד נכשל, שמור את השגיאה והמשך בבדיקות קריאה בלבד עצמאיות ביעדים מאומתים אחרים; אם מתגלה בעיה בשיוך הסביבה או בערוץ הגישה המשותף, עצור את כל הסיבוב. רשום לכל מארח בנפרד זמן ואזור זמן, פקודה, מצב יציאה, ראיות מרכזיות ופריטים שלא הושלמו, ולבסוף סכם לפי שרת. לכל תיקון אפשרי תן המלצה נפרדת, ואל תבצע אותו.

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

הגבלת מקביליות והשארת כשל ביעד המתאים

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

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

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

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

שלב שישי: השלמת חקירת 502 ושחזור על שירות בדיקה אחד

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

הגבלת היקף החקירה תחילה

אפשר לנסח את המשימה כך:

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

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

502 מציין שה-proxy לא קיבל תגובת upstream זמינה, אך מקוד הסטטוס לבדו אי אפשר לקבוע אם התהליך יצא, אם יש אי-התאמה בפורט, אם יש חריגה בתלות או אם מדובר בבעיית חיבור. מבקשים מה-Agent ליישר את כתובת ה-upstream של ה-proxy, את ההאזנה בפועל ואת הלוגים באותו פרק זמן; בלוגים ממכונות שונות מאחדים תחילה אזורי זמן. אין להתייחס ל"המכונה מקוונת" כ"האפליקציה בריאה", ואין להסיק מהיעדר לוג תואם שלא אירעה שגיאה.

דרישה להצעת תיקון ניתנת לבדיקה

אם הראיות תומכות בכך ש"הפורט של ה-upstream בתצורת השחרור אינו תואם להאזנה בפועל", מבקשים מה-Agent להגיש קובץ ספציפי והבדל מינימלי, הפקודה המתוכננת, שירות הבדיקה המושפע, שיטת בדיקת התצורה ותנאי rollback. זו עדיין דוגמה מותנית בלבד; אם הראיות אינן תומכות, ממשיכים לחקור.

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

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

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

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

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

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

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

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

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

אפשר לנסח את המשימה הבאה כך:

לפי ראיות הבדיקה שרת-שרת מהסיבוב הזה, הצע תחילה תוכנית תיקון רק עבור test-web-01, ואל תבצע. פרט את זהות המארח לאחר אימות, את ההבדל הקונקרטי, את הפקודה המלאה, את ההשפעה, שלבי ה-rollback, בקשת הקבלה ותנאי העצירה. אפשר לבצע רק לאחר אישור מפורש למכונה הזאת; לאחר ההשלמה מסור ראיות בפועל והמתן להרשאה ליעדי הקבוצה הבאה. מכונות שלא אושרו נשארות ללא ביצוע. קבוצת production אינה בהיקף הזה, ואין לרשת את אישור הבדיקה.

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

לאחר ניתוק הטלפון, קודם מאמתים את מצב המשימה

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

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

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

מה הקשר בין קישוריות רשת של מכשירי חברה ובית לבין המאמר הזה?

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

גבולות נתוני החברה, המודל והממסר

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

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

FAQ

האם PandaSi יכולה לעשות תורנות אוטומטית, לקלוט התראות ולתקן ייצור?

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

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

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

האם צריך לפתוח פורט SSH ציבורי בשרת?

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

האם חייבים להתקין PandaPaw על כל שרת?

מסלול מכונת הניהול במאמר זה אינו דורש להתקין PandaPaw על כל יעד SSH, אך מכונת הניהול חייבת ערוץ רשת מאושר וחשבון מרוחק. במסלול התקנה ישירה מריצים את ה-Agent על המארח המתאים, וכל אחד מתחבר בנפרד; אין לערבב בין השניים כיכולת שליטה המונית אוטומטית אחת.

אם בדיקה של מכונה אחת נכשלת, אפשר להמשיך במכונות אחרות?

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

מה מאמתים קודם לאחר החיבור?

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

מקורות והיקף הבדיקה

הטיוטה הראשונה של מאמר זה נבדקה ב-31 באוקטובר 2026 מול ההתחלה המהירה של הפרויקט, תיעוד מארח PandaPaw, לוגיקת יצירת פקודת התקנת המכשיר ונקודת ההורדה של סקריפט ההתקנה הציבורי; ב-1 בנובמבר נוסף תהליך העבודה הרב-מכוני, ונבדקו מול המדריך הרשמי של OpenSSH המשמעות של תצורת SSH והפרמטרים. הפעם בדקנו רק לפי התיעוד והקוד הנוכחיים, ולא השלמנו התקנה וצימוד בפועל על מארח נקי, וגם לא הרצנו בסביבת ריבוי מכונות אמיתית את הבדיקות, השינויים המדורגים או דוגמת ה-502 במאמר; רשתות החברה, אישורי המנוע וציות הנתונים צריכים להיבחן בסביבת הבדיקה של כל חברה. כל התמונות הן המחשות מושגיות או תרשימי תהליך שנוצרו ב-AI, ולא צילומי מסך של ממשק.