AI SRE og AI DevOps i praksis: Brug PandaSi til at lade en Agent administrere flere servere centralt

AI SRE og AI DevOps kan tages i brug med en samlet serveroversigt og skrivebeskyttet inspektion. Denne artikel bruger PandaSi til at forbinde Agent på administrationsmaskinen, verificere flere servere én ad gangen via eksisterende SSH, opsummere kontrolresultaterne og derefter gennemføre ændringer via en proces med test på en enkelt server, godkendelse i batches og rollback.

PandaSiFørst offentliggjort Opdateret den
AI SRE og AI DevOps i praksis: Brug PandaSi til at lade en Agent administrere flere servere centralt

Central serveradministration af flere servere med en Agent via PandaSi kan begynde på én godkendt administrationsmaskine: Kør PandaPaw og Agent på administrationsmaskinen, og lad Agent få adgang til målene på en eksplicit liste via eksisterende SSH, VPN eller bastionvært. Kontrollér identiteten på hver enkelt server, udfør batchvise skrivebeskyttede inspektioner, og sammenfat resultaterne. Når der skal ændres noget, afprøves det først på én server, hvorefter ændringerne rulles ud i godkendte trin. AI SRE fokuserer på at undersøge pålidelighedsproblemer, AI DevOps på levering og infrastrukturændringer; begge kræver reviderbare beviser og klare rettighedsgrænser.

PandaSi tilbyder en indgang til sessioner og godkendelser på tværs af enheder, PandaPaw forbinder eksekveringsmaskinen, og de konkrete kommandoer udføres af den valgte Agent og værktøjerne dertil. At tilslutte er ikke det samme som at få rettigheder til virksomhedens servere, og det betyder heller ikke, at der allerede er implementeret døgnovervågning, automatisk alarmhåndtering eller uovervåget fejlretning. Nedenfor henvender vi os til udviklere og driftsfolk, der allerede har rettigheder til serverdrift, og som ønsker at følge arbejdet fra en telefon eller en anden computer, og går gennem tilslutning af administrationsmaskinen, skrivebeskyttet verifikation af flere maskiner, sammenfatning af resultater og etapevise ændringer. Serverne kan også installeres direkte hver for sig, men denne artikels hovedspor for flere maskiner bruger administrationsmaskinløsningen.

AI SRE og AI DevOps: Hvad skal Agent hjælpe med i de to roller?

Disse to begreber beskriver arbejdsområder, der overlapper. I denne artikel forstår vi dem ud fra følgende arbejdsdeling, uden at behandle dem som to produkter, der nødvendigvis skal købes hver for sig.

Dimension AI SRE AI DevOps
Kernespørgsmål Er tjenesten pålidelig, hvorfor opstod fejlen, og hvordan gendannes den med færre gentagelser? Hvordan leveres software og styres infrastruktur mere sikkert?
Typiske opgaver Sortere logs, korrelere afvigelser, kontrollere afhængigheder, foreslå gendannelsestiltag og bistå ved efteranalyse Læse pipelines, kontrollere udrulningskonfiguration, forberede ændringer og analysere fejl i udgivelser
Input til Agent Autoriserede logs, metrikker, topologi, hændelsestidslinje og driftsinstruktioner Repository, pipeline-poster, infrastrukturkonfiguration og udgivelsesregler
Forventet output Beviser, mulige årsager, risici samt gendannelses- og verifikationsplan Reviderbare diffs, eksekveringsplan, rollback-betingelser og leveringsbeviser
Beslutninger, som mennesker skal beholde Forretningsmæssig påvirkning, godkendelse af ændringer og accept af gendannelse Udgivelsesgodkendelse, adgangskontrol samt miljø- og ressourcegrænser

Hvis en testtjeneste lige er udgivet og returnerer 502: At undersøge, i hvilket lag anmodningen fejler, hører mest til AI SRE; at gennemgå den udrulningskonfiguration, der forårsagede problemet, og forberede næste levering hører mest til AI DevOps. Den samme Agent-session kan udføre begge typer arbejde; det afgørende er opgavens omfang, værktøjsrettigheder og acceptkriterier.

Trin 1: Vælg eksekveringsplacering, og indhent virksomhedens godkendelse

Før installation skal du have skriftlige svar på tre spørgsmål: hvilken maskine der må tilsluttes, hvilken systembruger der skal køre, og hvilke mapper og tjenester der må tilgås. Det skal også afklares før tilslutning, om virksomheden tillader, at logs eller kode sendes til en ekstern model. At man personligt kan logge ind via SSH, betyder ikke, at virksomheden har godkendt, at en personlig konto bindes til en ekstern Agent.

