AI SRE og AI DevOps i praksis: La en Agent administrere flere servere sentralt med PandaSi

Med PandaSi kan en Agent administrere flere servere sentralt, og du kan starte fra én godkjent administrasjonsmaskin: Kjør PandaPaw og Agent på administrasjonsmaskinen, og la Agent få tilgang til målene i en tydelig liste via eksisterende SSH, VPN eller bastionvert, kontrollere identiteten på hver maskin, utføre batchvis skrivebeskyttet inspeksjon og oppsummere resultatene; når det er behov for endringer, prøver du først på én maskin og ruller deretter ut i godkjente batcher. AI SRE fokuserer på å undersøke pålitelighetsproblemer, mens AI DevOps fokuserer på levering og endringer i infrastrukturen; begge krever etterprøvbare bevis og tydelige tillatelsesgrenser.

PandaSi gir en felles inngang for økter og godkjenninger på tvers av enheter, PandaPaw kobler til utførelsesmaskinen, og de konkrete kommandoene utføres av den valgte Agent og verktøyene dens. Å fullføre tilkoblingen betyr ikke at du har fått tilgang til selskapets servere, og det betyr heller ikke at overvåking døgnet rundt, automatisk varsling eller et ubetjent reparasjonssystem allerede er satt i drift. Nedenfor går vi gjennom administrasjonsmaskinens tilkobling, skrivebeskyttet verifisering av flere maskiner, oppsummering av resultater og trinnvis endringsprosess for utviklere og driftsfolk som allerede har driftsrettigheter til servere og ønsker å følge opp arbeidet fra mobilen eller en annen datamaskin. Serverne kan også installeres direkte hver for seg, men hovedsporet for flere maskiner i denne artikkelen bruker administrasjonsmaskinløsningen.

AI SRE og AI DevOps: Hva skal Agent hjelpe til med i hvert tilfelle?

Disse to begrepene beskriver arbeidsområder som overlapper. Vi bruker følgende arbeidsdeling for å forstå dem, ikke som to produkter som må kjøpes hver for seg.

For eksempel, en testtjeneste som returnerer 502 rett etter utgivelse: å undersøke hvilket ledd som feiler, heller mot AI SRE; å gå gjennom utgivelseskonfigurasjonen som forårsaket problemet og forberede neste leveranse, heller mot AI DevOps. Den samme økten med Agent kan utføre begge typer arbeid; det avgjørende er oppgavens omfang, verktøytillatelser og akseptkriterier.

Trinn 1: Velg utførelsessted og innhent selskapets godkjenning

Før installasjon, skriv ned tre svar: hvilken maskin som er tillatt å koble til, hvilken systembruker den skal kjøre som, og hvilke kataloger og tjenester den skal ha tilgang til. Om selskapet tillater at logger eller kode sendes til eksterne modeller, bør også avklares før tilkobling. At du personlig kan logge på med SSH betyr ikke at selskapet godkjenner at en personlig konto kobles til en ekstern Agent.

Alternativ A: Kjøre direkte på serveren. Kontroller først at selskapet ikke bare godkjenner brukernivå-Agent-tjenesten, men også enhetsnettverks- og nettverkstjenesteendringene som standardinstallasjonen innebærer; det gjeldende installasjonsskriptet kan på gjeldende systemd-verter kalle sudo for å registrere en systemnivå nettverkstjeneste. Etter at nødvendig godkjenning for installasjon, rettighetsheving og nettverksendringer er innhentet, og verten oppfyller gjeldende støttekrav, installerer du PandaPaw på serveren. Arbeidskatalogen, skallet og verktøyene du velger deretter, tilhører denne utførelsesmaskinen. Ikke bruk root som standard bare fordi det er «mer praktisk».

Alternativ B: La en godkjent administrasjonsmaskin koble til serveren. Hvis serveren ikke tillater installasjon, installerer du PandaPaw på en administrasjonsmaskin som selskapet har godkjent, og Agent kjører også der. Administrasjonsmaskinen må allerede kunne nå målserveren via SSH, VPN eller bastionvert som selskapet godkjenner, og ha tilsvarende kontorettigheter. Agent bruker deretter denne eksisterende kanalen; PandaSi gir ikke godkjenning for tilgang på dine vegne, omgår ikke bastionverten og etablerer ikke automatisk forbindelse til selskapets interne nett.

