AI SRE och AI DevOps i praktiken: låt en Agent hantera flera servrar centralt med PandaSi

Att låta en Agent hantera flera servrar centralt med PandaSi kan börja med en godkänd hanteringsmaskin: kör PandaPaw och Agent på hanteringsmaskinen, låt Agent komma åt målen i en tydlig förteckning via befintlig SSH, VPN eller jump host, verifiera identiteten på varje server, göra batchvisa skrivskyddade inspektioner och sammanställa resultaten; när ändringar behövs, prova först på en enskild server och arbeta sedan i godkända, stegvisa batchar. AI SRE fokuserar på att utreda tillförlitlighetsproblem, medan AI DevOps fokuserar på leverans- och infrastrukturändringar; båda kräver granskningsbara bevis och tydliga behörighetsgränser.

PandaSi tillhandahåller en ingång för sessioner och godkännanden mellan enheter, PandaPaw ansluter till exekveringsmaskinen och de konkreta kommandona körs av vald Agent och dess verktyg. Att slutföra anslutningen innebär inte att man har fått behörighet till företagets servrar, och inte heller att övervakning dygnet runt, automatiska larm eller obemannad reparationsfunktion redan är införd. Nedan riktar vi oss till utvecklare och drifttekniker som redan har behörighet att drifta servrar och som vill följa arbetet från en mobil eller en annan dator, genom hela flödet: anslutning av hanteringsmaskinen, skrivskyddad verifiering av flera maskiner, sammanställning av resultat och stegvisa ändringar. Servrar kan också installeras direkt var för sig, men huvudlinjen för flera maskiner i den här artikeln använder hanteringsmaskinslösningen.

AI SRE och AI DevOps: vad ska Agent hjälpa till med i respektive roll?

De två begreppen beskriver arbetsområden som överlappar. I den här artikeln använder vi följande uppdelning för att förstå dem, inte som två produkter som måste upphandlas separat.

Om en testtjänst till exempel returnerar 502 direkt efter en release: att utreda i vilket lager begäran misslyckas lutar mot AI SRE; att granska releasekonfigurationen som orsakade problemet och förbereda nästa leverans lutar mot AI DevOps. Samma Agent-session kan utföra båda typerna av arbete; det avgörande är uppdragets omfattning, verktygsbehörigheter och acceptanskriterier.

Steg 1: välj exekveringsplats och få företagets godkännande

Skriv innan installationen tydligt ned tre svar: vilken maskin som får anslutas, vilken systemanvändare som ska köra det och vilka kataloger och tjänster som får nås. Bekräfta också före anslutningen om företaget tillåter att loggar eller kod skickas till externa modeller. Att en person kan logga in med SSH betyder inte att företaget har godkänt att personens konto kopplas till en fjärr-Agent.

Alternativ A: köra direkt på servern. Bekräfta först att företaget inte bara godkänner en användarnivå-Agent-tjänst, utan även de ändringar av enhetsnätverk och nätverkstjänster som standardinstallationsflödet innebär; det aktuella installationsskriptet kan på tillämpliga systemd-värdar anropa sudo för att registrera en systemnivå-nätverkstjänst. Få godkännande för installation, privilegiehöjning och nätverksändringar, och installera PandaPaw på servern först när värden uppfyller gällande supportvillkor. Arbetskatalogen, shell och verktyg som väljs därefter tillhör den här exekveringsmaskinen. Använd inte root som standard bara för att det är ”enklare att arbeta”.

Alternativ B: en godkänd hanteringsmaskin ansluter till servern. Om installation inte är tillåten på servern installerar du PandaPaw på en hanteringsmaskin som företaget har godkänt, och Agent körs också där. Hanteringsmaskinen måste redan kunna nå målservern via företagets godkända SSH, VPN eller jump host och ha motsvarande kontobehörighet. Agent använder sedan den befintliga kanalen; PandaSi godkänner inte åtkomst åt dig, kringgår inte en jump host och öppnar inte automatiskt företagets interna nätverk.

Det som lättast blandas ihop i de två vägarna är ”den aktuella maskinen”. I hanteringsmaskinslösningen visar en pwd som Agent kör som standard hanteringsmaskinens katalog; endast kommandon som uttryckligen körs via SSH sker på målservern. Att ett servernamn förekommer i sessionen ersätter inte identitetsverifiering.

Steg 2: installera PandaPaw på exekveringsmaskinen

