Skip to content

හදිසි නිෂ්පාදන ඇනහිටීම, කාන්දු වූ API යතුරු, හෝ මකා දැමූ වළාකුළු යටිතල පහසුකම්

සෑම මෘදුකාංග ඉංජිනේරුවෙක්ම, පද්ධති පරිපාලකයෙක් සහ තාක්‍ෂණික දුරස්ථ සේවකයෙක් අවසානයේ විධානයක් අදහස් කරන විට බඩේ ගිලෙන මොහොතකට මුහුණ දෙයි. localhost හෝ staging එරෙහිව ක්රියාත්මක කරයි production: සුචිගත නොකළ DELETE a නොමැතිව WHERE වගන්තිය, a DROP TABLE හෝ terraform destroy, ඒ git push --force එය ප්‍රධාන ශාඛාව උඩින් ලියයි, නැතහොත් සජීවී AWS හෝ ස්ට්‍රයිප් රහස් යතුරු අඩංගු පොදු කැපවීමක්. වෘත්තීය අවසන් දත්ත ව්‍යසනයකින් මිනිත්තු 15ක සුළු ඉක්කාවක් වෙන් කරන්නේ ඔබේ දෑත් වහාම නතර කිරීම, ගබඩා කුට්ටි උඩින් ලිවීමට පෙර ලිවීමේ ගමනාගමනය කැටි කිරීම සහ නිවැරදි ප්‍රතිසාධන ප්‍රොටෝකෝලය ක්‍රියාත්මක කිරීමයි.

දැන් මේක කරන්න

  1. ඔබගේ දෑත් කැටි කර ඉක්මන් "fix" විධාන ක්‍රියාත්මක නොකරන්න, දත්ත සමුදා සේවාදායකය නැවත ආරම්භ කරන්න, හෝ ඔබගේ ටර්මිනල් කවුළුව වසා දමන්න. ඔබගේ වත්මන් පර්යන්ත අනුචලන බෆරය, කවච ඉතිහාසය සහ දේශීය .git/logs reflog හි නිශ්චිත ගනුදෙනු කාල මුද්දර, SHA හැෂ් සහ හානිය ආපසු හැරවීමට අවශ්‍ය සම්පත් හැඳුනුම්පත් අඩංගු වේ. ඔබගේ සම්පූර්ණ ටර්මිනල් අනුචලනය පළමුව ආරක්ෂිත පෙළ ගොනුවකට පිටපත් කරන්න.
  2. ඔබේ කණ්ඩායමේ සිද්දිය Slack/Teams නාලිකාවේ Severity-1 (SEV-1) සිදුවීමක් විනාඩි 2ක් ඇතුළත ප්‍රකාශ කරන්න. පාරිභෝගිකයන් දෝෂ 500ක් එල්ල කරන අතර ස්වයංක්‍රීය පසුබිම් රැකියා ඉතිරි වගු දූෂිත කරන අතරේ බිඳුණු නිෂ්පාදන දත්ත සමුදායක් රහසිගතව සකස් කිරීමට කිසිවිටෙක විනාඩි 45ක් වැය නොකරන්න. ඇමතුම් දත්ත සමුදා පරිපාලක (DBA) හෝ අඩවි විශ්වාසනීය ඉංජිනේරු (SRE) වහාම පිටුව කරන්න.
  3. ** ඔබ API යතුරක් කාන්දු කළේ නම්, .env ගොනුව, හෝ පොදු GitHub repo වෙත වලාකුළු රහස, සපයන්නාගේ උපකරණ පුවරුවේ යතුර ප්‍රථමයෙන් ඉවත් කරන්න (Git ඉතිහාසය නැවත ලිවීමට උත්සාහ කිරීමට පෙර).** ස්වයංක්‍රීය botnets පොදු GitHub Firehose API සීරීමට සහ සොරකම් කළ AWS, OpenAI, Stripe, සහ GCP යතුරු තත්පර 5*3 දක්වා ක්‍රියාත්මක කරයි. git push. දෙවන කැපවීමකින් හෝ බලහත්කාරයෙන් ගොනුව මකා දැමීමෙන් යතුර දැනටමත් ක්ලෝන කර ඇති ප්‍රහාරකයෙකු * නවත්වන්නේ නැත.
  4. ** ඔබ අහම්බයක් ධාවනය කළේ නම් DELETE, UPDATE, හෝ DROP නිෂ්පාදන දත්ත සමුදායක් මත, යෙදුම වහාම ලිවීමේ ගමනාගමනය කපා දමන්න.** වෙබ් යෙදුම නඩත්තු ප්‍රකාරයට දමන්න හෝ යෙදුම් පරිශීලකයාගේ ලිවීමේ අවසර අවලංගු කරන්න, එවිට නව එන ගනුදෙනු මගින් රික්ත නොවූ මිය ගිය ටියුපල් උඩින් ලිවීමට හෝ Point-In-Time Recovery (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 ඔබේ ප්‍රාදේශීය රාජ්‍ය ගොනුව දූෂිත කිරීමට හෝ නැති කිරීමට හැකි අශෝභන ගබ්සාවකට දෙවරක් බල කරයි.

Danger

Git හි රහසක් කාන්දු වීමෙන් පසු # 1 මාරක වැරැද්ද: ඔබ දුවන නිසා ඔබ ආරක්ෂිත යැයි කිසි විටෙකත් නොසිතන්න git rm .env && git commit -m "remove secret" && git push. Git හි ඇති සෑම ඓතිහාසික කැපවීමක්ම කැපවීමේ ප්‍රස්ථාරයේ සදහටම ප්‍රසිද්ධියේ කියවිය හැකි අතර, ඔබ ශාඛාව උඩින් ලිව්වත් git push --force, GitHub API සහ public archive crawlers හරහා අනාථ කැප SHA වෙත ප්‍රවේශ විය හැකිය (GHArchive) තත්පර 1ක් පවා දුරස්ථ ගබඩාවක් ස්පර්ශ කරන ඕනෑම රහසක් සියයට 100ක් සම්මුතියකට ලක් වූවක් සේ සලකා වහාම නිකුත් කරන සැපයුම්කරු වෙත අවලංගු කර/භ්‍රමණය කළ යුතුය.

හදිසි ට්‍රයිජ් කාර්ය ප්‍රවාහය: දත්ත සමුදාය පහත වැටීම, git බලය තල්ලු කිරීම හෝ රහස් කාන්දු වීම

ඔබේ පළමු මිනිත්තු 5 තාක්ෂණික සංග්‍රහය සඳහා මෙම තීරණ ගස අනුගමනය කරන්න.

flowchart TD
    A["නිෂ්පාදන ඉංජිනේරු හදිසි"] --> B{"දැන් සිදු වූ අසාර්ථකත්වය කුමක්ද?"}
    B -->|"නිෂ්පාදනයේ අහඹු SQL පහත වැටීම / මකා දැමීම / යාවත්කාලීන කිරීම"| C["යෙදුම් ලිවීම් / නඩත්තු මාදිලිය නවත්වන්න; VACUUM ධාවනය නොකරන්න"]
    B -->|"Git හි කාන්දු වූ API යතුර / .env / පුද්ගලික යතුර"| D["තත්පර 60ක් ඇතුළත Cloud Dashboard හි රහස අවලංගු කර කරකවන්න"]
    B -->|"අහඹු git push --force / Deleted Branch"| E["දේශීයව git reflog ධාවනය කරන්න; පිටපත් කරන්න Last Good Commit SHA"]
    B -->|"අහඹු ටෙරාෆෝම් විනාශ කිරීම / මකා දැමූ S3 හෝ VM"| F["IAM සැසිය මරන්න හෝ Ctrl+C ඔබන්න; .tfstate සංරක්ෂණය කරන්න"]
    C --> G["නියම UTC කාල මුද්‍රාව සටහන් කරන්න; Cloud PITR Clone හෝ Binlog ෆ්ලෑෂ්බැක් ක්‍රියාරම්භ කරන්න"]
    D --> H["අනවසර ස්පින්-අප් සඳහා CloudTrail / ප්‍රවේශ ලොග විගණනය කරන්න; Git-filter-repo සමඟ Repo ස්ක්‍රබ් කරන්න"]
    E --> I["GitHub සිදුවීම් විමසන්න / Git push --force-with-lease සමඟ ශාඛාව Reflog සහ Restore"]
    F --> J["S3 අනුවාද මකන්න සලකුණු, EBS ස්නැප්ෂොට්, හෝ Cloud Recycle Bin පරීක්ෂා කරන්න"]

1 කොටස: හදිසි නිෂ්පාදන දත්ත සමුදාය DROP, TRUNCATE, හෝ DELETE තොරව WHERE

විනාශකාරී SQL විමසුමක් සජීවී නිෂ්පාදන දත්ත ගබඩාවකට පහර දුන් විට, නිවැරදි ප්‍රතිසාධන යාන්ත්‍රණය ඔබගේ දත්ත සමුදා එන්ජිම (PostgreSQL, MySQL/MariaDB, SQL Server, MongoDB, හෝ DynamoDB) සහ ප්‍රකාශය DML එකක්ද යන්න මත රඳා පවතී.DELETE / UPDATE) හෝ DDL (DROP TABLE / TRUNCATE) මෙහෙයුම.

