Skip to content

ಆಕಸ್ಮಿಕ ಉತ್ಪಾದನೆ ಸ್ಥಗಿತ, ಸೋರಿಕೆಯಾದ API ಕೀಗಳು ಅಥವಾ ಅಳಿಸಲಾದ ಮೇಘ ಮೂಲಸೌಕರ್ಯ

ಪ್ರತಿಯೊಬ್ಬ ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರ್, ಸಿಸ್ಟಮ್ಸ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಮತ್ತು ಟೆಕ್ನಿಕಲ್ ರಿಮೋಟ್ ವರ್ಕರ್‌ಗಳು ಅಂತಿಮವಾಗಿ ಹೊಟ್ಟೆ ಬೀಳುವ ಕ್ಷಣವನ್ನು ಎದುರಿಸುತ್ತಾರೆ localhost ಅಥವಾ staging ವಿರುದ್ಧ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ production: ಒಂದು ಸೂಚ್ಯಂಕವಿಲ್ಲದ DELETE ಎ ಇಲ್ಲದೆ WHERE ಷರತ್ತು, ಎ DROP TABLE ಅಥವಾ terraform destroy, ಎ git push --force ಅದು ಮುಖ್ಯ ಶಾಖೆಯನ್ನು ತಿದ್ದಿ ಬರೆಯುತ್ತದೆ, ಅಥವಾ ಲೈವ್ AWS ಅಥವಾ ಸ್ಟ್ರೈಪ್ ರಹಸ್ಯ ಕೀಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಸಾರ್ವಜನಿಕ ಬದ್ಧತೆ. ವೃತ್ತಿಜೀವನದ ಅಂತ್ಯದ ಡೇಟಾ ದುರಂತದಿಂದ 15-ನಿಮಿಷದ ಸಣ್ಣ ಬಿಕ್ಕಳಿಕೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ಎಂದರೆ ನಿಮ್ಮ ಕೈಗಳನ್ನು ತಕ್ಷಣವೇ ನಿಲ್ಲಿಸುವುದು, ಶೇಖರಣಾ ಬ್ಲಾಕ್‌ಗಳನ್ನು ತಿದ್ದಿ ಬರೆಯುವ ಮೊದಲು ಬರೆಯುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಫ್ರೀಜ್ ಮಾಡುವುದು ಮತ್ತು ಸರಿಯಾದ ಮರುಪಡೆಯುವಿಕೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು.

ಈಗಲೇ ಇದನ್ನು ಮಾಡಿ

  1. ನಿಮ್ಮ ಕೈಗಳನ್ನು ಫ್ರೀಜ್ ಮಾಡಿ ಮತ್ತು ಅವಸರದ "ಫಿಕ್ಸ್" ಆಜ್ಞೆಗಳನ್ನು ಚಲಾಯಿಸಬೇಡಿ, ಡೇಟಾಬೇಸ್ ಸರ್ವರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಅಥವಾ ನಿಮ್ಮ ಟರ್ಮಿನಲ್ ವಿಂಡೋವನ್ನು ಮುಚ್ಚಿ. ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಟರ್ಮಿನಲ್ ಸ್ಕ್ರಾಲ್‌ಬ್ಯಾಕ್ ಬಫರ್, ಶೆಲ್ ಇತಿಹಾಸ ಮತ್ತು ಸ್ಥಳೀಯ .git/logs ರೆಫ್ಲಾಗ್ ನಿಖರವಾದ ವಹಿವಾಟಿನ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳು, ಕಮಿಟ್ SHA ಹ್ಯಾಶ್‌ಗಳು ಮತ್ತು ಹಾನಿಯನ್ನು ಹಿಮ್ಮೆಟ್ಟಿಸಲು ಅಗತ್ಯವಿರುವ ಸಂಪನ್ಮೂಲ ಐಡಿಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಟರ್ಮಿನಲ್ ಸ್ಕ್ರಾಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ಮೊದಲು ಸುರಕ್ಷಿತ ಪಠ್ಯ ಫೈಲ್‌ಗೆ ನಕಲಿಸಿ.
  2. ನಿಮ್ಮ ತಂಡದ ಘಟನೆಯ ಸ್ಲಾಕ್/ತಂಡಗಳ ಚಾನಲ್‌ನಲ್ಲಿ 2 ನಿಮಿಷಗಳಲ್ಲಿ ತೀವ್ರತೆ-1 (SEV-1) ಘಟನೆಯನ್ನು ಘೋಷಿಸಿ. ಗ್ರಾಹಕರು 500 ದೋಷಗಳನ್ನು ಹೊಡೆಯುತ್ತಿರುವಾಗ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಹಿನ್ನೆಲೆ ಕೆಲಸಗಳು ಉಳಿದಿರುವ ಟೇಬಲ್‌ಗಳನ್ನು ಭ್ರಷ್ಟಗೊಳಿಸುತ್ತಿರುವಾಗ ಮುರಿದ ಉತ್ಪಾದನಾ ಡೇಟಾಬೇಸ್ ಅನ್ನು ರಹಸ್ಯವಾಗಿ ಸರಿಪಡಿಸಲು 45 ನಿಮಿಷಗಳನ್ನು ಎಂದಿಗೂ ವ್ಯಯಿಸಬೇಡಿ. ಆನ್-ಕಾಲ್ ಡೇಟಾಬೇಸ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ (DBA) ಅಥವಾ ಸೈಟ್ ವಿಶ್ವಾಸಾರ್ಹತೆ ಇಂಜಿನಿಯರ್ (SRE) ಅನ್ನು ತಕ್ಷಣವೇ ಪುಟ ಮಾಡಿ.
  3. ** ನೀವು API ಕೀಲಿಯನ್ನು ಸೋರಿಕೆ ಮಾಡಿದರೆ, .env ಫೈಲ್, ಅಥವಾ ಸಾರ್ವಜನಿಕ GitHub ರೆಪೊಗೆ ಕ್ಲೌಡ್ ರಹಸ್ಯ, ಒದಗಿಸುವವರ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿರುವ ಕೀಯನ್ನು ಮೊದಲು ಹಿಂತೆಗೆದುಕೊಳ್ಳಿ (Git ಇತಿಹಾಸವನ್ನು ಪುನಃ ಬರೆಯಲು ಪ್ರಯತ್ನಿಸುವ ಮೊದಲು).** ಸ್ವಯಂಚಾಲಿತ ಬಾಟ್‌ನೆಟ್‌ಗಳು ಸಾರ್ವಜನಿಕ GitHub Firehose API ಅನ್ನು ಸ್ಕ್ರ್ಯಾಪ್ ಮಾಡಿ ಮತ್ತು ಕದ್ದ AWS, OpenAI, ಸ್ಟ್ರೈಪ್ ಮತ್ತು GCP 1 ಅನ್ನು ನಿಮ್ಮ 5 ಸೆಕೆಂಡುಗಳಲ್ಲಿ **3 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ. git push. ಎರಡನೇ ಕಮಿಟ್‌ನಲ್ಲಿ ಫೈಲ್ ಅನ್ನು ಅಳಿಸುವುದು ಅಥವಾ ಬಲವಂತವಾಗಿ ತಳ್ಳುವುದು ಕೀಲಿಯನ್ನು ಈಗಾಗಲೇ ಕ್ಲೋನ್ ಮಾಡಿದ ಆಕ್ರಮಣಕಾರರನ್ನು ತಡೆಯುವುದಿಲ್ಲ.
  4. ** ನೀವು ಆಕಸ್ಮಿಕವಾಗಿ ಓಡಿದರೆ DELETE, UPDATE, ಅಥವಾ DROP ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತಕ್ಷಣವೇ ಬರೆಯಿರಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕಡಿತಗೊಳಿಸಿ.** ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ವಹಣೆ ಮೋಡ್‌ಗೆ ಇರಿಸಿ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಬಳಕೆದಾರರ ಬರವಣಿಗೆ ಅನುಮತಿಗಳನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳಿ ಇದರಿಂದ ಹೊಸ ಒಳಬರುವ ವಹಿವಾಟುಗಳು ನಿರ್ವಾತವಾದ ಡೆಡ್ ಟುಪಲ್‌ಗಳನ್ನು ಓವರ್‌ರೈಟ್ ಮಾಡುವುದಿಲ್ಲ ಅಥವಾ ಪಾಯಿಂಟ್-ಇನ್-ಟೈಮ್ ರಿಕವರಿ (PITR) ಅನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸುವುದಿಲ್ಲ.
  5. ** ಎಂದಿಗೂ ಓಡಬೇಡಿ VACUUM, OPTIMIZE TABLE, ಅಥವಾ git gc --prune=now ಆಕಸ್ಮಿಕವಾಗಿ ಅಳಿಸಿದ ನಂತರ
  6. ಒಂದು ವೇಳೆ terraform destroy ಅಥವಾ ಕ್ಲೌಡ್ ಅಳಿಸುವಿಕೆ ಸ್ಕ್ರಿಪ್ಟ್ ಇನ್ನೂ ನಿಮ್ಮ ಟರ್ಮಿನಲ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ, ಒತ್ತಿರಿ Ctrl + C ಒಮ್ಮೆ (ಎರಡು ಬಾರಿ ಅಲ್ಲ) ಅಥವಾ IAM ಸೆಷನ್ ಟೋಕನ್ ಅನ್ನು ಕಿಲ್ ಮಾಡಿ. ಒತ್ತುವುದು Ctrl + C ಒಮ್ಮೆ ಆಕರ್ಷಕವಾದ ಸ್ಥಿತಿಯ ಫ್ಲಶ್ ಅನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ ಆದ್ದರಿಂದ ಟೆರಾಫಾರ್ಮ್ ಭಾಗಶಃ ಉಳಿಸುತ್ತದೆ .tfstate ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂಬುದರ; ಒತ್ತುವುದು Ctrl + C ಎರಡು ಬಾರಿ ನಿಮ್ಮ ಸ್ಥಳೀಯ ಸ್ಟೇಟ್ ಫೈಲ್ ಅನ್ನು ಭ್ರಷ್ಟಗೊಳಿಸಬಹುದಾದ ಅಥವಾ ಕಳೆದುಕೊಳ್ಳುವ ಅನಪೇಕ್ಷಿತ ಸ್ಥಗಿತವನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ.