Sti A: Kør direkte på serveren. Bekræft først, at virksomheden ikke kun har godkendt brugerrettede Agent-tjenester, men også de ændringer af enhedsnetværk og netværkstjenester, som standardinstallationsprocessen indebærer; det aktuelle installationsscript kan på understøttede systemd-værter kalde sudo for at registrere en netværkstjeneste på systemniveau. Indhent godkendelse til den relevante installation, rettighedsforhøjelse og netværksændring, og installer først PandaPaw på serveren, når værten opfylder de aktuelle supportbetingelser. Den arbejdsmappe, shell og de værktøjer, der vælges derefter, tilhører denne eksekveringsmaskine. Brug ikke root som standard, bare fordi det "er mere praktisk".

Sti B: Brug en godkendt administrationsmaskine til at gå ind på serveren. Hvis serveren ikke må installeres på, installeres PandaPaw på en virksomhedsgodkendt administrationsmaskine, og Agent kører også der. Administrationsmaskinen skal allerede kunne nå målserveren via virksomhedens godkendte SSH, VPN eller bastionvært og have de tilsvarende kontorettigheder. Agent kalder derefter denne eksisterende kanal; PandaSi godkender ikke adgangen for dig, omgår ikke bastionværten og åbner ikke automatisk virksomhedens interne netværk.

To veje: direkte eksekvering på serveren og en administrationsmaskine, der går ind på serveren via en eksisterende adgangskanal
Diagram over adgangsveje: Bestem først Agent-værten og derefter målserveren; session-relayet giver ikke serverrettigheder.

Det, der lettest forveksles i de to veje, er "den aktuelle maskine". I administrationsmaskinmodellen kører Agent som standard pwd, og det, den ser, er administrationsmaskinens mappe; kun kommandoer, der eksplicit udføres via SSH, sker på målserveren. At et servernavn optræder i sessionen, kan ikke erstatte identitetsverifikation.

Trin 2: Installer PandaPaw på eksekveringsmaskinen

Gå ind i arbejdsfladen via PandaSi, log ind, åbn enhedssiden /devices?add=1, vælg Tilføj enhed, og kopiér den engangskommando til installation, som siden genererer til det aktuelle operativsystem. Standardinstallationen indeholder konfiguration af enhedsinterkobling, kan anmode om rettighedsforhøjelse og ændre systemets netværkstjenester; lad først en virksomhedsadministrator gennemgå installationsindholdet og godkende de relevante rettigheder, og kør derefter kommandoen på den eksekveringsmaskine, du valgte i forrige trin. Hvis der kun er godkendt brugerrettet tilslutning og ikke enhedsnetværksinterkobling, bør du ikke køre denne artikels standardinstallationskommando direkte; bekræft først en godkendt installationsmetode med administratoren. Hvis indgangen eller brandteksten ændrer sig fra version til version, gælder det, der vises i den aktuelle arbejdsflade; den relevante værtproces kan også sammenlignes med Hurtig start.

Engangskommandoen indeholder parringslegitimationsoplysninger til enheden. Indsæt den ikke i chats, sagsbilletter, offentlige scripts eller skærmbilleder, og genbrug ikke den samme kommando til flere maskiner; hvis den er brugt eller udløbet, skal du hente en ny fra enhedssiden.

Hvis du ikke bruger kommandoen med engangslegitimationsoplysninger, er den grundlæggende installationsindgang for macOS / Linux:

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

Dette downloader og udfører installationsscriptet; følg virksomhedens proces for softwareinstallation og scriptgennemgang først. Denne gang er der kun kontrolleret mod aktuel dokumentation og kildekode; installation og parring er ikke testet på en ren vært. Den offentlige downloadindgang for installationsscriptet er bekræftet tilgængelig. Kompatibilitet for værtsplatforme og installationsdetaljer findes i PandaPaw-værtsguide.

Hvis kontogodkendelsen for den grundlæggende installation ikke er gennemført, fortsætter du på eksekveringsmaskinen:

bash
pandapaw login

Følg den viste enhedsgodkendelsesproces for at fuldføre parringen, og kontroller derefter:

bash
pandapaw status

Hvis kommandoen ikke findes, skal du først åbne en ny terminal, så shellen genindlæser PATH. Gentag ikke installationen eller tving ikke et nyt login bare for at "prøve"; skel først mellem tre situationer: binæren findes ikke, kontoen er ikke bundet, eller baggrundstjenesten er unormal.

Trin 3: Vælg maskine, motor og arbejdsmappe