Det som lettest skaper forvirring i de to alternativene, er «gjeldende maskin». I administrasjonsmaskinløsningen kjører Agent som standard pwd, og ser administrasjonsmaskinens katalog; bare kommandoer som uttrykkelig kjøres via SSH, skjer på målserveren. At et servernavn vises i økten, erstatter ikke identitetsverifisering.

Trinn 2: Installer PandaPaw på utførelsesmaskinen

Gå inn i arbeidsbenken fra PandaSi, logg inn og åpne enhetssiden /devices?add=1, velg å legge til enhet, og kopier den engangsinstallasjonskommandoen som siden genererer for gjeldende operativsystem. Standardinstallasjonen inkluderer konfigurasjon for enhetsnettverk og kan be om rettighetsheving og endre systemets nettverkstjenester; la først en administrator i selskapet gå gjennom installasjonsinnholdet og godkjenne de nødvendige rettighetene, og kjør deretter kommandoen på utførelsesmaskinen du valgte i forrige trinn. Hvis bare brukernivåtilgang er godkjent og ikke enhetsnettverk, bør du ikke kjøre standardinstallasjonskommandoen i denne artikkelen direkte; avklar først den godkjente installasjonsmetoden med administratoren. Hvis inngangen eller merkevaretteksten endres mellom versjoner, gjelder det som vises i gjeldende arbeidsbenk; den tilhørende vertsprosessen kan også sammenlignes med hurtigstart.

Engangskommandoen inneholder enhetskoblingslegitimasjon. Ikke lim den inn i samtaler, saksbilletter, offentlige skript eller skjermbilder, og ikke gjenbruk samme kommando for å koble til flere maskiner; hent en ny fra enhetssiden hvis den er brukt eller utløpt.

Hvis du ikke bruker kommandoen med engangslegitimasjon, er basisinstallasjonsinngangen for macOS / Linux:

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

Dette laster ned og kjører installasjonsskriptet, så følg selskapets prosess for programvareinstallasjon og skriptgjennomgang. Denne gangen er alt kontrollert mot gjeldende dokumentasjon og kildekode; installasjon og sammenkobling er ikke testet på en ren vert. Den offentlige nedlastingsinngangen for installasjonsskriptet er bekreftet tilgjengelig. Kompatibilitet med vertsplattformer og installasjonsdetaljer finnes i PandaPaw-vertveiledningen.

Hvis kontogodkjenningen for basisinstallasjonen ikke er fullført, fortsetter du på utførelsesmaskinen:

pandapaw login

Følg den viste enhetsgodkjenningsflyten for å fullføre sammenkoblingen, og kontroller deretter:

pandapaw status

Hvis kommandoen ikke finnes, åpne først et nytt terminalvindu slik at skallet laster PATH på nytt. Ikke installer på nytt eller tving frem ny pålogging gjentatte ganger «bare for å teste»; skill først mellom tre situasjoner: binærfilen ikke funnet, kontoen ikke tilknyttet, og unormal bakgrunnstjeneste.

Trinn 3: Velg maskin, motor og arbeidskatalog

Åpne arbeidsbenken /agent, velg utførelsesmaskinen du nettopp koblet til, og velg deretter Claude Code, Codex eller PandaCode samt arbeidskatalogen du har tillatelse til å bruke. Verifiser først med en testkatalog, slik at du ikke går rett inn i en produksjonskonfigurasjonskatalog.

Enhetssammenkobling og modellpålogging er to forskjellige ting. PandaPaw-pålogging betyr at verten har etablert forbindelse til arbeidsbenkkontoen; den valgte motoren trenger fortsatt gyldig modellautorisasjon, abonnement eller API-konfigurasjon. Hvis enheten vises som tilkoblet men modellen ikke svarer, sjekk først motorens påloggingsmelding, kvote og modellkonfigurasjon; ikke bare installer PandaPaw på nytt.

