Случаен прекин на производството, протечени клучеви на API или избришана инфраструктура во облак¶

Секој софтверски инженер, системски администратор и технички далечински работник на крајот се соочуваат со моментот кој паѓа стомак кога командата наменета за localhost или staging извршува против production: неиндексиран DELETE без а WHERE клаузула, а DROP TABLE или terraform destroy, А git push --force што ја препишува главната гранка или јавна обврзница која содржи живи тајни клучеви AWS или Stripe. Она што го дели малото икање од 15 минути од катастрофата со податоци што завршува кариерата е веднаш да ги запрете вашите раце, да го замрзнете сообраќајот за пишување пред да се препишат блоковите за складирање и да го извршите вистинскиот протокол за обновување.

Направете го ова сега¶

1. **Замрзнете ги рацете и НЕ извршувајте избрзани команди за „поправка“, рестартирајте го серверот на базата на податоци или затворете го вашиот терминален прозорец. .git/logs reflog ги содржи точните временски ознаки на трансакцијата, извршете хашови на SHA и ID на ресурси потребни за да се врати штетата. Прво, копирајте го целиот терминал за прелистување во безбедна текстуална датотека.
2. Прогласете инцидент со сериозност-1 (SEV-1) во инцидентот на вашиот тим Slack/Teams канал во рок од 2 минути. Никогаш не трошете 45 минути обидувајќи се тајно да поправите скршена база на податоци за производство додека клиентите постигнуваат 500 грешки, а автоматизираните задачи во заднина ги расипуваат преостанатите табели. Веднаш кажете го администраторот на базата на податоци на повик (DBA) или инженерот за доверливост на локацијата (SRE).
3. Ако сте протеколе клуч API, .env датотека или облак тајна на јавно складиште на GitHub, ПРВО ПОВРШЕТЕ го клучот во контролната табла на давателот (пред да се обидете да ја преработите историјата на Git). Автоматските ботнети го гребат јавниот GitHub Firehose API и ги извршуваат украдените AWS, OpenAI, Stripe и GCP клучеви во рок од **** секунди од вашите ***15 git push. Бришењето на датотеката во второ извршување или присилно туркање не го спречува напаѓачот кој веќе го клонирал клучот.
4. Ако сте истрчале случајно DELETE, UPDATE, или DROP во производствената база на податоци, веднаш отсечете го сообраќајот WRITE на апликацијата. Ставете ја веб-апликацијата во режим на одржување или отповикајте ги дозволите за пишување на корисникот на апликацијата за новите дојдовни трансакции да не ги презапишуваат невакуумираните мртви торки или да не го комплицираат Обновувањето од точка во време (PITR).
5. Никогаш не трчај VACUUM, OPTIMIZE TABLE, или git gc --prune=now по случајно бришење. И релациските бази на податоци (PostgreSQL MVCC, MySQL InnoDB) и Git ги задржуваат избришаните редови и сирачените обврзници непроменети на дискот додека пропусницата за собирање ѓубре/вакуум не ги врати физичките страниците.
6. Ако а terraform destroy или скриптата за бришење облак сè уште работи во вашиот терминал, притиснете Ctrl + C ЕДНАШ (не двапати) или убијте го токенот за сесија на IAM. Притискање Ctrl + C еднаш активира грациозна состојба, па Terraform го зачувува делумното .tfstate на она што сè уште постои; притискање Ctrl + C двапати принудува неблагороден прекин што може да ја расипе или изгуби вашата локална државна датотека.

Работен тек на тријажа во итни случаи: паѓање на базата на податоци, присилно притискање на git или тајно истекување¶

Следете го ова дрво на одлуки за да ги насочите вашите први 5 минути техничко ограничување.