Åbn arbejdsfladen /agent, vælg den eksekveringsmaskine, du netop har tilsluttet, og vælg derefter Claude Code, Codex eller PandaCode samt en godkendt arbejdsmappe. Test først i en testmappe, så du ikke starter med at gå ind i produktionskonfigurationsmappen.

Enhedsparring og modellogin er to forskellige ting. PandaPaw-login betyder, at værten har etableret forbindelse til arbejdsfladens konto; den valgte motor har stadig brug for en gyldig modelautorisation, et abonnement eller en API-konfiguration. Hvis enheden vises online, men modellen ikke svarer, skal du først kontrollere motorens loginprompt, kvote og modelkonfiguration i stedet for kun at geninstallere PandaPaw.

Kontroller også motorens værktøjsrettighedsindstillinger. At skrive "ændr ikke noget endnu" i chatten er en opgavebegrænsning og erstatter ikke operativsystemrettigheder eller motorens godkendelsesmekanisme. Hvis hver kommando skal godkendes enkeltvis, skal den tilsvarende rettighedstilstand konfigureres; antag ikke, at hver kommando automatisk viser en bekræftelsesdialog.

Trin 4: Bekræft identiteten med en skrivebeskyttet anmodning først

Den første opgave skal ikke være "ret serveren". Send først:

Udfør kun identitetskontrol, og ændr ikke filer eller tjenester. Rapportér det aktuelle værtsnavn, systembruger og absolutte arbejdsmappe, og vis filnavnene på øverste niveau i mappen. Læs ikke .env, private nøgler eller andre legitimationsoplysninger. Hvis du skal have adgang til målserveren, skal du først forklare forskellen mellem den aktuelle eksekveringsmaskine og målet og vente på min kontrol, før du fortsætter.

Linux / macOS kan bruge følgende identitetskontrolkommandoer:

bash
hostname
id -un
pwd

Du bør sammenligne returværdierne med det forventede punkt for punkt: Er det samme eksekveringsmaskine, er det den godkendte konto, er det den rigtige projektmappe. Lignende mappenavne, en enhed der er online, og en kommando med exitkode 0 beviser ikke alene, at tilslutningen er korrekt.

Administrationsmaskinløsningen kræver også, at begge ender kontrolleres separat. Nedenstående demonstrerer kun brug af et SSH-alias, som virksomheden allerede har konfigureret; company-test-server er et eksempel og skal erstattes med det mål, administratoren har bekræftet:

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

Undlad at slå kontrol af værtsnøgler fra for at løse prompten ved første forbindelse, og indsæt ikke SSH-adgangskoder eller private nøgler i Agent. Den eksterne pwd kan være kontoens hjemmemappe; antag derfor ikke ud fra det, at projektet er valgt. Efterfølgende kommandoer bør angive den absolutte sti til det eksterne projekt.

Acceptkriteriet er: Svaret kan knyttes til den korrekte vært, identitet og mappe; du kan se, hvad der blev udført; og rettighedsforespørgsler vises som forventet i den aktuelle rettighedstilstand. Gå derefter ind i den samme session igen fra en telefon eller en anden klient, og kontrollér, om historikken kan gendannes. Det er tættere på den reelle brugsvej end kun at se på en grøn onlineindikator.

Trin 5: Opret en serverfortegnelse, og kør derefter skrivebeskyttede inspektioner i batch

En Agent på en administrationsmaskine kan bruge eksisterende SSH til at tilgå flere servere på listen én efter én; PandaSi lader dig følge disse værktøjsoperationer og resultater i samme session. "Central administration" her kommer fra samme eksekveringsindgang, en eksplicit liste og en samlet rapport; det betyder ikke, at produktet har indbygget opdagelse af serveraktiver, automatisk fordeling på tværs af forbindelser eller en et-kliks gruppestyring. Administrationsmaskinen skal allerede være autoriseret for hvert mål; fordi man kan tilgå én maskine, kan man ikke antage, at man også kan tilgå andre maskiner i samme netværkssegment.

Lås målene fast med aliaser og miljøgrupper

Lad administratoren vedligeholde en liste uden legitimationsoplysninger. Alle navne nedenfor er fiktive eksempler; den faktiske liste skal opbevares på et virksomhedsgodkendt sted uden adgangskoder, private nøgler eller engangskommandoer til enheder.