Samtidig må du kontrollere motorens verktøytillatelsesinnstillinger. Å skrive «ikke endre ennå» i chatten er en oppgavebegrensning og erstatter ikke operativsystemtillatelser eller motorens godkjenningsmekanisme. Hvis du trenger godkjenning for hver kommando, konfigurer riktig tillatelsesmodus og ikke anta at hver kommando automatisk viser et bekreftelseskort.

Trinn 4: Verifiser identiteten med en skrivebeskyttet forespørsel først

Den første oppgaven bør ikke være «fikse serveren»; send i stedet:

Bare utfør identitetsverifisering, ikke endre filer eller tjenester. Rapporter gjeldende vertsnavn, systembruker og absolutt arbeidskatalog, og list opp filnavnene på øverste nivå i katalogen. Ikke les .env, private nøkler eller annen legitimasjon. Hvis det er nødvendig å få tilgang til målserveren, forklar først forskjellen mellom gjeldende utførelsesmaskin og målet, og vent på at jeg verifiserer før du fortsetter.

Identitetsverifiseringskommandoer som kan brukes på Linux / macOS er:

hostname
id -un
pwd

Du bør sammenligne returverdiene punkt for punkt med forventningene: om det er samme utførelsesmaskin, om det er en godkjent konto, og om det er riktig prosjektkatalog. Lignende katalognavn, at enheten er tilkoblet, eller at kommandoen har utgangskode 0, er ikke alene bevis på at tilkoblingen er riktig.

Administrasjonsmaskinløsningen krever også verifisering i begge ender. Nedenfor demonstreres bare bruk av et SSH-alias som selskapet allerede har konfigurert; company-test-server er et eksempel og må byttes til målet administratoren har bekreftet:

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

Ikke løs første tilkoblingsvarsel ved å slå av verifisering av vertsnøkkel, og ikke lim SSH-passord eller private nøkler inn til Agent. Ekstern pwd kan være kontoens hjemmekatalog, så du kan ikke ut fra det anta at prosjektet er valgt; senere kommandoer bør angi den absolutte stien til det eksterne prosjektet eksplisitt.

Godkjenningskriteriene er: svaret samsvarer med riktig vert, identitet og katalog; du kan se hva som ble utført; og tillatelsesspørsmål vises som forventet i gjeldende tillatelsesmodus. Deretter går du inn i samme økt igjen fra mobilen eller en annen klient og kontrollerer om historikken kan gjenopprettes. Dette er nærmere den reelle bruksflyten enn å bare se på den grønne online-prikken.

Trinn 5: Lag serveroversikten først, og kjør deretter skrivebeskyttet inspeksjon i batch

En Agent på én administrasjonsmaskin kan bruke eksisterende SSH til å besøke flere servere i listen etter tur; PandaSi lar deg følge disse verktøyoperasjonene og resultatene i samme økt. «Sentral administrasjon» her kommer fra én felles utførelsesinngang, en tydelig liste og en samlet rapport; det betyr ikke at produktet har innebygd oppdagelse av serverressurser, automatisk oppgavefordeling på tvers av tilkoblinger eller et grensesnitt for ettklikks gruppestyring. Administrasjonsmaskinen må allerede være autorisert for hvert mål; du kan ikke anta at den har tilgang til andre maskiner i samme nettsegment bare fordi den har tilgang til én.

Lås målene med aliaser og miljøgruppering

La administratoren vedlikeholde en liste uten legitimasjon. Alle navnene nedenfor er fiktive eksempler; den faktiske listen bør ligge på et sted selskapet har godkjent, uten passord, private nøkler eller engangskommandoer for enheter.

SSH-aliaset er navnet i administrasjonsmaskinens eksisterende SSH-konfigurasjon, ikke enhetsnavnet i PandaSi. La administratoren verifisere målet, kontoen, porten og eventuell nødvendig tilgangsformidling som aliaset peker til; du kan ikke bekrefte at det er en testmaskin bare fordi navnet inneholder test. OpenSSH støtter konfigurasjon som matches etter Host-oppføringer, og en ekstern kommando angitt på kommandolinjen kjøres på målverten; se SSH-klientkonfigurasjonshåndboken og SSH-kommandohåndboken.

