Nejaušs ražošanas pārtraukums, noplūdušas API atslēgas vai dzēsta mākoņa infrastruktūra¶

Katrs programmatūras inženieris, sistēmu administrators un tehniskais attālinātais darbinieks galu galā saskaras ar vēdergraizes brīdi, kad komanda, kas paredzēta localhost vai staging izpilda pret production: neindeksēts DELETE bez a WHERE klauzula, a DROP TABLE vai terraform destroy, a git push --force kas pārraksta galveno filiāli vai publisku apņemšanos, kas satur dzīvās AWS vai Stripe slepenās atslēgas. 15 minūšu nelielas žagas no karjeras beigu datu katastrofas atšķir tas, ka nekavējoties tiek apturēta jūsu rokas, tiek apturēta rakstīšanas trafiks, pirms tiek pārrakstīti krātuves bloki, un tiek izpildīts pareizais atkopšanas protokols.

Dariet to tagad¶

1. Sasaldējiet rokas un NEpalaidiet pārsteidzīgas "labošanas" komandas, restartējiet datu bāzes serveri un neaizveriet termināļa logu. Jūsu pašreizējais termināļa ritināšanas buferis, čaulas vēsture un lokālais .git/logs reflog satur precīzus darījumu laikspiedolus, veic SHA jaucējus un resursu ID, kas nepieciešami, lai novērstu bojājumus. Vispirms kopējiet visu termināļa ritināšanu drošā teksta failā.
2. Paziņojiet par 1. nopietnības (SEV-1) incidentu savas komandas incidentā Slack/Teams kanālā 2 minūšu laikā. Nekad nepavadiet 45 minūtes, mēģinot slepeni salabot bojātu ražošanas datu bāzi, kamēr klienti saskaras ar 500 kļūdām un automatizēti fona darbi sabojā atlikušās tabulas. Nekavējoties meklējiet izsaukuma datu bāzes administratoru (DBA) vai vietnes uzticamības inženieri (SRE).
3. Ja nopludinājāt API atslēgu, .env failu vai mākoņa noslēpumu publiskam GitHub repo, PIRMS ATSAUKTI atslēgu pakalpojumu sniedzēja informācijas panelī (pirms mēģināt pārrakstīt Git vēsturi). Automatizētie robottīkli nokopj publisko GitHub Firehose API un izpilda nozagtās AWS, OpenAI, Stripe un GCP atslēgas 3 līdz 15 sekunžu laikā. git push. Faila dzēšana, veicot otro apņemšanos vai piespiedu nospiešanu, neaptur uzbrucēju, kurš jau ir klonējis atslēgu.
4. Ja jūs skrējāt nejauši DELETE, UPDATE, vai DROP ražošanas datu bāzē nekavējoties izgrieziet lietojumprogrammas WRITE trafiku. Ieslēdziet tīmekļa lietojumprogrammu uzturēšanas režīmā vai atsauciet lietotnes lietotāja rakstīšanas atļaujas, lai jaunie ienākošie darījumi nepārrakstītu nevakuumātos mirušos korešus vai nesarežģītu atkopšanu laikā (PITR).
5. Nekad neskrien VACUUM, OPTIMIZE TABLE, vai git gc --prune=now pēc nejaušas dzēšanas. Gan relāciju datu bāzes (PostgreSQL MVCC, MySQL InnoDB), gan Git saglabā diskā neskartas dzēstās rindas un bezsaimnieka saistības, līdz atkritumu savākšanas/vakuuma caurlaide fiziski atgūst lapas.
6. Ja a terraform destroy vai mākoņa dzēšanas skripts joprojām darbojas jūsu terminālī, nospiediet Ctrl + C VIENREIZ (ne divreiz) vai nogaliniet IAM sesijas marķieri. Nospiežot Ctrl + C vienreiz aktivizē graciozu stāvokļa skalošanu, tāpēc Terraform saglabā daļēju .tfstate par to, kas joprojām pastāv; nospiežot Ctrl + C divreiz piespiež negodīgu pārtraukšanu, kas var sabojāt vai zaudēt jūsu vietējās valsts failu.

Ārkārtas šķirošanas darbplūsma: datu bāzes izkrišana, git piespiedu nospiešana vai slepena noplūde¶

Izpildiet šo lēmumu koku, lai veiktu pirmās 5 tehniskās ierobežošanas minūtes.

