Hei alle sammen. Jeg jobber som ledende systemadministrator hos OK og er ansvarlig for stabil drift av portalen. Jeg vil snakke om hvordan vi bygde en prosess for automatisk å erstatte disker, og deretter hvordan vi ekskluderte administratoren fra denne prosessen og erstattet ham med en bot.
Denne artikkelen er en slags translitterasjon på HighLoad+ 2018
Bygge en diskutskiftingsprosess
Først noen tall
OK er en gigantisk tjeneste som brukes av millioner av mennesker. Den betjenes av rundt 7 tusen servere, som er plassert i 4 forskjellige datasentre. Serverne inneholder mer enn 70 tusen disker. Stabler du dem oppå hverandre får du et tårn over 1 km høyt.
Harddisker er den serverkomponenten som svikter oftest. Med slike volumer må vi bytte rundt 30 disker per uke, og denne prosedyren har blitt en lite hyggelig rutine.
Hendelser
Vårt firma har innført fullverdig hendelseshåndtering. Vi registrerer hver hendelse i Jira, og så løser og ordner vi det. Hvis en hendelse hadde en effekt på brukerne, så går vi definitivt sammen og tenker på hvordan vi kan reagere raskere i slike tilfeller, hvordan vi kan redusere effekten og selvfølgelig hvordan vi kan forhindre gjentakelse.
Lagringsenheter er intet unntak. Statusen deres overvåkes av Zabbix. Vi overvåker meldinger i Syslog for skrive-/lesefeil, analyserer status for HW/SW-raid, overvåker SMART og beregner slitasje for SSD-er.
Hvordan disker ble endret før
Når en utløser oppstår i Zabbix, opprettes en hendelse i Jira og tildeles automatisk de riktige ingeniørene i datasentrene. Dette gjør vi med alle HW-hendelser, det vil si de som krever noe fysisk arbeid med utstyr i datasenteret.
En datasenteringeniør er en person som løser problemer knyttet til maskinvare og er ansvarlig for å installere, vedlikeholde og demontere servere. Etter å ha mottatt billetten, begynner ingeniøren å jobbe. I diskhyller bytter han disker uavhengig. Men hvis han ikke har tilgang til den nødvendige enheten, henvender ingeniøren seg til systemadministratorene på vakt for å få hjelp. Først av alt må du fjerne disken fra rotasjon. For å gjøre dette må du gjøre de nødvendige endringene på serveren, stoppe applikasjoner og demontere disken.
Vakthavende systemansvarlig har ansvaret for driften av hele portalen i arbeidsskiftet. Han undersøker hendelser, utfører reparasjoner og hjelper utviklere med å fullføre små oppgaver. Han driver ikke bare med harddisker.
Tidligere kommuniserte datasenteringeniører med systemadministratoren via chat. Ingeniører sendte lenker til Jira-billetter, administratoren fulgte dem, førte en logg over arbeidet i en notisblokk. Men chat er upraktisk for slike oppgaver: informasjonen der er ikke strukturert og går raskt tapt. Og administratoren kunne ganske enkelt gå bort fra datamaskinen og ikke svare på forespørsler på en stund, mens ingeniøren sto ved serveren med en stabel med disker og ventet.
Men det verste var at administratorene ikke så hele bildet: hvilke diskhendelser som fantes, hvor det potensielt kunne oppstå et problem. Dette skyldes det faktum at vi delegerer alle HW-hendelser til ingeniører. Ja, det var mulig å vise alle hendelser på administratorens dashbord. Men det er mange av dem, og administratoren var involvert bare for noen av dem.
I tillegg kunne ikke ingeniøren angi prioriteringer riktig, fordi han ikke vet noe om formålet med spesifikke servere eller distribusjon av informasjon mellom stasjoner.
Ny erstatningsprosedyre
Det første vi gjorde var å flytte alle diskhendelser til en egen type "HW disk" og la til feltene "block device name", "size" og "disk type" til den slik at denne informasjonen ble lagret i billetten og ville ikke trenger å konstant utveksle i chat.
Vi ble også enige om at vi under en hendelse bare skulle bytte en disk. Dette forenklet automatiseringsprosessen, statistikkinnsamlingen og arbeidet i fremtiden betydelig.
I tillegg la vi til feltet "ansvarlig administrator". Vakthavende systemadministrator settes automatisk inn der. Dette er veldig praktisk, for nå ser ingeniøren alltid hvem som har ansvaret. Du trenger ikke å gå til kalenderen og søke. Det var dette feltet som gjorde det mulig å vise billetter på administratorens dashbord som kunne trenge hans hjelp.
For å sikre at alle deltakerne fikk maksimalt utbytte av innovasjoner, laget vi filtre og dashbord og fortalte gutta om dem. Når folk forstår endringer, tar de ikke avstand fra dem som noe unødvendig. Det er viktig for en ingeniør å vite racknummeret der serveren er plassert, størrelsen og typen disk. Administratoren må først og fremst forstå hva slags gruppe med servere dette er og hva effekten kan være når du bytter ut en disk.
Tilstedeværelsen av felt og deres visning er praktisk, men det reddet oss ikke fra behovet for å bruke chatter. For å gjøre dette måtte vi endre arbeidsflyten.
Tidligere var det slik:
Slik fortsetter ingeniører å jobbe i dag når de ikke trenger administratorhjelp.
Det første vi gjorde var å introdusere en ny status undersøke. Billetten er i denne statusen når ingeniøren ennå ikke har bestemt seg for om han vil trenge en administrator eller ikke. Gjennom denne statusen kan teknikeren overføre billetten til administratoren. I tillegg bruker vi denne statusen til å merke billetter når en disk må byttes, men selve disken ikke er på stedet. Dette skjer i tilfelle av CDN-er og eksterne nettsteder.
Vi har også lagt til status Klar. Billetten overføres til den etter å ha erstattet disken. Det vil si at alt er allerede gjort, men HW/SW RAID er synkronisert på serveren. Dette kan ta ganske lang tid.
Hvis en administrator er involvert i arbeidet, blir ordningen litt mer komplisert.
Fra status Åpen Billetten kan oversettes av både systemadministrator og ingeniør. I status I prosess administratoren fjerner disken fra rotasjon slik at teknikeren ganske enkelt kan trekke den ut: slår på bakgrunnsbelysningen, demonterer disken, stopper applikasjoner, avhengig av den spesifikke gruppen av servere.
Billetten overføres deretter til Klar til å endre: Dette er et signal til ingeniøren om at disken kan trekkes ut. Alle feltene i Jira er allerede fylt ut, ingeniøren vet hvilken type og størrelse på disken. Disse dataene legges inn enten automatisk på forrige status eller av administratoren.
Etter at du har byttet ut disken, endres billettstatusen til Endret. Den sjekker at riktig disk er satt inn, partisjonering er utført, applikasjonen startes og noen datagjenopprettingsoppgaver startes. Billetten kan også overføres til status Klar, i dette tilfellet vil administratoren forbli ansvarlig, fordi han satte disken i rotasjon. Det komplette diagrammet ser slik ut.
Å legge til nye felt gjorde livet vårt mye enklere. Gutta begynte å jobbe med strukturert informasjon, det ble klart hva som måtte gjøres og på hvilket stadium. Prioriteringer har blitt mye mer relevante, siden de nå er satt av administrator.
Det er ikke behov for chatter. Selvfølgelig kan administratoren skrive til ingeniøren "dette må byttes ut raskere," eller "det er allerede kveld, vil du ha tid til å erstatte det?" Men vi kommuniserer ikke lenger daglig i chatter om disse problemene.
Disker begynte å bli endret i grupper. Hvis administratoren kom på jobb litt tidlig, han har ledig tid, og ingenting har skjedd ennå, kan han forberede en rekke servere for utskifting: fyll ut feltene, fjern diskene fra rotasjon og overfør oppgaven til en ingeniør. Ingeniøren kommer til datasenteret litt senere, ser oppgaven, tar de nødvendige stasjonene fra lageret og erstatter dem umiddelbart. Som et resultat har erstatningsraten økt.
Lærdom når du bygger arbeidsflyt
- Når du konstruerer en prosedyre, må du samle informasjon fra forskjellige kilder.
Noen av administratorene våre visste ikke at ingeniøren endrer diskene selv. Noen trodde at MD RAID-synkronisering ble håndtert av ingeniører, selv om noen av dem ikke engang hadde tilgang til det. Noen ledende ingeniører gjorde dette, men ikke alltid fordi prosessen ikke ble beskrevet noe sted. - Prosedyren skal være enkel og forståelig.
Det er vanskelig for en person å ha mange trinn i tankene. De viktigste nabostatusene i Jira bør plasseres på hovedskjermen. Du kan gi dem nytt navn, for eksempel kaller vi Pågår Klar til endring. Og andre statuser kan skjules i en rullegardinmeny slik at de ikke er et øyesår. Men det er bedre å ikke begrense folk, for å gi dem muligheten til å gjøre overgangen.
Forklar verdien av innovasjon. Når folk forstår, aksepterer de den nye prosedyren mer. Det var veldig viktig for oss at folk ikke klikker seg gjennom hele prosessen, men følger den. Så bygget vi automatisering på dette. - Vent, analyser, finn ut av det.
Det tok oss omtrent en måned å bygge prosedyre, teknisk implementering, møter og diskusjoner. Og implementeringen tar mer enn tre måneder. Jeg så hvordan folk sakte begynner å bruke innovasjonen. Det var mye negativitet i de tidlige stadiene. Men det var helt uavhengig av selve prosedyren og dens tekniske gjennomføring. En administrator brukte for eksempel ikke Jira, men Jira-pluginen i Confluence, og noen ting var ikke tilgjengelige for ham. Vi viste ham Jira, og administratorens produktivitet økte både for generelle oppgaver og for å bytte ut disker.
Automatisering av diskutskifting
Vi nærmet oss automatisering av diskutskifting flere ganger. Vi hadde allerede utviklinger og skript, men de fungerte alle enten interaktivt eller manuelt og krevde lansering. Og først etter å ha innført den nye prosedyren skjønte vi at det var akkurat dette vi manglet.
Siden nå er erstatningsprosessen vår delt inn i stadier, som hver har en spesifikk utøver og en liste over handlinger, kan vi aktivere automatisering i etapper, og ikke alle på en gang. For eksempel kan det enkleste trinnet - Ready (kontrollere RAID/datasynkronisering) enkelt delegeres til en bot. Når boten har lært litt, kan du gi den en viktigere oppgave - å sette disken i rotasjon osv.
Zoo oppsett
Før vi snakker om boten, la oss ta en kort utflukt til vår dyrehage med installasjoner. For det første skyldes det den gigantiske størrelsen på infrastrukturen vår. For det andre prøver vi å velge den optimale maskinvarekonfigurasjonen for hver tjeneste. Vi har rundt 20 hardware RAID-modeller, for det meste LSI og Adaptec, men det finnes også HP og DELL av forskjellige versjoner. Hver RAID-kontroller har sitt eget administrasjonsverktøy. Settet med kommandoer og utstedelsen av dem kan variere fra versjon til versjon for hver RAID-kontroller. Der HW-RAID ikke brukes, kan mdraid brukes.
Vi gjør nesten alle nyinstallasjoner uten diskbackup. Vi prøver å ikke lenger bruke maskinvare- og programvare-RAID, da vi sikkerhetskopierer systemene våre på datasenternivå, ikke servere. Men selvfølgelig er det mange eldre servere som må støttes.
Et sted blir diskene i RAID-kontrollere overført til råenheter, et eller annet sted brukes JBOD-er. Det er konfigurasjoner med en systemdisk på serveren, og hvis den må byttes ut, må du installere serveren på nytt med installasjon av OS og applikasjoner, av samme versjoner, deretter legge til konfigurasjonsfiler, starte applikasjoner. Det er også mange servergrupper der sikkerhetskopiering utføres ikke på diskundersystemnivå, men direkte i selve applikasjonene.
Totalt har vi over 400 unike servergrupper som kjører nesten 100 forskjellige applikasjoner. For å dekke et så stort antall alternativer, trengte vi et multifunksjonelt automatiseringsverktøy. Gjerne med en enkel DSL, slik at ikke bare den som har skrevet den kan støtte det.
Vi valgte Ansible fordi det er agentløst: det var ikke nødvendig å forberede infrastruktur, en rask start. I tillegg er det skrevet i Python, som er akseptert som standard innad i teamet.
Generell ordning
La oss se på den generelle automatiseringsordningen ved å bruke én hendelse som eksempel. Zabbix oppdager at sdb-disken har feilet, triggeren lyser, og en billett opprettes i Jira. Administratoren så på det, innså at det ikke var et duplikat og ikke en falsk positiv, det vil si at disken måtte endres, og overførte billetten til Pågår.
DiskoBot-applikasjonen, skrevet i Python, spør med jevne mellomrom Jira etter nye billetter. Den merker at en ny Pågående billett har dukket opp, den tilsvarende tråden utløses, som lanserer spilleboken i Ansible (dette gjøres for hver status i Jira). I dette tilfellet lanseres Prepare2change.
Ansible sendes til verten, fjerner disken fra rotasjon og rapporterer status til applikasjonen via tilbakeringinger.
Basert på resultatene, overfører boten automatisk billetten til Klar for endring. Ingeniøren mottar et varsel og går for å bytte disk, hvoretter han overfører billetten til Changed.
I henhold til skjemaet beskrevet ovenfor, går billetten tilbake til boten, som lanserer en annen spillebok, går til verten og setter disken i rotasjon. Boten lukker billetten. Hurra!
La oss nå snakke om noen komponenter i systemet.
Diskobot
Denne applikasjonen er skrevet i Python. Den velger billetter fra Jira i henhold til JQL. Avhengig av statusen til billetten, går sistnevnte til den tilsvarende behandleren, som igjen starter Ansible-spilleboken som tilsvarer statusen.
JQL og pollingintervaller er definert i applikasjonens konfigurasjonsfil.
jira_states:
investigate:
jql: '… status = Open and "Disk Size" is EMPTY'
interval: 180
inprogress:
jql: '… and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
ready:
jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
interval: 7200
For eksempel, blant billetter i statusen Pågår, er bare de med feltene Diskstørrelse og Enhetsnavn fylt ut valgt. Enhetsnavn er navnet på blokkenheten som trengs for å kjøre spilleboken. Diskstørrelse er nødvendig slik at teknikeren vet hvilken størrelse disk som trengs.
Og blant billetter med Klar-status filtreres billetter med dbot_ignore-etiketten ut. Vi bruker forresten Jira-etiketter både til slik filtrering og for merking av dupliserte billetter og innsamling av statistikk.
Hvis en spillebok mislykkes, tildeler Jira etiketten dbot_failed slik at den kan sorteres ut senere.
Interoperabilitet med Ansible
Applikasjonen kommuniserer med Ansible via . Til playbook_executor sender vi filnavnet og et sett med variabler. Dette lar deg beholde Ansible-prosjektet i form av vanlige yml-filer, i stedet for å beskrive det i Python-kode.
Også i Ansible, via *extra_vars*, navnet på blokkeringsenheten, statusen til billetten, samt callback_url, som inneholder problemnøkkelen - den brukes for tilbakeringing i HTTP.
For hver lansering genereres et midlertidig inventar bestående av én vert og gruppen som denne verten tilhører, slik at group_vars blir brukt.
Her er et eksempel på en oppgave som implementerer HTTP tilbakeringing.
Vi får resultatet av å utføre playbooks ved å bruke callaback(er). De er av to typer:
- , gir den data om resultatene av utførelse av playbook. Den beskriver oppgavene som ble lansert, fullført vellykket eller mislykket. Denne tilbakeringingen kalles når spilleboken er ferdig avspilt.
- HTTP tilbakeringing for å motta informasjon mens du spiller en spillebok. I Ansible-oppgaven utfører vi en POST/GET-forespørsel til applikasjonen vår.
Variabler sendes gjennom HTTP-tilbakekall(er) som ble definert under kjøringen av playbook og som vi ønsker å lagre og bruke i påfølgende kjøringer. Vi skriver disse dataene i sqlite.
Vi legger også igjen kommentarer og endrer billettstatus via HTTP tilbakeringing.
HTTP tilbakeringing
# Make callback to Diskobot App
# Variables:
# callback_post_body: # A dict with follow keys. All keys are optional
# msg: If exist it would be posted to Jira as comment
# data: If exist it would be saved in Incident.variables
# desire_state: Set desire_state for incident
# status: If exist Proceed issue to that status
- name: Callback to Diskobot app (jira comment/status)
uri:
url: "{{ callback_url }}/{{ devname }}"
user: "{{ diskobot_user }}"
password: "{{ diskobot_pass }}"
force_basic_auth: True
method: POST
body: "{{ callback_post_body | to_json }}"
body_format: json
delegate_to: 127.0.0.1
Som mange oppgaver av samme type legger vi den i en egen felles fil og inkluderer den om nødvendig, for ikke å gjenta den hele tiden i spillebøker. Dette inkluderer callback_ url, som inneholder problemnøkkelen og vertsnavnet. Når Ansible utfører denne POST-forespørselen, forstår boten at den kom som en del av en slik og en hendelse.
Og her er et eksempel fra spilleboken, der vi sender ut en disk fra en MD-enhet:
# Save mdadm configuration
- include: common/callback.yml
vars:
callback_post_body:
status: 'Ready to change'
msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
data:
mdadm_data: "{{ mdadm_remove_disk.removed }}"
parted_info: "{{ parted_info | default() }}"
when:
- mdadm_remove_disk | changed
- mdadm_remove_disk.removed
Denne oppgaven overfører Jira-billetten til statusen "Klar til endring" og legger til en kommentar. Variabelen mdam_data lagrer også en liste over md-enheter som disken ble fjernet fra, og parted_info lagrer en partisjonsdump fra parted.
Når ingeniøren setter inn en ny disk, kan vi bruke disse variablene til å gjenopprette partisjonsdumpen, samt sette inn disken i md-enhetene den ble fjernet fra.
Mulig kontrollmodus
Det var skummelt å slå på automatikken. Derfor bestemte vi oss for å kjøre alle playbooks i modusen
, der Ansible ikke utfører noen handlinger på serverne, men bare emulerer dem.
En slik lansering kjøres gjennom en egen tilbakeringingsmodul, og resultatet av playbook-kjøringen lagres i Jira som en kommentar.
For det første gjorde dette det mulig å validere arbeidet til boten og playbooks. For det andre økte det administratorers tillit til boten.
Da vi bestod valideringen og innså at du kan kjøre Ansible ikke bare i tørrkjøringsmodus, laget vi en Kjør Diskobot-knapp i Jira for å starte den samme spilleboken med de samme variablene på samme vert, men i normal modus.
I tillegg brukes knappen til å starte spilleboken på nytt hvis den krasjer.
Playbooks struktur
Jeg har allerede nevnt at avhengig av statusen til Jira-billetten, lanserer boten forskjellige spillebøker.
For det første er det mye enklere å organisere inngangen.
For det andre er det i noen tilfeller rett og slett nødvendig.
For eksempel, når du erstatter en systemdisk, må du først gå til distribusjonssystemet, opprette en oppgave, og etter riktig distribusjon vil serveren bli tilgjengelig via ssh, og du kan rulle ut applikasjonen på den. Hvis vi gjorde alt dette i én spillebok, ville ikke Ansible kunne fullføre det på grunn av at verten ikke var tilgjengelig.
Vi bruker Ansible-roller for hver gruppe servere. Her kan du se hvordan lekeboken(e) er organisert i en av dem.
Dette er praktisk fordi det umiddelbart er klart hvor hvilke oppgaver er plassert. I main.yml, som er inngangen til Ansible-rollen, kan vi ganske enkelt inkludere etter billettstatus eller generelle oppgaver som kreves for alle, for eksempel å sende identifikasjon eller motta en token.
etterforskning.yml
Kjører for billetter i Etterforskning og Åpen status. Det viktigste for denne spilleboken er navnet på blokkenheten. Denne informasjonen er ikke alltid tilgjengelig.
For å få det, analyserer vi Jira-sammendraget, den siste verdien fra Zabbix-utløseren. Den kan inneholde navnet på blokkeringsenheten - heldig. Eller det kan inneholde et monteringspunkt, så må du gå til serveren, analysere den og beregne den nødvendige disken. Utløseren kan også overføre en scsi-adresse eller annen informasjon. Men det hender også at det ikke er spor, og man må analysere.
Etter å ha funnet ut navnet på blokkeringsenheten, samler vi inn informasjon om typen og størrelsen på disken fra den for å fylle ut feltene i Jira. Vi fjerner også informasjon om leverandør, modell, firmware, ID, SMART, og legger alt dette inn i en kommentar i Jira-billetten. Administratoren og ingeniøren trenger ikke lenger å søke etter disse dataene. 🙂
prepare2change.yml
Fjerne disken fra rotasjon, klargjøring for utskifting. Det vanskeligste og viktigste stadiet. Det er her du kan stoppe applikasjonen når den ikke bør stoppes. Eller ta ut en disk som ikke har nok replikaer, og dermed ha en effekt på at brukerne mister noen data. Her har vi flest sjekker og varsler i chatten.
I det enkleste tilfellet snakker vi om å fjerne en disk fra en HW/MD RAID.
I mer komplekse situasjoner (i våre lagringssystemer), når sikkerhetskopieringen utføres på applikasjonsnivå, må du gå til applikasjonen via API, rapportere diskutgangen, deaktivere den og starte gjenopprettingen.
Vi migrerer nå massevis til , og hvis serveren er skybasert, kaller Diskobot cloud API, sier at den kommer til å fungere med denne minion - serveren som kjører containere - og spør "migrer alle containere fra denne minion." Og slår samtidig på bakgrunnsbelysningen på disken slik at ingeniøren umiddelbart kan se hvilken som må trekkes ut.
endret.yml
Etter å ha erstattet en disk, sjekker vi først tilgjengeligheten.
Ingeniører installerer ikke alltid nye stasjoner, så vi la til en sjekk for SMART-verdier som tilfredsstiller oss.
Hvilke egenskaper ser vi på?Antall omfordelte sektorer (5) < 100
Gjeldende avventende sektortelling (107) == 0
Hvis stasjonen mislykkes i testen, blir teknikeren varslet om å skifte den ut igjen. Hvis alt er i orden, slås bakgrunnsbelysningen av, merker påføres og platen settes i rotasjon.
klar.yml
Det enkleste tilfellet: sjekke HW/SW raid-synkronisering eller fullføre datasynkronisering i applikasjonen.
Application API
Jeg har nevnt flere ganger at boten ofte får tilgang til applikasjons-APIer. Selvfølgelig hadde ikke alle applikasjoner de nødvendige metodene, så de måtte endres. Her er de viktigste metodene vi bruker:
- Status. Status for en klynge eller disk for å forstå om den kan arbeides med;
- Start stopp. Diskaktivering/deaktivering;
- Migrer/gjenopprett. Datamigrering og gjenoppretting under og etter utskifting.
Lærdom fra Ansible
Jeg elsker Ansible virkelig. Men ofte, når jeg ser på forskjellige opensource-prosjekter og ser hvordan folk skriver lekebøker, blir jeg litt redd. Komplekse logiske sammenvevninger av når/løkke, mangel på fleksibilitet og idempotens på grunn av hyppig bruk av skall/kommando.
Vi bestemte oss for å forenkle alt så mye som mulig, og utnytte fordelen med Ansible - modularitet. På det høyeste nivået er det spillebøker; de kan skrives av enhver administrator, tredjepartsutvikler som kan litt Ansible.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Hvis noe logikk er vanskelig å implementere i playbooks, flytter vi det inn i en Ansible-modul eller et filter. Skript kan skrives i Python eller et hvilket som helst annet språk.
De er enkle og raske å skrive. For eksempel består diskbakgrunnsbelysningsmodulen, et eksempel på som er vist ovenfor, av 265 linjer.
På det laveste nivået ligger biblioteket. For dette prosjektet skrev vi en egen applikasjon, en slags abstraksjon over maskinvare- og programvare-RAIDer som utfører de tilsvarende forespørslene.
Ansibles største styrker er dens enkelhet og klare lekebøker. Jeg tror at du må bruke dette og ikke generere skumle yaml-filer og et stort antall forhold, skallkode og løkker.
Hvis du vil gjenta vår erfaring med Ansible API, må du huske på to ting:
- Playbook_executor og playbooks generelt kan ikke gis en timeout. Det er en timeout på ssh-økten, men det er ingen timeout på playbook. Hvis vi prøver å avmontere en disk som ikke lenger eksisterer i systemet, vil spilleboken kjøre uendelig, så vi måtte pakke lanseringen inn i en egen wrapper og drepe den med en timeout.
- Ansible kjører på forked prosesser, så APIen er ikke trådsikker. Vi kjører alle lekebøkene våre enkelttrådede.
Som et resultat var vi i stand til å automatisere utskiftingen av omtrent 80 % av diskene. Totalt sett er erstatningsraten doblet. I dag ser administratoren bare på hendelsen og bestemmer seg for om disken må endres eller ikke, og gjør så ett klikk.
Men nå begynner vi å støte på et annet problem: noen nye administratorer vet ikke hvordan de skal bytte stasjoner. 🙂
Kilde: www.habr.com