පියවර 1: හරියටම UTC වේලා මුද්‍රාව තත්පරයට සටහන් කරන්න

ඕනෑම උපස්ථ කොන්සෝලයක් ස්පර්ශ කිරීමට පෙර, ** නිශ්චිත වත්මන් UTC වේලාව** (date -u Linux/macOS පර්යන්තයේ, හෝ SELECT NOW(); SQL ප්‍රේරකය තුළ) සහ ඔබේ විනාශකාරී විමසුම ක්‍රියාත්මක වීමට * පෙර* හරියටම තත්පරය ඇස්තමේන්තු කරන්න. Point-In-Time Recovery (PITR) දත්ත සමුදායේ Write-Ahead ලොගය නැවත ධාවනය කිරීම මගින් ක්‍රියා කරයි (WAL PostgreSQL හි හෝ ද්විමය ලොගය (binlog MySQL හි) දක්වා T_minus_1_second ඔබගේ නරක විමසුම පැමිණීමට පෙර.

පියවර 2: පසුබිම් රැකියා සහ යෙදුම් ලිවීම් නවත්වන්න (MVCC ටියුපල් ආරක්ෂා කරන්න)

PostgreSQL තුළ, ක්‍රියාත්මක කිරීම DELETE FROM users; හෝ UPDATE orders SET status = 'cancelled'; නෑ ඇත්ත වශයෙන්ම තැටියේ ඇති වගු ගොනුවෙන් දත්ත එක් බයිටයක් මකා දමන්නේ නැත. PostgreSQL භාවිතා කරන නිසා ** බහු අනුවාද සමගාමී පාලනය (MVCC)**, a DELETE සරලව සකසයි xmax අනාගත විමසුම්වලට නොපෙනෙන ලෙස සලකුණු කිරීම සඳහා එක් එක් පේළි ටියුපල් මත ගනුදෙනු හැඳුනුම්පත ශීර්ෂකය, සම්පූර්ණ පේළි දත්ත නොවෙනස්ව තබා ඇත base/ නැවත භාවිත කළ හැකි ඉඩ සලකුණු කිරීම සඳහා autovacuum පැමිණෙන තෙක් heap ගොනුව.

  • ඔබ ස්වයං-සත්කාරක හෝ VM PostgreSQL හි සිටී නම් සහ මෑත උපස්ථයක් නොමැති නම්: වහාම සම්බන්ධ වන්න superuser සහ එම මේසය මත autovacuum අක්රිය කරන්න (ALTER TABLE table_name SET (autovacuum_enabled = false);), හෝ PostgreSQL සේවාව නවතා අමු වාරණ මට්ටමේ ගොනු පද්ධති සැණරුවක් ගන්න (LVM / EBS ස්නැප්ෂොට්) හි /var/lib/postgresql/data නාමාවලිය. විශේෂිත PostgreSQL අධිකරණ වෛද්ය දිගු (pg_dirtyread) මකාදැමූ හෝ පෙර-යාවත්කාලීන පේළිවලින් සියයට 100 ක් මිනිත්තු කිහිපයකින් රික්ත නොකළ ගොඩ වගුවෙන් කෙලින්ම කියවා ප්‍රතිසාධනය කළ හැක.

එන්ජිම සහ වලාකුළු වේදිකාව අනුව දත්ත සමුදා ප්‍රතිසාධන අනුකෘතිය

දත්ත සමුදා වේදිකාව හදිසි අනතුරු සඳහා වේගවත්ම ප්‍රතිසාධන ක්‍රමය DROP / DELETE පියවරෙන් පියවර තාක්ෂණික ක්රියාත්මක කිරීම
AWS RDS / Aurora (PostgreSQL / MySQL) ස්වයංක්‍රීය පොයින්ට්-ඉන්-ටයිම් ප්‍රතිසාධනය (PITR) නව අවස්ථාවකට (දින 1 සිට 35 දක්වා රඳවා ගැනීමේ කවුළුව තුළ ඕනෑම තත්පරයකට ප්‍රතිසාධනය කරයි) 1. AWS RDS කොන්සෝලය විවෘත කරන්න -> ස්වයංක්‍රීය උපස්ථ -> ඔබේ නිෂ්පාදන DB තෝරන්න -> කාලයට ප්‍රතිසාධනය කරන්න.
2. අභිරුචි දිනය සහ වේලාව තෝරන්න සහ ඔබේ නරක විමසුම ක්‍රියාත්මක වීමට පෙර **තත්පර 10 සිට 30 දක්වා නිශ්චිත UTC වේලා මුද්‍රාව ඇතුළත් කරන්න.
3. RDS සමාන්තර ක්ලෝනයක් කරකවයි (prod-db-recovery) විනාඩි 10 සිට 25 දක්වා. නොවෙනස්ව මේසය දමන්න (pg_dump -t my_table හෝ mysqldump) ප්‍රතිසාධන ක්ලෝනයෙන් එය නැවත සජීවී Prod DB වෙත ආයාත කරන්න (නැතහොත් DNS CNAME/අවසාන ලක්ෂ්‍යය ප්‍රතිසාධන ක්ලෝනයට මාරු කරන්න).
Google Cloud SQL / Azure Database Point-In-Time Clone GCP කොන්සෝලය තුළ -> Cloud SQL අවස්ථාව තෝරන්න -> ක්ලෝනය -> ක්ලෝනය පෙර අවස්ථාවේ සිට ක්ලෝන කරන්න (UTC) -> හරහා ක්ලෝනයෙන් නැතිවූ පේළි උපුටා ගන්න pg_dump / mysqldump හෝ විදේශ දත්ත එතුම (postgres_fdw)
Supabase / Neon / PlanetScale ක්ෂණික ශාඛාව / කාල-සංචාර ප්‍රතිසාධනය Neon: ඓතිහාසික වේලා මුද්‍රාවකින් ශාඛාව ක්ෂණික පිටපතක් ලිවීමට සාදන්න (Timestamp හෝ LSN මිනිත්තු 1 කට පෙර) තත්පර 2 කින් සහ වගුව ආපසු පිටපත් කරන්න.
Supabase: Dashboard -> Database -> Backups -> Point in Time Recovery.
PlanetScale: යෙදවීමේ ඉල්ලීම් UI තුළ ඇති ක්‍රම ප්‍රතිවර්තනය / පෙරළීමේ මුරපොල බොත්තම භාවිත කරන්න.
Self-Hosted MySQL / MariaDB (සමඟ binlog_format = ROW) ** බින්ලොග් ප්‍රතිලෝම (binlog2sql / mysqlbinlog --flashback)** MySQL සමඟ ධාවනය වන විට binlog_format = ROW (MySQL 5.7.7 සිට පෙරනිමිය), සෑම DELETE හෝ UPDATE බලපෑමට ලක් වූ සෑම පේළියකම ** සම්පූර්ණ පෙර සහ පසු රූපය** ද්විමය ලොගයට ලියයි (mysql-bin.0000XX) දුවන්න binlog2sql --flashback (හෝ MariaDB mysqlbinlog --flashback) නිශ්චිත ප්‍රතිලෝම ස්වයංක්‍රීයව උත්පාදනය කිරීමට එම නිශ්චිත ලොග් ස්ථානය මත INSERT හෝ UPDATE SQL ස්ක්‍රිප්ට් සහ සම්පූර්ණ උපස්ථයක් ප්‍රතිසාධනය නොකර තත්පර 60 කින් එය නැවත ධාවනය කරන්න.
Snowflake / BigQuery (Cloud Data ගබඩා) Bilt-In SQL Time Travel (AT / BEFORE) ශුන්‍ය උපස්ථ ප්‍රතිසාධනය අවශ්‍යයි. මිනිත්තු 5කට පෙර තිබූ මේසය විමසන්න:
හිම පියලි: CREATE OR REPLACE TABLE my_table AS SELECT * FROM my_table AT(OFFSET => -60*5); (හෝ UNDROP TABLE my_table;)
BigQuery: SELECT * FROM dataset.my_table FOR SYSTEM_TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 10 MINUTE);
MongoDB Atlas / Replica Set Oplog PITR ප්‍රතිසාධනය හෝ ප්‍රමාද වූ ද්විතියික සාමාජික MongoDB Atlas හි: Backup -> Restore -> Point in Time (replays the time local.oplog.rs වැටීමට පෙර හරියටම තත්පරය දක්වා එකතු කිරීම).