Danger

Git ನಲ್ಲಿ ರಹಸ್ಯವನ್ನು ಸೋರಿಕೆಯ ನಂತರ #1 ಮಾರಣಾಂತಿಕ ತಪ್ಪು: ನೀವು ಓಡಿದ್ದರಿಂದ ನೀವು ಸುರಕ್ಷಿತವಾಗಿರುತ್ತೀರಿ ಎಂದು ಎಂದಿಗೂ ಭಾವಿಸಬೇಡಿ git rm .env && git commit -m "remove secret" && git push. Git ನಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಐತಿಹಾಸಿಕ ಬದ್ಧತೆಯು ಕಮಿಟ್ ಗ್ರಾಫ್‌ನಲ್ಲಿ ಸಾರ್ವಜನಿಕವಾಗಿ ಶಾಶ್ವತವಾಗಿ ಓದಬಲ್ಲದು ಮತ್ತು ನೀವು ಶಾಖೆಯನ್ನು ಇದರೊಂದಿಗೆ ತಿದ್ದಿ ಬರೆದರೂ ಸಹ git push --force, ಅನಾಥ ಕಮಿಟ್ SHA ಗಿಟ್‌ಹಬ್ API ಮತ್ತು ಸಾರ್ವಜನಿಕ ಆರ್ಕೈವ್ ಕ್ರಾಲರ್‌ಗಳ ಮೂಲಕ ಪ್ರವೇಶಿಸಬಹುದಾಗಿದೆ (GHArchive) ** ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಯನ್ನು 1 ಸೆಕೆಂಡ್‌ಗೆ ಮುಟ್ಟುವ ಯಾವುದೇ ರಹಸ್ಯವನ್ನು 100 ಪ್ರತಿಶತ ರಾಜಿ ಮಾಡಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ತಕ್ಷಣವೇ ವಿತರಿಸುವ ಪೂರೈಕೆದಾರರಲ್ಲಿ ಹಿಂತೆಗೆದುಕೊಳ್ಳಬೇಕು/ತಿರುಗಿಸಬೇಕು.**

ತುರ್ತು ಚಿಕಿತ್ಸೆಯ ಸರದಿ ನಿರ್ಧಾರ ಕೆಲಸದ ಹರಿವು: ಡೇಟಾಬೇಸ್ ಡ್ರಾಪ್, ಜಿಟ್ ಫೋರ್ಸ್-ಪುಶ್, ಅಥವಾ ರಹಸ್ಯ ಸೋರಿಕೆ

ನಿಮ್ಮ ಮೊದಲ 5 ನಿಮಿಷಗಳ ತಾಂತ್ರಿಕ ಧಾರಣವನ್ನು ಮಾರ್ಗ ಮಾಡಲು ಈ ನಿರ್ಧಾರ ವೃಕ್ಷವನ್ನು ಅನುಸರಿಸಿ.

flowchart TD
    A["ಪ್ರೊಡಕ್ಷನ್ ಇಂಜಿನಿಯರಿಂಗ್ ತುರ್ತು ಪರಿಸ್ಥಿತಿ"] --> B{"ಯಾವ ವೈಫಲ್ಯ ಸಂಭವಿಸಿದೆ?"}
    B -->|"ಪ್ರಾಡ್‌ನಲ್ಲಿ ಆಕಸ್ಮಿಕ SQL ಡ್ರಾಪ್ / ಡಿಲೀಟ್ / ಅಪ್‌ಡೇಟ್"| C["ಅಪ್ಲಿಕೇಶನ್ ಬರಹಗಳನ್ನು ನಿಲ್ಲಿಸಿ / ನಿರ್ವಹಣೆ ಮೋಡ್; VACUUM ಅನ್ನು ರನ್ ಮಾಡಬೇಡಿ"]
    B -->|"Git ನಲ್ಲಿ ಸೋರಿಕೆಯಾದ API ಕೀ / .env / ಖಾಸಗಿ ಕೀ"| D["60 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಕ್ಲೌಡ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ರಹಸ್ಯವನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳಿ ಮತ್ತು ತಿರುಗಿಸಿ"]
    B -->|"ಆಕಸ್ಮಿಕ git ಪುಶ್ --ಫೋರ್ಸ್ / ಅಳಿಸಿದ ಶಾಖೆ"| E["ಜಿಟ್ ರಿಫ್ಲಾಗ್ ಅನ್ನು ಸ್ಥಳೀಯವಾಗಿ ರನ್ ಮಾಡಿ; ಕೊನೆಯ ಗುಡ್ ಕಮಿಟ್ SHA ನಕಲಿಸಿ"]
    B -->|"ಆಕಸ್ಮಿಕ ಟೆರಾಫಾರ್ಮ್ ನಾಶ / ಅಳಿಸಲಾಗಿದೆ S3 ಅಥವಾ VM"| F["IAM ಸೆಷನ್ ಅನ್ನು ಕಿಲ್ ಮಾಡಿ ಅಥವಾ Ctrl+C ಅನ್ನು ಒಮ್ಮೆ ಒತ್ತಿರಿ; ಸಂರಕ್ಷಿಸಿ .tfstate"]
    C --> G["ನಿಖರವಾದ UTC ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿ; ಕ್ಲೌಡ್ ಪಿಐಟಿಆರ್ ಕ್ಲೋನ್ ಅಥವಾ ಬಿನ್‌ಲಾಗ್ ಫ್ಲ್ಯಾಶ್‌ಬ್ಯಾಕ್ ಅನ್ನು ಟ್ರಿಗರ್ ಮಾಡಿ"]
    D --> H["ಅನಧಿಕೃತ ಸ್ಪಿನ್-ಅಪ್‌ಗಳಿಗಾಗಿ ಕ್ಲೌಡ್‌ಟ್ರೈಲ್ / ಪ್ರವೇಶ ಲಾಗ್‌ಗಳನ್ನು ಆಡಿಟ್ ಮಾಡಿ; ಜಿಟ್-ಫಿಲ್ಟರ್-ರೆಪೋದೊಂದಿಗೆ ರೆಪೋವನ್ನು ಸ್ಕ್ರಬ್ ಮಾಡಿ"]
    E --> I["ಜಿಟ್‌ಹಬ್ ಈವೆಂಟ್‌ಗಳನ್ನು ಪ್ರಶ್ನಿಸಿ / ರಿಫ್ಲಾಗ್ ಮತ್ತು ಜಿಟ್ ಪುಶ್‌ನೊಂದಿಗೆ ಶಾಖೆಯನ್ನು ಮರುಸ್ಥಾಪಿಸಿ --ಫೋರ್ಸ್-ವಿತ್-ಲೀಸ್"]
    F --> J["S3 ಆವೃತ್ತಿಯನ್ನು ಅಳಿಸಿ ಮಾರ್ಕರ್‌ಗಳು, EBS ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಅಥವಾ ಕ್ಲೌಡ್ ಮರುಬಳಕೆ ಬಿನ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ"]