Gå till arbetsytan via PandaSi, logga in och öppna enhetssidan /devices?add=1, välj att lägga till en enhet och kopiera den engångskommandorad för installation som sidan genererar för det aktuella operativsystemet. Standardinstallationen omfattar konfiguration för enhetsanslutning och kan begära privilegiehöjning och ändra systemets nätverkstjänster; låt först företagets administratör granska installationsinnehållet och godkänna motsvarande behörigheter, och kör sedan kommandot på den exekveringsmaskin som valdes i föregående steg. Om endast användarnivåanslutning har godkänts och inte enhetsnätverk, ska du inte köra artikelns standardinstallationskommando direkt; bekräfta först den godkända installationslösningen med administratören. När ingångs- eller varumärkestexter ändras mellan versioner gäller det som visas i den aktuella arbetsytan; den relaterade värdprocessen finns också i Snabbstart.

Engångskommandot innehåller autentiseringsuppgifter för enhetsparkoppling. Klistra inte in det i chattar, ärenden, offentliga skript eller skärmbilder, och återanvänd inte samma kommando för att ansluta flera maskiner; hämta ett nytt från enhetssidan om det har använts eller gått ut.

Om du inte använder kommandot med engångsuppgifter är basingången för installation på macOS / Linux:

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

Detta laddar ned och kör installationsskriptet, så följ företagets processer för programvaruinstallation och skriptgranskning. Den här gången har vi endast kontrollerat mot aktuell dokumentation och källkod, inte slutfört installation och parkoppling på en ren värd; den offentliga nedladdningsadressen för installationsskriptet har bekräftats vara åtkomlig. Kompatibilitet med värdplattformar och installationsdetaljer finns i PandaPaw-värdguide.

Om kontogodkännandet för basinstallationen inte är slutfört, fortsätt på exekveringsmaskinen:

pandapaw login

Följ den visade enhetsgodkännandeprocessen för att slutföra parkopplingen och kontrollera sedan:

pandapaw status

Om kommandot inte hittas, öppna först en ny terminal så att shell laddar om PATH. Installera eller tvinga inte fram ny inloggning om och om igen ”för att testa”; skilj först på tre fall: binärfilen hittas inte, kontot är inte kopplat och bakgrundstjänsten är onormal.

Steg 3: välj maskin, motor och arbetskatalog

Öppna arbetsytan /agent, välj den nyss anslutna exekveringsmaskinen och välj sedan Claude Code, Codex eller PandaCode samt en godkänd arbetskatalog. Verifiera först med en testkatalog och undvik att börja direkt i produktionskonfigurationskatalogen.

Enhetsparkoppling och modellinloggning är två olika saker. PandaPaw-inloggning innebär att värden har upprättat en anslutning till arbetsytans konto; den valda motorn behöver fortfarande giltig modellauktorisering, prenumeration eller API-konfiguration. Om enheten visas som online men modellen inte svarar, kontrollera först motorns inloggningsprompt, kvot och modellkonfiguration i stället för att bara installera om PandaPaw.

Kontrollera samtidigt motorns verktygsbehörighetsinställningar. Att skriva ”ändra inte först” i chatten är en uppgiftsbegränsning och ersätter inte operativsystemets behörigheter eller motorns godkännandemekanism. När godkännande krävs för varje kommando ska motsvarande behörighetsläge konfigureras; utgå inte från att varje kommando automatiskt visar ett bekräftelsekort.

Steg 4: verifiera identiteten först med en skrivskyddad begäran

Skriv inte ”reparera servern” som första uppgift; skicka först:

Gör endast identitetsverifiering, ändra inga filer eller tjänster. Rapportera aktuellt värdnamn, systemanvändare och absolut arbetskatalog samt lista filnamnen på översta nivån i katalogen. Läs inte .env, privata nycklar eller andra autentiseringsuppgifter. Om målservern behöver nås, förklara först skillnaden mellan den aktuella exekveringsmaskinen och målet och vänta på min kontroll innan du fortsätter.

Identitetsverifieringskommandon som fungerar på Linux / macOS är:

hostname
id -un
pwd

Jämför returvärdena punkt för punkt med det förväntade: är det samma exekveringsmaskin, är det ett godkänt konto och är det rätt projektkatalog? Liknande katalognamn, en enhet som är online eller exitkoden 0 för ett kommando bevisar inte var för sig att anslutningen är korrekt.