2 කොටස: කාන්දු වූ API යතුරු, .env රහස්, හෝ Git වෙත කැප වූ පුද්ගලික යතුරු

ඔබ අහම්බෙන් සිදු කළේ නම් .env ගොනුව, an id_rsa SSH යතුර, Firebase/GCP සේවා ගිණුම් JSON ගොනුවක්, තීරු රහස් යතුරක් (sk_live_...), හෝ AWS AKIA... Git වෙත ප්‍රවේශ යතුර, මෙම හරියටම ද්වි-අදියර අනුපිළිවෙල අනුගමනය කරන්න: අදියර (වලාකුළෙහි යතුර මරන්න) පළමුව, සහ Phase B (Git ගබඩාව ස්ක්‍රබ් කරන්න) දෙවනුව.

අදියර A: ක්ෂණික තත්පර 60ක ක්ලවුඩ් අක්තපත්‍ර අඩංගු කිරීම (මෙය පළමුව කරන්න)

1. AWS (AKIA... ප්‍රවේශ යතුරු ID + රහස් ප්‍රවේශ යතුර)

bots GitHub වෙතින් AWS යතුරක් සොරකම් කළ විට, ඔවුන්ගේ ස්වයංක්‍රීය ස්ක්‍රිප්ට් තත්පර 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 තුළ සම්මුතිගත ප්‍රවේශ යතුරු ID හෝ පරිශීලක නාමය මඟින් පෙරහන් කරන්න.
    • මෙම අඛණ්ඩ ඇමතුම් 5 සඳහා විශේෂයෙන් පරීක්ෂා කරන්න: CreateUser, CreateAccessKey, AttachUserPolicy, AssumeRole, සහ RunInstances. ඕනෑම වංචනික අවස්ථා අවසන් කිරීමට AWS Cost Explorer සහ EC2 Global View සියලුම කලාප හරහා පරීක්ෂා කරන්න, සහ AWS ආධාරක නඩුවක් (ගිණුම සහ බිල්පත් -> සම්මුතිගත ගිණුම) විවෘත කරන්න. ඔබ ප්‍රධාන කාන්දුවක් වාර්තා කරන විට සහ අවස්ථා කඩිනමින් අවසන් කරන විට AWS සාමාන්‍යයෙන් වංචනික ගණනය කිරීම් බිල්පත් ඉවත් කරයි.