ಭಾಗ 1: ಆಕಸ್ಮಿಕ ಉತ್ಪಾದನಾ ಡೇಟಾಬೇಸ್ DROP, TRUNCATE, ಅಥವಾ DELETE ಇಲ್ಲದೆ WHERE

ವಿನಾಶಕಾರಿ SQL ಪ್ರಶ್ನೆಯು ಲೈವ್ ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೊಡೆದಾಗ, ನಿಖರವಾದ ಮರುಪಡೆಯುವಿಕೆ ಕಾರ್ಯವಿಧಾನವು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಎಂಜಿನ್ (PostgreSQL, MySQL/MariaDB, SQL ಸರ್ವರ್, MongoDB, ಅಥವಾ DynamoDB) ಮತ್ತು ಹೇಳಿಕೆಯು DML ಆಗಿದ್ದರೆ (DELETE / UPDATE) ಅಥವಾ DDL (DROP TABLE / TRUNCATE) ಕಾರ್ಯಾಚರಣೆ.

ಹಂತ 1: ನಿಖರವಾದ UTC ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಎರಡನೆಯದಕ್ಕೆ ರೆಕಾರ್ಡ್ ಮಾಡಿ

ಯಾವುದೇ ಬ್ಯಾಕಪ್ ಕನ್ಸೋಲ್ ಅನ್ನು ಸ್ಪರ್ಶಿಸುವ ಮೊದಲು, ** ನಿಖರವಾದ ಪ್ರಸ್ತುತ UTC ಸಮಯವನ್ನು ಬರೆಯಿರಿ** (date -u Linux/macOS ಟರ್ಮಿನಲ್‌ನಲ್ಲಿ, ಅಥವಾ SELECT NOW(); SQL ಪ್ರಾಂಪ್ಟ್ ಒಳಗೆ) ಮತ್ತು ನಿಮ್ಮ ವಿನಾಶಕಾರಿ ಪ್ರಶ್ನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುವ * ಮೊದಲು* ನಿಖರವಾದ ಸೆಕೆಂಡ್ ಅನ್ನು ಅಂದಾಜು ಮಾಡಿ. ಪಾಯಿಂಟ್-ಇನ್-ಟೈಮ್ ರಿಕವರಿ (PITR) ಡೇಟಾಬೇಸ್‌ನ ರೈಟ್-ಮುಂದೆ ಲಾಗ್ ಅನ್ನು ಮರುಪಂದ್ಯ ಮಾಡುವ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (WAL PostgreSQL ನಲ್ಲಿ) ಅಥವಾ ಬೈನರಿ ಲಾಗ್ (binlog MySQL ನಲ್ಲಿ) ವರೆಗೆ T_minus_1_second ನಿಮ್ಮ ಕೆಟ್ಟ ಪ್ರಶ್ನೆ ಬರುವ ಮೊದಲು.

ಹಂತ 2: ಹಿನ್ನೆಲೆ ಕೆಲಸಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಬರಹಗಳನ್ನು ನಿಲ್ಲಿಸಿ (MVCC ಟುಪಲ್‌ಗಳನ್ನು ರಕ್ಷಿಸಿ)

PostgreSQL ನಲ್ಲಿ, ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತಿದೆ DELETE FROM users; ಅಥವಾ UPDATE orders SET status = 'cancelled'; ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಟೇಬಲ್ ಫೈಲ್‌ನಿಂದ ಒಂದು ಬೈಟ್ ಡೇಟಾವನ್ನು ಅಳಿಸುತ್ತದೆ ** ಅಲ್ಲ** ಈಗಿನಿಂದಲೇ. ಏಕೆಂದರೆ PostgreSQL ಬಳಸುತ್ತದೆ ಮಲ್ಟಿ-ಆವೃತ್ತಿ ಏಕಕಾಲಿಕ ನಿಯಂತ್ರಣ (MVCC), a DELETE ಸರಳವಾಗಿ ಹೊಂದಿಸುತ್ತದೆ xmax ಪ್ರತಿ ಸಾಲಿನ ಟ್ಯೂಪಲ್‌ನಲ್ಲಿನ ವಹಿವಾಟು ID ಹೆಡರ್ ಭವಿಷ್ಯದ ಪ್ರಶ್ನೆಗಳಿಗೆ ಅದೃಶ್ಯವೆಂದು ಗುರುತಿಸಲು, ಸಂಪೂರ್ಣ ಸಾಲಿನ ಡೇಟಾವನ್ನು ಒಳಗೆ ಹಾಗೆಯೇ ಇರಿಸುತ್ತದೆ base/ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಜಾಗವನ್ನು ಗುರುತಿಸಲು ಆಟೊವಾಕ್ಯೂಮ್ ಬರುವವರೆಗೆ ಹೀಪ್ ಫೈಲ್.

  • ** ನೀವು ಸ್ವಯಂ ಹೋಸ್ಟ್ ಅಥವಾ VM PostgreSQL ನಲ್ಲಿದ್ದರೆ ಮತ್ತು ಯಾವುದೇ ಇತ್ತೀಚಿನ ಬ್ಯಾಕಪ್ ಹೊಂದಿಲ್ಲದಿದ್ದರೆ:** ತಕ್ಷಣವೇ ಹೀಗೆ ಸಂಪರ್ಕಿಸಿ superuser ಮತ್ತು ಆ ಮೇಜಿನ ಮೇಲೆ ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ (ALTER TABLE table_name SET (autovacuum_enabled = false);), ಅಥವಾ PostgreSQL ಸೇವೆಯನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಕಚ್ಚಾ ಬ್ಲಾಕ್-ಲೆವೆಲ್ ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ತೆಗೆದುಕೊಳ್ಳಿ (LVM / EBS ಸ್ನ್ಯಾಪ್‌ಶಾಟ್) ನ /var/lib/postgresql/data ಡೈರೆಕ್ಟರಿ. ವಿಶೇಷವಾದ PostgreSQL ಫೋರೆನ್ಸಿಕ್ ವಿಸ್ತರಣೆಗಳು (pg_dirtyread) 100 ಪ್ರತಿಶತ ಅಳಿಸಿದ ಅಥವಾ ಪೂರ್ವ-ಅಪ್‌ಡೇಟ್ ಸಾಲುಗಳನ್ನು ನಿರ್ವಾತ ಹೀಪ್ ಟೇಬಲ್‌ನಿಂದ ನೇರವಾಗಿ ನಿಮಿಷಗಳಲ್ಲಿ ಓದಬಹುದು ಮತ್ತು ಮರುಪಡೆಯಬಹುದು.

ಎಂಜಿನ್ ಮತ್ತು ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮೂಲಕ ಡೇಟಾಬೇಸ್ ಮರುಪಡೆಯುವಿಕೆ ಮ್ಯಾಟ್ರಿಕ್ಸ್

ಡೇಟಾಬೇಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆಕಸ್ಮಿಕವಾಗಿ ವೇಗವಾಗಿ ಚೇತರಿಸಿಕೊಳ್ಳುವ ವಿಧಾನ DROP / DELETE ಹಂತ-ಹಂತದ ತಾಂತ್ರಿಕ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ
AWS RDS / ಅರೋರಾ (PostgreSQL / MySQL) ಸ್ವಯಂಚಾಲಿತ ಪಾಯಿಂಟ್-ಇನ್-ಟೈಮ್ ರಿಕವರಿ (PITR) ಹೊಸ ನಿದರ್ಶನಕ್ಕೆ (1 ರಿಂದ 35-ದಿನಗಳ ಧಾರಣ ವಿಂಡೋದಲ್ಲಿ ಯಾವುದೇ ಸೆಕೆಂಡಿಗೆ ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ) 1. AWS RDS ಕನ್ಸೋಲ್ ತೆರೆಯಿರಿ -> ಸ್ವಯಂಚಾಲಿತ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು -> ನಿಮ್ಮ ಉತ್ಪನ್ನ DB ಆಯ್ಕೆಮಾಡಿ -> ಸಮಯಕ್ಕೆ ಮರುಸ್ಥಾಪಿಸಿ.
2. ಕಸ್ಟಮ್ ದಿನಾಂಕ ಮತ್ತು ಸಮಯವನ್ನು ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು ನಿಖರವಾದ UTC ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ನಮೂದಿಸಿ 10 ರಿಂದ 30 ಸೆಕೆಂಡುಗಳ ಮೊದಲು ನಿಮ್ಮ ಕೆಟ್ಟ ಪ್ರಶ್ನೆಯು ರನ್ ಆಗುತ್ತದೆ.
3. RDS ಒಂದು ಸಮಾನಾಂತರ ಕ್ಲೋನ್ ಅನ್ನು ತಿರುಗಿಸುತ್ತದೆ (prod-db-recovery) 10 ರಿಂದ 25 ನಿಮಿಷಗಳಲ್ಲಿ. ಅಖಂಡ ಟೇಬಲ್ ಅನ್ನು ಎಸೆಯಿರಿ (pg_dump -t my_table ಅಥವಾ mysqldump) ಮರುಪ್ರಾಪ್ತಿ ಕ್ಲೋನ್‌ನಿಂದ ಮತ್ತು ಅದನ್ನು ಲೈವ್ ಪ್ರಾಡ್ DB ಗೆ ಆಮದು ಮಾಡಿ (ಅಥವಾ DNS CNAME/ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಚೇತರಿಸಿಕೊಂಡ ಕ್ಲೋನ್‌ಗೆ ಸ್ವ್ಯಾಪ್ ಮಾಡಿ).
Google ಕ್ಲೌಡ್ SQL / ಅಜೂರ್ ಡೇಟಾಬೇಸ್ ಪಾಯಿಂಟ್-ಇನ್-ಟೈಮ್ ಕ್ಲೋನ್ GCP ಕನ್ಸೋಲ್‌ನಲ್ಲಿ -> ಕ್ಲೌಡ್ SQL ನಿದರ್ಶನವನ್ನು ಆಯ್ಕೆಮಾಡಿ -> ** ಕ್ಲೋನ್** -> ** ಕ್ಲೋನ್ ಅನ್ನು ಮುಂಚಿನ ಸಮಯದಿಂದ ಆಯ್ಕೆಮಾಡಿ (UTC)** -> ಮೂಲಕ ಕ್ಲೋನ್‌ನಿಂದ ಕಾಣೆಯಾದ ಸಾಲುಗಳನ್ನು ಹೊರತೆಗೆಯಿರಿ pg_dump / mysqldump ಅಥವಾ ವಿದೇಶಿ ಡೇಟಾ ಹೊದಿಕೆ (postgres_fdw)
Supabase / Neon / PlanetScale ** ತತ್‌ಕ್ಷಣ ಶಾಖೆ / ಸಮಯ-ಪ್ರಯಾಣ ಮರುಸ್ಥಾಪನೆ** ** ನಿಯಾನ್:** ಐತಿಹಾಸಿಕ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ನಿಂದ ತತ್‌ಕ್ಷಣದ ನಕಲು ಬ್ರಾಂಚ್ ಅನ್ನು ರಚಿಸಿ (Timestamp ಅಥವಾ LSN 1 ನಿಮಿಷದ ಹಿಂದೆ) 2 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಮತ್ತು ಟೇಬಲ್ ಅನ್ನು ಮತ್ತೆ ನಕಲಿಸಿ.
Supabase: Dashboard -> Database -> Backups -> Point in Time Recovery.
PlanetScale: ನಿಯೋಜನೆ ವಿನಂತಿ UI ನಲ್ಲಿ ಸ್ಕೀಮಾ ರಿವರ್ಟ್ / ರಿವೈಂಡ್ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಬಟನ್ ಬಳಸಿ.
ಸ್ವಯಂ ಹೋಸ್ಟ್ ಮಾಡಿದ 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 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಅದನ್ನು ಮರುಪ್ಲೇ ಮಾಡಿ.
ಸ್ನೋಫ್ಲೇಕ್ / ಬಿಗ್‌ಕ್ವೆರಿ (ಕ್ಲೌಡ್ ಡೇಟಾ ವೇರ್‌ಹೌಸ್‌ಗಳು) ** ಅಂತರ್ನಿರ್ಮಿತ SQL ಸಮಯ ಪ್ರಯಾಣ (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);
ಮೊಂಗೋಡಿಬಿ ಅಟ್ಲಾಸ್ / ರೆಪ್ಲಿಕಾ ಸೆಟ್ Oplog PITR ಮರುಸ್ಥಾಪನೆ ಅಥವಾ ತಡವಾದ ದ್ವಿತೀಯ ಸದಸ್ಯ ಮೊಂಗೋಡಿಬಿ ಅಟ್ಲಾಸ್‌ನಲ್ಲಿ: ** ಬ್ಯಾಕಪ್ -> ಮರುಸ್ಥಾಪಿಸಿ -> ಪಾಯಿಂಟ್ ಇನ್ ಟೈಮ್** (ಮರುಪ್ರದರ್ಶನಗಳು local.oplog.rs ಡ್ರಾಪ್ ಮೊದಲು ನಿಖರವಾದ ಸೆಕೆಂಡ್ ವರೆಗೆ ಸಂಗ್ರಹಣೆ).

ಭಾಗ 2: ಸೋರಿಕೆಯಾದ API ಕೀಗಳು, .env ರಹಸ್ಯಗಳು ಅಥವಾ Git ಗೆ ಬದ್ಧವಾಗಿರುವ ಖಾಸಗಿ ಕೀಲಿಗಳು

ನೀವು ಆಕಸ್ಮಿಕವಾಗಿ ಬದ್ಧರಾಗಿದ್ದರೆ .env ಕಡತ, ಒಂದು id_rsa SSH ಕೀ, Firebase/GCP ಸೇವಾ ಖಾತೆ JSON ಫೈಲ್, ಸ್ಟ್ರೈಪ್ ರಹಸ್ಯ ಕೀ (sk_live_...), ಅಥವಾ AWS AKIA... Git ಗೆ ಪ್ರವೇಶ ಕೀಲಿ, ಈ ನಿಖರವಾದ ಎರಡು-ಹಂತದ ಅನುಕ್ರಮವನ್ನು ಅನುಸರಿಸಿ: ** ಹಂತ A (ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಕೀಲಿಯನ್ನು ಕೊಲ್ಲು)** ಮೊದಲು, ಮತ್ತು ** ಹಂತ B (Git ರೆಪೊಸಿಟರಿಯನ್ನು ಸ್ಕ್ರಬ್ ಮಾಡಿ)** ಎರಡನೆಯದು.

ಹಂತ A: ತಕ್ಷಣದ 60-ಸೆಕೆಂಡ್ ಕ್ಲೌಡ್ ರುಜುವಾತು ಧಾರಕ (ಇದನ್ನು ಮೊದಲು ಮಾಡಿ)

1. AWS (AKIA... ಪ್ರವೇಶ ಕೀ ID + ರಹಸ್ಯ ಪ್ರವೇಶ ಕೀ)