Hanteringsmaskinslösningen kräver också separat verifiering i båda ändar. Nedan visas endast användning av ett SSH-alias som företaget redan har konfigurerat; company-test-server är ett exempel och måste bytas mot ett mål som administratören har bekräftat:

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

Stäng inte av värdnyckelverifiering för att lösa prompten vid första anslutningen, och klistra inte in SSH-lösenord eller privata nycklar till Agent. Fjärrens pwd kan vara kontots hemkatalog, så utgå inte från att projektet redan är valt; efterföljande kommandon ska ange den absoluta sökvägen till fjärrprojektet.

Godkännandekriteriet är: svaret motsvarar rätt värd, identitet och katalog; du kan se vad som har körts; behörighetsfrågor visas som förväntat i det aktuella behörighetsläget. Gå därefter in i samma session igen från en mobil eller en annan klient och kontrollera om historiken kan återställas. Det ligger närmare den verkliga användningen än att bara titta på en grön online-punkt.

Steg 5: skapa först en serverförteckning och gör sedan batchvisa skrivskyddade inspektioner

En Agent på en hanteringsmaskin kan anropa befintlig SSH och i tur och ordning nå flera servrar i förteckningen; PandaSi låter dig följa dessa verktygsoperationer och resultat i samma session. ”Central hantering” här kommer från samma exekveringsingång, en tydlig förteckning och en enhetlig rapport; det innebär inte att produkten har inbyggd serverinventering, automatiskt arbetsfördelning mellan anslutningar eller ett gränssnitt för massstyrning med ett klick. Hanteringsmaskinen måste redan ha behörighet till varje mål; att en maskin kan nås innebär inte att andra maskiner i samma nätsegment kan nås.

Lås målen med alias och miljögruppering

Låt administratören underhålla en förteckning utan autentiseringsuppgifter. Alla namn nedan är fiktiva exempel; den faktiska förteckningen ska förvaras på en plats som företaget har godkänt och får inte innehålla lösenord, privata nycklar eller engångskommandon för enheter.

SSH-aliaset är ett namn i hanteringsmaskinens befintliga SSH-konfiguration, inte ett enhetsnamn i PandaSi. Låt administratören verifiera målet, kontot, porten och eventuell nödvändig åtkomstförmedling som aliaset pekar på; bekräfta inte att det är en testmaskin bara för att namnet innehåller test. OpenSSH stöder konfigurationsmatchning via Host-poster, och ett fjärrkommando som anges på kommandoraden körs på målvärden; se Manual för SSH-klientkonfiguration och Manual för ssh-kommandot.

Om PandaPaw är installerat separat på varje server kan du också välja motsvarande exekveringsmaskin i arbetsytan och arbeta maskin för maskin; men tolka inte ”flera maskiner är online” som att en session automatiskt schemalägger alla anslutningar. Fortsättningsvis använder artikeln genomgående lösningen där hanteringsmaskinen går via befintlig SSH, så att två exekveringsplatser inte blandas i samma rapport.

Verifiera först seriellt och begränsa sedan inspektionspunkterna

Första gången gör du identitetsverifiering maskin för maskin enligt förteckningen, utan att läsa applikationskonfiguration eller fullständiga loggar. Nedan följer ett seriellt Bash-exempel för hanteringsmaskinen som endast listar de två testmaskiner som är tillåtna i denna omgång; det gör ingen automatisk miljöidentifiering och ersätter inte manuell kontroll av förväntad identitet.

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

Dessa kommandon illustrerar endast organisationen och kördes inte på de två exempelvärdarna i den här artikeln. BatchMode=yes gör att autentisering misslyckas utan att vänta på interaktiv inmatning; ConnectTimeout=5 begränsar steget där anslutningen upprättas, inte den totala tidsgränsen för hela fjärrkommandot. Den totala körtidsgränsen bör anges separat av ett godkänt verktyg eller en uppgiftskörare. Stäng inte av värdnyckelverifiering för batchkörning; en jump host som kräver interaktiv MFA ska använda företagets godkända åtkomstflöde och inte det här icke-interaktiva exemplet.