Miljø SSH-alias Forventet værtsnavn Forventet bruger Ekstern projektmappe Autorisation i denne runde
test test-web-01 demo-test-web-01 opsread Godkendt absolut sti til projekt A Identitetskontrol, skrivebeskyttet kontrol af angivne tjenester
test test-worker-01 demo-test-worker-01 opsread Godkendt absolut sti til projekt A Identitetskontrol, skrivebeskyttet kontrol af angivne tjenester
production prod-web-01 demo-prod-web-01 opsread Godkendt absolut sti til projekt A Udelukket i denne runde; søg separat
production prod-web-02 demo-prod-web-02 opsread Godkendt absolut sti til projekt A Udelukket i denne runde; søg separat

SSH-aliaset er et navn i administrationsmaskinens eksisterende SSH-konfiguration, ikke PandaSi-enhedsnavnet. Administratoren skal kontrollere målet, kontoen, porten og eventuelle adgangsrelay, som aliaset peger på; man kan ikke bekræfte, at det er en testmaskine, alene fordi navnet indeholder test. OpenSSH understøtter konfiguration, der matches efter Host-poster, og en ekstern kommando angivet på kommandolinjen udføres på målværten; se SSH-klientkonfigurationsmanualen og SSH-kommandomanualen.

Diagram over én administrationsmaskine, der via eksisterende SSH tilgår test- og produktionsservere i henhold til en autoriseret liste
Diagram over administration af flere maskiner: Kontrollér hvert mål mod listen, begræns samtidighed, og godkend produktionsadgang separat; dette er ikke et skærmbillede af en gruppestyring.

Hvis der er installeret PandaPaw på hver server separat, kan du også vælge den tilsvarende eksekveringsmaskine i arbejdsfladen og arbejde på én maskine ad gangen; men forstå ikke "flere maskiner er online" som, at én session automatisk koordinerer alle forbindelser. Resten af denne artikel bruger konsekvent løsningen, hvor administrationsmaskinen går via eksisterende SSH, så to forskellige eksekveringsplaceringer ikke blandes sammen i én rapport.

Verificér serielt først, og afgræns derefter inspektionspunkterne

Første gang skal du udføre identitetskontrol på hver maskine efter listen, uden at læse applikationskonfiguration eller fulde logs. Nedenfor er et serielt Bash-eksempel for administrationsmaskinen; det viser kun de to testmaskiner, der er tilladt i denne runde; det udfører ikke automatisk miljøgenkendelse og erstatter ikke den manuelle kontrol af den forventede identitet.

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

Disse kommandoer bruges kun til at illustrere organiseringen; denne artikel har ikke kørt dem på de to eksempelværter. BatchMode=yes gør, at autentificering ikke venter på interaktivt input ved fejl; ConnectTimeout=5 begrænser forbindelsesopbygningsfasen, ikke den samlede tidsgrænse for hele den eksterne kommando. Den samlede eksekveringstidsgrænse bør sættes separat af det godkendte værktøj eller opgavekøreren. Slå ikke værtsnøglekontrollen fra for at køre i batch; bastionværter, der kræver interaktiv MFA, bør bruge virksomhedens godkendte adgangsproces, og dette ikke-interaktive eksempel bør ikke genbruges direkte.

Efter kommandoen skal du først sammenligne det forventede værtsnavn og den forventede konto fra listen for hver maskine og derefter kontrollere den godkendte eksterne projektsti. pwd i outputtet ovenfor er normalt kun den eksterne loginmappe, ikke et bevis på, at projektstien er korrekt. En exitkode på 0 betyder kun, at disse kommandoer blev fuldført; det betyder ikke, at værtsidentiteten matcher, og endnu mindre, at forretningen er sund. Hvis en maskines identitet ikke stemmer, markeres målet som blokeret, og du må ikke fortsætte med at læse forretningsdata; hvis der er fælles tvivlspunkter i samme miljø eller adgangskanal, sættes hele batchen på pause.

Efter identitetskontrollen kan du lade Agent køre det samme sæt godkendte skrivebeskyttede kontroller på denne rundes testmaskiner: status for angivne tjenester, forventede lyttende porte, ledig diskplads, et afidentificeret fejlsammendrag inden for et angivet tidsvindue og en godkendt health-anmodning. Udvid ikke "inspektion" til at installere probes, rekursivt læse alle mapper eller automatisk reparere. Kontrolkommandoer varierer mellem systemer, tjenesteadministrationsværktøjer og applikationer; de skal suppleres efter listen, og ét sæt kommandoer bør ikke tvinges ned over alle værter.

Brug en prompt til at gøre eksekveringsgrænsen klar