ಬಾಟ್‌ಗಳು GitHub ನಿಂದ AWS ಕೀಲಿಯನ್ನು ಕದಿಯುವಾಗ, ಗರಿಷ್ಠ ಗಾತ್ರದ GPU EC2 ನಿದರ್ಶನಗಳನ್ನು ಸ್ಪಿನ್ ಅಪ್ ಮಾಡಲು ಅವರ ಸ್ವಯಂಚಾಲಿತ ಸ್ಕ್ರಿಪ್ಟ್ 10 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ನಿಮ್ಮ ಖಾತೆಯನ್ನು ಹಿಟ್ ಮಾಡುತ್ತದೆ (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 ಕಾಸ್ಟ್ ಎಕ್ಸ್‌ಪ್ಲೋರರ್ ಮತ್ತು EC2 ಗ್ಲೋಬಲ್ ವ್ಯೂ ಅನ್ನು ಎಲ್ಲಾ ಪ್ರದೇಶಗಳಾದ್ಯಂತ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ತಕ್ಷಣ AWS ಬೆಂಬಲ ಪ್ರಕರಣವನ್ನು ತೆರೆಯಿರಿ (ಖಾತೆ ಮತ್ತು ಬಿಲ್ಲಿಂಗ್ -> ರಾಜಿ ಖಾತೆ). ನೀವು ಪ್ರಮುಖ ಸೋರಿಕೆಯನ್ನು ವರದಿ ಮಾಡಿದಾಗ AWS ವಾಡಿಕೆಯಂತೆ ಮೋಸದ ಕಂಪ್ಯೂಟ್ ಬಿಲ್‌ಗಳನ್ನು ಮನ್ನಾ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಿದರ್ಶನಗಳನ್ನು ತಕ್ಷಣವೇ ಮುಕ್ತಾಯಗೊಳಿಸುತ್ತದೆ.

2. ಪಟ್ಟೆ (sk_live_...), OpenAI (sk-...), SendGrid, Twilio ಮತ್ತು Slack Tokens

  • ** ಸ್ಟ್ರೈಪ್:** ಗೆ ಹೋಗಿ ** ಡೆವಲಪರ್‌ಗಳು -> API ಕೀಗಳು -> ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಕೀಗಳು / ನಿರ್ಬಂಧಿತ ಕೀಗಳು -> ಮೂರು ಚುಕ್ಕೆಗಳನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿ (...) -> ರೋಲ್ ಕೀ**. "ಈಗ ಮುಕ್ತಾಯ" ಆಯ್ಕೆಮಾಡಿ (ಅಥವಾ ನೀವು ಇದೀಗ ನಿಮ್ಮ ಉತ್ಪಾದನಾ ಪರಿಸರದ ವೇರಿಯೇಬಲ್‌ಗಳಿಗೆ ಹೊಸ ಕೀಲಿಯನ್ನು ಸಕ್ರಿಯವಾಗಿ ನಿಯೋಜಿಸುತ್ತಿದ್ದರೆ ಮಾತ್ರ 1-ಗಂಟೆಯ ಗ್ರೇಸ್ ವಿಂಡೋವನ್ನು ಹೊಂದಿಸಿ).
  • OpenAI / Anthropic: API ಕೀಗಳ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗೆ ಹೋಗಿ ಮತ್ತು ತಕ್ಷಣವೇ ಹಿಂತೆಗೆದುಕೊಳ್ಳಿ / ಅಳಿಸಿ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿ ಆದ್ದರಿಂದ ಸ್ವಯಂಚಾಲಿತ ಪ್ರಾಕ್ಸಿ ಸ್ಕ್ರಾಪರ್‌ಗಳು ಸಾವಿರಾರು ಡಾಲರ್‌ಗಳ LLM ಟೋಕನ್ ಕ್ರೆಡಿಟ್‌ಗಳನ್ನು ನಿಮಿಷಗಳಲ್ಲಿ ಹರಿಸುವುದಿಲ್ಲ.
  • GitHub ಪರ್ಸನಲ್ ಆಕ್ಸೆಸ್ ಟೋಕನ್‌ಗಳು (PAT ಗಳು), ಫೈನ್-ಗ್ರೇನ್ಡ್ ಟೋಕನ್‌ಗಳು ಮತ್ತು ಡಿಪ್ಲೋಯ್ ಕೀಗಳು: GitHub ಸೆಟ್ಟಿಂಗ್‌ಗಳು -> ಡೆವಲಪರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು -> ವೈಯಕ್ತಿಕ ಪ್ರವೇಶ ಟೋಕನ್‌ಗಳು ಗೆ ಹೋಗಿ ಮತ್ತು ಸೋರಿಕೆಯಾದ ಟೋಕನ್‌ನಲ್ಲಿ ಅಳಿಸು / ಹಿಂತೆಗೆದುಕೊಳ್ಳಿ ಕ್ಲಿಕ್ ಮಾಡಿ, ನಂತರ ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ಲಾಗ್ *** ಆಡಿಟ್ ಪರಿಶೀಲಿಸಿSettings -> Audit log) ಗಾಗಿ repo.clone, repo.access, ಅಥವಾ ಮಾನ್ಯತೆ ವಿಂಡೋದ ಸಮಯದಲ್ಲಿ ಅನಧಿಕೃತ ವೆಬ್‌ಹೂಕ್ ರಚನೆ.
  • ** ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕ ತಂತಿಗಳು (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 ರೆಪೋ-ಕ್ಲೀನರ್):**
    • ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಯ ತಾಜಾ ಬೇರ್ ಮಿರರ್ ಕ್ಲೋನ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ ಮತ್ತು ಸೋರಿಕೆಯಾದ ಫೈಲ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ (ಉದಾಹರಣೆಗೆ, .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 ಪುಲ್ ವಿನಂತಿ / ಬದ್ಧ ವೀಕ್ಷಣೆಗಳನ್ನು ಶುದ್ಧೀಕರಿಸಿ:**
    • ಸ್ವಚ್ಛಗೊಳಿಸಿದ ಇತಿಹಾಸವನ್ನು ಮೂಲಕ್ಕೆ ಹಿಂದಕ್ಕೆ ತಳ್ಳಿರಿ (git push origin --force --all ಮತ್ತು git push origin --force --tags)
    • ** ಪ್ರಮುಖ GitHub ಕ್ಯಾಶ್-ಬದ್ಧ ಹಂತ:** ನೀವು ಸ್ವಚ್ಛಗೊಳಿಸಿದ ಇತಿಹಾಸವನ್ನು ಒತ್ತಾಯಿಸಿದ ನಂತರವೂ, ಹಳೆಯ 40-ಅಕ್ಷರವನ್ನು ತಿಳಿದಿರುವ ಯಾರಾದರೂ 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 (ದಿ ರಿಫ್ಲಾಗ್)

ನೀವು ಬದ್ಧತೆಯನ್ನು ರಚಿಸಿದಾಗ, ಶಾಖೆಗಳನ್ನು ಬದಲಿಸಿ, ಮರುಬೇಸ್ ಮಾಡಿ ಅಥವಾ ಮರುಹೊಂದಿಸಿದಾಗ, Git ಹಿಂದಿನದನ್ನು ದಾಖಲಿಸುತ್ತದೆ HEAD ಮತ್ತು ಶಾಖೆಯ ತುದಿ SHA-1/SHA-256 ಪಾಯಿಂಟರ್‌ಗಳು ಸ್ಥಳೀಯ ಲೆಡ್ಜರ್ ಒಳಗೆ ** ಉಲ್ಲೇಖ ಲಾಗ್ (git reflog)**, ಮತ್ತು ಕಸ ಸಂಗ್ರಹಣೆಯು ಅವುಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಮೊದಲು **ಕನಿಷ್ಠ 14 ರಿಂದ 90 ದಿನಗಳವರೆಗೆ ** ಡಿಸ್ಕ್‌ನಲ್ಲಿ ನಿಜವಾದ ಅನಾಥ ಬದ್ಧ ವಸ್ತುಗಳನ್ನು ಇರಿಸುತ್ತದೆ.

ಹಂತ-ಹಂತದ Git ತುರ್ತು ಮರುಪಡೆಯುವಿಕೆ ಪಾಕವಿಧಾನಗಳು

ಸನ್ನಿವೇಶ 1: ನೀವು ಓಡಿದ್ದೀರಿ git push --force ಮತ್ತು ತಿದ್ದಿ ಬರೆಯಲಾಗಿದೆ origin/main

  1. ** ನಿಖರವಾದ ಕಮಿಟ್ 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 ಶಾಖೆ.
    • ವಿಧಾನ ಸಿ (GitHub REST API ಈವೆಂಟ್‌ಗಳ ಲಾಗ್ ಅನ್ನು ಪ್ರಶ್ನಿಸಿ): ನಿಮ್ಮ ಸ್ಥಳೀಯ ರಿಫ್ಲಾಗ್ ರಿಮೋಟ್ ಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, GitHub ನ ಪುಶ್ ಈವೆಂಟ್‌ಗಳ 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)

ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್-ಆಸ್-ಕೋಡ್ (IaC) ಪೈಪ್‌ಲೈನ್ ಅಥವಾ ಹಸ್ತಚಾಲಿತ CLI ಆಜ್ಞೆಯು ಉತ್ಪಾದನಾ ಕ್ಲೌಡ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹರಿದು ಹಾಕಲು ಪ್ರಾರಂಭಿಸಿದರೆ:

  1. ** ಮರಣದಂಡನೆಯನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ನಿಲ್ಲಿಸಿ:**
    • ನಿಮ್ಮ ಟರ್ಮಿನಲ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ಚಾಲನೆಯಲ್ಲಿದ್ದರೆ, ** ಒತ್ತಿರಿCtrl + C ಒಮ್ಮೆ** ಆದ್ದರಿಂದ Terraform ತನ್ನ ಪ್ರಸ್ತುತ API ಕರೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ನವೀಕರಿಸಿದದನ್ನು ಬರೆಯುತ್ತದೆ .tfstate ಶುದ್ಧವಾಗಿ ಫೈಲ್ ಮಾಡಿ. GitHub ಕ್ರಿಯೆಗಳು, GitLab CI, ಅಥವಾ ಟೆರ್ರಾಫಾರ್ಮ್ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ರನ್ ಆಗುತ್ತಿದ್ದರೆ, ರನ್ ರದ್ದುಮಾಡು ಕ್ಲಿಕ್ ಮಾಡಿ ಮತ್ತು ಕ್ಲೌಡ್ ಕನ್ಸೋಲ್‌ನಲ್ಲಿ CI ರನ್ನರ್‌ನ AWS/GCP IAM ಪಾತ್ರವನ್ನು ತಕ್ಷಣವೇ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ಇದರಿಂದ ವಿಮಾನದಲ್ಲಿನ API ಅಳಿಸುವಿಕೆಗಳು ವಿಫಲಗೊಳ್ಳುತ್ತವೆ AccessDenied.
  2. ** ಕರೆಂಟ್ ಅನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಿ .tfstate ತಕ್ಷಣ ಫೈಲ್ ಮಾಡಿ:**
    • ನಿಮ್ಮ ರಿಮೋಟ್ ಸ್ಟೇಟ್ ಫೈಲ್‌ನ ಸ್ಥಳೀಯ ನಕಲನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ (terraform state pull > emergency-backup.tfstate) ಮತ್ತು 10 ನಿಮಿಷಗಳ ಹಿಂದಿನ ಹಿಂದಿನ ಸ್ಥಿತಿಯ ಆವೃತ್ತಿಯನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ನಿಮ್ಮ ಟೆರಾಫಾರ್ಮ್ ಸ್ಟೇಟ್ ಬಕೆಟ್‌ನಲ್ಲಿ S3 ಬಕೆಟ್ ಆವೃತ್ತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ.
  3. ** ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್ "ಸಾಫ್ಟ್-ಡಿಲೀಟ್" ಮತ್ತು ಮರುಬಳಕೆ ಬಿನ್ ಸುರಕ್ಷತಾ ಜಾಲಗಳನ್ನು ಪರಿಶೀಲಿಸಿ:**
    • Amazon S3 (ಬಕೆಟ್ ಆವೃತ್ತಿಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ): ಆವೃತ್ತಿಯ S3 ಬಕೆಟ್‌ನಲ್ಲಿ ಫೈಲ್‌ಗಳನ್ನು ಅಳಿಸಲಾಗುತ್ತಿದೆ (aws s3 rm --recursive) ಅಲ್ಲ ಒಂದೇ ವಸ್ತುವನ್ನು ಅಳಿಸುವುದಿಲ್ಲ; ಇದು ಕೇವಲ ಪ್ರತಿ ವಸ್ತುವಿನ ಮೇಲೆ ಶೂನ್ಯ-ಬೈಟ್ ಮಾರ್ಕರ್ ಅಳಿಸು ಅನ್ನು ಸೇರಿಸುತ್ತದೆ. ಅಳಿಸಿ ಗುರುತುಗಳನ್ನು ತೆಗೆದುಹಾಕಿ (S3 ಬ್ಯಾಚ್ ಕಾರ್ಯಾಚರಣೆಗಳು ಅಥವಾ 5-ಲೈನ್ ಪೈಥಾನ್ ಮೂಲಕ boto3 ಸ್ಕ್ರಿಪ್ಟ್) ನಿಮ್ಮ 100 ಪ್ರತಿಶತ ಫೈಲ್‌ಗಳನ್ನು ತಕ್ಷಣ ಮರುಸ್ಥಾಪಿಸಲು.
    • AWS EBS ಸಂಪುಟಗಳು ಮತ್ತು RDS ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು (ಮರುಬಳಕೆ ಬಿನ್): ಕಾನ್ಸೋಲ್‌ನಲ್ಲಿ AWS ಮರುಬಳಕೆ ಬಿನ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ ಮತ್ತು AWS ಬ್ಯಾಕಪ್ ವಾಲ್ಟ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
    • Google ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ (GCP) ಮತ್ತು Microsoft Azure: ಅಳಿಸಲಾದ GCP ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಅಜುರೆ ಸಂಪನ್ಮೂಲ ಗುಂಪುಗಳು / ಕೀ ವಾಲ್ಟ್‌ಗಳು / ಶೇಖರಣಾ ಖಾತೆಗಳು ಸಾಫ್ಟ್ ಡಿಲೀಟ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಒಂದು ಮರುಸ್ಥಾಪನೆ ಕ್ಲಿಕ್ ಮೂಲಕ 7 ರಿಂದ 30 ದಿನಗಳವರೆಗೆ ಮರುಪಡೆಯಬಹುದಾಗಿದೆ.