2. තීරු (sk_live_...), OpenAI (sk-...), SendGrid, Twilio, සහ Slack Tokens

  • ** ඉරි:** යන්න ** සංවර්ධකයින් -> API යතුරු -> සම්මත යතුරු / සීමා කළ යතුරු -> තිත් තුන ක්ලික් කරන්න (...) -> රෝල් යතුර**. "දැන් කල් ඉකුත් වන්න" තෝරන්න (හෝ ඔබ දැන් ඔබේ නිෂ්පාදන පරිසර විචල්‍යයන් වෙත නව යතුර සක්‍රියව යොදවන්නේ නම් පමණක් පැය 1ක සහන කවුළුවක් සකසන්න).
  • OpenAI / Anthropic: API Keys උපකරණ පුවරුව වෙත ගොස් වහාම Revoke / Delete ක්ලික් කරන්න, එවිට ස්වයංක්‍රීය ප්‍රොක්සි සීරීම් යන්ත්‍රවලට මිනිත්තු කිහිපයකින් ඩොලර් දහස් ගණනක LLM ටෝකන් බැර ඉවත් කළ නොහැක.
  • GitHub පුද්ගලික ප්‍රවේශ ටෝකන (PATs), සියුම්-ග්‍රේන්ඩ් ටෝකන, සහ යෙදවීමේ යතුරු: GitHub සැකසීම් -> සංවර්ධක සැකසුම් -> පුද්ගලික ප්‍රවේශ ටෝකන වෙත ගොස් කාන්දු වූ ටෝකනයෙහි Delete / Revoke ක්ලික් කරන්න, ඉන්පසු ඔබේ සංවිධානයේ Log ***Audit පරීක්ෂා කරන්න.Settings -> Audit log) සඳහා repo.clone, repo.access, හෝ නිරාවරණ කවුළුව තුළ අනවසර webhook නිර්මාණය.
  • ** දත්ත සමුදා සම්බන්ධතා නූල් (DATABASE_URL / postgres:// / mongodb+srv://) සහ Redis URL:** දත්ත සමුදා එන්ජිම තුළ දත්ත සමුදා පරිශීලකයාගේ මුරපදය වෙනස් කරන්න (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 හි දත්ත සමුදා මුරපදයක් වෙනස් කිරීම නව පිවිසුම් අවහිර කිරීම පමණක් වන අතර ප්‍රහාරකයාගේ දැනටමත් විවෘත සම්බන්ධතාව පයින් ගසන තෙක් සජීවීව තබයි.

අදියර B: 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 ඉල්ලීම / කැපවීම් බැලීම් ඉවත් කරන්න:**
    • පිරිසිදු කළ ඉතිහාසය නැවත මූලාරම්භයට තල්ලු කරන්න (git push origin --force --all සහ git push origin --force --tags)
    • වැදගත් GitHub cached-commit පියවර: ඔබ පිරිසිදු කළ ඉතිහාසයක් බලහත්කාරයෙන් තල්ලු කිරීමෙන් පසුව පවා, පැරණි 40-අක්ෂර දන්නා ඕනෑම අයෙකු SHA URL (SHA URL) සිදු කරයි.github.com/org/repo/commit/abc1234...) GitHub සේවාදායක පැත්තේ කසළ එකතු කිරීම ක්‍රියාත්මක කරන තෙක් GitHub හි වෙබ් UI මත පැරණි අපිරිසිදු කැපවීම තවමත් බැලිය හැක. නියම පැරණි කැපවීම SHA සමඟ GitHub සහාය (හෝ ගබඩාවේ ආරක්‍ෂක උපදේශන / ආධාරක ද්වාරය භාවිතා කරන්න) සම්බන්ධ කර ** වෙබ් හැඹිලියෙන් ඉවත් කර ඇති/ එල්ලා වැටෙන කැපවීම ඉවත් කර ධාවනය කරන ලෙස ඔවුන්ගෙන් ඉල්ලා සිටින්න. git gc දුරස්ථ ගබඩාවේ**.