flowchart TD
    A["Ražošanas inženierijas ārkārtas situācija"] --> B{"Kura kļūme tikko notika?"}
    B -->|"Nejauši SQL DROP/DELETE/UPDATE prod"| C["Apturēt lietotņu rakstīšanu / uzturēšanas režīmu; NEdarbiniet VAKUUMU"]
    B -->|"Noplūda API atslēga / .env / privātā atslēga pakalpojumā Git"| D["Atsauciet un pagrieziet noslēpumu mākoņa informācijas panelī 60 sekunžu laikā"]
    B -->|"Nejaušs git push --force / Deleted Branch"| E["Palaist git reflog lokāli; Kopēt Last Good Commit SHA"]
    B -->|"Nejaušas terraformas iznīcināšana / dzēsts S3 vai VM"| F["Nogalināt IAM sesiju vai vienreiz nospiediet Ctrl+C; Saglabāt .tfstate"]
    C --> G["Ierakstīt precīzu UTC laika zīmogu; Iedarbiniet mākoņa PITR klonu vai Binlog Flashback"]
    D --> H["Pārbaudīt CloudTrail/piekļuves žurnālus neatļautiem paplašināšanās gadījumiem; Scrub Repo ar git-filter-repo"]
    E --> I["GitHub notikumu vaicājums / Reflog & Restore Branch ar git push , force-with-lease"]
    F --> J["Pārbaudiet S3 versiju dzēšanas marķierus, EBS momentuzņēmumus vai mākoņa atkritni"]

1. daļa: Nejaušas ražošanas datu bāze DROP, TRUNCATE, vai DELETE bez WHERE¶

Kad destruktīvs SQL vaicājums sasniedz dzīvu produkcijas datu bāzi, precīzs atkopšanas mehānisms ir atkarīgs no jūsu datu bāzes programmas (PostgreSQL, MySQL/MariaDB, SQL Server, MongoDB vai DynamoDB) un no tā, vai paziņojums bija DML (DELETE / UPDATE) vai DDL (DROP TABLE / TRUNCATE) darbība.

1. darbība: ierakstiet precīzu UTC laikspiedolu līdz sekundei¶

Pirms pieskaraties jebkurai rezerves konsolei, pierakstiet precīzo pašreizējo UTC laiku (date -u Linux/macOS terminālā vai SELECT NOW(); SQL uzvednē) un aprēķiniet precīzu sekundi tieši pirms, kad tika sākta jūsu destruktīvā vaicājuma izpilde. Point-In-Time Recovery (PITR) darbojas, atkārtoti atskaņojot datu bāzes ierakstīšanas žurnālu (WAL PostgreSQL) vai binārajā žurnālā (binlog MySQL) līdz T_minus_1_second tieši pirms sliktā vaicājuma saņemšanas.

2. darbība. Apturiet fona darbus un lietojumprogrammu rakstīšanu (aizsargājiet MVCC kopas)¶

Programmā PostgreSQL, izpilde DELETE FROM users; vai UPDATE orders SET status = 'cancelled'; vai ne faktiski uzreiz neizdzēš nevienu datu baitu no tabulas faila diskā. Tā kā PostgreSQL izmanto Multi-Version Concurrency Control (MVCC), a DELETE vienkārši iestata xmax darījuma ID galvene katrā rindas virknē, lai atzīmētu to kā neredzamu turpmākajiem vaicājumiem, atstājot visus rindas datus neskartus base/ kaudzes failu, līdz parādās autovacuum, lai atzīmētu vietu atkārtoti lietojamu.

• Ja izmantojat pašmitinātu vai VM PostgreSQL un jums nav nesena dublējuma: Nekavējoties izveidojiet savienojumu kā superuser un atspējot autovakuumu uz šī galda (ALTER TABLE table_name SET (autovacuum_enabled = false);), vai apturiet PostgreSQL pakalpojumu un uzņemiet neapstrādātu bloka līmeņa failu sistēmas momentuzņēmumu (LVM / EBS momentuzņēmums) no /var/lib/postgresql/data direktoriju. Specializētie PostgreSQL kriminālistikas paplašinājumi (pg_dirtyread) var nolasīt un dažu minūšu laikā nolasīt un atgūt 100 procentus izdzēsto vai pirms atjaunināšanas rindu tieši no netīrītās kaudzes tabulas.

Datu bāzes atkopšanas matrica pēc dzinēja un mākoņa platformas¶

2. daļa: noplūdušas API atslēgas, .env noslēpumus vai privātās atslēgas, kas piešķirtas Git¶

Ja esat nejauši izdarījis .env fails, an id_rsa SSH atslēga, Firebase/GCP pakalpojuma konta JSON fails, Stripe slepenā atslēga (sk_live_...) vai AWS AKIA... Piekļuves atslēga Git, izpildiet tieši šo divu fāžu secību: ** A fāze (nogaliniet atslēgu mākonī)** un ** B fāze (notīriet Git krātuvi)** pēc tam.