Efter kommandona: jämför först varje maskin mot förväntat värdnamn och konto i förteckningen och kontrollera sedan den godkända fjärrprojektets sökväg. pwd i utdata ovan är vanligtvis bara fjärrens inloggningskatalog och bevisar inte att projektsökvägen är korrekt. Exitkoden 0 betyder bara att just dessa kommandon slutfördes; det betyder inte att värdens identitet matchar och ännu mindre att affärstjänsten är frisk. Om någon maskins identitet inte stämmer markerar du målet som blockerat och fortsätter inte läsa affärsdata; om det finns gemensamma tveksamheter i samma miljö eller åtkomstkanal pausar du hela kontrollen.

Efter godkänd identitetsverifiering låter du Agent köra samma uppsättning godkända skrivskyddade kontroller på denna omgångs testmaskiner: status för angivna tjänster, förväntade lyssnande portar, återstående diskutrymme, en avidentifierad felsammanfattning inom ett angivet tidsfönster och en godkänd hälsokontrollbegäran. Utöka inte ”inspektion” till att installera prober, läsa alla kataloger rekursivt eller automatiskt reparera. Kontrollkommandon skiljer sig mellan operativsystem, tjänstehanterare och applikationer; komplettera enligt förteckningen och tvinga inte in samma kommando på alla värdar.

Förtydliga körningsgränserna med en prompt

Du kör på hanteringsmaskinen. Få endast åtkomst till test-web-01 och test-worker-01 i testgruppen enligt den godkända serverförteckningen; skanna inte nya adresser och få inte åtkomst till production-gruppen. Verifiera först seriellt värdnamn, användare och absolut sökväg till fjärrprojektet på varje maskin; blockera målet om det inte stämmer med förteckningen. Efter godkänd kontroll får du endast kontrollera tjänstestatus, portar, disk och hälsokontrollbegäran som uttryckligen auktoriserats i förteckningen; ta endast avidentifierade loggutdrag från det angivna tidsfönstret. Kör hela första omgången seriellt, ändra ingen konfiguration, starta inte om, installera inga beroenden och höj inte behörigheter automatiskt. Om en enskild anslutning misslyckas ska felet bevaras och oberoende skrivskyddade kontroller av andra verifierade mål fortsätta; om miljötillhörighet eller gemensamma åtkomstkanaler verkar onormala pausar du hela batchen. Registrera tid och tidszon, kommando, exitstatus, viktiga bevis och ej slutförda punkter separat för varje maskin och sammanställ slutligen per server. Ge separata förslag på eventuella reparationer; utför dem inte.

Detta är en uppgiftsbegränsning och bör kombineras med skrivskyddade konton, godkännande av motorns verktyg och begränsad nätverksåtkomst. Att skriva ”ändra inte” i prompten gör inte automatiskt ett skrivbart konto skrivskyddat.

Begränsa samtidigheten och låt fel stanna vid rätt mål

Första inspektionen görs seriellt för enklare kontroll; när det finns många mål kan du, inom företagets tillåtna sätt att köra verktyg, ange en låg samtidighetsgräns, till exempel högst två kontroller samtidigt. ”Två” här är en exempelbudget för arbetet, inte en produktgräns eller prestandagaranti för PandaSi. Om vald Agent eller valt verktyg inte kan begränsa samtidigheten tillförlitligt, fortsätt seriellt och ersätt inte med tillfälliga obegränsade bakgrundsjobb.

Ge varje kontroll en egen tidsgräns och egen resultatpost; ett misslyckat mål ska inte utlösa omstart, ominstallation eller oändliga omförsök för hela batchen. Registrera anslutningstimeout, identitetsavvikelse, otillräcklig behörighet och misslyckat kontrollkommando separat och tryck inte ihop allt till ”offline”. Om felet kommer från en gemensam jump host, autentiseringskälla eller oklar miljötillhörighet ska du stanna och kontrollera de gemensamma orsakerna i stället för att fortsätta öka samtidigheten.

Sammanställningstabellen måste för varje maskin visa om identiteten matchar, vilka kontroller som faktiskt kördes, viktiga bevis och okända punkter. Nedan visas endast postformatet; texten i tabellen är ifyllnadsanvisningar, inte uppmätta resultat:

Rapporten ska ange ”hur många som planerades kontrolleras, hur många som slutfördes, hur många som misslyckades och hur många som hoppades över” samt ge bevis för varje mål. När resultat saknas får du inte anta att allt är friskt; att ett batchkommando till slut har exitkod 0 får inte heller dölja att en enskild maskin redan har misslyckats under vägen.

Steg 6: genomför först 502-utredning och återställning på en testtjänst