3 වෙනි කොටස: හදිසි අනතුරක් ඉවත් කිරීම git push --force, git reset --hard, හෝ මකා දැමූ ශාඛාව

ඔබ අහම්බෙන් දිව ගියහොත් git push --force සහ ඔබේ කණ්ඩායමේ සාමාජිකයින්ගේ කැපවීම් අතුගා දැමුවා main, නැත්නම් දිව්වා git reset --hard HEAD-5 සහ දේශීය වැඩවලින් සම්පූර්ණ දිනයක් අහිමි විය, ** කලබල නොවන්න, මන්ද Git කිසි විටෙකත් කැප වූ වස්තූන් වහාම මකා නොදමයි.**

ඔබේ "නැතිවූ" කැපවීම් තවමත් ආරක්ෂිතව ඇතුළත වාඩි වී සිටින්නේ ඇයි? .git/logs (The Reflog)

ඔබ කැපවීමක් සාදන විට, ශාඛා මාරු කරන විට, නැවත සකස් කරන විට, හෝ නැවත සකස් කරන විට, Git පෙර එක වාර්තා කරයි HEAD සහ ශාඛා ඉඟිය SHA-1/SHA-256 ස්ථානීය ලෙජරයක් ඇතුළත ** යොමු ලොගය (git reflog)**, සහ කසළ එකතු කිරීමෙන් ඒවා ඉවත් කිරීමට පෙර අවම වශයෙන් දින 14 සිට 90 දක්වා සැබෑ අනාථ කැපවීම් වස්තු තැටියේ තබා ගනී.

පියවරෙන් පියවර Git හදිසි ප්‍රතිසාධන වට්ටෝරු