Hvis PandaPaw er installert på hver server separat, kan du også velge tilsvarende utførelsesmaskin i arbeidsbenken og arbeide maskin for maskin; men du bør ikke forstå «flere maskiner er online» som at én økt automatisk koordinerer alle tilkoblinger. Videre i denne artikkelen bruker vi konsekvent løsningen der administrasjonsmaskinen går via eksisterende SSH, for å unngå å blande to utførelsessteder i én rapport.

Verifiser serielt først, og begrens deretter inspeksjonselementene

Første gang gjør du identitetsverifisering maskin for maskin etter listen, uten å lese applikasjonskonfigurasjon eller fullstendige logger. Nedenfor er et serielt Bash-eksempel for administrasjonsmaskinen som bare lister de to testmaskinene som er tillatt i denne runden; det gjør ingen automatisk miljøgjenkjenning og erstatter ikke manuell kontroll av forventet 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

Disse kommandoene brukes bare til å illustrere organiseringen, og denne artikkelen har ikke kjørt dem på de to eksempelvertene. BatchMode=yes gjør at autentisering ikke venter på interaktiv input når den mislykkes; ConnectTimeout=5 begrenser fasen der tilkoblingen etableres, ikke den totale tidsgrensen for hele den eksterne kommandoen. Den totale kjøretidsgrensen bør settes separat av et godkjent verktøy eller en oppgaveutfører. Ikke slå av verifisering av vertsnøkkel for å kunne kjøre i batch; bastionverter som krever interaktiv MFA bør bruke selskapets godkjente tilgangsprosess, og dette ikke-interaktive eksempelet bør ikke gjenbrukes der.

Når kommandoen er fullført, sammenlign først forventet vertsnavn og konto i listen for hver maskin, og kontroller deretter den godkjente eksterne prosjektstien. pwd i utdataene ovenfor er vanligvis bare den eksterne innloggingskatalogen, ikke bevis på at prosjektstien er riktig. At kommandoen har utgangskode 0 betyr bare at disse kommandoene ble fullført; det betyr ikke at vertsidentiteten stemmer, og enda mindre at tjenesten er sunn. Hvis én maskin har feil identitet, markerer du målet som blokkert og slutter å lese forretningsdata; hvis det oppstår felles tvil i samme miljø eller tilgangskanal, stopper du hele batchkontrollen.

Når identitetsverifiseringen er bestått, lar du Agent kjøre det samme settet med godkjente skrivebeskyttede kontroller på testmaskinene i denne runden: status for angitte tjenester, forventede lyttende porter, ledig diskplass, maskert feilsammendrag innenfor et angitt tidsvindu og en godkjent helseforespørsel. Ikke utvid «inspeksjon» til å installere prober, lese alle kataloger rekursivt eller reparere automatisk. Kontrollkommandoer varierer mellom operativsystemer, tjenestebehandlere og applikasjoner; de bør suppleres per liste, og ett sett kommandoer bør ikke tvinges på alle verter.

Bruk en ledetekst for å gjøre utførelsesgrensene tydelige

Du kjører på administrasjonsmaskinen. Få bare tilgang til test-web-01 og test-worker-01 i testgruppen i henhold til den godkjente serverlisten; ikke skann nye adresser og ikke få tilgang til produksjonsgruppen. Kontroller først serielt vertsnavn, bruker og absolutt sti til eksternt prosjekt for hver maskin, og blokker målet hvis det ikke stemmer med listen. Når det er bestått, kontrollerer du bare tjenestestatus, porter, disk og helseforespørsler som listen uttrykkelig autoriserer; logger skal bare hentes som maskerte utdrag fra det angitte tidsvinduet. Hele første runde kjøres serielt, uten å endre konfigurasjon, starte på nytt, installere avhengigheter eller heve rettigheter automatisk. Hvis tilkoblingen til én maskin mislykkes, beholder du feilen og fortsetter med uavhengige skrivebeskyttede kontroller på andre verifiserte mål; hvis miljøtilhørighet eller felles tilgangskanal virker unormal, stopper du hele batchen. For hver maskin registrerer du tid og tidssone, kommando, utgangsstatus, viktige bevis og ufullstendige punkter, og til slutt oppsummerer du per server. Eventuelle reparasjoner skal bare gis som forslag og ikke utføres.