A fāze: tūlītēja 60 sekunžu mākoņa akreditācijas datu ierobežošana (dariet to PIRMAIS)¶

1. AWS (AKIA... Piekļuves atslēgas ID + slepenā piekļuves atslēga)¶

Kad roboti nozog AWS atslēgu no GitHub, to automatizētais skripts nonāk jūsu kontā 10 sekunžu laikā, lai izveidotu maksimālā izmēra GPU EC2 gadījumus (p4d.24xlarge / g5.48xlarge) visos 30+ globālajos AWS reģionos (tostarp izvēlētajos reģionos, piemēram, Džakartā, Osakā un Tuvajos Austrumos), lai iegūtu kriptovalūtu vai izveidotu aizmugures IAM lietotāju ar AdministratorAccess pirms sākotnējās atslēgas dzēšanas.

1. Nekavējoties deaktivizējiet un izdzēsiet noplūdušo piekļuves atslēgu:
   • Atveriet AWS konsole -> IAM -> Lietotāji -> [kompromitēts lietotājs] -> Drošības akreditācijas dati -> Piekļuves atslēgas -> Noklikšķiniet uz Deaktivizēt, pēc tam uz Dzēst (vai izmantojot CLI: aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name MyUser).
2. ** Pievienojiet skaidru informāciju DenyAll pagaidu neitralizācijas politika aws sts sesijas marķieri:**
   • Kritiskais slazds: pat pēc tam, kad esat izdzēsis AKIA... IAM piekļuves atslēga, ja uzbrucējs jau ir zvanījis sts:GetSessionToken vai sts:AssumeRole pirmo 30 sekunžu laikā tās ir īslaicīgas ASIA... sesijas marķieris ir derīgs 1-12 stundas, ja vien nepievienojat skaidru iekļautu Lieguma politiku (piemēram, AWSCompromisedKeyQuarantineV2 vai visu aizlieguma politika marķieriem, kas izdoti pirms pašreizējā laikspiedola) lietotājam vai lomai.
3. Pārbaudiet AWS CloudTrail, lai nodrošinātu noturību aizmugures durvīm:
   • Atveriet sadaļu AWS CloudTrail , > notikumu vēsture un filtrējiet pēc apdraudētā piekļuves atslēgas ID vai lietotāja vārda pēdējo 2 stundu laikā.
   • Īpaši pārbaudiet šos 5 noturīgos zvanus: CreateUser, CreateAccessKey, AttachUserPolicy, AssumeRole, un RunInstances. Pārbaudiet AWS Cost Explorer un EC2 Global View visos visos reģionos, lai pārtrauktu jebkādas negodīgas instances, un nekavējoties atveriet AWS atbalsta lietu (konts un norēķini , > apdraudēts konts). AWS regulāri atsakās no krāpnieciskiem aprēķinu rēķiniem, kad ziņojat par atslēgas noplūdi un nekavējoties pārtraucat gadījumus.

2. Svītra (sk_live_...), OpenAI (sk-...), SendGrid, Twilio un Slack Tokens¶