දර්ශනය 1: ඔබ දිව ගියා git push --force සහ උඩින් ලිව්වා origin/main

  1. ** නිශ්චිත කැපවීම SHA සොයන්න origin/main ඔබේ බලය තල්ලු කිරීමට පෙර දකුණට පෙන්වා ඇත:**
    • ** ක්‍රමය A (ඔබගේ දේශීය දුරස්ථ ලුහුබැඳීමේ රෙෆ්ලොග් පරීක්ෂා කරන්න):** ඔබ තල්ලු කළ පර්යන්තයේ මෙම විධානය ක්‍රියාත්මක කරන්න: 
      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 ඔබේ බල තල්ලුව එය නැවත ලිවීමට පෙර දකුණේ විය.
    • ** ක්‍රමය B (දුවන ලද නැති ඕනෑම සගයකුගෙන් විමසන්න git pull තවමත්):** ගෙන ආ ඕනෑම සේවකයෙක් main අදටත් පෙර ඔවුන්ගේ ප්‍රදේශයේ නොවෙනස්ව කැපවූ ඉතිහාසයක් ඇත origin/main ශාඛාව.
    • ** ක්‍රමය C (GitHub REST API සිදුවීම් ලොගය විමසන්න):** ඔබගේ ප්‍රාදේශීය reflog හි දුරස්ථ තත්වය නොමැති නම්, GitHub හි 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 පෙර කැපවීම 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. ට පෙර කැපවීම SHA සොයා ගන්න reset: ඇතුල්වීම (උදා., HEAD@{2}: commit: feat: add payment webhook), සහ එම SHA වෙත කෙලින්ම යොමු කරමින් නව ගලවා ගැනීමේ ශාඛාවක් සාදන්න: 
    git switch -c rescue-branch HEAD@{2}
  3. ඔබ විසින් කැප නොකළ * ගොනුවක් ඔබට අහිමි වුවහොත් කුමක් කළ යුතුද? git added (වේදිකාගත) සහ පසුව අතුගා දැමීම 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 වරක්** එවිට Terraform එහි වත්මන් API ඇමතුම අවසන් කර යාවත්කාලීනය ලියයි .tfstate පිරිසිදුව ගොනු කරන්න. GitHub ක්‍රියා, GitLab CI, හෝ Terraform Cloud තුළ ක්‍රියාත්මක වන්නේ නම්, ධාවනය අවලංගු කරන්න ක්ලික් කර ක්ලවුඩ් කොන්සෝලයේ CI ධාවකයාගේ AWS/GCP IAM භූමිකාව වහාම අක්‍රිය කරන්න එවිට පියාසර API මකා දැමීම අසාර්ථක වේ. AccessDenied.
  2. ** ධාරාව උපස්ථ කරන්න .tfstate වහාම ගොනු කරන්න:**
    • ඔබගේ දුරස්ථ රාජ්‍ය ගොනුවේ දේශීය පිටපතක් බාගන්න (terraform state pull > emergency-backup.tfstate) සහ විනාඩි 10කට පෙර සිට පෙර ප්‍රාන්ත අනුවාදය ලබා ගැනීමට ඔබේ Terraform රාජ්‍ය බාල්දියේ S3 බාල්දි අනුවාදය පරීක්ෂා කරන්න.
  3. ** වලාකුළු සපයන්නා "මෘදු-මකන්න" සහ ප්‍රතිචක්‍රීකරණ බඳුන් ආරක්ෂණ දැල් පරීක්ෂා කරන්න:**
    • Amazon S3 (Bucket Versioning සක්‍රීය කර ඇත): අනුවාදිත S3 බාල්දියක ගොනු මකා දැමීම (aws s3 rm --recursive) තනි වස්තුවක් මකා දමන්නේ නෑ; එය හුදෙක් එක් එක් වස්තුවට ඉහලින් ශුන්‍ය බයිටයක් ඇතුල් කරයි මකන්න මාර්කර්. Delete Markers ඉවත් කරන්න (S3 Batch Operations හෝ 5-line Python හරහා boto3 ස්ක්‍රිප්ට්) ඔබගේ ගොනු වලින් සියයට 100 ක් ක්ෂණිකව ප්‍රතිසාධනය කිරීමට.
    • AWS EBS වෙළුම් සහ RDS ස්නැප්ෂොට් (ප්‍රතිචක්‍රීකරණ බඳුන): වින්‍යාස කර ඇත්නම් කොන්සෝලයේ AWS ප්‍රතිචක්‍රීකරණ බඳුන පරීක්ෂා කරන්න, සහ AWS උපස්ථ සුරක්ෂිතාගාර පරීක්ෂා කරන්න.
    • Google Cloud Platform (GCP) සහ Microsoft Azure: මකා දැමූ GCP ව්‍යාපෘති සහ Azure Resource Groups / Key Vaults / Storage Accounts with 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 Cloud Storage bucket / Terraform Cloud Workspace States ටැබය) දුරස්ථ පසුතලය ජීවත් වේ, S3 කොන්සෝලයේ ඉහළින් ඇති Show versions ටොගල ක්ලික් කරන්න, සොයන්න 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 අගුළු ගොනුව මිය ගිය ක්‍රියාවලි ID මගින් අගුළු දමා ඇත.
    • ප්‍රථමයෙන් ඔබේ CI උපකරණ පුවරුවේ සහ ඔබේ කණ්ඩායම් සගයන් සමඟ වෙනත් ටෙරාෆෝම් ක්‍රියාවලි ශුන්‍යයක් තවමත් එම වැඩබිමට එරෙහිව ක්‍රියාත්මක වන බව තහවුරු කර, පසුව දෝෂ පණිවිඩයේ මුද්‍රණය කර ඇති Lock ID UUID භාවිතයෙන් අනාථ වූ අගුල මුදා හරින්න: 
      terraform force-unlock <LOCK_ID_UUID>
  3. ** ඉතිරිව ඇති දත්ත සමුදායන් ප්‍රතිනිර්මාණය නොකර අර්ධ වශයෙන් විනාශ වූ පරිසරයක් නැවත ගොඩනැගීම (terraform import:**
    • අ terraform destroy ඔබගේ අස්ථායී යෙදුම් පැටවුම් ශේෂයන් අතුගා දැමුවා (aws_lb) සහ ECS/EKS සේවක නෝඩ් ඔබ එය නැවැත්වීමට පෙර, ** එය නිවැරදි කිරීමට පහසුය**: සරලව ධාවනය කරන්න terraform apply සහ Terraform විසින් සියලුම අස්ථායී ජාලකරණය ප්‍රතිනිර්මාණය කරන අතර මිනිත්තු 5 කින් මුල සිටම ස්ථර ගණනය කරනු ලබන අතර ඔබේ ඉතිරිව ඇති RDS දත්ත ගබඩාව ස්පර්ශ නොකර තබයි.
    • ඔබගේ රාජ්‍ය ගොනුවට ඉතිරිව ඇති රාජ්‍ය දත්ත ගබඩාවක හෝ S3 බාල්දියක මාර්ග අහිමි වුවහොත්, ** භාවිතා කරන්නimport {} වින්‍යාස බ්ලොක්** (ටෙරාෆෝම් 1.5+) හෝ terraform import aws_db_instance.prod_db my-rds-instance-id පවතින වලාකුළු සම්පත විනාශ නොකර ඔබේ රාජ්‍ය ගොනුවට නැවත බැඳීමට සහ ධාවනය කිරීමට terraform plan තහවුරු කිරීමට "0 to destroy" අයදුම් කිරීමට පෙර.

5 වෙනි කොටස: ඔබේ කළමනාකරුට විදුලිය බිඳ වැටීමක් දන්වා නිර්දෝෂී පශ්චාත් මරණ පරීක්ෂණයක් මෙහෙයවන්නේ කෙසේද

ඔබ දුරස්ථව වැඩ කරන අතරතුර නිෂ්පාදන සිදුවීමක් ඇති කළ විට, ඔබේ වෘත්තීය කීර්තිය නිර්වචනය වන්නේ වැරදීමකින්ම නොවේ, නමුත් ඔබේ විනිවිදභාවයේ වේගය, සන්සුන් සන්නිවේදනය සහ ක්‍රමානුකූල පිළියම් මගින්.

සිදුවීම් සන්නිවේදනයේ ස්වර්ණමය රීති 3

  1. සැඟවීමකින්, ප්‍රමාදයකින් හෝ දොස් පැවරීමකින් තොරව කරුණු, බලපෑම සහ ETA සඳහන් කරන්න: සොයාගැනීමෙන් මිනිත්තු 2ක් ඇතුළත දෝෂය වාර්තා කරන්න.
  2. ** "Root-Cause Fix" වෙතින් "අවම කිරීම" (ලේ ගැලීම නැවැත්වීම) වෙන් කරන්න:** හදිසි අවස්ථාවකදී, ඔබගේ එකම ඉලක්කය සේවාව ප්‍රතිසාධනය කිරීමයි (නරක යෙදවීම ආපසු පෙරළීම, PITR දත්ත සමුදා ක්ලෝනය වෙත අසාර්ථක වීම හෝ විශේෂාංගය ෆ්ලෑග් ඔෆ් කිරීම). හෙට සඳහා ගැඹුරු කේත ප්‍රතිසාධනය සුරකින්න.
  3. ** සාමාන්‍ය මිනිත්තු 15ක හෘද ස්පන්දන යාවත්කාලීන** සිදුවීම් නාලිකාවේ පළ කරන්න, එවිට විධායකයින් සහ පාරිභෝගික සහාය යමෙකු පාලනය කරන බව දැන ගන්න.

ස්ලැක් / කණ්ඩායම් සිදුවීම් ප්‍රකාශන පිටපත පිටපත් කරන්න

[SEV-1 සිදුවීම] නිෂ්පාදනය [සේවාව / දත්ත සමුදායේ නම] බලපෑම - මොකද වුණේ: දී [HH:MM UTC], ක්රියාත්මක කරන අතරතුර [brief technical action, e.g., a data migration script], බලාපොරොත්තු නොවූ දෙයක් [DELETE / config change / force-push] නිෂ්පාදනය සඳහා යොදන ලදී [database / service]. - වත්මන් පාරිභෝගික බලපෑම: [e.g., Checkout API is returning 500 errors / User profile updates are paused]. - ක්ෂණික අවම කිරීම සිදු වෙමින් පවතී: 1. ගමනාගමනය ලියන්න [table/service] දත්ත අඛණ්ඩතාව ආරක්ෂා කිරීම සඳහා විරාම කර ඇත. 2. Point-In-Time Recovery (PITR) ක්ලෝන කිරීම [HH:MM:SS UTC] (සිද්ධියට තත්පර 10කට පෙර) දැනට කැරකෙමින් පවතී [AWS RDS / GCP]. - සිද්ධි අණදෙන නිලධාරි: @[Your Name] (උපකාර @[DBA/On-Call SRE]) - ඊළඟ යාවත්කාලීනය: විනාඩි 15 කින් ([HH:MM UTC]) හෝ ප්‍රතිසාධන ක්ලෝනය අන්තර්ජාලයට පැමිණි වහාම.

පශ්චාත් සිදුවීම් ඉංජිනේරු ආරක්ෂණ පිරික්සුම් ලැයිස්තුව (ඔබේ නිර්දෝෂී පශ්චාත් මරණ පරීක්ෂණය සඳහා)

නිෂ්පාදනයේ සෑම මිනිස් දෝෂයක්ම ඇත්ත වශයෙන්ම පද්ධති සැලසුම් පරතරයකි (එක් පිටපතක් අලවා ඇති ටර්මිනල් විධානයකට ආරක්ෂක වැටක් නොමැතිව නිෂ්පාදනය අතහැරිය හැකි නම්, පද්ධතිය අසාර්ථක වීමට බලා සිටියේය). ඊළඟ දවසේ ඔබේ පශ්චාත් මරණ ලේඛනයේ මෙම කොන්ක්රීට් තාක්ෂණික ආරක්ෂක වැටවල් යෝජනා කර ක්රියාත්මක කරන්න:

  • ** වර්ණ කේතය සහ උපසර්ග නිෂ්පාදන විමසුම් (kube-ps1, psql .psqlrc):** ඔබේ shell සහ SQL සේවාදායකයා වින්‍යාස කරන්න එවිට ඕනෑම සම්බන්ධතාවයක් PRODUCTION දීප්තිමත් රතු පැහැයක් පෙන්වයි [PROD-DB] ක්ෂණිකව සහ සෑම අන්තර්ක්‍රියාකාරී PostgreSQL සැසියක්ම a තුළ ආරම්භ කරයි BEGIN; පෙරනිමියෙන් ගනුදෙනු අවහිර කිරීම (හෝ කට්ටල SET default_transaction_read_only = on;)
  • ** සබල කරන්න safe-updates (--i-am-a-dummy) MySQL/MariaDB සේවාදායකයින් තුළ:** එකතු කරන්න safe-updates දක්වා [mysql] තුළ -/.my.cnf එබැවින් MySQL කිසිවක් ක්‍රියාත්මක කිරීම ප්‍රතික්ෂේප කරයි UPDATE හෝ DELETE a නොමැති ප්‍රකාශය WHERE ප්රධාන වගන්තිය හෝ a LIMIT.
  • ** සක්රිය කරන්න DeletionProtection = true සියලුම නිෂ්පාදන RDS දත්ත සමුදායන්, S3 බාල්දි සහ Terraform රාජ්‍ය සම්පත් මත** (lifecycle { prevent_destroy = true })
  • ** Git ශාඛා ආරක්ෂණ නීති බලාත්මක කරන්න 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) දත්ත සමුදා අවස්ථාව වෙත මාරු නොකළ යුත්තේ ඇයි?