Följande är ett undervisningsexempel, inte en incident som mätts i den här artikeln och inte en uppsättning reparationskommandon som kan kopieras rakt av till alla servrar. Anta att en godkänd testtjänst returnerar 502 efter en release och att du redan känner till testdomänen, tjänstenamnet och projektkatalogen.

Avgränsa först utredningen

Du kan formulera uppgiften så här:

Utred 502-felet efter releasen av testtjänsten. Verifiera först målvärd, användare och katalog och kontrollera skrivskyddat den senaste releaseposten, relevant tjänstestatus, lyssnande portar samt proxy- och applikationsloggar inom det angivna tidsfönstret. Starta inte om, ändra inte konfiguration, installera inga beroenden och få inte åtkomst till andra miljöer. Returnera endast avidentifierade utdrag som är relevanta för den här incidenten och lista bevis, möjliga orsaker och vilken information som saknas.

Ange tidsfönster och tydliga loggkällor först, så att Agent inte rekursivt går igenom hela servern. Även skrivskyddad åtkomst kan läcka data: token, kundinformation och begärandetexter i loggar måste fortfarande filtreras innan de når modellens kontext, inte skickas och sedan få modellen att ”glömma” dem.

502 visar att proxyn inte kunde få ett användbart svar från uppströms, men statuskoden ensam avgör inte om det beror på att en process har avslutats, portmatchningsfel, onormalt beroende eller anslutningsproblem. Låt Agent jämföra proxyns uppströmsadress, faktiska lyssnande och loggar från samma tidsperiod; enhetliga tidszoner för loggar mellan maskiner först. Behandla inte ”maskinen är online” som ”applikationen är frisk” och inte heller avsaknad av matchande loggar som att inget fel har inträffat.

Begär granskningsbara reparationsförslag

Om bevisen stöder att ”uppströmsporten i releasekonfigurationen inte stämmer med det faktiska lyssnandet”, låt Agent lämna den specifika filen och minsta möjliga diff, kommandon som planeras köras, påverkad testtjänst, metod för konfigurationskontroll och återställningsvillkor. Även detta är bara ett villkorat exempel; om bevisen inte stöder det ska utredningen fortsätta.

Det som godkänns ska vara en specifik ändring, inte ”du har fullt ansvar”. Godkänn till exempel att ändra en angiven testproxykonfiguration och att ladda om testproxyn efter att konfigurationskontrollen har godkänts; du får inte samtidigt uppgradera beroenden, rensa databasen, ändra produktionskonfiguration eller starta om hela värden. De faktiska kommandona måste fastställas utifrån den processhanterare och de distributionregler som används.

Verifiera användarvägen efter utförandet

Efter godkänt utförande ska acceptansen minst omfatta: om konfigurationskontrollen godkändes, om relevanta processer och portar matchar förväntan, om hälsokontrollendpointen fungerar och om en faktisk testbegäran från en fristående klient via den ursprungliga ingången har återställts. Om hälsokontrollendpointen ger 200 men affärsroutning, autentisering eller databasbegäranden fortfarande misslyckas, får det inte skrivas som ”problemet är löst”.

Låt slutligen Agent sammanställa körda kommandon, faktiska ändringar, verifieringsresultat och kvarvarande risker; skriv uttryckligen okänt för punkter som inte har verifierats. Lämna tillbaka bekräftad orsak och åtgärder för att förhindra återfall till företagets ärendesystem. Utredningsfasen är AI SRE-stöd; när korrigeringen senare förs in i konfigurationsrepot och releaseprocessen sträcker det sig till AI DevOps.

Steg 7: ändra andra servrar i batchar först efter att en enskild maskin har godkänts

Auktorisering för batchvis inspektion och batchvisa ändringar ska hållas åtskilda. Att flera tjänster har olika versioner innebär inte att alla kan uppgraderas direkt; tjänster med samma namn kan ha olika roller eller använda olika konfigurationer. Kontrollera först om skillnaderna är förväntade och lägg sedan fram en ändringsplan som listar varje mål för sig.

Välj endast en tydlig testmaskin i första batchen. I planen ska målalias, verifierad värdidentitet, ursprunglig version eller konfiguration, planerad diff, förväntad påverkan, kontrollmetod, återställningssteg och stoppvillkor vara fasta. Kör den här maskinen efter godkännande och vänta på acceptans av hälsokontrollendpoint och faktisk användarväg; utan bevis på återställning får status inte markeras som lyckad och nästa batch får inte påbörjas.