ಮುರಿದ ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಮರುಪಡೆಯುವುದು ಹೇಗೆ .tfstate ರಾಜ್ಯದ ಕಡತ ಅಥವಾ ಮರು-ಆಮದು ಅನಾಥ ಮೂಲಸೌಕರ್ಯ

ಯಾವಾಗ ಎ terraform apply ಅಥವಾ ಆಕಸ್ಮಿಕ terraform destroy ವಿಮಾನದ ಮಧ್ಯದಲ್ಲಿ ಅಡಚಣೆ ಉಂಟಾಗುತ್ತದೆ, ಅಥವಾ ಯಾರಾದರೂ ಆಕಸ್ಮಿಕವಾಗಿ S3/GCS ನಲ್ಲಿ ರಿಮೋಟ್ ಸ್ಟೇಟ್ ಫೈಲ್ ಅನ್ನು ಅಳಿಸಿದಾಗ, ನಿಮ್ಮ ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯವು ಅಪಾಯಕಾರಿ ಸ್ಪ್ಲಿಟ್-ಮೆದುಳಿನ ಸ್ಥಿತಿಗೆ ಪ್ರವೇಶಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳು AWS/GCP ನಲ್ಲಿ ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ ಮತ್ತು ಇತರವುಗಳು ಕಾಣೆಯಾಗಿವೆ. .tfstate:

  1. ** ತಿದ್ದಿ ಬರೆಯಲಾದ ಅಥವಾ ಅಳಿಸಲಾದ ರಿಮೋಟ್ ಅನ್ನು ಮರುಪಡೆಯಲಾಗುತ್ತಿದೆ .tfstate S3 / GCS ಆವೃತ್ತಿಯಿಂದ ಫೈಲ್:**
    • JSON ಅನ್ನು ಎಂದಿಗೂ ಹಸ್ತಚಾಲಿತವಾಗಿ ಸಂಪಾದಿಸಬೇಡಿ .tfstate ಪ್ರತಿಯೊಂದು ಆಯ್ಕೆಯು ವಿಫಲಗೊಳ್ಳದ ಹೊರತು ಪಠ್ಯ ಸಂಪಾದಕದಲ್ಲಿ ಕೈಯಿಂದ ಫೈಲ್, ಏಕೆಂದರೆ ಒಂದೇ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ "serial" ಅಥವಾ "lineage" UUID ಸ್ಟ್ರಿಂಗ್ ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಮತ್ತೆ ಅನ್ವಯಿಸದಂತೆ ನಿರ್ಬಂಧಿಸುತ್ತದೆ.
    • ರಿಮೋಟ್ ಬ್ಯಾಕೆಂಡ್ ವಾಸಿಸುವ ನಿಮ್ಮ S3 ಬಕೆಟ್ (ಅಥವಾ Google ಕ್ಲೌಡ್ ಸ್ಟೋರೇಜ್ ಬಕೆಟ್ / ಟೆರಾಫಾರ್ಮ್ ಕ್ಲೌಡ್ ವರ್ಕ್‌ಸ್ಪೇಸ್ ** ಸ್ಟೇಟ್ಸ್** ಟ್ಯಾಬ್) ತೆರೆಯಿರಿ, 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 ಲಾಕ್ ಫೈಲ್ ಡೆಡ್ ಪ್ರಕ್ರಿಯೆ ID ಯಿಂದ ಲಾಕ್ ಆಗಿರುತ್ತದೆ.
    • ಮೊದಲು ನಿಮ್ಮ CI ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ಮತ್ತು ನಿಮ್ಮ ತಂಡದ ಸದಸ್ಯರೊಂದಿಗೆ ಶೂನ್ಯ ಇತರ ಟೆರಾಫಾರ್ಮ್ ಪ್ರಕ್ರಿಯೆಗಳು ಆ ಕಾರ್ಯಸ್ಥಳದ ವಿರುದ್ಧ ಇನ್ನೂ ಚಾಲನೆಯಲ್ಲಿವೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ನಂತರ ದೋಷ ಸಂದೇಶದಲ್ಲಿ ಮುದ್ರಿಸಲಾದ ಲಾಕ್ ಐಡಿ UUID ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅನಾಥ ಲಾಕ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿ: 
      terraform force-unlock <LOCK_ID_UUID>
  3. ** ಉಳಿದಿರುವ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸದೆ ಭಾಗಶಃ ನಾಶವಾದ ಪರಿಸರವನ್ನು ಪುನರ್ನಿರ್ಮಿಸುವುದು (terraform import):**
    • ಒಂದು ವೇಳೆ ಎ terraform destroy ನಿಮ್ಮ ಸ್ಥಿತಿಯಿಲ್ಲದ ಅಪ್ಲಿಕೇಶನ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು ಅಳಿಸಿಹಾಕಿದೆ (aws_lb) ಮತ್ತು ECS/EKS ವರ್ಕರ್ ನೋಡ್‌ಗಳನ್ನು ನೀವು ನಿಲ್ಲಿಸುವ ಮೊದಲು, ** ಸರಿಪಡಿಸಲು ಸುಲಭ**: ಸರಳವಾಗಿ ರನ್ ಮಾಡಿ terraform apply ಮತ್ತು ಟೆರ್ರಾಫಾರ್ಮ್ ಎಲ್ಲಾ ಸ್ಥಿತಿಯಿಲ್ಲದ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಅನ್ನು ಮರುಸೃಷ್ಟಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಉಳಿದಿರುವ RDS ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸ್ಪರ್ಶಿಸದೆ ಬಿಡುವಾಗ 5 ನಿಮಿಷಗಳಲ್ಲಿ ಮೊದಲಿನಿಂದ ಲೇಯರ್‌ಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ.
    • ನಿಮ್ಮ ರಾಜ್ಯದ ಫೈಲ್ ಉಳಿದಿರುವ ಸ್ಟೇಟ್‌ಫುಲ್ ಡೇಟಾಬೇಸ್ ಅಥವಾ 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. ** "ಮೂಲ-ಕಾರಣ ಫಿಕ್ಸ್" ನಿಂದ ಪ್ರತ್ಯೇಕ "ಮಿಟಿಗೇಷನ್" (ರಕ್ತಸ್ರಾವವನ್ನು ನಿಲ್ಲಿಸುವುದು) ನಾಳೆಗಾಗಿ ಆಳವಾದ ಕೋಡ್ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅನ್ನು ಉಳಿಸಿ.
  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. ಪಾಯಿಂಟ್-ಇನ್-ಟೈಮ್ ರಿಕವರಿ (PITR) ಕ್ಲೋನ್ ಗೆ [HH:MM:SS UTC] (ಈವೆಂಟ್‌ಗೆ 10 ಸೆಕೆಂಡುಗಳ ಮೊದಲು) ಪ್ರಸ್ತುತ ಸ್ಪಿನ್ ಅಪ್ ಆಗುತ್ತಿದೆ [AWS RDS / GCP]. - ಘಟನೆ ಕಮಾಂಡರ್: @[Your Name] (ಸಹಾಯ ಮಾಡಿದವರು @[DBA/On-Call SRE]) - ಮುಂದಿನ ನವೀಕರಣ: 15 ನಿಮಿಷಗಳಲ್ಲಿ ([HH:MM UTC]) ಅಥವಾ ರಿಕವರಿ ಕ್ಲೋನ್ ಆನ್‌ಲೈನ್‌ಗೆ ಬಂದ ತಕ್ಷಣ.