ඔබ අහම්බෙන් තනි වගුවකින් පේළි මකා දැමුවේ නම් (උදාහරණයක් ලෙස, the `user_preferences` වගුව) 14:00 UTC ට, සහ 13:59:50 UTC වෙත ප්‍රතිසාධනය කරන ලද PITR ක්ලෝනයක් කරකැවීමට මිනිත්තු 20 ක් ගතවේ, ඔබේ සජීවී නිෂ්පාදන දත්ත ගබඩාව තුළ නීත්‍යානුකූල නව පාරිභෝගික ඇණවුම් සහ ගෙවීම් දහස් ගණනක් අඛණ්ඩව ක්‍රියාත්මක කර තිබිය හැක. `orders` 14:00 සහ 14:20 UTC අතර වගුව. ඔබ ඔබේ සම්පූර්ණ නිෂ්පාදන DNS අන්ත ලක්ෂ්‍යය 13:59:50 PITR ක්ලෝනය වෙත අන්ධ ලෙස මාරු කළහොත්, ඔබ එම මිනිත්තු 20ක නවතම පාරිභෝගික ඇණවුම් මකා දමනු ඇත. ඒ වෙනුවට, ප්‍රධාන දත්ත සමුදාය මාර්ගගතව තබා ගන්න (කැඩුණු විශේෂාංගය මත පමණක් ලිවීම් විරාම කර ඇත) සහ 13:59:50 PITR ක්ලෝනයෙන් අතුරුදහන් වූ පේළි පමණක් සජීවී නිෂ්පාදන වගුවට අපනයනය කරන්න.

