İstehsalın təsadüfən kəsilməsi, sızan API açarları və ya silinmiş bulud infrastrukturu¶

Hər bir proqram mühəndisi, sistem administratoru və texniki uzaqdan işləyən işçi, nəticədə, əmr üçün nəzərdə tutulan mədə-dövlət anı ilə qarşılaşır. localhost və ya staging əleyhinə icra edir production: indekssiz DELETE olmadan WHERE bənd, a DROP TABLE və ya terraform destroy, a git push --force əsas filialın və ya canlı AWS və ya Stripe məxfi açarlarını ehtiva edən ictimai öhdəliyin üzərinə yazır. 15 dəqiqəlik kiçik hıçqırıqları karyerasını bitirən məlumat fəlakətindən ayıran şey əllərinizi dərhal dayandırmaq, yaddaş bloklarının üzərinə yazılmamışdan əvvəl yazma trafikini dondurmaq və düzgün bərpa protokolunu yerinə yetirməkdir.

Bunu indi edin¶

1. Əllərinizi dondurun və tələsik "düz" əmrlərini yerinə yetirməyin, verilənlər bazası serverini yenidən başladın və ya terminal pəncərənizi bağlamayın. Cari terminal geriyə sürüşmə buferi, qabıq tarixçəsi və yerli .git/logs reflog dəqiq əməliyyat vaxt möhürlərini, SHA hashlarını və zərəri aradan qaldırmaq üçün lazım olan resurs identifikatorlarını ehtiva edir. Əvvəlcə bütün terminal sürüşdürməsini təhlükəsiz mətn faylına köçürün.
2. Komandanızın insident Slack/Teams kanalında 2 dəqiqə ərzində Ağırlıq-1 (SEV-1) insidentini elan edin. Müştərilər 500 xəta ilə üzləşərkən və avtomatlaşdırılmış fon işləri qalan cədvəlləri korlayarkən, heç vaxt 45 dəqiqənizi yalnız pozulmuş istehsal verilənlər bazasını gizli şəkildə düzəltməyə sərf etməyin. Zəng üzrə Verilənlər Bazasının Administratorunu (DBA) və ya Saytın Etibarlılığı Mühəndisinə (SRE) dərhal müraciət edin.
3. Bir API açarını sızdırmısınızsa, .env faylı və ya ictimai GitHub repo üçün bulud sirrini İLK olaraq provayderin idarə panelindəki açarı LƏĞV EDİN (Git tarixçəsini yenidən yazmağa çalışmazdan əvvəl). Avtomatlaşdırılmış botnetlər ictimai GitHub Firehose API-ni qırır və oğurlanmış AWS, OpenAI, Stripe və GCP açarlarını 3-dən5 saniyəyə qədər icra edir. git push. Faylın ikinci əməliyyatda silinməsi və ya zorla basdırılması açarı artıq klonlamış təcavüzkarı * dayandırmır*.
4. ** Əgər təsadüfən qaçmısınızsa DELETE, UPDATE, və ya DROP istehsal verilənlər bazasında tətbiqin YAZI trafikini dərhal kəsin.** Veb tətbiqini Baxım Rejiminə qoyun və ya proqram istifadəçisinin yazma icazələrini ləğv edin ki, yeni daxil olan əməliyyatlar vakuumdan təmizlənməmiş ölü çubuqların üzərinə yazmasın və ya Vaxtında Bərpa (PITR) prosesini çətinləşdirməsin.
5. Heç vaxt qaçmayın VACUUM, OPTIMIZE TABLE, və ya git gc --prune=now təsadüfən silindikdən sonra. Həm relyasiya verilənlər bazası (PostgreSQL MVCC, MySQL InnoDB) həm də Git, zibil yığımı/vakuum keçidi səhifələri fiziki olaraq geri alana qədər silinmiş sətirləri və yetim tapşırıqları diskdə toxunulmaz saxlayır.
6. Əgər a terraform destroy və ya bulud silmə skripti hələ də terminalınızda işləyir, basın Ctrl + C BİR DƏFƏ (iki dəfə deyil) və ya IAM sessiya nişanını öldürün. Basılır Ctrl + C bir dəfə zərif bir vəziyyətə səbəb olur, beləliklə Terraform qismən saxlayır .tfstate hələ də mövcud olanlar; basaraq Ctrl + C iki dəfə yerli dövlət faylınızı poza və ya itirə biləcək nalayiq aborta məcbur edir.

Fövqəladə triage iş axını: verilənlər bazası düşməsi, git force-push və ya gizli sızma¶

Texniki qorunmanın ilk 5 dəqiqəsini təyin etmək üçün bu qərar ağacına əməl edin.