Dette er en oppgavebegrensning, og den bør også kombineres med skrivebeskyttet konto, godkjenning av motorens verktøy og begrensninger i nettverkstilgang. Å skrive «endring forbudt» i ledeteksten gjør ikke automatisk en skrivbar konto om til en skrivebeskyttet konto.

Begrens samtidighet og la feil bli værende på riktig mål

Første inspeksjon bør kjøres serielt for enkel verifisering; når det er mange mål, kan du sette en liten samtidighetsgrense innenfor selskapets godkjente måte å kjøre verktøy på, for eksempel maksimalt to maskiner samtidig. «To» her er et eksempel på driftsbudsjett, ikke en produktgrense eller ytelsesgaranti fra PandaSi. Hvis den valgte Agent eller verktøyet ikke pålitelig kan begrense samtidighet, fortsetter du serielt og bruker ikke midlertidige ubegrensede bakgrunnsoppgaver som erstatning.

Hver kontroll skal ha egen tidsavbrudd og resultatregistrering; en feil på ett mål bør ikke utløse omstart, reinstallasjon eller ubegrensede nye forsøk for hele batchen. Registrer tilkoblingstidsavbrudd, identitetsavvik, utilstrekkelige rettigheter og feilede kontrollkommandoer separat, og press dem ikke sammen til «offline». Hvis feilen kommer fra en felles bastionvert, autentiseringskilde eller uklar miljøtilhørighet, bør du stoppe og kontrollere felles årsaker i stedet for å øke samtidigheten videre.

Oppsummeringstabellen må liste opp per maskin om identiteten stemmer, hvilke kontroller som faktisk ble utført, viktige bevis og ukjente punkter. Nedenfor vises bare registreringsformatet; teksten i tabellen er utfyllingsveiledning, ikke målte resultater:

Rapporten bør angi «hvor mange maskiner som var planlagt kontrollert, hvor mange som ble fullført, hvor mange som feilet og hvor mange som ble hoppet over», og gi bevis for hvert mål. Manglende resultater kan ikke tolkes som sunn tilstand som standard; at den endelige utgangskoden for en batchkommando er 0, kan heller ikke skjule at én maskin allerede feilet underveis.

Trinn 6: Gjennomfør 502-undersøkelse og gjenoppretting på én testtjeneste først

Følgende er et pedagogisk eksempel, ikke en faktisk hendelse testet i denne artikkelen, og heller ikke et sett reparasjonskommandoer som kan kopieres til alle servere. Anta at en testtjeneste du har tillatelse til å betjene, returnerer 502 etter utgivelse, og at du allerede kjenner testdomenet, tjenestenavnet og prosjektkatalogen.

Begrens undersøkelsesomfanget først

Du kan skrive oppgaven slik:

Undersøk 502-feilen etter utgivelsen av testtjenesten. Kontroller først målverten, brukeren og katalogen, og kontroller skrivebeskyttet den siste utgivelsesloggen, status for relevante tjenester, lyttende porter og proxy- og applikasjonslogger i det angitte tidsvinduet. Ikke start på nytt, endre konfigurasjon, installer avhengigheter eller få tilgang til andre miljøer. Returner bare maskerte utdrag som er relevante for denne feilen, og list opp bevis, mulige årsaker og hvilken informasjon som mangler.

Gi først et tidsvindu og tydelige loggkilder, slik at Agent ikke rekursivt går gjennom hele serveren. Skrivebeskyttet kan også lekke data: tokens, kundeinformasjon og forespørselsinnhold i logger bør fortsatt filtreres før de kommer inn i modellkonteksten, ikke sendes først og deretter få modellen til å «glemme» dem.

502 indikerer at proxyen ikke fikk et brukbart oppstrøms svar, men statuskoden alene kan ikke avgjøre om det er prosessavslutning, portfeil, avhengighetsfeil eller tilkoblingsproblem. La Agent justere proxyens oppstrømsadresse, faktisk lytting og logger fra samme tidsperiode; logger fra flere maskiner bør først synkroniseres til samme tidssone. Ikke behandle «maskinen er online» som «applikasjonen er sunn», og ikke behandle manglende samsvarende logger som direkte bevis på at ingen feil har skjedd.