ಘಟನೆಯ ನಂತರದ ಇಂಜಿನಿಯರಿಂಗ್ ರಕ್ಷಣಾತ್ಮಕ ಪರಿಶೀಲನಾಪಟ್ಟಿ (ನಿಮ್ಮ ದೋಷರಹಿತ ಮರಣೋತ್ತರ ಪರೀಕ್ಷೆಗಾಗಿ)

ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಮಾನವ ದೋಷವು ವಾಸ್ತವವಾಗಿ ಸಿಸ್ಟಮ್ಸ್ ವಿನ್ಯಾಸದ ಅಂತರವಾಗಿದೆ (ಒಂದೇ ಕಾಪಿ-ಪೇಸ್ಟ್ ಮಾಡಿದ ಟರ್ಮಿನಲ್ ಆಜ್ಞೆಯು ಗಾರ್ಡ್ರೈಲ್ ಇಲ್ಲದೆ ಉತ್ಪಾದನೆಯನ್ನು ಬಿಡಬಹುದಾದರೆ, ಸಿಸ್ಟಮ್ ವಿಫಲಗೊಳ್ಳಲು ಕಾಯುತ್ತಿದೆ). ಮರುದಿನ ನಿಮ್ಮ ಮರಣೋತ್ತರ ದಾಖಲೆಯಲ್ಲಿ ಈ ಕಾಂಕ್ರೀಟ್ ಟೆಕ್ನಿಕಲ್ ಗಾರ್ಡ್ರೈಲ್‌ಗಳನ್ನು ಪ್ರಸ್ತಾಪಿಸಿ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಿ:

  • ** ಬಣ್ಣ-ಕೋಡ್ ಮತ್ತು ಪೂರ್ವಪ್ರತ್ಯಯ ಉತ್ಪಾದನಾ ಪ್ರಾಂಪ್ಟ್‌ಗಳು (kube-ps1, psql .psqlrc):** ನಿಮ್ಮ ಶೆಲ್ ಮತ್ತು 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 ಎ ಕೊರತೆಯಿರುವ ಹೇಳಿಕೆ WHERE ಪ್ರಮುಖ ಷರತ್ತು ಅಥವಾ ಎ LIMIT.
  • ** ಆನ್ ಮಾಡಿ DeletionProtection = true ಎಲ್ಲಾ ಉತ್ಪಾದನಾ RDS ಡೇಟಾಬೇಸ್‌ಗಳು, S3 ಬಕೆಟ್‌ಗಳು ಮತ್ತು ಟೆರಾಫಾರ್ಮ್ ಸ್ಟೇಟ್‌ಫುಲ್ ಸಂಪನ್ಮೂಲಗಳಲ್ಲಿ** (lifecycle { prevent_destroy = true })
  • ** Git ಶಾಖೆಯ ರಕ್ಷಣೆ ನಿಯಮಗಳನ್ನು ಜಾರಿಗೊಳಿಸಿ main / production:** ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ Allow force pushes ಮತ್ತು Allow deletions GitHub/GitLab ನಲ್ಲಿ ಸಂರಕ್ಷಿತ ಶಾಖೆಗಳಲ್ಲಿ ಆದ್ದರಿಂದ ರೆಪೊಸಿಟರಿ ನಿರ್ವಾಹಕರು ಸಹ ಸಾಧ್ಯವಿಲ್ಲ git push --force ಗೆ main.
  • ** ಪೂರ್ವ ಬದ್ಧತೆಯ ರಹಸ್ಯ ಸ್ಕ್ಯಾನಿಂಗ್ ಕೊಕ್ಕೆಗಳನ್ನು ಸ್ಥಾಪಿಸಿ (gitleaks ಅಥವಾ trufflehog) ಮತ್ತು GitHub ಪುಶ್ ರಕ್ಷಣೆ:** ಬ್ಲಾಕ್ ಕಮಿಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ AKIA, sk_live_, ಅಥವಾ .env ಮೊದಲು ಸ್ಥಳೀಯವಾಗಿ ಮಾದರಿಗಳು git commit ಸಹ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

ಆಕಸ್ಮಿಕವಾಗಿ ಉತ್ಪಾದನಾ ಡೇಟಾಬೇಸ್ ಟೇಬಲ್ ಅನ್ನು ಕೈಬಿಟ್ಟಿದ್ದಕ್ಕಾಗಿ ಅಥವಾ ಸೈಟ್ ಸ್ಥಗಿತಕ್ಕೆ ಕಾರಣವಾದ ಕಾರಣದಿಂದ ನನ್ನನ್ನು ವಜಾಗೊಳಿಸಲಾಗುವುದೇ?

