Minder uren aan serverwerk en auditvoorbereiding, met elke run gekoppeld aan de vastlegging van zijn wijziging.

Voor middelgrote banken, verzekeraars, betaalinstellingen en fondsbeheerders met een eigen beheerteam, en voor de hosters die hen bedienen. Routinematig serverwerk draait als plannen die iedereen in het team kan uitvoeren, en elke run is gekoppeld aan de vastlegging van de wijziging waar hij bij hoort, zodat de steekproef die een auditor vraagt al bestaat.

Bespaarde uren

Routineklussen op servers kosten niemand meer een middag.

Een plan wordt één keer geschreven en draait elke keer hetzelfde, met een voorbeeld op elke host. Zie infrastructuurautomatisering.

Een serverpark patchen: Een patchcampagne draait in golven met een foutdrempel en stopt zodra de fouten die overschrijden, zodat een slechte patch niet het hele park bereikt.
Configuratiewijzigingen: Bewerk een bestand of een template op veel servers tegelijk. Elke host toont eerst zijn diff voordat er iets verandert, en elke revisie blijft bewaard.
Uitdiensttreding: De uitdiensttreding haalt de toegang van een persoon in één stap overal weg, met bewijs per host, en er hoeft geen sleutel te worden vervangen.

Elke run gekoppeld aan de vastlegging van zijn wijziging

Wie hem draaide, wat hij op elke host deed, en onder welke wijziging hij was goedgekeurd.

Met rollen per omgeving bouwen en testen uw engineers een plan in staging, terwijl het beheerteam het in productie draait. Elke run houdt zijn eigen vastlegging, dus een wijziging is een keten die u van verzoek tot uitkomst kunt lezen en geen reeks tickets die u nog moet samenbrengen.

Fig. 1, vastlegging van de wijziging voor run #4f2a, revisie 7

Change record /Patch nginx across prod, run #4f2a

Sample

@alex → AIDry-run passedApproved by @danaAudited · #4f2a

Origin: Drafted by the AI composer for @alex
Targets: web-01, web-02, web-03 in prod
Dry run: 3 hosts, 12 changes, 0 destructive
Approved: Dana Okafor at 14:32:07, for revision 7 only
Outcome: Completed on 3 hosts, 4 steps

Diffweb-02

/etc/nginx/nginx.conf+3/−2

 --- a/etc/nginx/nginx.conf
 +++ b/etc/nginx/nginx.conf
 @@ -1,7 +1,7 @@
  user  www-data;
−worker_processes  4;
+worker_processes  auto;
  pid /run/nginx.pid;
 @@ -31,6 +31,7 @@
      ssl_prefer_server_ciphers on;
−    ssl_protocols TLSv1.2;
+    ssl_protocols TLSv1.3;
+    ssl_session_tickets off;

Een gepubliceerd voorbeeld

Wat één bank meldde met hetzelfde patroon.

PagerDuty publiceerde de case van een Australische bank die haar automatisering in staging bouwt en test, in productie draait en elke run koppelt aan de vastlegging van een wijziging. PagerDuty meldt dat de auditvoorbereiding daalde van twee tot drie weken naar minder dan een dag, ongeveer 250 uur per maand. Dit is de klant van PagerDuty en het verhaal van PagerDuty, niet dat van Opafra. Lees het op pagerduty.com/customer/australian-bank.

Standaardwijzigingen en de noodprocedure

Keur routinewerk één keer goed. Houd een noodprocedure achter de hand.

Beide staan beschreven op de pagina wijzigingsbeheer.

Catalogus van standaardwijzigingen: Een plan wordt één keer goedgekeurd en vaak gedraaid als standaardwijziging. Elke run wordt nog steeds vastgelegd, en een wijziging die eerder onder een goedkeuring draaide, is minder riskant dan een nieuwe.
Noodprocedure: Draai nu, wanneer productie plat ligt. Een tweede persoon keurt het goed en beoordeelt het achteraf, en het wordt vastgelegd als noodwijziging.
Elke run gekoppeld aan de vastlegging van zijn wijziging: De run legt vast wie hem draaide, op welke hosts en welke goedgekeurde revisie, naast de wijziging waar hij bij hoort.

Auditvoorbereiding

De vastleggingen ontstaan terwijl het werk gebeurt.

De vastleggingen van toegang, wijzigingen en hersteltests worden geschreven terwijl het werk draait, en het auditlog exporteert als CSV of NDJSON. Een audit voorbereiden wordt verzamelen wat er al is. Zie de bewijspagina voor de vier vastleggingen.

Goed om te weten

Hosters, reikwijdte en grenzen, zonder omweg gezegd.

Hosters die financiële bedrijven bedienen: Een hoster die servers beheert voor een financiële instelling, heeft die instelling nodig om wijzigingen op haar eigen servers goed te keuren en de vastlegging te bewaren. Zie hosting en managed serviceproviders.
Gebouwd voor Linux-servers: Opafra verbindt via SSH en is daarom gebouwd voor Linux-servers.
Wat niet in de vastlegging staat: Opafra legt vast wat er via Opafra loopt. Werk dat op een server langs een andere weg gebeurt, staat niet in deze vastleggingen.
Geen certificering: Opafra is geen certificering, en deze pagina beweert niet wat DORA of een andere regel van u vraagt. Ze toont de vastleggingen die het werk achterlaat.

Zie het naast uw wijzigingsproces.

Vertel ons hoe wijzigingen nu in productie komen en wie ze goedkeurt. U krijgt een demo en uw prijs schriftelijk binnen één werkdag, zonder gesprek.

Vraag een demo aan