Du kører på administrationsmaskinen. Tilgå kun test-web-01 og test-worker-01 i testgruppen i overensstemmelse med den godkendte serverliste; scan ikke nye adresser, og tilgå ikke produktionsgruppen. Kontrollér først serielt hvert værtsnavn, bruger og absolutte eksterne projektsti, og blokér målet, hvis det ikke stemmer med listen. Når det er godkendt, må du kun kontrollere de tjenester, porte, diske og health-anmodninger, som listen udtrykkeligt har godkendt; logfiler må kun være afidentificerede uddrag fra det angivne tidsvindue. Hele forløbet køres serielt første gang; ændr ikke konfiguration, genstart ikke, installer ikke afhængigheder, og forhøj ikke rettigheder automatisk. Hvis én forbindelse fejler, skal fejlen bevares, og du skal fortsætte med uafhængige skrivebeskyttede kontroller af andre verificerede mål; hvis der opdages afvigelser i miljøtilhørsforhold eller fælles adgangskanal, skal hele batchen sættes på pause. Registrér for hver maskine tid og tidszone, kommando, exitstatus, centrale beviser og uafsluttede punkter, og sammenfat til sidst pr. server. Eventuelle reparationer skal gives som forslag og må ikke udføres.

Dette er en opgavebegrænsning og bør kombineres med en skrivebeskyttet konto, motorens værktøjsgodkendelser og netværksadgangsbegrænsninger. At skrive "forbud mod ændringer" i prompten gør ikke automatisk en skrivbar konto skrivebeskyttet.

Begræns samtidighed, og lad fejl blive ved det relevante mål

Første inspektion bør være seriel for at gøre kontrol nem; ved mange mål kan du sætte en lille samtidighedsgrænse inden for virksomhedens godkendte måde at køre værktøjer på, for eksempel højst to samtidige kontroller. "To" her er et eksempel på et driftsbudget, ikke en produktgrænse eller ydeevnegaranti fra PandaSi. Hvis den valgte Agent eller det valgte værktøj ikke pålideligt kan begrænse samtidighed, skal du fortsætte serielt i stedet for at bruge midlertidige ubegrænsede baggrundsopgaver.

Hver kontrol skal have sin egen timeout og resultatregistrering; hvis ét mål fejler, bør det ikke udløse genstart, geninstallation eller ubegrænsede gentagne forsøg på hele batchen. Registrér forbindelses-timeout, identitetsafvigelse, utilstrækkelige rettigheder og fejlede kontrolkommandoer hver for sig; komprimer dem ikke til "offline". Hvis fejlen kommer fra en fælles bastionvært, en autentificeringskilde eller et uklart miljøtilhørsforhold, skal du stoppe og undersøge den fælles årsag i stedet for at øge samtidigheden.

Sammenfatningstabellen skal pr. maskine vise, om identiteten stemmer, hvilke kontroller der faktisk blev udført, centrale beviser og ukendte punkter. Nedenstående viser kun registreringsformatet; teksten i tabellen er udfyldningsinstruktioner, ikke målte resultater:

Mål Identitetskontrol Tjeneste- og health-kontrol Årsag til ikke afsluttet Næste skridt
test-web-01 Udfyld faktiske beviser Ukendt, før det er udført Udfyld efter den faktiske situation Beslut efter kontrol
test-worker-01 Udfyld faktiske beviser Ukendt, før det er udført Udfyld efter den faktiske situation Beslut efter kontrol

Rapporten skal angive "hvor mange maskiner der var planlagt kontrolleret, hvor mange der blev færdige, hvor mange der fejlede, og hvor mange der blev sprunget over" og give beviser for hvert mål. Hvis der mangler resultater, må man ikke antage, at alt er sundt; og en samlet exitkode på 0 fra batchkommandoen kan heller ikke skjule, at en maskine undervejs allerede er fejlet.

Trin 6: Gennemfør først 502-undersøgelsen og gendannelsen på én testtjeneste

Nedenstående er et undervisningseksempel, ikke en faktisk hændelse testet i denne artikel og ikke et sæt reparationskommandoer, der kan kopieres direkte til alle servere. Antag, at en testtjeneste, der er godkendt til drift, returnerer 502 efter en udgivelse, og at du kender testdomænet, tjenestenavnet og projektmappen.

Seks-trins forløb fra målkontrol til skrivebeskyttet undersøgelse, forslag til ændring, manuel godkendelse, eksekvering og accept af gendannelse
Diagram over fejlfindingsforløbet: Godkend den konkrete ændring, og kontrollér ved gendannelse både health-endpointet og de faktiske brugeranmodninger.

Afgræns undersøgelsens omfang først

Du kan formulere opgaven sådan:

Undersøg 502 efter udgivelsen af testtjenesten. Kontrollér først målvært, bruger og mappe, og undersøg skrivebeskyttet den seneste udrulningspost, status for de relevante tjenester, lyttende porte samt proxy- og applikationslogs i det angivne tidsvindue. Genstart ikke, ændr ikke konfiguration, installer ikke afhængigheder, og tilgå ikke andre miljøer. Returnér kun afidentificerede uddrag, der er relevante for denne fejl, og angiv beviser, mulige årsager og hvilke oplysninger der stadig mangler.

Angiv først tidsvinduet og de klare logkilder, så Agent ikke rekursivt gennemgår hele serveren. Skrivebeskyttet adgang kan også lække data: Tokens, kundeoplysninger og anmodningstekster i logs bør stadig filtreres, før de kommer ind i modelkonteksten; de skal ikke sendes først og derefter "glemmes" af modellen.

502 betyder, at proxyen ikke kunne få et brugbart svar fra upstream, men statuskoden alene kan ikke afgøre, om det skyldes, at processen er stoppet, at porten ikke matcher, at en afhængighed fejler, eller at der er et forbindelsesproblem. Lad Agent sammenholde proxyens upstream-adresse, den faktiske lytning og logs fra samme tidsrum; logs på tværs af maskiner skal først have ens tidszoner. Betragt ikke "maskinen er online" som "applikationen er sund", og antag heller ikke, at der ikke er sket en fejl, blot fordi der ikke findes matchende logs.

Kræv et reviderbart reparationsforslag

Hvis beviserne understøtter, at "upstream-porten i udrulningskonfigurationen ikke matcher den faktiske lytning", skal du bede Agent om at fremlægge den konkrete fil og den mindste diff, de planlagte kommandoer, den berørte testtjeneste, metoden til konfigurationskontrol og rollback-betingelser. Dette er stadig kun et betinget eksempel; hvis beviserne ikke understøtter det, skal undersøgelsen fortsætte.

Det, der godkendes, skal være en konkret ændring, ikke "du har fuld kontrol". Godkend for eksempel ændring af en angivet testproxykonfiguration og genindlæsning af den pågældende testproxy, efter at konfigurationskontrollen er bestået; det må ikke medføre opgradering af afhængigheder, oprydning i databasen, ændring af produktionskonfiguration eller genstart af hele værten. De faktiske kommandoer skal fastlægges ud fra den anvendte procesmanager og udrulningsprocedure.

Verificér brugerens vej efter eksekvering

Efter godkendt eksekvering skal accepten som minimum omfatte: Om konfigurationskontrollen bestod, om de relevante processer og porte opfører sig som forventet, om health-endpointet fungerer, og om en faktisk testanmodning fra en uafhængig klient via den oprindelige indgang er gendannet. Hvis health-endpointet returnerer 200, men forretningsrouting, autentificering eller databaseanmodninger stadig fejler, må det ikke skrives som "problemet er løst".

Lad til sidst Agent sammenfatte de udførte kommandoer, de faktiske ændringer, verifikationsresultaterne og resterende risici; punkter, der ikke er verificeret, skal udtrykkeligt markeres som ukendte. Overlever de bekræftede årsager og efterfølgende forebyggelsestiltag til virksomhedens registreringssystem. Undersøgelsesfasen er AI SRE-assisteret; når rettelsen efterfølgende føjes ind i konfigurationsrepositoryet og udrulningsprocessen, bevæger det sig over i AI DevOps.

Trin 7: Når én maskine er godkendt, ændres de øvrige servere i etaper

Godkendelse til batchvis inspektion og batchvise ændringer skal holdes adskilt. At opdage, at flere tjenester har forskellige versioner, betyder ikke, at de uden videre kan opgraderes alle sammen; tjenester med samme navn kan også have forskellige roller eller bruge forskellige konfigurationer. Kontrollér først, om forskellene er forventede, og foreslå derefter en ændringsplan med hvert mål angivet separat.

Vælg kun én klar testmaskine i første parti. Planen skal fastlægge målaliaset, den kontrollerede værtsidentitet, den oprindelige version eller konfiguration, den foreslåede diff, den forventede påvirkning, kontrolmetoden, rollback-trin og stopbetingelser. Når den er godkendt, udføres ændringen på denne ene maskine, og du venter på accept via health-endpointet og den faktiske brugervej; uden bevis for gendannelse må status ikke markeres som vellykket, og næste parti må ikke starte.