flowchart TD
    A["İstehsalat Mühəndisliyi Təcili"] --> B{"Hansı uğursuzluq indi baş verdi?"}
    B -->|"Prod-da təsadüfən SQL DROP / DELETE / YENİLƏMƏ"| C["Proqramın Yazılmasını / Baxım Rejimini dayandırın; VAKUUM İŞLƏMƏYİN"]
    B -->|"Git-də sızan API Açarı / .env / Şəxsi Açar"| D["60 saniyə ərzində bulud tablosunda sirri ləğv edin və fırladın"]
    B -->|"Təsadüfi git push --force / Silinmiş filial"| E["git reflogu Yerli olaraq işə salın; Son Yaxşı İşləmə SHA-nı kopyalayın"]
    B -->|"Təsadüfi terraform məhv / Silinmiş S3 və ya VM"| F["IAM Sessiyasını öldürün və ya Ctrl+C düyməsini bir dəfə basın; .tfstate-i qoruyun"]
    C --> G["Dəqiq UTC Vaxtını qeyd edin; Cloud PITR Clone və ya Binlog Flashback-i işə salın"]
    D --> H["CloudTrail / İcazəsiz Spin-Uplar üçün Giriş Qeydlərini yoxlayın; Repo-nu git-filter-repo ilə ovuşdurun"]
    E --> I["git push --force-with-lease ilə GitHub Hadisələrini / Reflog və Bərpa Filialını sorğulayın"]
    F --> J["S3 Versiyasının Silinmə Markerlərini, EBS Snapshots və ya Bulud Zibil qutusunu yoxlayın"]

1-ci hissə: Təsadüfi istehsalat bazası DROP, TRUNCATE, və ya DELETE olmadan WHERE¶

Dağıdıcı SQL sorğusu canlı istehsal verilənlər bazasına toxunduqda, dəqiq bərpa mexanizmi verilənlər bazanız mühərrikindən (PostgreSQL, MySQL/MariaDB, SQL Server, MongoDB və ya DynamoDB) və ifadənin DML () olub-olmamasından asılıdır.DELETE / UPDATE) və ya DDL (DROP TABLE / TRUNCATE) əməliyyat.

Addım 1: Dəqiq UTC vaxt damgasını ikinciyə qədər qeyd edin¶

Hər hansı ehtiyat konsoluna toxunmazdan əvvəl dəqiq cari UTC vaxtını yazın (date -u Linux/macOS terminalında və ya SELECT NOW(); SQL sorğusunda) və dağıdıcı sorğunuz icra olunmağa başlamazdan əvvəl * tam saniyəni təxmin edin. Point-In-Time Recovery (PITR) verilənlər bazasının “İrəlidə yaz” jurnalını təkrar oxumaqla işləyir.WAL PostgreSQL-də) və ya Binary Log (binlog MySQL-də) qədər T_minus_1_second pis sorğunuz gəlməzdən əvvəl.

Addım 2: Fon işlərini və proqram yazmasını dayandırın (MVCC dəstlərini qoruyun)¶

PostgreSQL-də icra olunur DELETE FROM users; və ya UPDATE orders SET status = 'cancelled'; ** faktiki olaraq diskdəki cədvəl faylından bir bayt məlumatı dərhal silmir. PostgreSQL Multi-Version Concurrency Control (MVCC) istifadə etdiyi üçün, DELETE sadəcə olaraq təyin edir xmax Gələcək sorğular üçün görünməz kimi qeyd etmək üçün hər bir cərgədə tranzaksiya identifikatoru başlığı yerləşdirin və bütün sətir məlumatlarını bütöv vəziyyətdə saxlayaraq base/ autovacuum təkrar istifadə edilə bilən məkanı qeyd etmək üçün gələnə qədər yığın faylı.

• Əgər siz özünüzdə və ya VM PostgreSQL-dəsinizsə və son ehtiyat nüsxəniz yoxdursa: Dərhal qoşulun superuser və həmin masada avtovakuumu söndürün (ALTER TABLE table_name SET (autovacuum_enabled = false);) və ya PostgreSQL xidmətini dayandırın və xam blok səviyyəli fayl sistemi şəklini çəkin (LVM / EBS snapshot) nin /var/lib/postgresql/data kataloq. Xüsusi PostgreSQL məhkəmə genişləndirmələri (pg_dirtyread) silinmiş və ya əvvəlcədən yenilənmiş sətirlərin 100 faizini bir neçə dəqiqə ərzində birbaşa vakuum edilməmiş yığın cədvəlindən oxuya və bərpa edə bilər.

Mühərrik və bulud platforması ilə verilənlər bazasının bərpa matrisi¶

Hissə 2: Sızdırılmış API açarları, .env sirlər və ya Git-ə sadiq qalan şəxsi açarlar¶