Efter godkänt prov anger du nästa batchs mållista, batchstorlek och samtidighetsgräns uttryckligen; använd inte ett implicit omfång som ”alla återstående maskiner” som ändras med förteckningen. I slutet av varje batch kontrollerar du faktisk version och begäranderesultat och registrerar lyckade, misslyckade och ej körda mål. Om identitetsavvikelse, misslyckad konfigurationskontroll, försämrade affärsbegäranden eller misslyckad återställning uppstår ska efterföljande batchar stoppas och bevis bevaras för ansvarig; behandla inte godkännande i testfasen som produktionsgodkännande.

Återställning måste också definieras per maskin. Konfigurationsändringar kan återställas till tidigare konfiguration på ett godkänt sätt; när databasmigreringar, dataskrivningar eller sidoeffekter i externa system är inblandade får du inte anta att ”byta tillbaka till den gamla versionen” upphäver påverkan, utan ansvarig måste först fastställa återställningsplanen. Återställ endast mål som faktiskt har ändrats och behöver återställas; kör inte omvända kommandon urskillningslöst på hela gruppen.

Du kan formulera nästa uppgift så här:

Baserat på bevisen från denna maskin-för-maskin-inspektion ska du först endast föreslå en reparationsplan för test-web-01 och inte utföra den. Lista den verifierade värdidentiteten, den specifika diffen, fullständiga kommandon, påverkan, återställningssteg, acceptansbegäran och stoppvillkor. Utför först efter uttryckligt godkännande för den här maskinen; lämna faktiska bevis när det är klart och vänta på auktorisering för nästa batchmål. Maskiner utan godkännande förblir ej körda. Produktionsgruppen ingår inte i denna omgång och kan inte ärva testgodkännandet.

När både test och produktion behöver hanteras ska produktion gå igenom företagets separata ändringsprocess. En enhetlig hanteringsingång eliminerar inte miljöisolering, underhållsfönster, releasegodkännanden eller revisionskrav.

När mobilen tappar anslutningen: bekräfta först uppgiftens status

Att stänga klienten, att mobilen går till bakgrunden eller att nätverket kopplas ned ska inte tolkas som att fjärrkommandot har stoppats. Processer på exekveringsmaskinen kan fortsätta köra; de kan också misslyckas på grund av att värden tappar anslutningen, att motorn avslutas eller att fjärrkanalen begränsas. Gå tillbaka till den ursprungliga sessionen och titta först på verktygsresultaten och kontrollera sedan processer, artefakter och tjänstestatus så att du inte startar om installation, release eller migrering i onödan.

Fjärrkommandokedjan kan visa ”ingen exitstatus returnerades”: en timeout i anslutningslagret betyder inte att kommandot inte har startat. Långa uppgifter behöver tydliga tidsgränser, statusregistrering och sätt att avbryta i företagets exekveringskanal, särskilt när flera SSH-hopp är inblandade. Den här artikeln behandlar inte en viss versions kanaltimeout som en allmän regel för alla SSH-verktyg.

När något behöver stoppas använder du en tydlig stoppåtgärd och verifierar fjärrexekveringens status; vid icke-idempotenta ändringar med oklar status ska en människa ta över och bekräfta först. Försök inte avgöra om föregående körning lyckades genom att klicka upprepade gånger eller skicka samma instruktion igen.

Vad har företagets och hemmets enhetsnätverk med den här artikeln att göra?

Den här artikeln förutsätter att den godkända åtkomstkanalen från hanteringsmaskinen till varje server redan finns; fokus ligger på hur Agent organiserar arbetet per mål. Hur flera enheter i företaget och hemmet ansluts till nätverk, når varandra och hanterar nätverksgränser är en annan anslutningsuppgift som inte blandas in här; att nätverket fungerar innebär inte heller att du har rätt att drifta alla enheter i det. Om du behöver förstå enhetsanslutning kan du först läsa den befintliga Beskrivning av enhetsanslutning och följa företagets nätverksgodkännandeprocess.

Gränser för företagsdata, modeller och relä

”Verktyg körs lokalt” beskriver exekveringsplatsen och lovar inte att data aldrig lämnar företaget. Sessionsmeddelanden och godkännanden går genom produktens kommunikationskanal; loggar, kod och verktygsutdata som ges till Agent kan också ingå i begäranden till vald modellleverantör. Kontrollera företagets godkända modeller, datahanteringsvillkor, loggbevarande och åtkomstpolicy före anslutning.