Be om et gjennomgåelig reparasjonsforslag

Hvis bevisene støtter at «oppstrømsporten i utgivelseskonfigurasjonen ikke samsvarer med den faktiske lyttingen», lar du Agent legge frem den konkrete filen og minste differanse, kommandoen den planlegger å kjøre, den berørte testtjenesten, metoden for konfigurasjonskontroll og tilbakerullingsbetingelser. Dette er fortsatt bare et betinget eksempel; hvis bevisene ikke støtter det, fortsetter du undersøkelsen.

Godkjenningsobjektet bør være en konkret endring, ikke «du har full kontroll». For eksempel å godkjenne endring av en angitt testproxykonfigurasjon og laste testproxyen på nytt etter at konfigurasjonskontrollen er bestått; du kan ikke samtidig oppgradere avhengigheter, rydde databasen, endre produksjonskonfigurasjon eller starte hele verten på nytt. De faktiske kommandoene må fastsettes ut fra prosessbehandleren og distribusjonsrutinene som brukes.

Verifiser brukerflyten etter utførelse

Etter godkjent utførelse bør aksepten minst dekke: om konfigurasjonskontrollen besto, om relevante prosesser og porter er som forventet, om helseendepunktet fungerer, og om en faktisk testforespørsel fra en uavhengig klient via den opprinnelige inngangen er gjenopprettet. Hvis helseendepunktet svarer 200, men forretningsruting, autentisering eller databasforespørsler fortsatt feiler, kan du ikke skrive at «problemet er løst».

Til slutt lar du Agent oppsummere utførte kommandoer, faktiske endringer, verifiseringsresultater og gjenværende risiko; punkter som ikke er verifisert, skal uttrykkelig skrives som ukjente. Lever den bekreftede årsaken og tiltakene for å hindre gjentakelse tilbake til selskapets journalsystem. Undersøkelsesfasen får AI SRE-støtte; når korrigeringen senere tas inn i konfigurasjonsrepoet og utgivelsesprosessen, utvides det til AI DevOps.

Trinn 7: Etter at én maskin er bestått, endre andre servere i batcher

Autorisasjon for batchinspeksjon og batchendring bør holdes atskilt. At flere tjenester har ulike versjoner, betyr ikke at du uten videre kan oppgradere dem alle; tjenester med samme navn kan også ha ulike roller eller bruke ulik konfigurasjon. Kontroller først om forskjellene er forventet, og legg deretter frem en endringsplan som lister opp hvert mål.

Den første batchen bør bare velge én tydelig testmaskin. I planen fastsetter du målaliaset, den verifiserte vertsidentiteten, opprinnelig versjon eller konfigurasjon, foreslått differanse, forventet påvirkning, kontrollmetode, tilbakerullingssteg og stoppbetingelser. Etter godkjenning utfører du endringen på denne ene maskinen og venter på aksept av helseendepunktet og den faktiske brukerflyten; uten bevis på gjenoppretting kan du ikke merke statusen som vellykket og gå videre til neste batch.

Etter at prøvekjøringen er bestått, angir du mållisten, batchstørrelsen og samtidighetsgrensen for neste batch eksplisitt; du kan ikke bruke en implisitt omfang som «alle gjenværende maskiner» som endres med listen. Ved slutten av hver batch kontrollerer du faktisk versjon og forespørselsresultater, og registrerer vellykkede, mislykkede og ikke-utførte mål. Hvis det oppstår identitetsavvik, feilet konfigurasjonskontroll, forringelse av forretningsforespørsler eller mislykket tilbakerulling, stopper du senere batcher og beholder bevisene til ansvarlig person; ikke behandle godkjenning fra testfasen som produksjonsgodkjenning.

Tilbakerulling må også defineres per maskin. Konfigurasjonsendringer kan gjenopprettes til tidligere konfigurasjon på godkjent måte; når det gjelder databasemigrering, dataskriving eller bivirkninger i eksterne systemer, kan du ikke anta at «bytt tilbake til gammel versjon» opphever påvirkningen; ansvarlig person bør først fastsette gjenopprettingsplanen. Rull bare tilbake mål som faktisk er endret og trenger gjenoppretting, og ikke kjør omvendte kommandoer uten forskjell på hele gruppen.