Əgər təsadüfən bir .env fayl, an id_rsa SSH açarı, Firebase/GCP xidmət hesabı JSON faylı, Stripe məxfi açarı (sk_live_...) və ya AWS AKIA... Git-ə giriş açarı ilə bu dəqiq iki fazalı ardıcıllığa əməl edin: Mərhələ A (Buludda açarı öldürün) birinci və Mərhələ B (Git deposunu ovuşdurun) ikinci.

Faza A: Dərhal 60 saniyəlik bulud etimadnaməsinin saxlanması (İLK bunu edin)¶

1. AWS (AKIA... Giriş Açarı ID + Gizli Giriş Açarı)¶

Botlar GitHub-dan AWS açarını oğurladıqda, onların avtomatlaşdırılmış skripti maksimum ölçülü GPU EC2 instansiyalarını fırlatmaq üçün 10 saniyə ərzində hesabınıza daxil olur (p4d.24xlarge / g5.48xlarge) bütün 30-dan çox qlobal AWS regionunda (o cümlədən Cakarta, Osaka və Yaxın Şərq kimi qoşulma regionları) kriptovalyuta əldə etmək və ya arxa qapı IAM istifadəçisi yaradır. AdministratorAccess orijinal açarı silməzdən əvvəl.

1. Sızan Giriş Açarını dərhal deaktiv edin və silin:
   • AWS Konsolu -> IAM -> İstifadəçilər -> [Güzəştli İstifadəçi] -> Təhlükəsizlik etimadnamələri -> Giriş düymələri -> Deaktiv et, sonra Sil üzərinə klikləyin (və ya CLI vasitəsilə: aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name MyUser).
2. Açıq ifadə əlavə edin DenyAll müvəqqəti neytrallaşdırmaq siyasəti aws sts sessiya nişanları:
   • Kritik tələ: Siz sildikdən sonra belə AKIA... Təcavüzkar artıq zəng edibsə, IAM giriş açarı sts:GetSessionToken və ya sts:AssumeRole ilk 30 saniyə ərzində onların müvəqqəti ASIA... Siz açıq-aşkar daxili Rəd etmək siyasəti (məsələn, kimi) əlavə etməyincə, sessiya nişanı 1-12 saat ərzində etibarlı qalır. AWSCompromisedKeyQuarantineV2 və ya istifadəçi və ya rola cari vaxt damğasından əvvəl verilmiş tokenlər üçün Hamısını rədd etmə siyasəti).
3. Arxa qapının davamlılığı üçün AWS CloudTrail-i yoxlayın:
   • AWS CloudTrail -> Hadisə tarixçəsini açın və son 2 saat ərzində pozulmuş Giriş Açarının ID-si və ya İstifadəçi adı ilə filtrləyin.
   • Xüsusilə bu 5 davamlı çağırış üçün yoxlayın: CreateUser, CreateAccessKey, AttachUserPolicy, AssumeRole, və RunInstances. Hər hansı saxtakarlıq nümunələrinə son qoymaq üçün bütün regionlarda AWS Cost Explorer və EC2 Global View-u yoxlayın və dərhal AWS Dəstək İşini (Hesab və Faktura -> Təhlükəli Hesab) açın. Əsas sızma barədə məlumat verdikdə və nümunələri dərhal dayandırdığınız zaman AWS müntəzəm olaraq saxta hesablama hesablarından imtina edir.

2. Zolaq (sk_live_...), OpenAI (sk-...), SendGrid, Twilio və Slack Tokens¶