Behåll befintlig nyckelhantering och revisionsprocess; autentiseringsuppgifter ska läsas från den godkända autentiseringslösningen på exekveringsmaskinen och inte klistras in i chattar eller kodarkiv. Begränsa körkontot och nätverkets åtkomstomfång och ge logg- och katalogbehörigheter efter behov. Vid avslutad anställning, skrotning av utrustning eller behörighetsändring ska du samtidigt hantera enhetsauktorisering i arbetsytan, kontot på exekveringsmaskinen och åtkomsträtten till målservern; att ta bort en klient är inte samma sak som att återkalla alla exekveringsbehörigheter.

Vanliga frågor (FAQ)

Kan PandaSi automatiskt ha jour, ta emot larm och reparera produktion?

Den här artikeln handlar om fjärrsessioner, auktoriserade åtgärder och manuella uppföljningsflöden. Övervakning dygnet runt, larmintegration, automatiska utlösare och obemannad reparation kräver ytterligare övervakningssystem, utlösare, runbooks och behörighetsstyrning; dessa förmågor kan inte härledas från en lyckad anslutning.

Går det att använda om företagets servrar inte får installera programvara?

Du kan överväga den godkända hanteringsmaskinslösningen, förutsatt att hanteringsmaskinen redan har laglig nätverks- och identitetsbehörighet att nå målen. Om företaget också förbjuder den här typen av extern Agent-anslutning ska du först gå igenom godkännandeprocessen i stället för att byta till en dold anslutningsväg.

Behöver servern öppna en offentlig SSH-port?

PandaPaw:s sessionsanslutning upprättas genom att båda sidor aktivt gör utgående anslutningar, så det behövs vanligtvis inga nya offentliga inkommande portar för klientanslutning. Men hanteringsmaskinen måste fortfarande ha en företagsgodkänd åtkomstkanal till målservern; om utgående trafik är begränsad ska nätverksadministratören konfigurera det och du ska inte själv stänga av skyddet.

Måste PandaPaw installeras på varje server?

Hanteringsmaskinslösningen i den här artikeln kräver inte att PandaPaw installeras på varje SSH-mål, men hanteringsmaskinen måste ha en godkänd nätverkskanal och ett fjärrkonto. I direktinstallationslösningen körs Agent på respektive värd och ansluts var för sig; blanda inte ihop de två till en och samma automatiska massstyrningsförmåga.

Om en maskins inspektion misslyckas, kan andra maskiner fortsätta?

För skrivskyddade kontroller som är identitetsverifierade och oberoende av varandra kan du bevara bevisen för målets fel och fortsätta med andra mål; om det handlar om ett gemensamt åtkomstfel eller tveksamhet kring miljötillhörighet ska hela batchen pausas. Ändringsfasen följer de godkända stoppvillkoren och regeln ”inspektion kan fortsätta” får inte tillämpas.

Vad ska accepteras först efter anslutningen?

Verifiera först hanteringsmaskinen, modellsvar och sessionsåterställning, kontrollera sedan målens identitet, kataloger och behörigheter maskin för maskin enligt förteckningen, slutför skrivskyddad inspektion och resultatsammanställning och gå slutligen igenom godkännande, acceptans av faktiska begäranden och efterföljande batchflöde på en testtjänst. Värdet med anslutningen är att auktoriserade uppgifter kan följas upp kontinuerligt; om det är lämpligt att utöka till fler tjänster bör avgöras utifrån bevisen från denna acceptans.

Källor och granskningsomfång

Den här artikelns första utkast granskades den 31 oktober 2026 mot projektets snabbstart, PandaPaw-värddokumentation, logiken för generering av enhetsinstallationskommandon och den offentliga nedladdningsadressen för installationsskriptet; den 1 november kompletterades flödet för arbete med flera maskiner och SSH-konfiguration och parametersemantik kontrollerades mot OpenSSH:s officiella manualer. Den här gången har vi endast kontrollerat mot aktuell dokumentation och källkod, inte slutfört installation och parkoppling på en ren värd och inte heller kört artikelns inspektion, batchvisa ändringar eller 502-exempel i en verklig miljö med flera maskiner; varje företags nätverk, motorns godkännanden och datakompatibilitet måste accepteras i den egna testmiljön. Illustrationerna är AI-genererade koncept- eller processbilder, inte skärmbilder av gränssnittet.