Du kan skrive neste oppgave slik:

Basert på bevisene fra maskin-for-maskin-inspeksjonen i denne runden, foreslå først en reparasjonsplan bare for test-web-01, uten å utføre den. List opp verifisert vertsidentitet, konkrete forskjeller, fullstendige kommandoer, påvirkning, tilbakerullingssteg, akseptforespørsel og stoppbetingelser. Utfør først etter uttrykkelig godkjenning for denne maskinen; når den er fullført, gi faktiske bevis og vent på autorisasjon for neste batch med mål. Maskiner som ikke er godkjent, forblir uutførte. Produksjonsgruppen er utenfor denne runden og kan ikke arve testgodkjenningen.

Når både test og produksjon må håndteres, går produksjon gjennom selskapets egen endringsprosess. En felles administrasjonsinngang fjerner ikke krav til miljøisolering, vedlikeholdsvinduer, utgivelsesgodkjenning eller revisjon.

Når mobilen mister forbindelsen, kontroller oppgavestatusen først

At klienten lukkes, mobilen går til bakgrunnen eller nettverket kobles fra, bør ikke tolkes som at den eksterne kommandoen er stoppet. Prosessen på utførelsesmaskinen kan fortsette å kjøre; den kan også mislykkes fordi verten er frakoblet, motoren avsluttes eller den eksterne kanalen er begrenset. Når du kommer tilbake til den opprinnelige økten, se først på verktøyresultatene, og kontroller deretter prosess, artefakter og tjenestestatus for å unngå å starte installasjon, utgivelse eller migrering på nytt.

Fjernkommandokjeden kan gi «ingen utgangsstatus returnert»: et tidsavbrudd i tilkoblingslaget betyr ikke at kommandoen ikke startet. For langvarige oppgaver må du angi tidsavbrudd, statusregistrering og avbrytelsesmåte i selskapets utførelseskanal, spesielt når flere SSH-hopp er involvert. Denne artikkelen behandler ikke tidsavbruddsverdien for én versjon som en generell regel for alle SSH-verktøy.

Når du trenger å stoppe, bruk en tydelig stoppoperasjon og verifiser ekstern utførelsesstatus; ved ikke-idempotente endringer med uklar status bør du først overta manuelt og bekrefte. Ikke gjett om forrige forsøk lyktes ved å klikke gjentatte ganger eller sende samme instruksjon på nytt.

Hva har nettverksoppsett for bedrifts- og hjemmeenheter med denne artikkelen å gjøre?

Denne artikkelen forutsetter at den godkjente tilgangskanalen fra administrasjonsmaskinen til hver server allerede finnes, og fokuserer på hvordan Agent organiserer arbeidet per mål. Hvordan flere enheter på kontoret og hjemme kobles til nettverket, får tilgang til hverandre og håndterer nettverksgrenser, er en annen tilkoblingsoppgave som ikke blandes inn her; vellykket nettverksoppsett betyr heller ikke at du har rett til å drifte alle enhetene i det. Hvis du trenger å forstå enhetstilkobling, kan du først se den eksisterende beskrivelsen av enhetsinterkobling og følge selskapets prosess for nettverksgodkjenning.

Grensene for selskapsdata, modeller og relé

«Verktøyet kjører lokalt» beskriver utførelsesstedet og lover ikke at data aldri forlater selskapet. Øktmeldinger og godkjenninger går gjennom produktets kommunikasjonskanal; logger, kode og verktøyutdata som gis til Agent, kan også inngå i forespørsler til den valgte modellleverandøren. Før tilkobling bør du kontrollere selskapets godkjente modeller, datahåndteringsavtaler, loggoppbevaring og tilgangspolicy.

Behold eksisterende nøkkeladministrasjon og revisjonsprosesser, les legitimasjon fra den godkjente legitimasjonsløsningen på utførelsesmaskinen, og ikke lim den inn i samtaler eller kodelagre. Begrens kjørekontoen og nettverkets rekkevidde, og gi tilgang til logger og kataloger etter behov. Ved avsluttet ansettelse, utfasing av utstyr eller endring av rettigheter, må du samtidig håndtere enhetsautorisasjon i arbeidsbenken, utførelsesmaskinens konto og tilgangen til målserveren; å slette én klient er ikke det samme som å trekke tilbake alle utførelsesrettigheter.