• Svītra: dodieties uz sadaļu Izstrādātāji -> API atslēgas -> Standarta atslēgas / Ierobežotās atslēgas -> Noklikšķiniet uz trim punktiem (...) -> Ritināšanas taustiņš. Izvēlieties “Beigties tūlīt” (vai iestatiet 1 stundas pagarinājuma periodu tikai tad, ja pašlaik aktīvi izvietojat jauno atslēgu savos ražošanas vides mainīgajos).
• OpenAI/Anthropic: atveriet API atslēgu informācijas paneli un nekavējoties noklikšķiniet uz Atsaukt/Dzēst, lai automātiskie starpniekservera skrāpji nevarētu dažu minūšu laikā iztērēt tūkstošiem dolāru LLM marķiera kredītu.
• GitHub personiskās piekļuves marķieri (PAT), smalki izstrādāti marķieri un izvietošanas atslēgas: dodieties uz GitHub iestatījumi -> Izstrādātāja iestatījumi -> Personiskās piekļuves pilnvaras un noklikšķiniet uz Dzēst/atsaukt uz nopludinātās pilnvaras, pēc tam pārbaudiet savas organizācijas Audita žurnālu (Settings -> Audit log) priekš repo.clone, repo.access, vai nesankcionēta tīmekļa aizķeres izveide ekspozīcijas loga laikā.
• Datu bāzes savienojuma virknes (DATABASE_URL / postgres:// / mongodb+srv://) un Redis URL: mainiet datu bāzes lietotāja paroli datu bāzes dzinējā (ALTER USER app_user WITH PASSWORD 'new_random_secret';), un pēc tam pārtrauciet visus pašlaik atvērtos aktīvos TCP savienojumus, kas pieder vecajiem akreditācijas datiem (SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE usename = 'app_user' AND pid <> pg_backend_pid(); programmā PostgreSQL), jo, mainot datu bāzes paroli programmā PostgreSQL vai MySQL, tiek bloķēti tikai jauni pieteikumi un uzbrucēja jau atvērts savienojums tiek atstāts dzīvs, līdz tas tiek atspēkots.

B fāze: Git vēstures noslēpuma tīrīšana (git filter-repo & GitHub kešatmiņas izlikšana)¶

Kad noplūdes atslēga ir mirusi un pagriezta ražošanā, notīriet slepeno virkni no Git saistību vēstures, lai drošības skeneri pārtrauktu brīdinājumus:

1. Pārrakstiet repozitorija vēsturi, izmantojot git filter-repo (vai BFG Repo-Cleaner):
   • Paņemiet jaunu sava krātuves spoguļa klonu un noņemiet noplūdušo failu (piemēram, .env) no katras vēsturiskās saistības visās nozarēs un tagos:

     # 1. Remove a specific file (.env) from all commits in history:
     git filter-repo --invert-paths --path .env
     
     # OR 2. Replace a specific secret string with ***REMOVED*** everywhere:
     echo "sk_live_YOUR_SECRET_STRING==>***REMOVED***" > replacements.txt
     git filter-repo --replace-text replacements.txt
     

2. Piespiedu nospiediet notīrīto vēsturi un iztīriet kešatmiņā saglabātos GitHub Pull Request/Commit skatus:
   • Pārvietot notīrīto vēsturi atpakaļ uz izcelsmi (git push origin --force --all un git push origin --force --tags).
   • Svarīga GitHub kešatmiņas izpildes darbība: pat pēc tam, kad esat piespiedu kārtā nospiedis notīrītu vēsturi, ikviens, kurš zina veco 40 rakstzīmju apņemšanos, veic SHA URL (github.com/org/repo/commit/abc1234...) joprojām var skatīt veco, neiztīrīto apņemšanos GitHub tīmekļa lietotāja saskarnē, līdz GitHub palaiž servera puses atkritumu savākšanu. Sazinieties ar GitHub atbalsta dienestu (vai izmantojiet repozitorija drošības padomdevēju/atbalsta portālu) ar precīzu veco saistību SHA un palūdziet izlikt no tīmekļa kešatmiņas atsauktās/karājās saistības un palaist. git gc attālajā repozitorijā.

3. daļa: Negadījuma atsaukšana git push --force, git reset --hard, vai dzēsta filiāle¶

Ja nejauši skrējāt git push --force un noslaucīja jūsu komandas biedru saistības main, vai skrēja git reset --hard HEAD-5 un zaudēja pilnu dienu vietējā darba, nekrītiet panikā, jo Git gandrīz nekad neizdzēš apņemtos objektus uzreiz.

Kāpēc jūsu "zaudētās" saistības joprojām ir droši iekšā .git/logs (The Reflog)¶

Ikreiz, kad izveidojat apņemšanos, pārslēdzat zarus, veiciet atkārtotu bāzi vai atiestatiet, Git ieraksta iepriekšējo HEAD un atzara gala norādes SHA-1/SHA-256 vietējā virsgrāmatā, ko sauc par atsauču žurnālu (git reflog) un glabā faktiskos bezsaimnieka saistību objektus diskā vismaz 14 līdz 90 dienas, pirms atkritumu savākšana tos noņem.

Soli pa solim Git ārkārtas atkopšanas receptes¶

1. scenārijs: jūs skrējāt git push --force un pārrakstīja origin/main¶

1. Atrodiet precīzu apņemšanās SHA origin/main norādīja tieši pirms jūsu piespiedu grūdiena:
   • A metode (Pārbaudiet vietējo attālās izsekošanas reflog): Palaidiet šo komandu terminālī, kurā nospiedāt:

     git reflog show origin/main
     

     Jūs redzēsit šādu izvadi:

     a1b2c3d (HEAD -> main, origin/main) refs/remotes/origin/main@{0}: update by push
     9f8e7d6 refs/remotes/origin/main@{1}: fetch: fast-forward
     

     Lūk,9f8e7d6 (origin/main@{1}) ir precīza apņemšanās origin/main bija ieslēgts tieši pirms jūsu piespiedu nospiešanas to pārrakstīja.
   • B metode (Pajautājiet jebkuram komandas biedram, kurš nav skrējis git pull vēl): Jebkurš kolēģis, kurš atnesa main agrāk šodien joprojām ir neskarta apņemšanās vēsture sēž viņu vietējā origin/main filiāle.
   • C metode (GitHub REST API notikumu žurnāla vaicājums): Ja jūsu lokālajam reflogam nav attālā stāvokļa, vaicājiet GitHub push notikumu API, lai redzētu "before" Piespiedu nospiešanas notikuma SHA jaucējvārds:

     gh api /repos/OWNER/REPO/events --jq '.[] | select(.type=="PushEvent") | {actor: .actor.login, before: .payload.before, head: .payload.head, time: .created_at}'
     

2. ** Atjaunot origin/main droši uz iepriekšējo apņemšanos SHA:**
   • Pārbaudiet, vai apņemšanās izskatās pareizi (git log -n 5 9f8e7d6), pēc tam nospiediet tieši šo SHA atpakaļ uz tālvadības pulti main filiāle, izmantojot --force-with-lease:

     git push --force-with-lease origin 9f8e7d6:refs/heads/main
     

2. scenārijs: jūs skrējāt git reset --hard vai pirms nosūtīšanas izdzēsa vietējo filiāli¶

1. Skrien git reflog jūsu vietējā repozitorijā:

   git reflog --date=iso
   

2. Atrodiet saistību SHA tieši pirms reset: ieraksts (piem., HEAD@{2}: commit: feat: add payment webhook) un izveidojiet jaunu glābšanas atzaru, kas norāda tieši uz šo SHA:

   git switch -c rescue-branch HEAD@{2}
   

3. ** Ko darīt, ja esat pazaudējis nesaistītu failu, kuru jūs git added (iestudēts) un pēc tam noslaucīja ar git reset --hard?**
   • Brīdī, kad tu skrien git add myfile.ts, Git saspiež un ieraksta visu šī faila saturu .git/objects/ kā karājošs lāse, pat ja jūs nekad neesat skrējis git commit. Atgūstiet to, uzskaitot visus nokarenos punktus, kas sakārtoti pēc modifikācijas laika:

     git fsck --lost-found
     # Inspect the recovered blobs written into .git/lost-found/other/
     

4. daļa: Nejauši terraform destroy vai dzēsta mākoņkrātuve (S3, EBS, virtuālās mašīnas)¶

Ja Infrastructure-as-Code (IaC) konveijera vai manuālā CLI komanda sāk nojaukt ražošanas mākoņa resursus:

1. Droši pārtrauciet izpildi:
   • Ja terminālī darbojas lokāli, nospiediet Ctrl + C VIENREIZ tāpēc Terraform pabeidz savu pašreizējo API zvanu un raksta atjaunināto .tfstate failu tīri. Ja darbojas programmā GitHub Actions, GitLab CI vai Terraform Cloud, noklikšķiniet uz Atcelt palaist un nekavējoties atspējojiet CI skrējēja AWS/GCP IAM lomu mākoņa konsolē, lai API dzēšana lidojuma laikā neizdotos. AccessDenied.
2. ** Dublējiet strāvu .tfstate nekavējoties failu:**
   • Lejupielādējiet attālā stāvokļa faila lokālo kopiju (terraform state pull > emergency-backup.tfstate) un pārbaudiet S3 segmenta versiju savā Terraform stāvokļa segmentā, lai iegūtu iepriekšējo stāvokļa versiju, kas bija pieejama pirms 10 minūtēm.
3. Pārbaudiet mākoņpakalpojumu sniedzēja "Soft-Delete" un atkritnes drošības tīklus:
   • Amazon S3 (ar iespējotu segmenta versiju): failu dzēšana S3 versiju segmentā (aws s3 rm --recursive) ne neizdzēš vienu objektu; tā tikai ievieto nulles baitu Dzēst marķieri katra objekta augšpusē. Noņemiet dzēšanas marķierus (izmantojot S3 pakešu operācijas vai 5 rindu Python boto3 skripts), lai nekavējoties atjaunotu 100 procentus failu.
   • AWS EBS sējumi un RDS momentuzņēmumi (atkritne): Pārbaudiet AWS atkritni konsolē, ja tā ir konfigurēta, un atzīmējiet AWS dublēšanas glabātuves.
   • Google Cloud Platform (GCP) un Microsoft Azure: dzēstie GCP projekti un Azure resursu grupas/atslēgas glabātuves/krātuves konti ar iespējotu Soft Delete paliek atkopjami 7 līdz 30 dienas, veicot vienu atjaunošanas klikšķi konsolē.

Kā atgūt salauztu Terraformu .tfstate valsts failu vai atkārtoti importēt bāreņu infrastruktūru¶

Kad a terraform apply vai nejauši terraform destroy tiek pārtraukta lidojuma laikā vai kad kāds nejauši izdzēš attālā stāvokļa failu S3/GCS, jūsu mākoņa infrastruktūra nonāk bīstamā sadalītā smadzeņu stāvoklī, kurā daži resursi joprojām pastāv AWS/GCP, bet citi trūkst .tfstate:

1. Pārrakstītas vai izdzēstas tālvadības pults atkopšana .tfstate fails no S3/GCS versijas:
   • Nekad manuāli nerediģējiet JSON .tfstate failu ar roku teksta redaktorā, ja vien visas pārējās opcijas nav bijušas neizdevušās, jo viena neatbilstība "serial" vai "lineage" UUID virkne neļaus Terraform vairs pieteikties.
   • Atveriet savu S3 kopu (vai Google Cloud Storage kopu/Terraform Cloud Workspace States cilni), kurā atrodas attālā aizmugursistēma, noklikšķiniet uz slēdža Rādīt versijas S3 konsoles augšdaļā un atrodiet terraform.tfstate versijas laikspiedols tieši pirms nepareizas palaišanas, lejupielādējiet to un droši atsūtiet to atpakaļ jaunajā pašreizējā stāvoklī:

     # Push a recovered historical state file back to the remote backend safely
     terraform state push recovered-pre-incident.tfstate
     

2. Iestrēguša stāvokļa bloķēšanas pārtraukšana (Error acquiring the state lock):
   • Kad jūs pārtraucat sliktu terraform destroy ar Ctrl + C vai nogalināt piekārtu CI skrējēju, attālā DynamoDB tabula vai GCS bloķēšanas fails paliek bloķēts ar mirušā procesa ID.
   • Vispirms savā CI informācijas panelī un kopā ar komandas biedriem pārbaudiet, vai šajā darbvietā joprojām nedarbojas neviens cits Terraform process, un pēc tam atlaidiet bezsaimnieka bloķēšanu, izmantojot kļūdas ziņojumā norādīto bloķēšanas ID UUID:

     terraform force-unlock <LOCK_ID_UUID>
     

3. Daļēji iznīcinātas vides atjaunošana, neizveidojot no jauna saglabājušās datu bāzes (terraform import):
   • Ja a terraform destroy noslaucīja jūsu bezvalsts lietojumprogrammu slodzes balansētājus (aws_lb) un ECS/EKS darbinieku mezglus, pirms to pārtraucāt, to ir viegli salabot: vienkārši palaidiet terraform apply un Terraform 5 minūšu laikā no jauna izveidos visus bezvalstnieku tīklus un aprēķinās slāņus, vienlaikus atstājot neskartu jūsu izdzīvojušo RDS datubāzi.
   • Ja jūsu statusa fails pazaudēja izdzīvojušo datubāzi vai S3 segmentu, izmantojiet import {} konfigurācijas bloks (Terraform 1.5+) vai terraform import aws_db_instance.prod_db my-rds-instance-id lai saistītu esošo mākoņa resursu atpakaļ jūsu stāvokļa failā, to neiznīcinot, un palaist terraform plan lai apstiprinātu "0 to destroy" pirms pieteikšanās.

5. daļa. Kā paziņot savam vadītājam par pārtraukumu un vadīt nevainojamu pēcnāves operāciju¶

Ja, strādājot attālināti, izraisāt ražošanas incidentu, jūsu profesionālo reputāciju nosaka nevis pati kļūda, bet gan jūsu caurskatāmības ātrums, mierīga komunikācija un sistemātiska atlīdzināšana.

3 incidentu komunikācijas zelta likumi¶

1. Norādiet faktus, ietekmi un ETA, neslēpjot, nekavējot un nevainojot: ziņojiet par kļūdu 2 minūšu laikā pēc atklāšanas.
2. Atdaliet "Mitigation" (asiņošanas apturēšana) no "Sākotnējā cēloņa novēršana": Ārkārtas gadījumā jūsu vienīgais mērķis ir pakalpojuma atjaunošana (sliktās izvietošanas atcelšana, pāreja uz PITR datu bāzes klonu vai līdzekļa karoga noņemšana). Saglabājiet dziļo koda pārstrukturēšanu rītdienai.
3. Ievietojiet regulārus 15 minūšu sirdsdarbības atjauninājumus incidentu kanālā, lai vadītāji un klientu atbalsts zinātu, ka kāds to kontrolē.

Kopējiet un ielīmējiet Slack / Teams Incident Declaration Script¶

[SEV-1 INCIDENTS] Ražošana [Pakalpojums/Datu bāzes nosaukums] Ietekme - Kas notika: Plkst [HH:MM UTC], izpildes laikā [brief technical action, e.g., a data migration script], neparedzēts [DELETE / config change / force-push] tika izmantots ražošanā [database / service]. - Pašreizējā ietekme uz klientu: [e.g., Checkout API is returning 500 errors / User profile updates are paused]. - Notiek tūlītēja ietekmes mazināšana: 1. Ierakstiet trafiku uz [table/service] ir apturēta, lai saglabātu datu integritāti. 2. Point-In-Time Recovery (PITR) klons uz [HH:MM:SS UTC] (10 sekundes pirms notikuma) pašlaik griežas [AWS RDS / GCP]. - Incidentu komandieris: @[Your Name] (palīdzēja @[DBA/On-Call SRE]). - Nākamais atjauninājums: Pēc 15 minūtēm ([HH:MM UTC]) vai tiklīdz atkopšanas klons nonāk tiešsaistē.

Pēcincidenta inženiertehnisko drošības pasākumu kontrolsaraksts (jūsu bezvainīgajai pēcnāves gadījumiem)¶

Katra cilvēka kļūda ražošanā faktiski ir sistēmu projektēšanas nepilnība (ja viena kopēt ielīmēta termināļa komanda var pārtraukt ražošanu bez aizsargmargas, sistēma gaidīja, kad neizdosies). Nākamajā dienā savā pēcnāves dokumentā piedāvājiet un ieviesiet šīs konkrētās tehniskās margas:

• ** Krāsu koda un prefiksu izgatavošanas uzvednes (kube-ps1, psql .psqlrc):** Konfigurējiet čaulu un SQL klientu tā, lai izveidotu savienojumu ar PRODUCTION parāda spilgti sarkanu krāsu [PROD-DB] uzvedni un sāk katru interaktīvo PostgreSQL sesiju iekšā a BEGIN; transakciju bloks pēc noklusējuma (vai komplekti SET default_transaction_read_only = on;).
• Iespējot safe-updates (--i-am-a-dummy) MySQL/MariaDB klientiem: Pievienot safe-updates uz [mysql] iekšā -/.my.cnf tāpēc MySQL tieši atsakās izpildīt jebkuru UPDATE vai DELETE paziņojums, kurā trūkst a WHERE atslēgas klauzula vai a LIMIT.
• Ieslēdziet DeletionProtection = true visās ražošanas RDS datu bāzēs, S3 segmentos un Terraform statusa resursos (lifecycle { prevent_destroy = true }).
• ** Ieviest Git filiāles aizsardzības noteikumus main / production:** Atspējot Allow force pushes un Allow deletions aizsargātās filiālēs GitHub/GitLab, tāpēc pat repozitoriju administratori nevar git push --force uz main.
• Instalējiet pirmsapstiprināšanas slepenās skenēšanas āķus (gitleaks vai trufflehog) un GitHub Push Protection: Bloķējiet saistības, kas satur AKIA, sk_live_, vai .env modeļi lokāli iepriekš git commit pat izdodas.

Bieži uzdotie jautājumi¶

Vai mani atlaidīs par nejaušu ražošanas datu bāzes tabulas nomešanu vai vietnes darbības pārtraukumu?¶

Veselīgās inženiertehniskajās organizācijās, kas praktizē nevainojamu drošības kultūru (standarts mūsdienu tehnoloģiju, DevOps un SRE komandās), inženieri netiek atlaisti par godīgām cilvēciskām kļūdām ražošanā, ja vien viņi nekavējoties ziņo par incidentu un palīdz atjaunot pakalpojumu. Inženierzinātņu vadītāji atzīst, ka, ja jaunākajam vai vecākajam izstrādātājam bija neapstrādātas atļaujas un aizsargmargu trūkums, lai nomestu ražošanas tabulu ar vienu nepārskatītu komandu, galvenais iemesls ir piekļuves kontroles un izvietošanas rīku nepilnība, nevis ļaunprātība. Praksē inženieris, kurš tikko piedzīvoja šo pārtraukumu, tagad ir vienīgā drošākā persona komandā attiecībā uz šo sistēmu. Vienīgā rīcība, kas konsekventi noved pie izbeigšanas, ir mēģinājums slēpt datu zuduma notikumu, dzēst audita žurnālus vai melot incidenta izmeklēšanas laikā.

Kāpēc man nevajadzētu nekavējoties pārslēgt savu reāllaika produkcijas trafiku uz nesen atjaunoto Point-In-Time Recovery (PITR) datu bāzes gadījumu?¶

Ja nejauši izdzēsāt rindas no vienas tabulas (piemēram, `user_preferences` tabula) plkst. 14:00 UTC, un ir nepieciešamas 20 minūtes, lai izveidotu PITR klonu, kas atjaunots uz 13:59:50 UTC, iespējams, jūsu reāllaika datu bāze ir turpinājusi apstrādāt tūkstošiem likumīgu jaunu klientu pasūtījumu un maksājumu. `orders` galds laikā no 14:00 līdz 14:20 UTC. Ja visu savu ražošanas DNS galapunktu akli novirzīsit uz 13:59:50 PITR klonu, jūs iznīcināsit šīs 20 minūtes pilnīgi jaunu klientu pasūtījumu. Tā vietā saglabājiet galveno datu bāzi tiešsaistē (ar pauzētu rakstīšanu tikai bojātajā funkcijā) un eksportējiet tikai trūkstošās rindas no 13:59:50 PITR klona atpakaļ tiešā ražošanas tabulā.

Ja es padarīšu publisku GitHub repozitoriju privātu divas minūtes pēc nejaušas nospiešanas .env failu, vai man joprojām ir jāpagriež visas API atslēgas?¶

Jā, 100 procenti no šīm atslēgām joprojām ir nekavējoties jāatsauc un jāpagriež. Katra publiskajā GitHub repozitorijā nosūtītā apņemšanās tiek pārraidīta reāllaikā, izmantojot publisko GitHub Events API (“Firehose”), un dažu sekunžu laikā to indeksē gan likumīgi drošības arhīva pakalpojumi (piemēram, GHArchive), gan ļaunprātīgi automatizēti akreditācijas datu savākšanas roboti, kas darbojas 24/7 mākoņtīklos. Pārvēršot repozitorija redzamību no Publisks uz Privāts divas minūtes vēlāk, netiek dzēsta kopija, kuru jau ir lejupielādējuši automatizētie skrāpji.

Kā dara git push --force-with-lease novērstu pārtraukumus salīdzinājumā ar git push --force?¶

Kad jūs palaist standarta `git push --force`, Git bez nosacījumiem pārraksta attālo filiāli ar jūsu vietējo filiāli, klusībā iznīcinot visas saistības, ko komandas biedrs tikmēr ir novirzījis uz šo filiāli. Kad lietojat `git push --force-with-lease` (un vēl labāk, `--force-if-includes`), Git vispirms pārbauda attālo serveri, lai pārbaudītu, vai attālās filiāles gals joprojām atbilst precīzai commit SHA, ko jūsu vietējā mašīna pēdējo reizi ienesa. Ja kolēģis vai CI konveijers ir nosūtījis jaunu saistību attālajai filiālei kopš pēdējās ieneses, `--force-with-lease` droši pārtrauc ar "novecojušas informācijas" brīdinājumu, nevis noslauka savu darbu.

Pārbaudīti avoti¶

• Nacionālais standartu un tehnoloģiju institūts (NIST, Amerikas Savienotās Valstis): NIST SP 800-61 Rev. 2 / Rev. 3 Datoru drošības incidentu apstrādes rokasgrāmata un akreditācijas datu kompromisa ierobežojums.
• Amazon Web Services (AWS), Google Cloud Platform (GCP) un Microsoft Azure dokumentācija (Amerikas Savienotās Valstis): RDS automatizētā punkta atkopšanas (PITR) arhitektūra, AWS IAM apdraudētas galvenās karantīnas politikas (AWSCompromisedKeyQuarantineV2) un S3 versijas dzēšanas marķiera atkopšana.
• PostgreSQL globālās izstrādes grupa un MySQL/Oracle dokumentācija (starptautiskā): PostgreSQL rakstīšana uz priekšu (WAL), MVCC kopu redzamība un MySQL rindu bāzes binārā žurnāla zibatmiņas atkopšana.
• Git SCM oficiālā dokumentācija un GitHub drošības laboratorija (starptautiska): Git Reflog (git-reflog), Karājošo objektu atkopšana (git-fsck), Vēstures pārrakstīšana (git-filter-repo) un Slepenās skenēšanas Push Protection.
• USENIX asociācija / SREcon un Google vietņu uzticamības inženierijas (SRE) grāmatas (starptautiskas): Incidentu pārvaldība, ārkārtas atcelšanas šķirošana un nevainojama pēcnāves kultūra.

Saistītie ceļveži¶

• Ārkārtas attālinātā darba drošība un datu privātums
• Datoru dublējumkopijas 3-2-1 stratēģija un atkopšana pēc avārijas
• Nejauša failu dzēšana un formatēta diska atkopšana
• Tīmekļa mitināšanas krīzes migrācija un dublējuma atjaunošana
• Pikšķerēšana un uzlauzti konti
• Neatliekamās palīdzības numuri