ಬೇಸಿಗೆಯಲ್ಲಿ, ಖರೀದಿ ಚಟುವಟಿಕೆ ಮತ್ತು ವೆಬ್ ಯೋಜನೆಗಳ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ತೀವ್ರತೆಯು ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ ಎಂದು ಕ್ಯಾಪ್ಟನ್ ಒಬ್ವಿಯಸ್ ನಮಗೆ ಹೇಳುತ್ತಾನೆ. ಸರಳವಾಗಿ ಏಕೆಂದರೆ ಐಟಿ ತಜ್ಞರು ಸಹ ಕೆಲವೊಮ್ಮೆ ರಜೆಯ ಮೇಲೆ ಹೋಗುತ್ತಾರೆ. ಮತ್ತು CTO ಕೂಡ. ಕಚೇರಿಯಲ್ಲಿ ಉಳಿಯುವವರಿಗೆ ಇದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ, ಆದರೆ ಅದು ಈಗ ವಿಷಯವಲ್ಲ: ಬಹುಶಃ ಅದಕ್ಕಾಗಿಯೇ ಬೇಸಿಗೆಯಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೀಸಲಾತಿ ಯೋಜನೆಯ ಬಗ್ಗೆ ನಿಧಾನವಾಗಿ ಯೋಚಿಸಲು ಮತ್ತು ಅದನ್ನು ಸುಧಾರಿಸಲು ಯೋಜನೆಯನ್ನು ರೂಪಿಸಲು ಉತ್ತಮ ಅವಧಿಯಾಗಿದೆ. ಮತ್ತು ಯೆಗೊರ್ ಆಂಡ್ರೀವ್ ಅವರ ಅನುಭವ , ಸಮ್ಮೇಳನದಲ್ಲಿ ಅವರು ಮಾತನಾಡಿದರು .
ಬ್ಯಾಕಪ್ ಸೈಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವಾಗ ನೀವು ಬೀಳಬಹುದಾದ ಹಲವಾರು ಅಪಾಯಗಳಿವೆ. ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಸಿಕ್ಕಿಹಾಕಿಕೊಳ್ಳುವುದು ಸಂಪೂರ್ಣವಾಗಿ ಅಸಾಧ್ಯ. ಮತ್ತು ಈ ಎಲ್ಲದರಲ್ಲೂ ನಮ್ಮನ್ನು ಹಾಳುಮಾಡುವುದು, ಇತರ ಅನೇಕ ವಿಷಯಗಳಂತೆ, ಪರಿಪೂರ್ಣತೆ ಮತ್ತು ... ಸೋಮಾರಿತನ. ನಾವು ಎಲ್ಲವನ್ನೂ, ಎಲ್ಲವನ್ನೂ, ಎಲ್ಲವನ್ನೂ ಸಂಪೂರ್ಣವಾಗಿ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ, ಆದರೆ ನಾವು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮಾಡಬೇಕಾಗಿಲ್ಲ! ನೀವು ಕೆಲವು ಕೆಲಸಗಳನ್ನು ಮಾತ್ರ ಮಾಡಬೇಕಾಗಿದೆ, ಆದರೆ ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಮಾಡಿ, ಅವುಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ ಇದರಿಂದ ಅವು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ವೈಫಲ್ಯವು ಕೆಲವು ರೀತಿಯ ಮೋಜಿನ, ಮೋಜಿನ ವಿಷಯವಲ್ಲ; ಇದು ನಿಖರವಾಗಿ ಒಂದು ವಿಷಯವನ್ನು ಮಾಡಬೇಕಾದ ವಿಷಯವಾಗಿದೆ - ಅಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಿ ಇದರಿಂದ ಸೇವೆ, ಕಂಪನಿಯು ಕಡಿಮೆ ಹಣವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ಮತ್ತು ಎಲ್ಲಾ ಮೀಸಲಾತಿ ವಿಧಾನಗಳಲ್ಲಿ, ಈ ಕೆಳಗಿನ ಸನ್ನಿವೇಶದಲ್ಲಿ ಯೋಚಿಸಲು ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ: ಹಣ ಎಲ್ಲಿದೆ?
ಮೊದಲ ಬಲೆ: ನಾವು ದೊಡ್ಡ, ವಿಶ್ವಾಸಾರ್ಹ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಿದಾಗ ಮತ್ತು ಪುನರಾವರ್ತನೆಯಲ್ಲಿ ತೊಡಗಿದಾಗ, ನಾವು ಅಪಘಾತಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆಗೊಳಿಸುತ್ತೇವೆ. ಇದು ಭಯಾನಕ ತಪ್ಪು ಕಲ್ಪನೆ. ನಾವು ಪುನರುಜ್ಜೀವನದಲ್ಲಿ ತೊಡಗಿದಾಗ, ನಾವು ಅಪಘಾತಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಸಾಧ್ಯತೆಯಿದೆ. ಮತ್ತು ನಾವು ಎಲ್ಲವನ್ನೂ ಸರಿಯಾಗಿ ಮಾಡಿದರೆ, ಒಟ್ಟಾಗಿ ನಾವು ಅಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತೇವೆ. ಹೆಚ್ಚು ಅಪಘಾತಗಳು ಸಂಭವಿಸುತ್ತವೆ, ಆದರೆ ಅವು ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ. ಮೀಸಲಾತಿ ಎಂದರೇನು? - ಇದು ವ್ಯವಸ್ಥೆಯ ತೊಡಕು. ಯಾವುದೇ ತೊಡಕು ಕೆಟ್ಟದಾಗಿದೆ: ನಾವು ಹೆಚ್ಚು ಕಾಗ್‌ಗಳು, ಹೆಚ್ಚಿನ ಗೇರ್‌ಗಳು, ಒಂದು ಪದದಲ್ಲಿ, ಹೆಚ್ಚಿನ ಅಂಶಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಮತ್ತು, ಆದ್ದರಿಂದ, ಸ್ಥಗಿತದ ಹೆಚ್ಚಿನ ಅವಕಾಶ. ಮತ್ತು ಅವರು ನಿಜವಾಗಿಯೂ ಮುರಿಯುತ್ತಾರೆ. ಮತ್ತು ಅವು ಹೆಚ್ಚಾಗಿ ಮುರಿಯುತ್ತವೆ. ಒಂದು ಸರಳ ಉದಾಹರಣೆ: ನಾವು PHP ಮತ್ತು MySQL ನೊಂದಿಗೆ ವೆಬ್‌ಸೈಟ್ ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ. ಮತ್ತು ಅದನ್ನು ತುರ್ತಾಗಿ ಕಾಯ್ದಿರಿಸಬೇಕಾಗಿದೆ.
Shtosh (c) ನಾವು ಎರಡನೇ ಸೈಟ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ, ಒಂದೇ ರೀತಿಯ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ ... ಸಂಕೀರ್ಣತೆಯು ಎರಡು ಪಟ್ಟು ಹೆಚ್ಚಾಗುತ್ತದೆ - ನಾವು ಎರಡು ಘಟಕಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಒಂದು ಸೈಟ್ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲು ನಾವು ನಿರ್ದಿಷ್ಟ ತರ್ಕವನ್ನು ಸಹ ಹೊರತರುತ್ತೇವೆ - ಅಂದರೆ, ಡೇಟಾ ಪುನರಾವರ್ತನೆ, ಸ್ಥಿರ ಡೇಟಾವನ್ನು ನಕಲಿಸುವುದು ಇತ್ಯಾದಿ. ಆದ್ದರಿಂದ, ಪ್ರತಿಕೃತಿ ತರ್ಕವು ಸಾಮಾನ್ಯವಾಗಿ ಬಹಳ ಸಂಕೀರ್ಣವಾಗಿದೆ ಮತ್ತು ಆದ್ದರಿಂದ, ಸಿಸ್ಟಮ್ನ ಒಟ್ಟು ಸಂಕೀರ್ಣತೆಯು 2 ಅಲ್ಲ, ಆದರೆ 3, 5, 10 ಪಟ್ಟು ಹೆಚ್ಚಾಗಿರುತ್ತದೆ.
ಎರಡನೇ ಬಲೆ: ನಾವು ನಿಜವಾಗಿಯೂ ದೊಡ್ಡ ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಿದಾಗ, ನಾವು ಕೊನೆಯಲ್ಲಿ ಏನನ್ನು ಪಡೆಯಲು ಬಯಸುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಅತಿರೇಕವಾಗಿ ಭಾವಿಸುತ್ತೇವೆ. Voila: ನಾವು ಯಾವುದೇ ಅಲಭ್ಯತೆ ಇಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸೂಪರ್-ವಿಶ್ವಾಸಾರ್ಹ ವ್ಯವಸ್ಥೆಯನ್ನು ಪಡೆಯಲು ಬಯಸುತ್ತೇವೆ, ಅರ್ಧ ಸೆಕೆಂಡಿನಲ್ಲಿ ಬದಲಾಯಿಸುತ್ತದೆ (ಅಥವಾ ಇನ್ನೂ ಉತ್ತಮ, ತಕ್ಷಣವೇ), ಮತ್ತು ನಾವು ಕನಸುಗಳನ್ನು ನನಸಾಗಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಆದರೆ ಇಲ್ಲಿ ಒಂದು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವೂ ಇದೆ: ಅಪೇಕ್ಷಿತ ಸ್ವಿಚಿಂಗ್ ಸಮಯ ಕಡಿಮೆ, ಸಿಸ್ಟಮ್ ತರ್ಕವು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತದೆ. ಈ ತರ್ಕವನ್ನು ನಾವು ಎಷ್ಟು ಸಂಕೀರ್ಣಗೊಳಿಸಬೇಕೋ ಅಷ್ಟು ಹೆಚ್ಚಾಗಿ ವ್ಯವಸ್ಥೆಯು ಮುರಿದುಹೋಗುತ್ತದೆ. ಮತ್ತು ನೀವು ತುಂಬಾ ಅಹಿತಕರ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳಬಹುದು: ಅಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು ನಮ್ಮ ಎಲ್ಲಾ ಶಕ್ತಿಯಿಂದ ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ನಾವು ಎಲ್ಲವನ್ನೂ ಹೆಚ್ಚು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಏನಾದರೂ ತಪ್ಪಾದಾಗ, ಅಲಭ್ಯತೆಯು ದೀರ್ಘವಾಗಿರುತ್ತದೆ. ಇಲ್ಲಿ ನೀವು ಆಗಾಗ್ಗೆ ಯೋಚಿಸುತ್ತೀರಿ: ಸರಿ... ಕಾಯ್ದಿರಿಸದಿರುವುದು ಉತ್ತಮ. ಇದು ಏಕಾಂಗಿಯಾಗಿ ಮತ್ತು ಅರ್ಥವಾಗುವ ಅಲಭ್ಯತೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದರೆ ಉತ್ತಮ.
ನೀವು ಇದನ್ನು ಹೇಗೆ ಹೋರಾಡಬಹುದು? ನಮಗೆ ನಾವೇ ಸುಳ್ಳು ಹೇಳುವುದನ್ನು ನಿಲ್ಲಿಸಬೇಕು, ನಾವು ಈಗ ಇಲ್ಲಿ ಆಕಾಶನೌಕೆಯನ್ನು ನಿರ್ಮಿಸಲಿದ್ದೇವೆ ಎಂದು ನಮ್ಮನ್ನು ಹೊಗಳಿಕೊಳ್ಳುವುದನ್ನು ನಿಲ್ಲಿಸಬೇಕು, ಆದರೆ ಯೋಜನೆಯು ಎಷ್ಟು ಸಮಯದವರೆಗೆ ಸುಳ್ಳು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಸಮರ್ಪಕವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ. ಮತ್ತು ಈ ಗರಿಷ್ಠ ಸಮಯಕ್ಕೆ, ನಮ್ಮ ಸಿಸ್ಟಮ್ನ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ನಾವು ಯಾವ ವಿಧಾನಗಳನ್ನು ಬಳಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಾವು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ.
ಇದು "w ನಿಂದ ಕಥೆಗಳು" ... ಜೀವನದಿಂದ, ಸಹಜವಾಗಿ ಸಮಯ.
ಉದಾಹರಣೆ ಸಂಖ್ಯೆ ಒಂದು
N. ನಗರದಲ್ಲಿ ಪೈಪ್ ರೋಲಿಂಗ್ ಪ್ಲಾಂಟ್ ನಂ. 1 ಗಾಗಿ ವ್ಯಾಪಾರ ಕಾರ್ಡ್ ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಇದು ದೊಡ್ಡ ಅಕ್ಷರಗಳಲ್ಲಿ ಹೇಳುತ್ತದೆ - ಪೈಪ್ ರೋಲಿಂಗ್ ಪ್ಲಾಂಟ್ ಸಂಖ್ಯೆ 1. ಕೆಳಗೆ ಸ್ಲೋಗನ್ ಇದೆ: "ನಮ್ಮ ಪೈಪ್‌ಗಳು ಎನ್‌ನಲ್ಲಿ ದುಂಡಗಿನ ಪೈಪ್‌ಗಳಾಗಿವೆ." ಮತ್ತು ಕೆಳಗೆ CEO ಅವರ ಫೋನ್ ಸಂಖ್ಯೆ ಮತ್ತು ಅವರ ಹೆಸರು. ನೀವು ಕಾಯ್ದಿರಿಸಬೇಕೆಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ - ಇದು ಬಹಳ ಮುಖ್ಯವಾದ ವಿಷಯ! ಅದು ಏನನ್ನು ಒಳಗೊಂಡಿದೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಪ್ರಾರಂಭಿಸೋಣ. Html-ಸ್ಟ್ಯಾಟಿಕ್ಸ್ - ಅಂದರೆ, ಜನರಲ್ ಮ್ಯಾನೇಜರ್ ತನ್ನ ಪಾಲುದಾರರೊಂದಿಗೆ ಸ್ನಾನಗೃಹದ ಮೇಜಿನ ಬಳಿ ಕೆಲವು ರೀತಿಯ ಮುಂದಿನ ಒಪ್ಪಂದವನ್ನು ಚರ್ಚಿಸುತ್ತಿರುವ ಒಂದೆರಡು ಚಿತ್ರಗಳು. ನಾವು ಅಲಭ್ಯತೆಯ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಇದು ಮನಸ್ಸಿಗೆ ಬರುತ್ತದೆ: ನೀವು ಐದು ನಿಮಿಷಗಳ ಕಾಲ ಅಲ್ಲಿ ಮಲಗಬೇಕು, ಇನ್ನು ಮುಂದೆ ಇಲ್ಲ. ತದನಂತರ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ: ನಮ್ಮ ಈ ಸೈಟ್ನಿಂದ ಸಾಮಾನ್ಯವಾಗಿ ಎಷ್ಟು ಮಾರಾಟಗಳಿವೆ? ಎಷ್ಟು-ಎಷ್ಟು? "ಶೂನ್ಯ" ಎಂದರೆ ಏನು? ಮತ್ತು ಇದರರ್ಥ: ಏಕೆಂದರೆ ಜನರಲ್ ಕಳೆದ ವರ್ಷ ಎಲ್ಲಾ ನಾಲ್ಕು ವಹಿವಾಟುಗಳನ್ನು ಒಂದೇ ಟೇಬಲ್‌ನಲ್ಲಿ ಮಾಡಿದರು, ಅದೇ ಜನರೊಂದಿಗೆ ಅವರು ಸ್ನಾನಗೃಹಕ್ಕೆ ಹೋಗಿ ಮೇಜಿನ ಬಳಿ ಕುಳಿತುಕೊಳ್ಳುತ್ತಾರೆ. ಮತ್ತು ಸೈಟ್ ಒಂದು ದಿನ ಕುಳಿತಿದ್ದರೂ ಸಹ, ಭಯಾನಕ ಏನೂ ಸಂಭವಿಸುವುದಿಲ್ಲ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ.
ಪರಿಚಯಾತ್ಮಕ ಮಾಹಿತಿಯ ಆಧಾರದ ಮೇಲೆ, ಈ ಕಥೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಒಂದು ದಿನವಿದೆ. ಪುನರುಜ್ಜೀವನದ ಯೋಜನೆಯ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸೋಣ. ಮತ್ತು ಈ ಉದಾಹರಣೆಗಾಗಿ ನಾವು ಹೆಚ್ಚು ಆದರ್ಶ ಪುನರುಕ್ತಿ ಯೋಜನೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ: ನಾವು ಪುನರುಕ್ತಿಯನ್ನು ಬಳಸುವುದಿಲ್ಲ. ಈ ಸಂಪೂರ್ಣ ವಿಷಯವನ್ನು ಯಾವುದೇ ನಿರ್ವಾಹಕರು ಹೊಗೆ ವಿರಾಮಗಳೊಂದಿಗೆ ಅರ್ಧ ಗಂಟೆಯಲ್ಲಿ ಎತ್ತಬಹುದು. ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ, ಫೈಲ್ಗಳನ್ನು ಸೇರಿಸಿ - ಅದು ಇಲ್ಲಿದೆ. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಯಾವುದರ ಮೇಲೂ ನಿಗಾ ಇಡಬೇಕಿಲ್ಲ, ಯಾವುದಕ್ಕೂ ವಿಶೇಷ ಗಮನ ಕೊಡಬೇಕಿಲ್ಲ. ಅಂದರೆ, ಉದಾಹರಣೆ ಸಂಖ್ಯೆ ಒಂದರಿಂದ ತೀರ್ಮಾನವು ಸಾಕಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿದೆ: ಕಾಯ್ದಿರಿಸಬೇಕಾದ ಅಗತ್ಯವಿಲ್ಲದ ಸೇವೆಗಳನ್ನು ಕಾಯ್ದಿರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.
ಉದಾಹರಣೆ ಸಂಖ್ಯೆ ಎರಡು
ಕಂಪನಿ ಬ್ಲಾಗ್: ವಿಶೇಷವಾಗಿ ತರಬೇತಿ ಪಡೆದ ಜನರು ಅಲ್ಲಿ ಸುದ್ದಿ ಬರೆಯುತ್ತಾರೆ, ನಾವು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಪ್ರದರ್ಶನದಲ್ಲಿ ಭಾಗವಹಿಸಿದ್ದೇವೆ, ಆದರೆ ನಾವು ಮತ್ತೊಂದು ಹೊಸ ಉತ್ಪನ್ನವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದ್ದೇವೆ, ಇತ್ಯಾದಿ. ಇದು ವರ್ಡ್ಪ್ರೆಸ್, ಸಣ್ಣ ಡೇಟಾಬೇಸ್ ಮತ್ತು ಸ್ವಲ್ಪ ಸ್ಥಿರವಾದ ಸ್ಟ್ಯಾಂಡರ್ಡ್ PHP ಎಂದು ಹೇಳೋಣ. ಸಹಜವಾಗಿ, ನೀವು ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲೂ ಮಲಗಬಾರದು ಎಂಬುದು ಮತ್ತೆ ನೆನಪಿಗೆ ಬರುತ್ತದೆ - “ಐದು ನಿಮಿಷಗಳಿಗಿಂತ ಹೆಚ್ಚಿಲ್ಲ!” ಅಷ್ಟೆ. ಆದರೆ ಮುಂದೆ ಯೋಚಿಸೋಣ. ಈ ಬ್ಲಾಗ್ ಏನು ಮಾಡುತ್ತದೆ? ಜನರು ಯಾಂಡೆಕ್ಸ್‌ನಿಂದ, Google ನಿಂದ ಕೆಲವು ಪ್ರಶ್ನೆಗಳ ಆಧಾರದ ಮೇಲೆ ಸಾವಯವವಾಗಿ ಬರುತ್ತಾರೆ. ಕುವೆಂಪು. ಮಾರಾಟಕ್ಕೂ ಇದಕ್ಕೂ ಏನಾದರೂ ಸಂಬಂಧವಿದೆಯೇ? ಎಪಿಫ್ಯಾನಿ: ನಿಜವಾಗಿಯೂ ಅಲ್ಲ. ಜಾಹೀರಾತು ಸಂಚಾರವು ಮುಖ್ಯ ಸೈಟ್‌ಗೆ ಹೋಗುತ್ತದೆ, ಅದು ಬೇರೆ ಯಂತ್ರದಲ್ಲಿದೆ. ಬುಕಿಂಗ್ ಯೋಜನೆಯ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸೋಣ. ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ, ಅದನ್ನು ಒಂದೆರಡು ಗಂಟೆಗಳಲ್ಲಿ ಬೆಳೆಸಬೇಕಾಗಿದೆ ಮತ್ತು ಇದಕ್ಕಾಗಿ ತಯಾರಿ ಮಾಡುವುದು ಒಳ್ಳೆಯದು. ಮತ್ತೊಂದು ಡೇಟಾ ಕೇಂದ್ರದಿಂದ ಯಂತ್ರವನ್ನು ತೆಗೆದುಕೊಂಡು, ಪರಿಸರವನ್ನು ಅದರ ಮೇಲೆ ಸುತ್ತಿಕೊಳ್ಳುವುದು ಸಮಂಜಸವಾಗಿದೆ, ಅಂದರೆ ವೆಬ್ ಸರ್ವರ್, PHP, WordPress, MySQL ಮತ್ತು ಅದನ್ನು ಅಲ್ಲಿಯೇ ಬಿಡುವುದು. ಎಲ್ಲವೂ ಮುರಿದುಹೋಗಿದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡ ಕ್ಷಣದಲ್ಲಿ, ನಾವು ಎರಡು ಕೆಲಸಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ - mysql ಡಂಪ್ ಅನ್ನು 50 ಮೀಟರ್ ಸುತ್ತಿಕೊಳ್ಳಿ, ಅದು ಒಂದು ನಿಮಿಷದಲ್ಲಿ ಅಲ್ಲಿಗೆ ಹಾರುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿ ಬ್ಯಾಕಪ್‌ನಿಂದ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಚಿತ್ರಗಳನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ. ಇದೂ ಇಲ್ಲ, ದೇವರೇ ಬಲ್ಲ. ಹೀಗಾಗಿ, ಅರ್ಧ ಗಂಟೆಯಲ್ಲಿ ಇಡೀ ವಿಷಯವು ಏರುತ್ತದೆ. ಪ್ರತಿಕೃತಿ ಇಲ್ಲ, ಅಥವಾ ದೇವರು ನನ್ನನ್ನು ಕ್ಷಮಿಸಿ, ಸ್ವಯಂಚಾಲಿತ ವಿಫಲತೆ. ತೀರ್ಮಾನ: ಬ್ಯಾಕ್ಅಪ್ನಿಂದ ನಾವು ತ್ವರಿತವಾಗಿ ಏನನ್ನು ಹೊರತರಬಹುದು ಎಂಬುದನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ.
ಉದಾಹರಣೆ ಸಂಖ್ಯೆ ಮೂರು, ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ
ಅಂತರ್ಜಾಲ ಮಾರುಕಟ್ಟೆ. ತೆರೆದ ಹೃದಯದೊಂದಿಗೆ ಪಿಎಚ್ಪಿ ಸ್ವಲ್ಪ ಟ್ವೀಕ್ ಮಾಡಲಾಗಿದೆ, ಮೈಸ್ಕ್ಎಲ್ ಘನ ನೆಲೆಯನ್ನು ಹೊಂದಿದೆ. ಸಾಕಷ್ಟು ಸ್ಥಿರವಾಗಿದೆ (ಎಲ್ಲಾ ನಂತರ, ಆನ್‌ಲೈನ್ ಸ್ಟೋರ್ ಸುಂದರವಾದ ಎಚ್‌ಡಿ ಚಿತ್ರಗಳನ್ನು ಮತ್ತು ಎಲ್ಲಾ ವಿಷಯವನ್ನು ಹೊಂದಿದೆ), ಸೆಷನ್‌ಗಾಗಿ ರೆಡಿಸ್ ಮತ್ತು ಹುಡುಕಾಟಕ್ಕಾಗಿ ಎಲಾಸ್ಟಿಕ್‌ಸರ್ಚ್. ನಾವು ಅಲಭ್ಯತೆಯ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಮತ್ತು ಇಲ್ಲಿ, ಸಹಜವಾಗಿ, ಆನ್‌ಲೈನ್ ಸ್ಟೋರ್ ಒಂದು ದಿನ ನೋವುರಹಿತವಾಗಿ ಮಲಗಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಎಲ್ಲಾ ನಂತರ, ಅದು ಮುಂದೆ ಇರುತ್ತದೆ, ನಾವು ಹೆಚ್ಚು ಹಣವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ. ವೇಗವನ್ನು ಹೆಚ್ಚಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಎಷ್ಟು? ನಾವು ಒಂದು ಗಂಟೆ ಮಲಗಿದರೆ ಯಾರೂ ಹುಚ್ಚರಾಗುವುದಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಹೌದು, ನಾವು ಏನನ್ನಾದರೂ ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ, ಆದರೆ ನಾವು ಕಷ್ಟಪಟ್ಟು ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಅದು ಕೆಟ್ಟದಾಗುತ್ತದೆ. ಪ್ರತಿ ಗಂಟೆಗೆ ಅನುಮತಿಸಲಾದ ಅಲಭ್ಯತೆಯ ಯೋಜನೆಯನ್ನು ನಾವು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೇವೆ.
ಇದೆಲ್ಲವನ್ನೂ ಹೇಗೆ ಮೀಸಲಿಡಲು ಸಾಧ್ಯ? ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ನಿಮಗೆ ಕಾರು ಬೇಕು: ಒಂದು ಗಂಟೆ ಸಮಯವು ಸ್ವಲ್ಪ ಕಡಿಮೆ. MySQL: ಇಲ್ಲಿ ನಮಗೆ ಈಗಾಗಲೇ ಪುನರಾವರ್ತನೆ, ಲೈವ್ ರೆಪ್ಲಿಕೇಶನ್ ಅಗತ್ಯವಿದೆ, ಏಕೆಂದರೆ ಒಂದು ಗಂಟೆಯಲ್ಲಿ 100 GB ಹೆಚ್ಚಾಗಿ ಡಂಪ್‌ಗೆ ಸೇರಿಸಲಾಗುವುದಿಲ್ಲ. ಅಂಕಿಅಂಶಗಳು, ಚಿತ್ರಗಳು: ಮತ್ತೆ, ಒಂದು ಗಂಟೆಯಲ್ಲಿ 500 GB ಸೇರಿಸಲು ಸಮಯವಿಲ್ಲದಿರಬಹುದು. ಆದ್ದರಿಂದ, ಈಗಿನಿಂದಲೇ ಚಿತ್ರಗಳನ್ನು ನಕಲಿಸುವುದು ಉತ್ತಮ. ರೆಡಿಸ್: ಇಲ್ಲಿ ವಿಷಯಗಳು ಆಸಕ್ತಿದಾಯಕವಾಗುತ್ತವೆ. ರೆಡಿಸ್‌ನಲ್ಲಿ, ಸೆಷನ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ - ನಾವು ಅದನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಹೂಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ಏಕೆಂದರೆ ಇದು ತುಂಬಾ ಒಳ್ಳೆಯದಲ್ಲ: ಎಲ್ಲಾ ಬಳಕೆದಾರರನ್ನು ಲಾಗ್ ಔಟ್ ಮಾಡಲಾಗುತ್ತದೆ, ಅವರ ಬುಟ್ಟಿಗಳು ಖಾಲಿಯಾಗುತ್ತವೆ, ಇತ್ಯಾದಿ. ಜನರು ತಮ್ಮ ಬಳಕೆದಾರಹೆಸರು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಮರು-ನಮೂದಿಸಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅನೇಕ ಜನರು ದೂರ ಹೋಗಬಹುದು ಮತ್ತು ಖರೀದಿಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುವುದಿಲ್ಲ. ಮತ್ತೊಮ್ಮೆ, ಪರಿವರ್ತನೆಗಳು ಕಡಿಮೆಯಾಗುತ್ತವೆ. ಮತ್ತೊಂದೆಡೆ, ರೆಡಿಸ್ ನೇರವಾಗಿ ಅಪ್-ಟು-ಡೇಟ್ ಆಗಿದೆ, ಕೊನೆಯದಾಗಿ ಲಾಗ್-ಇನ್ ಮಾಡಿದ ಬಳಕೆದಾರರಿಗೆ ಬಹುಶಃ ಅಗತ್ಯವಿಲ್ಲ. ಮತ್ತು ರೆಡಿಸ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ನಿನ್ನೆಯಿಂದ ಬ್ಯಾಕ್ಅಪ್ನಿಂದ ಮರುಸ್ಥಾಪಿಸುವುದು ಉತ್ತಮ ರಾಜಿ, ಅಥವಾ, ನೀವು ಪ್ರತಿ ಗಂಟೆಗೆ ಮಾಡಿದರೆ, ಒಂದು ಗಂಟೆಯ ಹಿಂದೆ. ಅದೃಷ್ಟವಶಾತ್, ಅದನ್ನು ಬ್ಯಾಕ್ಅಪ್ನಿಂದ ಮರುಸ್ಥಾಪಿಸುವುದು ಎಂದರೆ ಒಂದು ಫೈಲ್ ಅನ್ನು ನಕಲಿಸುವುದು. ಮತ್ತು ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಕಥೆ Elasticsearch ಆಗಿದೆ. MySQL ಪ್ರತಿಕೃತಿಯನ್ನು ಯಾರು ತೆಗೆದುಕೊಂಡಿದ್ದಾರೆ? ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ ಪ್ರತಿಕೃತಿಯನ್ನು ಯಾರು ತೆಗೆದುಕೊಂಡಿದ್ದಾರೆ? ಮತ್ತು ಯಾರಿಗೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ನಂತರ ಕೆಲಸ ಮಾಡಿದೆ? ನನ್ನ ಪ್ರಕಾರ ನಾವು ನಮ್ಮ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಘಟಕವನ್ನು ನೋಡುತ್ತೇವೆ. ಇದು ಉಪಯುಕ್ತವೆಂದು ತೋರುತ್ತದೆ - ಆದರೆ ಇದು ಸಂಕೀರ್ಣವಾಗಿದೆ.
ನಮ್ಮ ಸಹ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ ಅನುಭವವಿಲ್ಲ ಎಂಬ ಅರ್ಥದಲ್ಲಿ ಸಂಕೀರ್ಣವಾಗಿದೆ. ಅಥವಾ ನಕಾರಾತ್ಮಕ ಅನುಭವವಿದೆ. ಅಥವಾ ಇದು ಇನ್ನೂ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು ಅಥವಾ ಕಚ್ಚಾತೆಯೊಂದಿಗೆ ಸಾಕಷ್ಟು ಹೊಸ ತಂತ್ರಜ್ಞಾನವಾಗಿದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ನಾವು ಯೋಚಿಸುತ್ತೇವೆ... ಡ್ಯಾಮ್, ಎಲಾಸ್ಟಿಕ್ ಕೂಡ ಆರೋಗ್ಯಕರವಾಗಿದೆ, ಬ್ಯಾಕ್ಅಪ್ನಿಂದ ಅದನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ನಾನು ಏನು ಮಾಡಬೇಕು? ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಎಲಾಸ್ಟಿಕ್ ಅನ್ನು ಹುಡುಕಾಟಕ್ಕಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ನಮ್ಮ ಆನ್‌ಲೈನ್ ಸ್ಟೋರ್ ಹೇಗೆ ಮಾರಾಟವಾಗುತ್ತದೆ? ನಾವು ಮಾರಾಟಗಾರರ ಬಳಿಗೆ ಹೋಗಿ ಜನರು ಎಲ್ಲಿಂದ ಬರುತ್ತಾರೆ ಎಂದು ಕೇಳುತ್ತೇವೆ. ಅವರು ಉತ್ತರಿಸುತ್ತಾರೆ: "ಯಾಂಡೆಕ್ಸ್ ಮಾರುಕಟ್ಟೆಯಿಂದ 90% ನೇರವಾಗಿ ಉತ್ಪನ್ನ ಕಾರ್ಡ್ಗೆ ಬರುತ್ತವೆ." ಮತ್ತು ಅವರು ಅದನ್ನು ಖರೀದಿಸುತ್ತಾರೆ ಅಥವಾ ಇಲ್ಲ. ಆದ್ದರಿಂದ, 10% ಬಳಕೆದಾರರಿಂದ ಹುಡುಕಾಟ ಅಗತ್ಯವಿದೆ. ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಪುನರಾವರ್ತನೆಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದು, ವಿಶೇಷವಾಗಿ ವಿವಿಧ ವಲಯಗಳಲ್ಲಿನ ವಿಭಿನ್ನ ಡೇಟಾ ಕೇಂದ್ರಗಳ ನಡುವೆ, ನಿಜವಾಗಿಯೂ ಬಹಳಷ್ಟು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೊಂದಿದೆ. ಯಾವ ನಿರ್ಗಮನ? ನಾವು ಕಾಯ್ದಿರಿಸಿದ ಸೈಟ್ನಿಂದ ಸ್ಥಿತಿಸ್ಥಾಪಕವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಅದರೊಂದಿಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ವಿಷಯವು ಎಳೆದರೆ, ನಾವು ಬಹುಶಃ ಅದನ್ನು ಒಂದು ದಿನ ಎತ್ತುತ್ತೇವೆ, ಆದರೆ ಇದು ಖಚಿತವಾಗಿಲ್ಲ. ವಾಸ್ತವವಾಗಿ, ತೀರ್ಮಾನವು ಒಂದೇ ಆಗಿರುತ್ತದೆ, ಪ್ಲಸ್ ಅಥವಾ ಮೈನಸ್: ನಾವು ಮತ್ತೆ, ಹಣದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದ ಸೇವೆಗಳನ್ನು ಕಾಯ್ದಿರಿಸುವುದಿಲ್ಲ. ರೇಖಾಚಿತ್ರವನ್ನು ಸರಳವಾಗಿಡಲು.
ಉದಾಹರಣೆ ಸಂಖ್ಯೆ ನಾಲ್ಕು, ಇನ್ನೂ ಹೆಚ್ಚು ಕಷ್ಟ
ಇಂಟಿಗ್ರೇಟರ್: ಹೂವುಗಳನ್ನು ಮಾರಾಟ ಮಾಡುವುದು, ಟ್ಯಾಕ್ಸಿಗೆ ಕರೆ ಮಾಡುವುದು, ಸರಕುಗಳನ್ನು ಮಾರಾಟ ಮಾಡುವುದು, ಸಾಮಾನ್ಯವಾಗಿ, ಯಾವುದಾದರೂ. ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಬಳಕೆದಾರರಿಗೆ 24/7 ಕೆಲಸ ಮಾಡುವ ಗಂಭೀರ ವಿಷಯ. ಪೂರ್ಣ ಪ್ರಮಾಣದ ಆಸಕ್ತಿದಾಯಕ ಸ್ಟಾಕ್ನೊಂದಿಗೆ, ಅಲ್ಲಿ ಆಸಕ್ತಿದಾಯಕ ನೆಲೆಗಳು, ಪರಿಹಾರಗಳು, ಹೆಚ್ಚಿನ ಹೊರೆ, ಮತ್ತು ಮುಖ್ಯವಾಗಿ, 5 ನಿಮಿಷಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಮಲಗಲು ನೋವುಂಟುಮಾಡುತ್ತದೆ. ಜನರು ಖರೀದಿಸುವುದಿಲ್ಲ ಎಂಬ ಕಾರಣದಿಂದಾಗಿ ಮಾತ್ರವಲ್ಲ, ಆದರೆ ಈ ವಿಷಯವು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ಜನರು ನೋಡುತ್ತಾರೆ, ಅವರು ಅಸಮಾಧಾನಗೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಹಿಂತಿರುಗಿ ಬರದಿರಬಹುದು.
ಸರಿ. ಐದು ನಿಮಿಷ. ಇದರ ಬಗ್ಗೆ ನಾವು ಏನು ಮಾಡಲಿದ್ದೇವೆ? ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು, ವಯಸ್ಕರಂತೆ, ಎಲ್ಲವನ್ನೂ ಪುನರಾವರ್ತಿಸುವ ಮೂಲಕ ನಿಜವಾದ ಬ್ಯಾಕಪ್ ಸೈಟ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಎಲ್ಲಾ ಹಣವನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಬಹುಶಃ ಈ ಸೈಟ್‌ಗೆ ಬದಲಾಯಿಸುವುದನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದು. ಮತ್ತು ಇದರ ಜೊತೆಗೆ, ನೀವು ಒಂದು ಪ್ರಮುಖ ವಿಷಯವನ್ನು ಮಾಡಲು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು: ವಾಸ್ತವವಾಗಿ, ಸ್ವಿಚಿಂಗ್ ನಿಯಮಗಳನ್ನು ಬರೆಯಿರಿ. ನೀವು ಎಲ್ಲವನ್ನೂ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಂದಿದ್ದರೂ ಸಹ ನಿಯಮಗಳು ತುಂಬಾ ಸರಳವಾಗಿರುತ್ತದೆ. ಸರಣಿಯಿಂದ “ಅಂತಹ ಮತ್ತು ಅಂತಹ ಅನ್ಸಿಬಲ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರನ್ ಮಾಡಿ”, “ಮಾರ್ಗ 53 ರಲ್ಲಿ ಅಂತಹ ಮತ್ತು ಅಂತಹ ಚೆಕ್‌ಬಾಕ್ಸ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿ” ಮತ್ತು ಹೀಗೆ - ಆದರೆ ಇದು ಕೆಲವು ರೀತಿಯ ಕ್ರಿಯೆಗಳ ನಿಖರವಾದ ಪಟ್ಟಿಯಾಗಿರಬೇಕು.
ಮತ್ತು ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿ ತೋರುತ್ತದೆ. ಪ್ರತಿಕೃತಿಯನ್ನು ಬದಲಾಯಿಸುವುದು ಕ್ಷುಲ್ಲಕ ಕಾರ್ಯವಾಗಿದೆ, ಅಥವಾ ಅದು ಸ್ವತಃ ಬದಲಾಯಿಸುತ್ತದೆ. DNS ನಲ್ಲಿ ಡೊಮೇನ್ ಹೆಸರನ್ನು ಪುನಃ ಬರೆಯುವುದು ಅದೇ ಸರಣಿಯಿಂದ ಬಂದಿದೆ. ತೊಂದರೆ ಏನೆಂದರೆ, ಅಂತಹ ಯೋಜನೆಯು ವಿಫಲವಾದಾಗ, ಪ್ಯಾನಿಕ್ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರಬಲವಾದ, ಗಡ್ಡಧಾರಿ ನಿರ್ವಾಹಕರು ಸಹ ಇದಕ್ಕೆ ಒಳಗಾಗಬಹುದು. ಸ್ಪಷ್ಟ ಸೂಚನೆಗಳಿಲ್ಲದೆ "ಟರ್ಮಿನಲ್ ತೆರೆಯಿರಿ, ಇಲ್ಲಿಗೆ ಬನ್ನಿ, ನಮ್ಮ ಸರ್ವರ್‌ನ ವಿಳಾಸವು ಇನ್ನೂ ಹೀಗಿದೆ," ಪುನರುಜ್ಜೀವನಕ್ಕಾಗಿ ನಿಗದಿಪಡಿಸಲಾದ 5 ನಿಮಿಷಗಳ ಸಮಯದ ಮಿತಿಯನ್ನು ಪೂರೈಸುವುದು ಕಷ್ಟ. ಒಳ್ಳೆಯದು, ಜೊತೆಗೆ, ನಾವು ಈ ನಿಬಂಧನೆಗಳನ್ನು ಬಳಸುವಾಗ, ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಕೆಲವು ಬದಲಾವಣೆಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡುವುದು ಸುಲಭ, ಉದಾಹರಣೆಗೆ, ಮತ್ತು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ನಿಯಮಗಳನ್ನು ಬದಲಾಯಿಸುವುದು.
ಸರಿ, ಮೀಸಲಾತಿ ವ್ಯವಸ್ಥೆಯು ತುಂಬಾ ಸಂಕೀರ್ಣವಾಗಿದ್ದರೆ ಮತ್ತು ಕೆಲವು ಹಂತದಲ್ಲಿ ನಾವು ತಪ್ಪು ಮಾಡಿದರೆ, ನಂತರ ನಾವು ನಮ್ಮ ಬ್ಯಾಕಪ್ ಸೈಟ್ ಅನ್ನು ನಾಶಪಡಿಸಬಹುದು ಮತ್ತು ಹೆಚ್ಚುವರಿಯಾಗಿ ಡೇಟಾವನ್ನು ಎರಡೂ ಸೈಟ್ಗಳಲ್ಲಿ ಕುಂಬಳಕಾಯಿಯಾಗಿ ಪರಿವರ್ತಿಸಬಹುದು - ಇದು ಸಂಪೂರ್ಣವಾಗಿ ದುಃಖಕರವಾಗಿರುತ್ತದೆ.
ಉದಾಹರಣೆ ಸಂಖ್ಯೆ ಐದು, ಸಂಪೂರ್ಣ ಹಾರ್ಡ್ಕೋರ್
ಪ್ರಪಂಚದಾದ್ಯಂತ ನೂರಾರು ಮಿಲಿಯನ್ ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿರುವ ಅಂತರರಾಷ್ಟ್ರೀಯ ಸೇವೆ. ಅಲ್ಲಿರುವ ಎಲ್ಲಾ ಸಮಯ ವಲಯಗಳು, ಗರಿಷ್ಠ ವೇಗದಲ್ಲಿ ಹೆಚ್ಚಿನ ಹೊರೆ, ನೀವು ಮಲಗಲು ಸಾಧ್ಯವಿಲ್ಲ. ಒಂದು ನಿಮಿಷ - ಮತ್ತು ಅದು ದುಃಖವಾಗುತ್ತದೆ. ಏನ್ ಮಾಡೋದು? ಕಾಯ್ದಿರಿಸಿ, ಮತ್ತೆ, ಪೂರ್ಣ ಕಾರ್ಯಕ್ರಮದ ಪ್ರಕಾರ. ಹಿಂದಿನ ಉದಾಹರಣೆಯಲ್ಲಿ ನಾನು ಮಾತನಾಡಿದ ಎಲ್ಲವನ್ನೂ ನಾವು ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಸ್ವಲ್ಪ ಹೆಚ್ಚು. ಆದರ್ಶ ಜಗತ್ತು, ಮತ್ತು ನಮ್ಮ ಮೂಲಸೌಕರ್ಯವು IaaC devops ನ ಎಲ್ಲಾ ಪರಿಕಲ್ಪನೆಗಳ ಪ್ರಕಾರವಾಗಿದೆ. ಅಂದರೆ, ಎಲ್ಲವೂ ಜಿಟ್‌ನಲ್ಲಿದೆ ಮತ್ತು ನೀವು ಬಟನ್ ಒತ್ತಿರಿ.
ಏನು ಕಾಣೆಯಾಗಿದೆ? ಒಂದು - ವ್ಯಾಯಾಮ. ಅವರಿಲ್ಲದೆ ಅದು ಅಸಾಧ್ಯ. ಎಲ್ಲವೂ ನಮ್ಮೊಂದಿಗೆ ಪರಿಪೂರ್ಣವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲವನ್ನೂ ನಿಯಂತ್ರಣದಲ್ಲಿಟ್ಟುಕೊಳ್ಳುತ್ತೇವೆ. ನಾವು ಗುಂಡಿಯನ್ನು ಒತ್ತಿ, ಎಲ್ಲವೂ ನಡೆಯುತ್ತದೆ. ಇದು ಹಾಗಿದ್ದರೂ - ಮತ್ತು ಅದು ಈ ರೀತಿ ಆಗುವುದಿಲ್ಲ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ - ನಮ್ಮ ಸಿಸ್ಟಮ್ ಇತರ ಕೆಲವು ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಇದು ಮಾರ್ಗ 53, s3 ಸಂಗ್ರಹಣೆ, ಕೆಲವು api ನೊಂದಿಗೆ ಏಕೀಕರಣದಿಂದ dns ಆಗಿದೆ. ಈ ಊಹಾತ್ಮಕ ಪ್ರಯೋಗದಲ್ಲಿ ನಾವು ಎಲ್ಲವನ್ನೂ ಊಹಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಮತ್ತು ನಾವು ನಿಜವಾಗಿಯೂ ಸ್ವಿಚ್ ಅನ್ನು ಎಳೆಯುವವರೆಗೆ, ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂದು ನಮಗೆ ತಿಳಿದಿರುವುದಿಲ್ಲ.
ಬಹುಶಃ ಅಷ್ಟೆ. ಸೋಮಾರಿಯಾಗಬೇಡಿ ಅಥವಾ ಅತಿಯಾಗಿ ಮಾಡಬೇಡಿ. ಮತ್ತು ಸಮಯವು ನಿಮ್ಮೊಂದಿಗೆ ಇರಬಹುದು!
ಮೂಲ: www.habr.com