FAQ

Kan PandaSi automatisk ha vakt, motta varsler og reparere produksjonen?

Denne artikkelen handler om eksterne økter, autoriserte operasjoner og manuell oppfølgingsflyt. Overvåking døgnet rundt, varslingsintegrasjon, automatisk utløsing og ubetjent reparasjon krever ekstra overvåkingssystemer, utløsere, kjørebøker og rettighetsstyring; du kan ikke utlede at disse evnene allerede finnes bare fordi tilkoblingen lykkes.

Kan løsningen brukes hvis selskapets servere ikke kan installere programvare?

Du kan vurdere den godkjente administrasjonsmaskinløsningen, forutsatt at administrasjonsmaskinen allerede har lovlig nettverks- og identitetstilgang til målene. Hvis selskapet også forbyr denne typen ekstern Agent-tilkobling, bør du først gå gjennom godkjenning, ikke bytte til en skjult tilkoblingsrute.

Må serveren åpne en offentlig SSH-port?

PandaPaw-øktstilkoblingen etableres ved at begge sider aktivt kobler ut, så det er vanligvis ikke nødvendig å legge til nye innkommende offentlige porter for klienttilkobling. Men administrasjonsmaskinen må fortsatt ha en godkjent tilgangskanal til målserveren; hvis utgående trafikk er begrenset, bør nettverksadministratoren konfigurere det, og du bør ikke slå av beskyttelsen selv.

Må PandaPaw installeres på hver server?

Administrasjonsmaskinløsningen i denne artikkelen krever ikke at PandaPaw installeres på hvert SSH-mål, men administrasjonsmaskinen må ha en godkjent nettverkskanal og ekstern konto. I direkteinstallasjonsløsningen kjører Agent på den aktuelle verten og kobles til hver for seg; ikke bland de to til én automatisk gruppestyringsevne.

Hvis én inspeksjon mislykkes, kan de andre maskinene fortsette?

For skrivebeskyttede kontroller med verifisert identitet og gjensidig uavhengighet kan du beholde feilbeviset for det målet og fortsette med andre mål; hvis det gjelder felles tilgangsfeil eller tvil om miljøtilhørighet, bør du stoppe hele batchen. Endringsfasen følger de godkjente stoppbetingelsene, og regelen «inspeksjon kan fortsette» kan ikke overføres dit.

Hva bør godkjennes først etter tilkobling?

Verifiser først administrasjonsmaskinen, modellsvaret og øktgjenopprettingen, og kontroller deretter målidentitet, katalog og rettigheter maskin for maskin etter listen, fullfør skrivebeskyttet inspeksjon og oppsummering av resultater, og gå til slutt gjennom godkjenning, aksept av faktiske forespørsler og den påfølgende batchprosessen på én testtjeneste. Verdien av tilkoblingen er at autoriserte oppgaver kan følges kontinuerlig; om det er egnet for å utvides til flere tjenester, bør avgjøres ut fra bevisene fra denne godkjenningen.

Kilder og kontrollomfang

Førsteutkastet av denne artikkelen ble kontrollert 31. oktober 2026 mot prosjektets hurtigstart, PandaPaw-vertdokumentasjon, logikken for generering av enhetsinstallasjonskommandoer og den offentlige nedlastingsinngangen for installasjonsskriptet; 1. november ble arbeidsflyten for flere maskiner supplert, og SSH-konfigurasjon og parametersemantikk ble kontrollert mot OpenSSHs offisielle håndbøker. Denne gangen er alt bare kontrollert mot gjeldende dokumentasjon og kildekode; installasjon og sammenkobling er ikke testet på en ren vert, og inspeksjonen, batch-endringene eller 502-eksempelet i denne artikkelen er ikke kjørt i et reelt miljø med flere maskiner; hvert selskaps nettverk, motorens godkjenning og datasamsvar må godkjennes i eget testmiljø. Illustrasjonene er AI-genererte konsept- eller flytskjemaer, ikke skjermbilder av grensesnittet.