Efter en vellykket prøvekørsel skal du udtrykkeligt angive mållisten, partistørrelsen og samtidighedsgrænsen for næste parti; brug ikke et implicit omfang som "alle resterende maskiner", som ændrer sig med listen. Ved afslutningen af hvert parti kontrolleres de faktiske versioner og anmodningsresultater, og der registreres vellykkede, fejlede og ikke-udførte mål. Hvis der opstår identitetsafvigelse, fejlet konfigurationskontrol, forringelse af forretningsanmodninger eller fejlet rollback, skal efterfølgende partier stoppes, og beviserne skal bevares til den ansvarlige; godkendelse i testfasen må ikke betragtes som produktionsgodkendelse.

Rollback skal også defineres pr. maskine. Konfigurationsændringer kan gendannes til den tidligere konfiguration på en godkendt måde; når det drejer sig om databasemigreringer, data skrivninger eller bivirkninger i eksterne systemer, kan man ikke antage, at "skift tilbage til den gamle version" ophæver påvirkningen; den ansvarlige skal først fastlægge gendannelsesplanen. Rul kun tilbage for mål, der faktisk er ændret og har brug for gendannelse; kør ikke blindt omvendte kommandoer på hele gruppen.

Du kan formulere den næste opgave sådan:

Baseret på beviserne fra denne maskinvis inspektion skal du først foreslå en reparationsplan for test-web-01 og ikke udføre den. Angiv den kontrollerede værtsidentitet, de konkrete forskelle, de fuldstændige kommandoer, påvirkningen, rollback-trin, acceptanmodningen og stopbetingelser. Der må først udføres, når denne maskine udtrykkeligt er godkendt; giv derefter de faktiske beviser og vent på godkendelse af næste målgruppe. Maskiner, der ikke er godkendt, forbliver uændrede. Produktionsgruppen er ikke omfattet denne gang og kan ikke arve testgodkendelsen.

Når både test og produktion skal håndteres, skal produktion følge virksomhedens separate ændringsprocedure. En fælles administrationsindgang fjerner ikke krav om miljøisolering, vedligeholdelsesvinduer, udgivelsesgodkendelse eller revision.

Når telefonen mister forbindelsen, skal du først bekræfte opgavens status

At lukke klienten, sætte telefonen i baggrunden eller miste netværket bør ikke forstås som, at den eksterne kommando er stoppet. Processer på eksekveringsmaskinen kan fortsætte; de kan også fejle på grund af, at værten går offline, at motoren afsluttes, eller at den eksterne kanal begrænses. Når du vender tilbage til den oprindelige session, skal du først se værktøjsresultaterne og derefter kontrollere proces, artefakter og tjenestestatus for at undgå at starte installation, udgivelse eller migrering igen.

Fjernkommandokæden kan give "ingen exitstatus returneret": En timeout i forbindelseslaget betyder ikke, at kommandoen ikke blev startet. Lange opgaver skal have tydelig timeout, statusregistrering og annulleringsmetode i virksomhedens eksekveringskanal, især når der er flere SSH-hop. Denne artikel behandler ikke en bestemt versions kanal-timeout som en generel regel for alle SSH-værktøjer.

Når der skal stoppes, skal du bruge en klar stop-handling og verificere den eksterne eksekveringsstatus; ved ikke-idempotente ændringer med uklar status skal et menneske overtage og bekræfte først. Stol ikke på gentagne klik eller på at sende den samme instruktion igen for at afgøre, om den forrige handling lykkedes.

Hvad er forholdet mellem virksomheds- og hjemmeenhedsnetværk og denne artikel?

Denne artikel forudsætter, at den godkendte adgangskanal fra administrationsmaskinen til hver server allerede findes, og fokuserer på, hvordan Agent organiserer arbejdet efter mål. Hvordan flere enheder i virksomheden og hjemmet kommer på netværket, tilgår hinanden og håndterer netværksgrænser, er en anden tilslutningsopgave og blandes ikke sammen her; vellykket netværksopsætning betyder heller ikke, at man har ret til at drive alle de pågældende enheder. Hvis du har brug for at forstå enhedstilslutning, kan du først læse den eksisterende enhedsinterkoblingsvejledning og følge virksomhedens netværksgodkendelsesprocedure.

Grænser for virksomhedsdata, modeller og relay

"Værktøjer kører lokalt" beskriver eksekveringsplaceringen og er ikke et løfte om, at data aldrig forlader virksomheden. Sessionsmeddelelser og godkendelser går gennem produktets kommunikationskanal; logs, kode og værktøjsoutput, der gives til Agent, kan også indgå i anmodninger til den valgte modeludbyder. Kontroller før tilslutning virksomhedens godkendte modeller, databehandlingsaftaler, logopbevaring og adgangspolitikker.