ದೋಷರಹಿತ ಸುರಕ್ಷತಾ ಸಂಸ್ಕೃತಿಯನ್ನು ಅಭ್ಯಾಸ ಮಾಡುವ ಆರೋಗ್ಯಕರ ಇಂಜಿನಿಯರಿಂಗ್ ಸಂಸ್ಥೆಗಳಲ್ಲಿ (ಆಧುನಿಕ ತಂತ್ರಜ್ಞಾನ, DevOps ಮತ್ತು SRE ತಂಡಗಳಾದ್ಯಂತ ಪ್ರಮಾಣಿತ), ಎಂಜಿನಿಯರ್‌ಗಳು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಪ್ರಾಮಾಣಿಕ ಮಾನವ ತಪ್ಪುಗಳಿಗಾಗಿ ವಜಾ ಮಾಡಲಾಗುವುದಿಲ್ಲ, ಅವರು ಘಟನೆಯನ್ನು ತಕ್ಷಣವೇ ವರದಿ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಸೇವೆಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತಾರೆ. ಜೂನಿಯರ್ ಅಥವಾ ಸೀನಿಯರ್ ಡೆವಲಪರ್‌ಗಳು ಒಂದೇ ಪರಿಶೀಲಿಸದ ಆಜ್ಞೆಯೊಂದಿಗೆ ಉತ್ಪಾದನಾ ಕೋಷ್ಟಕವನ್ನು ಬಿಡಲು ಕಚ್ಚಾ ಅನುಮತಿಗಳು ಮತ್ತು ಗಾರ್ಡ್‌ರೈಲ್‌ಗಳ ಕೊರತೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಮೂಲ ಕಾರಣ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ ಮತ್ತು ನಿಯೋಜನೆ ಸಾಧನದಲ್ಲಿನ ದೋಷವಾಗಿದೆ, ದುರುದ್ದೇಶವಲ್ಲ ಎಂದು ಎಂಜಿನಿಯರಿಂಗ್ ನಾಯಕರು ಗುರುತಿಸುತ್ತಾರೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಆ ನಿಲುಗಡೆಯನ್ನು ನೇರವಾಗಿ ಅನುಭವಿಸಿದ ಎಂಜಿನಿಯರ್ ಈಗ ಆ ವ್ಯವಸ್ಥೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ತಂಡದಲ್ಲಿ ಏಕೈಕ ಸುರಕ್ಷಿತ ವ್ಯಕ್ತಿಯಾಗಿದ್ದಾರೆ. ಡೇಟಾ ನಷ್ಟದ ಈವೆಂಟ್ ಅನ್ನು ಮುಚ್ಚಿಡಲು ಪ್ರಯತ್ನಿಸುವುದು, ಆಡಿಟ್ ಲಾಗ್‌ಗಳನ್ನು ಅಳಿಸುವುದು ಅಥವಾ ಘಟನೆಯ ತನಿಖೆಯ ಸಮಯದಲ್ಲಿ ಸುಳ್ಳು ಹೇಳುವುದು ಸತತವಾಗಿ ಮುಕ್ತಾಯಕ್ಕೆ ಕಾರಣವಾಗುವ ಏಕೈಕ ನಡವಳಿಕೆಯಾಗಿದೆ.

ನಾನು ತಕ್ಷಣವೇ ನನ್ನ ಲೈವ್ ಪ್ರೊಡಕ್ಷನ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೊಸದಾಗಿ ಮರುಸ್ಥಾಪಿಸಲಾದ ಪಾಯಿಂಟ್-ಇನ್-ಟೈಮ್ ರಿಕವರಿ (PITR) ಡೇಟಾಬೇಸ್ ನಿದರ್ಶನಕ್ಕೆ ಏಕೆ ಬದಲಾಯಿಸಬಾರದು?

ನೀವು ಆಕಸ್ಮಿಕವಾಗಿ ಒಂದೇ ಕೋಷ್ಟಕದಿಂದ ಸಾಲುಗಳನ್ನು ಅಳಿಸಿದರೆ (ಉದಾಹರಣೆಗೆ, ದಿ `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 ಈವೆಂಟ್‌ಗಳ API ("The Firehose") ಮೂಲಕ ನೈಜ ಸಮಯದಲ್ಲಿ ಪ್ರಸಾರ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಕಾನೂನುಬದ್ಧ ಭದ್ರತಾ ಆರ್ಕೈವಲ್ ಸೇವೆಗಳು (GHArchive ನಂತಹ) ಮತ್ತು ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಾದ್ಯಂತ 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 ಕಂಪ್ಯೂಟರ್ ಸೆಕ್ಯುರಿಟಿ ಇನ್ಸಿಡೆಂಟ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಗೈಡ್ ಮತ್ತು ರುಜುವಾತು ರಾಜಿ ಕಂಟೈನ್‌ಮೆಂಟ್.
  • ಅಮೆಜಾನ್ ವೆಬ್ ಸೇವೆಗಳು (AWS), ಗೂಗಲ್ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ (GCP), ಮತ್ತು ಮೈಕ್ರೋಸಾಫ್ಟ್ ಅಜುರೆ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ (ಯುನೈಟೆಡ್ ಸ್ಟೇಟ್ಸ್): RDS ಆಟೋಮೇಟೆಡ್ ಪಾಯಿಂಟ್-ಇನ್-ಟೈಮ್ ರಿಕವರಿ (PITR) ಆರ್ಕಿಟೆಕ್ಚರ್, AWS IAM ರಾಜಿಯಾದ ಪ್ರಮುಖ ಕ್ವಾರಂಟೈನ್ ನೀತಿಗಳು (AWSCompromisedKeyQuarantineV2), ಮತ್ತು S3 ಆವೃತ್ತಿ ಅಳಿಸುವಿಕೆ-ಮಾರ್ಕರ್ ರಿಕವರಿ.
  • PostgreSQL ಗ್ಲೋಬಲ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಗ್ರೂಪ್ ಮತ್ತು MySQL / ಒರಾಕಲ್ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ (ಅಂತರರಾಷ್ಟ್ರೀಯ): PostgreSQL ರೈಟ್-ಎಹೆಡ್ ಲಾಗಿಂಗ್ (WAL), MVCC ಟುಪಲ್ ಗೋಚರತೆ ಮತ್ತು MySQL ರೋ-ಬೇಸ್ಡ್ ಬೈನರಿ ಲಾಗ್ ಫ್ಲ್ಯಾಶ್‌ಬ್ಯಾಕ್ ರಿಕವರಿ.
  • Git SCM ಅಧಿಕೃತ ದಾಖಲೆ ಮತ್ತು GitHub ಭದ್ರತಾ ಲ್ಯಾಬ್ (ಅಂತರರಾಷ್ಟ್ರೀಯ): Git Reflog (git-reflog), ಡ್ಯಾಂಗ್ಲಿಂಗ್ ಆಬ್ಜೆಕ್ಟ್ ರಿಕವರಿ (git-fsck), ಇತಿಹಾಸವನ್ನು ಪುನಃ ಬರೆಯುವುದು (git-filter-repo), ಮತ್ತು ರಹಸ್ಯ ಸ್ಕ್ಯಾನಿಂಗ್ ಪುಶ್ ಪ್ರೊಟೆಕ್ಷನ್.
  • USENIX ಅಸೋಸಿಯೇಷನ್ ​​/ SREcon ಮತ್ತು Google ಸೈಟ್ ವಿಶ್ವಾಸಾರ್ಹತೆ ಇಂಜಿನಿಯರಿಂಗ್ (SRE) ಪುಸ್ತಕಗಳು (ಅಂತರರಾಷ್ಟ್ರೀಯ): ಘಟನೆಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು, ತುರ್ತು ರೋಲ್ಬ್ಯಾಕ್ ಚಿಕಿತ್ಸೆಯ ಸರದಿ ನಿರ್ಧಾರ, ಮತ್ತು ದೋಷರಹಿತ ಪೋಸ್ಟ್ಮಾರ್ಟಮ್ ಸಂಸ್ಕೃತಿ.

ಸಂಬಂಧಿತ ಮಾರ್ಗದರ್ಶಿಗಳು