• Stripe: gedin Tərtibatçılar -> API açarları -> Standart düymələr / Məhdud düymələr -> Üç nöqtəyə klikləyin (...) -> Roll düyməsini. "İndi başa çatır" seçin (və ya yeni açarı hazırda istehsal mühiti dəyişənlərinizə aktiv şəkildə yerləşdirirsinizsə, 1 saatlıq güzəşt pəncərəsi təyin edin).
• OpenAI / Anthropic: API Açarlarının idarə panelinə gedin və dərhal Ləğv et / Sil düyməsini klikləyin ki, avtomatlaşdırılmış proksi kazıyıcılar minlərlə dollar LLM token kreditini bir neçə dəqiqə ərzində boşalda bilməsin.
• GitHub Fərdi Giriş Tokenləri (PAT), İncə Tokenlər və Yerləşdirmə Açarları: GitHub Parametrləri -> Tərtibatçı parametrləri -> Şəxsi giriş nişanları bölməsinə keçin və sızmış nişanda Sil / Ləğv et üzərinə klikləyin, sonra təşkilatınızın Audit Qeydiyyatını yoxlayın (Settings -> Audit log) üçün repo.clone, repo.access, və ya ifşa pəncərəsi zamanı icazəsiz webhook yaradılması.
• Verilənlər bazası əlaqə sətirləri (DATABASE_URL / postgres:// / mongodb+srv://) və Redis URL-ləri: Verilənlər bazası mühərrikində verilənlər bazası istifadəçisinin parolunu dəyişdirin (ALTER USER app_user WITH PASSWORD 'new_random_secret';) və sonra **köhnə etimadnamələrə (SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE usename = 'app_user' AND pid <> pg_backend_pid(); PostgreSQL-də).

Faza B: Git tarixindən sirri təmizləmək (git filter-repo & GitHub keşinin çıxarılması)¶

Sızdırılmış açar öləndən və istehsalda fırlanandan sonra, təhlükəsizlik skanerlərinin xəbərdarlığını dayandırması üçün Git əməliyyat tarixçənizdən gizli sətri təmizləyin:

1. İstifadə edərək depo tarixçəsini yenidən yazın git filter-repo (və ya BFG Repo-Təmizləyici):
   • Depozitinizin təzə çılpaq güzgü klonunu götürün və sızan faylı silin (məsələn, .env) bütün filiallar və teqlər üzrə hər tarixi öhdəlikdən:

     # 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. Təmizlənmiş tarixçəni zorla itələyin və keşlənmiş GitHub Pull Request / Qəbul baxışlarını təmizləyin:
   • Təmizlənmiş tarixçəni mənşəyə geri itələyin (git push origin --force --all və git push origin --force --tags).
   • ** Vacib GitHub keşləmə addımı:** Təmizlənmiş tarixçəni zorla itələdikdən sonra belə, köhnə 40 simvoldan ibarət hər kəs SHA URL-ni (github.com/org/repo/commit/abc1234...) GitHub server tərəfi zibil kolleksiyasını işə salana qədər GitHub-un veb UI-də köhnə təmizlənməmiş öhdəliyi hələ də görə bilər. Dəqiq köhnə SHA öhdəliyi ilə GitHub Dəstəyi ilə əlaqə saxlayın (və ya repozitoriyanın Təhlükəsizlik Məsləhət / Dəstək portalından istifadə edin) və onlardan verilməmiş/saxlanılan öhdəliyi veb keşindən çıxarmağı və işə salmağı xahiş edin. git gc uzaq depoda.

3-cü hissə: Təsadüfün ləğvi git push --force, git reset --hard, və ya silinmiş filial¶

Əgər təsadüfən qaçmısınızsa git push --force və komanda yoldaşlarınızın öhdəliklərini sildiniz main, ya da qaçdı git reset --hard HEAD-5 və yerli işin tam gününü itirdim, panik etməyin, çünki Git demək olar ki, heç vaxt törədilmiş obyektləri dərhal silmir.

Niyə "itirilmiş" öhdəlikləriniz hələ də içəridə təhlükəsiz şəkildə oturur .git/logs (The Reflog)¶

Hər hansı bir öhdəlik yaratdığınız zaman, filialları dəyişdirin, yenidən qurun və ya sıfırlayın, Git əvvəlkini qeyd edir HEAD və filial ucu SHA-1/SHA-256 göstəriciləri İstinad jurnalı (git reflog) və zibilin yığılması onları silməzdən əvvəl faktiki yetim edilmiş icra obyektlərini ən azı 14-90 gün müddətində diskdə saxlayır.

Addım-addım Git təcili bərpa reseptləri¶

Ssenari 1: Siz qaçdınız git push --force və üzərinə yazdı origin/main¶

1. Dəqiq SHA-nı tapın origin/main zorla basmağınızdan əvvəl sağa işarə etdi:
   • Metod A (yerli uzaqdan izləmə reflogunu yoxlayın): Bu əmri itələdiyiniz terminalda işlədin:

     git reflog show origin/main
     

     Siz aşağıdakı kimi çıxışı görəcəksiniz:

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

     Budur, 9f8e7d6 (origin/main@{1}) dəqiq öhdəlikdir origin/main Sizin güc itələməniz onun üzərinə yazmazdan əvvəl aktiv idi.
   • Metodu B (Qaçmamış komanda yoldaşından soruşun git pull hələ): Gələn hər hansı iş yoldaşı main əvvəllər bu gün hələ də yerli oturan bütöv törətmə tarixi var origin/main filialı.
   • Metodu C (GitHub REST API Hadisələr jurnalını sorğulayın): Əgər yerli refloqunuzda uzaq vəziyyət yoxdursa, GitHub-un təkan hadisələri API-sini sorğulayın. "before" Force-push hadisəsinin SHA hashı:

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

2. ** Bərpa edin origin/main əvvəlki SHA-nı təhlükəsiz şəkildə yerinə yetirin:**
   • Öhdətin düzgün göründüyünü yoxlayın (git log -n 5 9f8e7d6), sonra həmin dəqiq SHA-nı pultdan geri itələyin main filialından istifadə edir --force-with-lease:

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

Ssenari 2: Siz qaçdınız git reset --hard və ya itələmədən əvvəl yerli filialı silin¶

1. Qaç git reflog yerli deponuzda:

   git reflog --date=iso
   

2. ** SHA-nın yerinə yetirilməsindən dərhal əvvəl tapın reset: giriş** (məsələn, HEAD@{2}: commit: feat: add payment webhook) və birbaşa həmin SHA-ya işarə edən yeni xilasetmə filialı yaradın:

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

3. Təhsil edilməmiş faylı itirsəniz nə olacaq? git added (səhnələşdirildi) və sonra silindi git reset --hard?*
   • Qaçdığın an git add myfile.ts, Git həmin faylın tam məzmununu sıxır və yazır .git/objects/ heç qaçmasanız belə, sallanan ləpə kimi git commit. Dəyişiklik müddətinə görə sıralanmış bütün sallanan ləkələri sadalamaqla onu bərpa edin:

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

4-cü hissə: Təsadüfi terraform destroy və ya silinmiş bulud yaddaşı (S3, EBS, VM-lər)¶

İnfrastruktur-as-Code (IaC) boru kəməri və ya manual CLI əmri istehsal bulud resurslarını sökməyə başlayırsa:

1. İcranı təhlükəsiz şəkildə dayandırın:
   • Terminalınızda yerli olaraq işləyirsə, ** düyməsini basın.Ctrl + C BİR DƏFƏ** beləliklə, Terraform cari API çağırışını bitirir və yenilənmişini yazır .tfstate təmiz fayl. Əgər GitHub Actions, GitLab CI və ya Terraform Cloud daxilində işləyirsinizsə, İşləməni Ləğv et üzərinə klikləyin və CI runnerinin bulud konsolunda AWS/GCP IAM rolunu dərhal deaktiv edin ki, uçuş zamanı API silmələri uğursuz olsun. AccessDenied.
2. Cərəyanı yedəkləyin .tfstate dərhal fayl:
   • Uzaq dövlət faylınızın yerli surətini endirin (terraform state pull > emergency-backup.tfstate) və 10 dəqiqə əvvəlki əvvəlki vəziyyət versiyasını əldə etmək üçün Terraform dövlət qutunuzda S3 bucket versiyasını yoxlayın.
3. Bulud provayderi "Soft-Delete" və Zibil qutusunun təhlükəsizlik şəbəkələrini yoxlayın:
   • Amazon S3 (Bucket Versioning aktivləşdirildikdə): Versiyalaşdırılmış S3 qutusunda faylların silinməsi (aws s3 rm --recursive) bir obyekti silmir; o, sadəcə olaraq hər obyektin üstünə sıfır baytlıq Markeri Sil əlavə edir. Silinmə işarələrini silin (S3 Batch Əməliyyatları və ya 5 sətirli Python vasitəsilə boto3 script) fayllarınızın 100 faizini dərhal bərpa etmək üçün.
   • AWS EBS Volumes & RDS Snapshots (Recycle Bin): Konfiqurasiya olunubsa, konsolda AWS Zibil qutusunu yoxlayın və AWS Backup kassalarını yoxlayın.
   • Google Bulud Platforması (GCP) və Microsoft Azure: Silinmiş GCP Layihələri və Azure Resurs Qrupları / Açar Vaultlar / Yumşaq Silinmə aktivləşdirilən Yaddaş Hesabları konsolda bir dəfə bərpa klikləməklə 7-30 gün müddətində bərpa oluna bilər.

Qırılan Terraformu necə bərpa etmək olar .tfstate dövlət faylı və ya yenidən idxal yetim infrastruktur¶

Nə vaxt a terraform apply ya da təsadüfi terraform destroy uçuşun ortasında kəsildikdə və ya kimsə təsadüfən S3/GCS-də uzaq dövlət faylını sildikdə, bulud infrastrukturunuz təhlükəli split-beyin vəziyyətinə daxil olur, burada bəzi resurslar hələ də AWS/GCP-də mövcuddur, digərləri isə yoxdur .tfstate:

1. Üzerinə yazılmış və ya silinmiş pultun bərpası .tfstate S3 / GCS Versiyasından fayl:
   • Heç vaxt JSON-u əl ilə redaktə etməyin .tfstate mətn redaktorunda əl ilə faylı hər bir digər seçim uğursuz olmadığı halda, çünki tək bir uyğunsuzluq var "serial" və ya "lineage" UUID sətri Terraformun bir daha müraciət etməsinə mane olacaq.
   • Uzaqdan idarəetmənin yaşadığı S3 qutusunu (və ya Google Bulud Saxlama qabı / Terraform Bulud İş Sahəsi Statuslar nişanını) açın, S3 konsolunun yuxarısındakı Versiyaları göstər keçidinə klikləyin, terraform.tfstate versiya pis işləmədən dərhal əvvəl vaxt möhürü vuruldu, onu endirin və yeni cari vəziyyət kimi təhlükəsiz şəkildə geri itələyin:

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

2. İlmiş vəziyyət kilidinin qırılması (Error acquiring the state lock):
   • Bir pis abort etdiyiniz zaman terraform destroy ilə Ctrl + C və ya asılmış CI qaçışçısını öldürsəniz, uzaq DynamoDB cədvəli və ya GCS kilid faylı ölü proses identifikatoru ilə kilidli olaraq qalır.
   • Əvvəlcə CI tablosunda və komanda yoldaşlarınızla sıfır digər Terraform prosesinin hələ də həmin iş sahəsinə qarşı işlədiyini yoxlayın, sonra xəta mesajında çap edilmiş Kilid İD UUID-dən istifadə edərək yetim kilidi buraxın:

     terraform force-unlock <LOCK_ID_UUID>
     

3. Sağ qalan verilənlər bazalarını yaratmadan qismən dağılmış mühitin yenidən qurulması (terraform import):
   • Əgər a terraform destroy vətəndaşlığı olmayan Tətbiq Yük balanslaşdırıcılarınızı sildi (aws_lb) və ECS/EKS işçi qovşaqlarını dayandırmadan əvvəl, bunu düzəltmək asandır: sadəcə işə salın terraform apply və Terraform 5 dəqiqə ərzində bütün vətəndaşlığı olmayan şəbəkələri yenidən yaradacaq və layları sıfırdan hesablayacaq, eyni zamanda sağ qalan RDS verilənlər bazanıza toxunulmaz.
   • Əgər dövlət faylınız sağ qalan dövlət məlumat bazası və ya S3 kovasının izini itiribsə, ** istifadə edin.import {} konfiqurasiya bloku** (Terraform 1.5+) və ya terraform import aws_db_instance.prod_db my-rds-instance-id mövcud bulud resursunu məhv etmədən yenidən dövlət faylınıza bağlamaq və işə salın terraform plan təsdiq etmək "0 to destroy" müraciət etməzdən əvvəl.

5-ci hissə: Müdirinizə nasazlıq barədə məlumat vermək və günahsız ölümdən sonra necə rəhbərlik etmək olar¶

Uzaqdan işləyərkən istehsalat insidentinə səbəb olduqda, peşəkar nüfuzunuz ** səhvin özü ilə deyil, şəffaflıq sürətiniz, sakit ünsiyyət və sistematik düzəlişinizlə müəyyən edilir.

Hadisə ilə bağlı ünsiyyətin 3 qızıl qaydası¶

1. Gizlətmədən, gecikdirmədən və ya günahlandırmadan faktları, təsir və ETA-nı göstərin: Xəta aşkar edildikdən sonra 2 dəqiqə ərzində bildirin.
2. "Kök Səbəb Düzəlişindən" ayrı "Yüzaltma" (Qanaxmanın dayandırılması): Fövqəladə vəziyyətdə yeganə məqsədiniz xidməti bərpa etməkdir (pis yerləşdirməni geri qaytarmaq, PITR verilənlər bazası klonuna keçmək və ya xüsusiyyət bayrağını silmək). Sabah üçün dərin kod refaktorinqini saxlayın.
3. Hadisə kanalında müntəzəm olaraq 15 dəqiqəlik ürək döyüntüsü yeniləmələri göndərin ki, rəhbərlər və müştəri dəstəyi kiminsə nəzarətdə olduğunu bilsinlər.

Slack / Komandaların Hadisə Bəyannaməsi Skriptini kopyalayıb yapışdırın¶

[SEV-1 HADİSƏ] İstehsal [Xidmət / Verilənlər Bazasının Adı] Təsir - Nə olub: At [HH:MM UTC], icra edərkən [brief technical action, e.g., a data migration script], nəzərdə tutulmayan [DELETE / config change / force-push] istehsalına tətbiq edilmişdir [database / service]. - Mövcud Müştəri Təsiri: [e.g., Checkout API is returning 500 errors / User profile updates are paused]. - Dərhal azaldılması davam edir: 1. Trafik yazın [table/service] məlumatların bütövlüyünü qorumaq üçün dayandırıldı. 2. Point-In-Time Recovery (PITR) klonlayın [HH:MM:SS UTC] (Tədbirdən 10 saniyə əvvəl) hazırda fırlanır [AWS RDS / GCP]. - Hadisə Komandiri: @[Your Name] (yardım etdi @[DBA/On-Call SRE]). - Növbəti Yeniləmə: 15 dəqiqəyə ([HH:MM UTC]) və ya bərpa klonu onlayn olan kimi.

Hadisədən sonrakı mühəndislik mühafizə vasitələrinə nəzarət siyahısı (Blameless Post-Mortem üçün)¶

İstehsaldakı hər bir insan səhvi əslində sistem dizayn boşluğudur (bir surəti yapışdırılmış terminal əmri qoruyucu barmaqlıq olmadan istehsalı dayandıra bilərsə, sistem uğursuzluğu gözləyirdi). Növbəti gün ölümdən sonrakı sənədinizdə bu konkret texniki qoruyucuları təklif edin və tətbiq edin:

• Rəng kodu və prefiks istehsal tələbləri (kube-ps1, psql .psqlrc): Shell və SQL klientinizi hər hansı bir əlaqə üçün konfiqurasiya edin PRODUCTION parlaq qırmızı göstərir [PROD-DB] xəbərdar edir və a daxilində hər interaktiv PostgreSQL sessiyasına başlayır BEGIN; Defolt olaraq əməliyyat bloku (və ya dəstlər SET default_transaction_read_only = on;).
• ** Aktivləşdirin safe-updates (--i-am-a-dummy) MySQL/MariaDB müştərilərində:** Əlavə edin safe-updates üçün [mysql] in -/.my.cnf buna görə də MySQL hər hansı birini icra etməkdən qəti şəkildə imtina edir UPDATE və ya DELETE olmayan bəyanat WHERE əsas bənd və ya a LIMIT.
• Aksın DeletionProtection = true bütün istehsal RDS verilənlər bazası, S3 vedrələri və Terraform dövlət resurslarında (lifecycle { prevent_destroy = true }).
• Git Branch Qoruma Qaydalarını tətbiq edin main / production: Deaktiv edin Allow force pushes və Allow deletions GitHub/GitLab-da qorunan filiallarda belə, hətta depo administratorları belə edə bilməz git push --force üçün main.
• Öncədən gizli skanlama qarmaqlarını quraşdırın (gitleaks və ya trufflehog) və GitHub Push Protection: Blok özündə ehtiva edir AKIA, sk_live_, və ya .env əvvəl yerli nümunələri git commit hətta müvəffəq olur.

Tez-tez verilən suallar¶

İstehsalat verilənlər bazası cədvəlini təsadüfən atdığım və ya saytın dayanmasına səbəb olduğum üçün işdən çıxarılacağam?¶

Qüsursuz təhlükəsizlik mədəniyyətini tətbiq edən sağlam mühəndislik təşkilatlarında (müasir texnologiya, DevOps və SRE komandaları arasında standart) mühəndislər, hadisəni dərhal bildirmək və xidmətin bərpasına kömək etmək şərtilə, istehsalatdakı dürüst insan səhvlərinə görə işdən çıxarılmırlar. Mühəndislik rəhbərləri başa düşürlər ki, əgər kiçik və ya yüksək səviyyəli tərtibatçının istehsal cədvəlini tək bir nəzərdən keçirilməmiş əmrlə atmaq üçün xam icazələri və qoruyucu barmaqlıqların olmaması varsa, bunun əsas səbəbi girişə nəzarət və yerləşdirmə alətlərindəki qüsurdur, pis niyyət deyil. Təcrübədə, bu kəsintiləri ilk dəfə yaşamış mühəndis indi həmin sistemlə bağlı komandada ən təhlükəsiz adamdır. Davamlı olaraq işin dayandırılmasına səbəb olan yeganə davranış məlumat itkisi hadisəsini ört-basdır etməyə çalışmaq, audit qeydlərini silmək və ya hadisənin araşdırılması zamanı yalan danışmaqdır.

Nə üçün mən canlı istehsal trafikimi dərhal yeni bərpa edilmiş Vaxtında Bərpa (PITR) verilənlər bazası nümunəsinə keçirməməliyəm?¶

Yalnız bir cədvəldən sətirləri təsadüfən silmisinizsə (məsələn, `user_preferences` cədvəl) UTC saat 14:00-da və 13:59:50 UTC-yə bərpa edilmiş PITR klonunu fırlatmaq 20 dəqiqə çəkir, canlı istehsal məlumat bazanız minlərlə qanuni yeni müştəri sifarişlərini və ödənişlərini emal etməyə davam etmiş ola bilər. `orders` 14:00 və 14:20 UTC arasında masa. Bütün istehsal DNS son nöqtənizi kor-koranə 13:59:50 PITR klonuna keçirsəniz, bu 20 dəqiqəlik yeni müştəri sifarişlərini siləcəksiniz. Bunun əvəzinə, əsas verilənlər bazasını onlayn saxlayın (yazmalar yalnız pozulmuş xüsusiyyətdə dayandırılmışdır) və 13:59:50 PITR klonundan yalnız itkin sətirləri yenidən canlı istehsal cədvəlinə ixrac edin.

Təsadüfən itələdikdən iki dəqiqə sonra ictimai GitHub anbarını Şəxsi etsəm .env fayl, mən hələ də bütün API düymələrini çevirməliyəm?¶

Bəli, bu açarların 100 faizi hələ də ləğv edilməli və dərhal çevrilməlidir. İctimai GitHub repozitoriyasına göndərilən hər bir öhdəlik ictimai GitHub Events API ("Firehose") üzərindən real vaxt rejimində yayımlanır və həm qanuni təhlükəsizlik arxiv xidmətləri (məsələn, GHArchive), həm də bulud şəbəkələrində 24/7 işləyən zərərli avtomatlaşdırılmış etimadnamə toplama botları tərəfindən saniyələr ərzində indeksləşdirilir. İki dəqiqə sonra repozitorun görünmə qabiliyyətini İctimaidən Şəxsiyə çevirmək avtomatlaşdırılmış kazıyıcıların artıq yüklənmiş nüsxəsini silmir.

Necə olur git push --force-with-lease ilə müqayisədə kəsilmələrin qarşısını alır git push --force?¶

Standart işlədiyiniz zaman `git push --force`, Git qeyd-şərtsiz olaraq yerli filialınızla uzaq filialın üzərinə yazır, bu vaxt həmin filiala itələnmiş komanda yoldaşını səssizcə məhv edir. İstifadə etdiyiniz zaman `git push --force-with-lease` (və daha yaxşısı, `--force-if-includes`), Git əvvəlcə uzaq serveri yoxlayır ki, uzaq filial ucun hələ də yerli maşınınızın sonuncu götürdüyü dəqiq SHA-ya uyğun gəlir. Əgər iş yoldaşınız və ya CI boru kəməri son götürmənizdən bəri uzaq filiala yeni öhdəlik qoyubsa, `--force-with-lease` işlərini silmək əvəzinə "köhnə məlumat" xəbərdarlığı ilə təhlükəsiz şəkildə abort edir.

Mənbələr yoxlanılıb¶

• Milli Standartlar və Texnologiya İnstitutu (NIST, Amerika Birləşmiş Ştatları): NIST SP 800-61 Rev. 2 / Rev. 3 Kompüter Təhlükəsizliyi İnsidentlərinin İdarə Edilməsi Bələdçisi və Etibarnamənin Kompromis Məhdudlaşdırılması.
• Amazon Veb Xidmətləri (AWS), Google Bulud Platforması (GCP) və Microsoft Azure Sənədləri (Amerika Birləşmiş Ştatları): RDS Avtomatlaşdırılmış Vaxtında Bərpa (PITR) Arxitekturası, AWS IAM Təhlükəli Əsas Karantin Siyasətləri (AWSCompromisedKeyQuarantineV2) və S3 Versiyasının Silinməsi-Markerin Bərpası.
• PostgreSQL Qlobal İnkişaf Qrupu və MySQL / Oracle Documentation (Beynəlxalq): PostgreSQL Write-Ahead Logging (WAL), MVCC Tuple Visibility və MySQL Row-based Binary Log Flashback Recovery.
• Git SCM Rəsmi Sənədləşdirmə və GitHub Təhlükəsizlik Laboratoriyası (Beynəlxalq): Git Reflog (git-reflog), Sallanan Obyektin Bərpası (git-fsck), Tarixin Yenidən Yazılması (git-filter-repo) və Gizli Scanning Push Protection.
• USENIX Assosiasiyası / SREcon və Google Saytın Etibarlılığı Mühəndisliyi (SRE) Kitabları (Beynəlxalq): İnsidentlərin İdarə Edilməsi, Fövqəladə Hallarda Geri Qaytarma Triajı və Qüsursuz Ölümdən Sonra Mədəniyyət.

Əlaqədar təlimatlar¶

• Fövqəladə hallarda uzaqdan iş təhlükəsizliyi və məlumat məxfiliyi
• Kompüter 3-2-1 strategiyasının ehtiyat nüsxəsini çıxarır və fəlakətin bərpası
• Faylın təsadüfən silinməsi və formatlanmış diskin bərpası
• Veb hostinq böhranı miqrasiyası və ehtiyat nüsxəsinin bərpası
• Fişinq və oğurlanmış hesablar
• Təcili yardım nömrələri