Bevar eksisterende nøglehåndtering og revisionsprocesser; læs legitimationsoplysninger fra den godkendte legitimationsfacilitet på eksekveringsmaskinen, og indsæt dem ikke i chats eller kode-repositories. Begræns driftskontoen og netværkets rækkevidde, og giv log- og mappetilladelser efter behov. Ved fratræden, udfasning af udstyr eller ændring af rettigheder skal du samtidig håndtere arbejdsfladens enhedsgodkendelse, eksekveringsmaskinens konto og adgangen til målserverne; at slette en klient er ikke det samme som at tilbagekalde alle eksekveringsrettigheder.

FAQ

Kan PandaSi automatisk holde vagt, modtage alarmer og reparere produktion?

Denne artikel handler om eksterne sessioner, autoriserede handlinger og manuelle opfølgningsprocesser. Døgnovervågning, alarmintegration, automatisk udløsning og uovervåget fejlretning kræver ekstra overvågningssystemer, triggere, runbooks og rettighedsstyring; man kan ikke udlede af en vellykket tilslutning, at disse funktioner allerede findes.

Kan det bruges, hvis der ikke må installeres software på virksomhedens servere?

Du kan overveje en godkendt administrationsmaskinløsning, forudsat at administrationsmaskinen allerede har lovlig netværks- og identitetsadgang til målene. Hvis virksomheden også forbyder denne type ekstern Agent-tilslutning, skal du først gå gennem godkendelse i stedet for at finde en skjult forbindelsesvej.

Skal der åbnes en offentlig SSH-port på serveren?

Sessionsforbindelsen i PandaPaw oprettes ved, at begge sider aktivt laver udgående forbindelser; det kræver normalt ikke nye offentlige indgående porte for klienttilslutning. Men administrationsmaskinen skal stadig have en virksomhedsgodkendt adgangskanal til målserveren; hvis udgående trafik er begrænset, skal netværksadministratoren konfigurere det, og du bør ikke selv slå beskyttelsen fra.

Skal PandaPaw installeres på hver server?

Administrationsmaskinløsningen i denne artikel kræver ikke, at PandaPaw installeres på hvert SSH-mål, men administrationsmaskinen skal have en godkendt netværkskanal og en ekstern konto. I direktinstallationsløsningen kører Agent på den pågældende vært og tilsluttes hver for sig; de to må ikke forveksles med den samme automatiske gruppestyringsfunktion.

Hvis én inspektion fejler, kan de andre maskiner så fortsætte?

For skrivebeskyttede kontroller, hvor identiteten er verificeret, og som er indbyrdes uafhængige, kan du bevare fejlbeviserne for det pågældende mål og fortsætte med de andre mål; hvis der er tale om en fælles adgangsfejl eller tvivl om miljøtilhørsforhold, skal hele batchen sættes på pause. I ændringsfasen følges de godkendte stopbetingelser; reglen om, at "inspektion kan fortsætte", kan ikke overføres.

Hvad skal accepteres først efter tilslutning?

Kontrollér først administrationsmaskinen, modelbesvarelsen og gendannelsen af sessionen; kontrollér derefter målidentitet, mappe og rettigheder for hver maskine efter listen, gennemfør skrivebeskyttet inspektion og sammenfat resultaterne, og gennemfør til sidst godkendelse, accept af faktiske anmodninger og den efterfølgende etapevise proces på én testtjeneste. Værdien af tilslutningen er, at autoriserede opgaver kan følges vedvarende; om det er egnet til at udvide til flere tjenester, bør afgøres ud fra beviserne fra denne accept.

Kilder og kontrolomfang

Dette udkast blev den 31. oktober 2026 kontrolleret mod projektets hurtigstart, PandaPaw-værtdokumentation, logikken til generering af enhedsinstallationskommandoer og den offentlige downloadindgang for installationsscriptet; den 1. november blev forløbet for flere maskiner tilføjet og SSH-konfiguration og parametersemantik kontrolleret mod OpenSSH's officielle manualer. Denne gang er der kun kontrolleret mod aktuel dokumentation og kildekode; installation og parring er ikke testet på en ren vært, og denne artikels inspektion, etapevise ændringer eller 502-eksempel er ikke udført i et rigtigt miljø med flere maskiner; hver virksomheds netværk, motorgodkendelse og datacompliance skal accepteres i deres eget testmiljø. Alle illustrationer er AI-genererede koncept- eller procesdiagrammer, ikke skærmbilleder af brugerfladen.