flowchart TD
    A["Производно инженерство вонредна состојба"] --> B{"Кој неуспех штотуку се случи?"}
    B -->|"Случајно SQL DROP / DELETE / UPDATE во Прод"| C["Стоп за пишување на апликација / режим на одржување; НЕ Работете со правосмукалка"]
    B -->|"Протече клуч за API / .env / Приватен клуч во Git"| D["Отповикајте и ротирајте ја тајната во контролната табла на облак во рок од 60 секунди"]
    B -->|"Случајно git push --force / Избришана гранка"| E["Стартувај git reflog Локално; Копирај го Last Good Commit SHA"]
    B -->|"Случајно тераформи уништи / избришани S3 или VM"| F["Убијте ја сесијата IAM или притиснете Ctrl+C еднаш; Зачувај .tfstate"]
    C --> G["Запишете го точниот временски печат UTC; Активирајте го Cloud PITR Clone или Binlog Flashback"]
    D --> H["Ревизија на CloudTrail / Дневници за пристап за неовластени спин-ап; Исчистете го Repo со git-filter-repo"]
    E --> I["Прашајте GitHub Events / Reflog & Restore Branch со git push --force-with-lease"]
    F --> J["Проверете го S3 Versioning Delete Markers, EBS Snapshots или Cloud Recycle Bin"]

Дел 1: База на податоци за случајно производство DROP, TRUNCATE, или DELETE без WHERE¶

Кога деструктивно SQL барање ќе ја погоди базата на податоци за производство во живо, точниот механизам за обновување зависи од моторот на вашата база на податоци (PostgreSQL, MySQL/MariaDB, SQL Server, MongoDB или DynamoDB) и дали изјавата е DML (DELETE / UPDATE) или ДДЛ (DROP TABLE / TRUNCATE) операција.

Чекор 1: Запишете го точниот временски печат UTC до вториот¶

Пред да допрете која било резервна конзола, запишете го точното моментално UTC време (date -u во Linux/macOS терминал или SELECT NOW(); внатре во SQL промптот) и проценете ја точната секунда само пред да започне да се извршува вашето деструктивно барање. Point-in-time Recovery (PITR) работи со репродукција на дневникот за пишување однапред на базата на податоци (WAL во PostgreSQL) или Бинарен дневник (binlog во MySQL) до T_minus_1_second непосредно пред да пристигне вашето лошо барање.

Чекор 2: Запрете ги задачите во заднина и запишувањето на апликациите (Заштитете ги MVCC множества)¶

Во ** PostgreSQL**, се извршува DELETE FROM users; или UPDATE orders SET status = 'cancelled'; не всушност брише ниту еден бајт податоци од датотеката со табелата на дискот веднаш. Бидејќи PostgreSQL користи Контрола за конкуренција на повеќе верзии (MVCC), а DELETE едноставно го поставува xmax ИД на трансакцијата заглавие на секоја торка на ред за да се означи како невидлив за идните прашања, оставајќи ги целосните податоци од редот непроменети во внатрешноста на base/ грамада датотека додека автовакуум не дојде заедно за да го означи просторот за повеќекратна употреба.