මම පොදු GitHub ගබඩාවක් පුද්ගලික කරන්නේ නම් අහම්බෙන් එකක් තල්ලු කිරීමෙන් මිනිත්තු දෙකකට පසුව .env ගොනුව, මට තවමත් සියලුම API යතුරු කරකවීමට අවශ්‍යද?

ඔව්, එම යතුරුවලින් සියයට 100ක් තවමත් අවලංගු කර වහාම කරකවා ගත යුතුය. පොදු GitHub ගබඩාවකට තල්ලු කරන සෑම කැපවීමක්ම පොදු GitHub Events API ("The Firehose") හරහා තථ්‍ය කාලීනව විකාශනය වන අතර නීත්‍යානුකූල ආරක්‍ෂක ලේඛනාගාර සේවා (GHArchive වැනි) සහ Cloud Networks හරහා 24/7 ක්‍රියාත්මක වන අනිෂ්ට ස්වයංක්‍රීය අක්තපත්‍ර අස්වනු නෙලීමේ බොට් යන දෙකෙන්ම තත්පර කිහිපයක් ඇතුළත සුචිගත කෙරේ. මිනිත්තු දෙකකට පසුව නිධියේ දෘශ්‍යතාව පොදු සිට පුද්ගලික වෙත පෙරලීමෙන් ස්වයංක්‍රීය සීරීම් දැනටමත් බාගත කර ඇති පිටපත මැකෙන්නේ නැත.

කොහොමද කරන්නේ git push --force-with-lease හා සසඳන විට ඇනහිටීම් වැළැක්වීම git push --force?

ඔබ සම්මත ධාවනය කරන විට `git push --force`, Git ඔබේ ප්‍රාදේශීය ශාඛාව සමඟින් දුරස්ථ ශාඛාව කොන්දේසි විරහිතව උඩින් ලියයි, ඒ අතරතුර එම ශාඛාවට තල්ලු කරන ලද කණ්ඩායමේ සගයකු ඕනෑම කැපවීමක් නිහඬව විනාශ කරයි. ඔබ භාවිතා කරන විට `git push --force-with-lease` (හා ඊටත් වඩා හොඳයි, `--force-if-includes`), දුරස්ථ ශාඛා ඉඟිය ඔබගේ දේශීය යන්ත්‍රය අවසන් වරට ලබා ගත් නිශ්චිත කැපවීම SHA සමඟ තවමත් ගැලපෙන බව තහවුරු කර ගැනීමට Git පළමුව දුරස්ථ සේවාදායකය පරීක්ෂා කරයි. ඔබ අවසන් වරට ලබා ගත් දින සිට සම සේවකයෙකු හෝ CI නල මාර්ගයක් දුරස්ථ ශාඛාව වෙත නව කැපවීමක් සිදු කළේ නම්, `--force-with-lease` ඔවුන්ගේ කාර්යය අතුගා දැමීම වෙනුවට "යල් පැන ගිය තොරතුරු" අනතුරු ඇඟවීමක් සමඟ ආරක්ෂිතව ගබ්සා කරයි.

මූලාශ්‍ර පරීක්ෂා කළා

  • ජාතික ප්‍රමිති සහ තාක්ෂණ ආයතනය (NIST, එක්සත් ජනපදය): NIST SP 800-61 Rev. 2 / Rev. 3 පරිගණක ආරක්ෂණ සිද්ධීන් හැසිරවීමේ මාර්ගෝපදේශය සහ අක්තපත්‍ර සම්මුති පාලනය.
  • Amazon Web Services (AWS), Google Cloud Platform (GCP), සහ Microsoft Azure Documentation (United States): RDS ස්වයංක්‍රීය පොයින්ට්-ඉන්-ටයිම් ප්‍රතිසාධන (PITR) ගෘහ නිර්මාණ ශිල්පය, AWS IAM සම්මුතිගත ප්‍රධාන නිරෝධායන ප්‍රතිපත්ති (AWSCompromisedKeyQuarantineV2), සහ S3 අනුවාදය Delete-Maker Recovery.
  • PostgreSQL Global Development Group සහ MySQL / Oracle Documentation (International): PostgreSQL Write-Ahead Logging (WAL), MVCC Tuple Visibility, සහ MySQL Row-Based Binary Log Flashback Recovery.
  • Git SCM නිල ලේඛන සහ GitHub ආරක්ෂක විද්‍යාගාරය (ජාත්‍යන්තර): Git Reflog (git-reflog), එල්ලෙන වස්තු ප්‍රතිසාධනය (git-fsck), ඉතිහාසය නැවත ලිවීම (git-filter-repo), සහ රහස් පරිලෝකන තල්ලු ආරක්ෂාව.
  • USENIX සංගමය / SREcon සහ Google Site Reliability Engineering (SRE) පොත් (ජාත්‍යන්තර): සිද්ධි කළමනා කිරීම, හදිසි ආපසු හැරවීමේ ත්‍රිත්වය, සහ දෝෂ රහිත පශ්චාත් මරණ සංස්කෘතිය.

අදාළ මාර්ගෝපදේශ