• Ако сте на само-хостиран или VM PostgreSQL и немате неодамнешна резервна копија: Веднаш поврзете се како superuser и оневозможете автовакуум на таа маса (ALTER TABLE table_name SET (autovacuum_enabled = false);(LVM / EBS снимка) на /var/lib/postgresql/data директориум. Специјализирани форензички екстензии на PostgreSQL (pg_dirtyread) може да чита и врати 100 проценти од избришаните или однапред да ги ажурира редовите директно од невакуумираната маса за неколку минути.

Матрица за обновување на базата на податоци по мотор и платформа за облак¶

Дел 2: протечени клучеви на API, .env тајни или приватни клучеви посветени на Git¶

Ако случајно сте извршиле .env датотека, ан id_rsa SSH клуч, датотека JSON-датотека за услуга Firebase/GCP, таен клуч Stripe (sk_live_...), или AWS AKIA... клуч за пристап до Git, следете ја оваа точна двофазна секвенца: Фаза А (Убијте го клучот во облакот) прво, и Фаза Б (Прочистете го складиштето Git) второ.

Фаза А: Непосредно задржување на акредитивите на облакот од 60 секунди (направете го ова ПРВО)¶

1. AWS (AKIA... ID на клуч за пристап + Таен клуч за пристап)¶

Кога ботови ќе украдат клуч AWS од GitHub, нивната автоматизирана скрипта ќе ја погоди вашата сметка во рок од 10 секунди за да ги врти примерите на GPU EC2 со максимална големина (p4d.24xlarge / g5.48xlarge) во сите 30+ глобални AWS региони (вклучувајќи ги и регионите за пријавување како Џакарта, Осака и Блискиот Исток) за рудирање криптовалути или создава корисник на IAM од задна врата со AdministratorAccess пред да го избришете оригиналниот клуч.

1. Деактивирајте и избришете го протечениот клуч за пристап веднаш:
   • Отворете AWS конзола -> IAM -> Корисници -> [Компромитиран корисник] -> Безбедносни акредитиви -> Копчиња за пристап -> Кликнете Деактивирај, потоа Избриши (или преку CLI: aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name MyUser).
2. Прикачете експлицитно DenyAll политика за неутрализирање на привремените aws sts токени за сесија:
   • Критична замка: Дури и откако ќе ја избришете AKIA... IAM пристапен клуч, ако напаѓачот веќе се јавил sts:GetSessionToken или sts:AssumeRole во текот на првите 30 секунди, нивни привремени ASIA... токенот за сесија останува валиден до 1 до 12 часа, освен ако не прикачите експлицитна политика Одбиј (како на пр. AWSCompromisedKeyQuarantineV2 или политика за одбивање на сите за токени издадени пред тековниот временски печат) на корисникот или улогата.
3. ** Проверете го AWS CloudTrail за упорност на задна врата:**
   • Отворете AWS CloudTrail -> Историја на настани и филтрирајте според компромитираниот Клуч за пристап или Корисничко име во изминатите 2 часа.
   • Проверете конкретно за овие 5 упорни повици: CreateUser, CreateAccessKey, AttachUserPolicy, AssumeRole, и RunInstances. Проверете ги AWS Cost Explorer и EC2 Global View низ сите региони за да ги прекинете сите непријателски случаи и да отворите непосреден AWS Support Case (сметка и наплата -> компромитирана сметка). AWS рутински се откажува од лажни сметки за пресметување кога ќе пријавите истекување на клучот и ќе ги прекинете случаите веднаш.

2. Пруга (sk_live_...), OpenAI (sk-...), SendGrid, Twilio и Slack Tokens¶

• ** Лента:** Одете во Програмери -> АПИ клучеви -> Стандардни клучеви / Ограничени клучеви -> Кликнете на трите точки (...) -> Клуче за тркалање. Изберете „Истекува сега“ (или поставете 1-часовен благодатен прозорец само ако активно го распоредувате новиот клуч во променливите на вашата производна средина во моментов).
• OpenAI / Anthropic: Одете на контролната табла API Keys и веднаш кликнете Отповикај / Избриши, така што автоматизираните прокси-гребувачи не можат да одземат илјадници долари од LLM-токени кредити за неколку минути.
• Текени за личен пристап на GitHub (PAT), фино-гранулирани токени и клучеви за распоредување: Одете во Поставки на GitHub -> Поставки за програмери -> Токени за личен пристап и кликнете Избриши / Отповикајте на протечениот токен, а потоа проверете го Дневникот за ревизија (Settings -> Audit log) за repo.clone, repo.access, или неовластено креирање веб-кука за време на прозорецот за изложување.
• ** Низи за поврзување со база на податоци (DATABASE_URL / postgres:// / mongodb+srv://) и URL-адреси на Redis:** Променете ја лозинката на корисникот на базата на податоци во моторот на базата на податоци (ALTER USER app_user WITH PASSWORD 'new_random_secret';), а потоа прекинете ги сите тековно отворени активни TCP конекции кои припаѓаат на старите ингеренции (SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE usename = 'app_user' AND pid <> pg_backend_pid(); во PostgreSQL), бидејќи менувањето на лозинката за базата на податоци во PostgreSQL или MySQL само блокира нови најавувања и ја остава веќе отворената врска на напаѓачот во живо додека не биде исклучен.

Фаза Б: Отстранување на тајната од историјата на Git (git filter-repo & Иселување на кешот на GitHub)¶

Штом протечениот клуч е мртов и ротира во производството, исчистете ја тајната низа од вашата историја на Git задолженија за да престанат да предупредуваат безбедносните скенери:

1. Препишете ја историјата на складиштето користејќи git filter-repo (или BFG Repo-Cleaner):
   • Земете свеж клон на голи огледало на вашето складиште и отстранете ја протечената датотека (на пример, .env) од секоја историска обврска во сите гранки и ознаки:

     # 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. Присилно турнете ја исчистената историја и исчистете ги кешираните GitHub Pull Request / Commit прегледи:
   • Вратете ја исчистената историја назад на своето потекло (git push origin --force --all и git push origin --force --tags).
   • Важен чекор за обврзување со кеширање на GitHub: Дури и откако насилно ќе ја турнете исчистената историја, секој што ја знае старата 40-знакна ќе изврши SHA URL (github.com/org/repo/commit/abc1234...) сè уште може да ја гледа старата неисчистена задолженост на веб-интерфејсот на GitHub додека GitHub не изврши собирање ѓубре од страна на серверот. Контактирајте со GitHub Support (или користете го порталот за безбедносно советување/поддршка на складиштето) со точно стариот commit SHA и замолете ги да го исфрлат дереференцираниот/висечкиот залог од веб-кешот и да го стартувате git gc на оддалеченото складиште.

Дел 3: Поништување случајно git push --force, git reset --hard, или избришана гранка¶

Ако случајно сте истрчале git push --force и ги избриша обврските на вашите соиграчи main, или трчаше git reset --hard HEAD-5 и изгуби цел ден локална работа, не паничете, бидејќи Git речиси никогаш не ги брише преземените објекти веднаш.

Зошто вашите „изгубени“ обврски сè уште седат безбедно внатре .git/logs (Рефлог)¶

Секогаш кога креирате commit, менувате гранки, ребазирате или ресетирате, Git го снима претходното HEAD и филијала врвот SHA-1/SHA-256 покажувачи во локалната книга наречена Референтен дневник (git reflog) и ги чува вистинските предмети за задолжени сирачиња на дискот најмалку 14 до 90 дена пред собирањето ѓубре да ги отстрани.

Чекор-по-чекор рецепти за итно закрепнување на Git¶

Сценарио 1: Трчавте git push --force и презапиша origin/main¶

1. Најдете го точниот commit SHA тоа origin/main покажа точно пред вашето присилно туркање:
   • Метод А (Проверете го локалното рефлог за следење од далечина): Извршете ја оваа команда во терминалот каде што сте притиснале:

     git reflog show origin/main
     

     Ќе видите излез како:

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

     Еве, 9f8e7d6 (origin/main@{1}) е точното обврзување origin/main беше вклучен точно пред да го препише вашето притискање.
   • Метод Б (Прашајте го секој соиграч кој не трчал git pull уште): Секој соработник што донел main порано денес сè уште има недопрената историја на заложби седи во нивната локална origin/main гранка.
   • Метод C (Прашање на дневникот на настани на GitHub REST API): Ако на вашето локално reflog му недостасува далечинска состојба, побарајте го GitHub's push events API за да ја видите "before" SHA хаш на настанот со сила-туркање:

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

2. ** Врати origin/main на претходниот commit SHA безбедно:**
   • Потврдете дека извршувањето изгледа правилно (git log -n 5 9f8e7d6), потоа турнете го токму тој SHA назад на далечинскиот управувач main гранка со користење --force-with-lease:

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

Сценарио 2: Трчавте git reset --hard или избришав локална филијала пред да притиснете¶

1. ** Трчај git reflog во вашето локално складиште:**

   git reflog --date=iso
   

2. ** Лоцирајте го commit SHA веднаш пред reset: влез** (на пр., HEAD@{2}: commit: feat: add payment webhook), и креирајте нова гранка за спасување насочена директно кон таа SHA:

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

3. Што ако изгубите неположена датотека што вие git addед (исценирани) и потоа избришани со git reset --hard?
   • Моментот кога трчате git add myfile.ts, Git ја компресира и ја запишува целосната содржина на таа датотека во .git/objects/ како висечка дупка, дури и ако никогаш не сте трчале git commit. Закрепнете го со наведување на сите висечки дамки подредени по време на модификација:

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

Дел 4: Случајно terraform destroy или избришано складирање во облак (S3, EBS, VMs)¶

Ако нафтоводот Infrastructure-as-Code (IaC) или рачната CLI команда почне да ги урива производствените ресурси на облакот:

1. Безбедно запрете го извршувањето:
   • Ако работи локално во вашиот терминал, притиснете Ctrl + C ONCE, така што Terraform го завршува својот тековен повик API и го пишува ажурираното .tfstate датотека чисто. Ако работи во GitHub Actions, GitLab CI или Terraform Cloud, кликнете Откажи ја работата и веднаш оневозможете ја улогата на AWS/GCP IAM на CI во конзолата на облак, така што бришењата на API за време на летот не успеат со AccessDenied.
2. ** Направете резервна копија на струјата .tfstate поднесете веднаш:**
   • Преземете локална копија од вашата далечинска државна датотека (terraform state pull > emergency-backup.tfstate) и проверете ја верзијата на кофата S3 на вашата корпа за состојбата на Terraform за да ја земете претходната состојба верзија од пред 10 минути.
3. Проверете ги безбедносните мрежи на давателот на облак „Soft-Delete“ и корпата за отпадоци:
   • Amazon S3 (со овозможено верзии на кофа): Бришење датотеки во верзија S3 корпа (aws s3 rm --recursive) не брише ниту еден објект; тој само вметнува нула бајт Избриши маркер на врвот на секој објект. Отстранете ги маркерите за бришење (преку S3 Batch Operations или Python од 5 линии boto3 скрипта) за да вратите 100 проценти од вашите датотеки веднаш.
   • AWS EBS Volumes & RDS Snapshots (Recycle Bin): Проверете ја AWS Recycle Bin во конзолата ако е конфигуриран и проверете ги AWS Backup сводовите.
   • Платформа на Google Cloud (GCP) и Microsoft Azure: Избришаните GCP проекти и Azure групите ресурси / клучните сефови / сметките за складирање со овозможено Soft Delete остануваат обновливи 7 до 30 дена преку еден клик за враќање во конзолата.

Како да го вратите скршениот Terraform .tfstate државна датотека или повторно увоз на сираче инфраструктура¶

Кога а terraform apply или случајно terraform destroy е прекината во текот на летот или кога некој случајно ќе ја избрише датотеката за далечинска состојба во S3/GCS, вашата облак инфраструктура влегува во опасна состојба на поделен мозок каде што некои ресурси сè уште постојат во AWS/GCP додека други недостасуваат од .tfstate:

1. Враќање на препишан или избришан далечински управувач .tfstate датотека од S3 / GCS верзија:
   • Никогаш рачно не уредувајте JSON .tfstate датотеката рачно во текстуален уредувач, освен ако секоја друга опција не е неуспешна, бидејќи една единствена не се совпаѓа "serial" или "lineage" Низата UUID ќе го блокира Terraform да не се применува повторно.
   • Отворете ја вашата корпа S3 (или табот за складирање облак на Google / табот Terraform Cloud Workspace States) каде што живее далечинскиот заднина, кликнете на копчето Прикажи верзии на горниот дел од конзолата S3, пронајдете го terraform.tfstate верзијата со временски печат непосредно пред лошото извршување, преземете ја и вратете ја безбедно како нова моментална состојба:

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

2. ** Кршење на заглавена државна брава (Error acquiring the state lock):**
   • Кога ќе абортирате лошо terraform destroy со Ctrl + C или убијте обесен CI тркач, далечинската табела DynamoDB или датотеката за заклучување GCS останува заклучена со мртвиот проект на процесот.
   • Прво проверете во вашата контролна табла CI и со вашите соиграчи дека нула други процеси на Terraform всушност сè уште се извршуваат против тој работен простор, а потоа отпуштете ја бравата со сираче користејќи го UUID-от за ID за заклучување отпечатен во пораката за грешка:

     terraform force-unlock <LOCK_ID_UUID>
     

3. ** Обнова на делумно уништена средина без повторно создавање на преживеаните бази на податоци (terraform import):**
   • Ако А terraform destroy ги избриша вашите рамнотежи на оптоварување апликации без државјанство (aws_lb) и работнички јазли ECS/EKS пред да го запрете, тоа е лесно да се поправи: едноставно стартувајте terraform apply и Terraform ќе ги рекреираат сите мрежи без државјанство и ќе ги пресметаат слоевите од нула за 5 минути додека ја оставаат вашата преживеана база на податоци RDS недопрена.
   • Ако вашата државна датотека изгуби трага од преживеаната државна база на податоци или кофа S3, користете import {} блок за конфигурација (Terraform 1.5+) или terraform import aws_db_instance.prod_db my-rds-instance-id за да го поврзете постоечкиот ресурс на облак назад во вашата државна датотека без да го уништите и да го стартувате terraform plan да потврди "0 to destroy" пред да аплицирате.

Дел 5: Како да му соопштите на вашиот менаџер за прекин и да водите беспрекорна посмртница¶

Кога предизвикувате инцидент во производството додека работите од далечина, вашата професионална репутација се дефинира не од самата грешка, туку од вашата брзина на транспарентност, мирна комуникација и систематско санирање.

3-те златни правила за комуникација со инциденти¶

1. Наведете факти, влијание и ЕТА без криење, одложување или обвинување: Пријавете ја грешката во рок од 2 минути по откривањето.
2. Одделете го „Mitigation“ (запирање на крварењето) од „Root-Cause Fix“: Во итен случај, вашата единствена цел е да ја вратите услугата (враќање на лошото распоредување, неуспех на клонот на базата на податоци PITR или исклучување на знамето на функцијата). Зачувајте го рефакторирањето на длабок код за утре.
3. Објавувајте редовни 15-минутни ажурирања за отчукувањата на срцето во каналот за инциденти, така што раководителите и поддршката за клиентите знаат дека некој има контрола.

Копирај-залепи скрипта за декларација за инциденти на Slack / Teams¶

[СЕВ-1 ИНЦИДЕНТ] Производство [Име на услуга/база на податоци] Влијание - Што се случи: Во [HH:MM UTC], while executing [brief technical action, e.g., a data migration script], ненамерен [DELETE / config change / force-push] was applied to production [database / service]. - Тековно влијание на клиентот: [e.g., Checkout API is returning 500 errors / User profile updates are paused]. - Immediate Mitigation in Progress: 1. Напишете сообраќај до [table/service] has been paused to preserve data integrity. 2. Клонирање на Point-in-Time Recovery (PITR) на [HH:MM:SS UTC] (10 секунди пред настанот) во моментов се врти [AWS RDS / GCP]. - Командант на инцидентот: @[Your Name] (помогнат од @[DBA/On-Call SRE]). - Next Update: In 15 minutes ([HH:MM UTC]) or as soon as the recovery clone comes online.

Post-incident engineering safeguards checklist (For your Blameless Post-Mortem)¶

Every human error in production is actually a systems design gap (if a single copy-pasted terminal command can drop production without a guardrail, the system was waiting to fail). Propose and implement these concrete technical guardrails in your post-mortem document the next day:

• Color-code and prefix production prompts (kube-ps1, psql .psqlrc): Configure your shell and SQL client so any connection to PRODUCTION прикажува светло црвено [PROD-DB] prompt and starts every interactive PostgreSQL session inside a BEGIN; transaction block by default (or sets SET default_transaction_read_only = on;).
• Enable safe-updates (--i-am-a-dummy) in MySQL/MariaDB clients: Add safe-updates до [mysql] in -/.my.cnf so MySQL outright refuses to execute any UPDATE или DELETE изјава на која недостасува а WHERE клучна клаузула или а LIMIT.
• Вклучи DeletionProtection = true на сите производствени бази на податоци RDS, кофи S3 и ресурси со статус на Terraform (lifecycle { prevent_destroy = true }).
• Спроведување на правилата за заштита на Git Branch на main / production: Оневозможи Allow force pushes и Allow deletions на заштитените гранки во GitHub/GitLab, така што дури и администраторите на складиштето не можат git push --force до main.
• Инсталирајте тајни куки за скенирање пред-поставување (gitleaks или trufflehog) и GitHub Push Protection: Block commits содржи AKIA, sk_live_, или .env шеми локално пред git commit дури и успева.

Најчесто поставувани прашања¶

Дали ќе бидам отпуштен поради случајно испуштање на табела со база на податоци за производство или предизвикување прекин на локацијата?¶

Во здрави инженерски организации кои практикуваат беспрекорна безбедносна култура (стандард во тимовите за модерна технологија, DevOps и SRE), инженерите не се отпуштаат поради искрени човечки грешки во производството, под услов веднаш да го пријават инцидентот и да помогнат во обновувањето на услугата. Инженерските лидери признаваат дека ако помлад или постар развивач имал необработени дозволи и недостаток на заштитни огради да испушти производна табела со една непрегледана команда, основната причина е недостаток во контролата на пристапот и алатките за распоредување, а не злоба. Во пракса, инженерот кој штотуку го доживеа тој прекин од прва рака сега е единствената најбезбедна личност во тимот во однос на тој систем. Единственото однесување кое постојано води до прекин е обидот да се прикрие настан за загуба на податоци, бришење на ревизорските дневници или лажење за време на истрагата за инцидентот.

Зошто не треба веднаш да го префрлам мојот сообраќај за производство во живо на ново обновениот примерок на базата на податоци Point-In-Time Recovery (PITR)?¶

Ако само случајно сте избришале редови од една табела (на пример, на `user_preferences` табела) во 14:00 UTC и потребни се 20 минути за да се врти клон PITR обновен на 13:59:50 UTC, вашата база на податоци за производство во живо можеби продолжила со обработка на илјадници легитимни нови нарачки и плаќања од клиенти во `orders` маса помеѓу 14:00 и 14:20 UTC. Ако слепо ја префрлите целата своја крајна точка на производство DNS на клонот PITR 13:59:50, ќе ги избришете тие 20 минути сосема нови нарачки од клиенти. Наместо тоа, чувајте ја главната база на податоци онлајн (со записите се паузирани само на скршената карактеристика) и извезете ги само редовите што недостасуваат од клонот PITR 13:59:50 назад во табелата за производство во живо.

Ако направам јавно складиште на GitHub Приватно две минути по случајно туркање на .env датотека, дали сè уште треба да ги ротирам сите API клучеви?¶

Да, 100 проценти од тие клучеви сепак мора да се отповикаат и да се ротираат веднаш. Секоја заложба што се турка во јавното складиште на GitHub се емитува во реално време преку јавното GitHub Events API („Fiehose“) и се индексира во рок од неколку секунди и од легитимните безбедносни архивски услуги (како што е GHArchive) и од злонамерните автоматизирани ботови за собирање акредитиви кои работат 24/7 низ облаците. Превртувањето на видливоста на складиштето од Јавно на Приватно две минути подоцна не ја брише копијата што веќе ја преземале автоматизираните гребење.

Како прави git push --force-with-lease спречи прекини во споредба со git push --force?¶

Кога трчате стандардно `git push --force`, Git unconditionally overwrites the remote branch with your local branch, silently destroying any commits a teammate pushed to that branch in the meantime. When you use `git push --force-with-lease` (and even better, `--force-if-includes`), Git checks the remote server first to verify that the remote branch tip still matches the exact commit SHA your local machine last fetched. If a coworker or CI pipeline pushed a new commit to the remote branch since your last fetch, `--force-with-lease` aborts safely with a "stale info" warning instead of wiping out their work.

Проверени извори¶

• National Institute of Standards and Technology (NIST, United States): NIST SP 800-61 Rev. 2 / Rev. 3 Computer Security Incident Handling Guide and Credential Compromise Containment.
• Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure Documentation (United States): RDS Automated Point-In-Time Recovery (PITR) Architecture, AWS IAM Compromised Key Quarantine Policies (AWSCompromisedKeyQuarantineV2), and S3 Versioning Delete-Marker Recovery.
• PostgreSQL Global Development Group and MySQL / Oracle Documentation (International): PostgreSQL Write-Ahead Logging (WAL), MVCC Tuple Visibility, and MySQL Row-Based Binary Log Flashback Recovery.
• Git SCM Official Documentation and GitHub Security Lab (International): Git Reflog (git-reflog), Dangling Object Recovery (git-fsck), History Rewriting (git-filter-repo), and Secret Scanning Push Protection.
• USENIX Association / SREcon and Google Site Reliability Engineering (SRE) Books (International): Managing Incidents, Emergency Rollback Triage, and Blameless Postmortem Culture.

Поврзани водичи¶

• Emergency remote work security and data privacy
• Компјутерски резервни копии 3-2-1 стратегија и враќање од катастрофи
• Accidental file deletion and formatted drive recovery
• Web hosting crisis migration and backup restoration
• Фишинг и компромитирани сметки
• Броеви за итни случаи