ಸೂಚನೆ. ಅನುವಾದ.: ಈ ಲೇಖನವು AWS ತಂತ್ರಜ್ಞಾನದ ಸುವಾರ್ತಾಬೋಧಕ ಆಡ್ರಿಯನ್ ಹಾರ್ನ್ಸ್‌ಬೈ ಅವರ ಲೇಖನಗಳ ಉತ್ತಮ ಸರಣಿಯನ್ನು ಮುಂದುವರೆಸಿದೆ, ಅವರು IT ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿನ ವೈಫಲ್ಯಗಳ ಪರಿಣಾಮಗಳನ್ನು ತಗ್ಗಿಸಲು ಪ್ರಯೋಗದ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಸರಳ ಮತ್ತು ಸ್ಪಷ್ಟ ರೀತಿಯಲ್ಲಿ ವಿವರಿಸಲು ಹೊರಟಿದ್ದಾರೆ.
"ನೀವು ಯೋಜನೆಯನ್ನು ಸಿದ್ಧಪಡಿಸಲು ವಿಫಲವಾದರೆ, ನೀವು ವಿಫಲಗೊಳ್ಳಲು ಯೋಜಿಸುತ್ತೀರಿ." - ಬೆಂಜಮಿನ್ ಫ್ರಾಂಕ್ಲಿನ್
В ಈ ಲೇಖನಗಳ ಸರಣಿಯಲ್ಲಿ, ನಾನು ಚೋಸ್ ಎಂಜಿನಿಯರಿಂಗ್ ಪರಿಕಲ್ಪನೆಯನ್ನು ಪರಿಚಯಿಸಿದೆ ಮತ್ತು ಉತ್ಪಾದನಾ ವೈಫಲ್ಯಗಳಿಗೆ ಕಾರಣವಾಗುವ ಮೊದಲು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿನ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಮತ್ತು ಸರಿಪಡಿಸಲು ಅದು ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಿದೆ. ಅವ್ಯವಸ್ಥೆಯ ಎಂಜಿನಿಯರಿಂಗ್ ಸಂಸ್ಥೆಗಳಲ್ಲಿ ಧನಾತ್ಮಕ ಸಾಂಸ್ಕೃತಿಕ ಬದಲಾವಣೆಯನ್ನು ಹೇಗೆ ಉತ್ತೇಜಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಸಹ ಇದು ಚರ್ಚಿಸಿದೆ.
ಮೊದಲ ಭಾಗದ ಕೊನೆಯಲ್ಲಿ, "ಸಿಸ್ಟಂಗಳಲ್ಲಿ ವೈಫಲ್ಯಗಳನ್ನು ಪರಿಚಯಿಸುವ ಸಾಧನಗಳು ಮತ್ತು ವಿಧಾನಗಳು" ಕುರಿತು ಮಾತನಾಡಲು ನಾನು ಭರವಸೆ ನೀಡಿದ್ದೇನೆ. ಅಯ್ಯೋ, ಈ ವಿಷಯದಲ್ಲಿ ನನ್ನ ತಲೆಯು ತನ್ನದೇ ಆದ ಯೋಜನೆಗಳನ್ನು ಹೊಂದಿತ್ತು, ಮತ್ತು ಈ ಲೇಖನದಲ್ಲಿ ಗೊಂದಲಮಯ ಎಂಜಿನಿಯರಿಂಗ್‌ಗೆ ಹೋಗಲು ಬಯಸುವ ಜನರಲ್ಲಿ ಉದ್ಭವಿಸುವ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ: ಮೊದಲು ಏನು ಮುರಿಯಬೇಕು?
ದೊಡ್ಡ ಪ್ರಶ್ನೆ! ಆದಾಗ್ಯೂ, ಅವರು ಈ ಪಾಂಡಾದಿಂದ ವಿಶೇಷವಾಗಿ ತಲೆಕೆಡಿಸಿಕೊಂಡಂತೆ ತೋರುತ್ತಿಲ್ಲ ...
ಗೊಂದಲದ ಪಾಂಡಾದೊಂದಿಗೆ ಗೊಂದಲಗೊಳ್ಳಬೇಡಿ!
ಸಣ್ಣ ಉತ್ತರ: ವಿನಂತಿಯ ಹಾದಿಯಲ್ಲಿ ನಿರ್ಣಾಯಕ ಸೇವೆಗಳನ್ನು ಗುರಿಪಡಿಸಿ.
ದೀರ್ಘವಾದ ಆದರೆ ಸ್ಪಷ್ಟವಾದ ಉತ್ತರ: ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗವನ್ನು ಎಲ್ಲಿ ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಮೂರು ಕ್ಷೇತ್ರಗಳಿಗೆ ಗಮನ ಕೊಡಿ:
- ನೋಡಿ ಕುಸಿತದ ಇತಿಹಾಸ ಮತ್ತು ಮಾದರಿಗಳನ್ನು ಗುರುತಿಸಿ;
- ನಿರ್ಧರಿಸಿ ನಿರ್ಣಾಯಕ ಅವಲಂಬನೆಗಳು;
- ಕರೆಯಲ್ಪಡುವ ಬಳಸಿ ಅತಿಯಾದ ಆತ್ಮವಿಶ್ವಾಸದ ಪರಿಣಾಮ.
ಇದು ತಮಾಷೆಯಾಗಿದೆ, ಆದರೆ ಈ ಭಾಗವನ್ನು ಸುಲಭವಾಗಿ ಕರೆಯಬಹುದು "ಸ್ವಯಂ ಅನ್ವೇಷಣೆ ಮತ್ತು ಜ್ಞಾನೋದಯಕ್ಕೆ ಒಂದು ಪ್ರಯಾಣ". ಅದರಲ್ಲಿ ನಾವು ಕೆಲವು ತಂಪಾದ ವಾದ್ಯಗಳೊಂದಿಗೆ "ಆಡಲು" ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ.
1. ಉತ್ತರವು ಹಿಂದೆ ಇರುತ್ತದೆ
ನಿಮಗೆ ನೆನಪಿದ್ದರೆ, ಮೊದಲ ಭಾಗದಲ್ಲಿ ನಾನು ದೋಷಗಳ ತಿದ್ದುಪಡಿ (COE) ಪರಿಕಲ್ಪನೆಯನ್ನು ಪರಿಚಯಿಸಿದೆ - ನಾವು ನಮ್ಮ ತಪ್ಪುಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುವ ವಿಧಾನ - ತಂತ್ರಜ್ಞಾನ, ಪ್ರಕ್ರಿಯೆ ಅಥವಾ ಸಂಘಟನೆಯಲ್ಲಿನ ತಪ್ಪುಗಳು - ಅವುಗಳ ಕಾರಣವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ತಡೆಯಲು ಭವಿಷ್ಯದಲ್ಲಿ ಮರುಕಳಿಸುವಿಕೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಇಲ್ಲಿ ನೀವು ಪ್ರಾರಂಭಿಸಬೇಕು.
"ವರ್ತಮಾನವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನೀವು ಹಿಂದಿನದನ್ನು ತಿಳಿದುಕೊಳ್ಳಬೇಕು." - ಕಾರ್ಲ್ ಸಗಾನ್
ವೈಫಲ್ಯಗಳ ಇತಿಹಾಸವನ್ನು ನೋಡಿ, ಅವುಗಳನ್ನು COE ಅಥವಾ ಪೋಸ್ಟ್‌ಮಾರ್ಟಮ್‌ಗಳಲ್ಲಿ ಟ್ಯಾಗ್ ಮಾಡಿ ಮತ್ತು ಅವುಗಳನ್ನು ವರ್ಗೀಕರಿಸಿ. ಸಾಮಾನ್ಯವಾಗಿ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುವ ಸಾಮಾನ್ಯ ಮಾದರಿಗಳನ್ನು ಗುರುತಿಸಿ ಮತ್ತು ಪ್ರತಿ COE ಗಾಗಿ, ಈ ಕೆಳಗಿನ ಪ್ರಶ್ನೆಯನ್ನು ನೀವೇ ಕೇಳಿಕೊಳ್ಳಿ:
"ಇದನ್ನು ಊಹಿಸಬಹುದೇ ಮತ್ತು ಆದ್ದರಿಂದ ತಪ್ಪು ಇಂಜೆಕ್ಷನ್ ಮೂಲಕ ತಡೆಯಬಹುದೇ?"
ನನ್ನ ವೃತ್ತಿಜೀವನದ ಆರಂಭದಲ್ಲಿ ಒಂದು ವೈಫಲ್ಯವನ್ನು ನಾನು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇನೆ. ನಾವು ಒಂದೆರಡು ಸರಳ ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗಗಳನ್ನು ನಡೆಸಿದ್ದರೆ ಅದನ್ನು ಸುಲಭವಾಗಿ ತಡೆಯಬಹುದಿತ್ತು:
ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ಬ್ಯಾಕೆಂಡ್ ನಿದರ್ಶನಗಳು ಆರೋಗ್ಯ ತಪಾಸಣೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತವೆ ) ವಿನಂತಿಗಳನ್ನು ಆರೋಗ್ಯಕರ ನಿದರ್ಶನಗಳಿಗೆ ಮರುನಿರ್ದೇಶಿಸಲು ELB ಈ ತಪಾಸಣೆಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಒಂದು ನಿದರ್ಶನವು "ಅನಾರೋಗ್ಯಕರ" ಎಂದು ತಿರುಗಿದಾಗ, ELB ಅದಕ್ಕೆ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಒಂದು ದಿನ, ಯಶಸ್ವಿ ಮಾರ್ಕೆಟಿಂಗ್ ಅಭಿಯಾನದ ನಂತರ, ದಟ್ಟಣೆಯ ಪ್ರಮಾಣವು ಹೆಚ್ಚಾಯಿತು ಮತ್ತು ಬ್ಯಾಕೆಂಡ್‌ಗಳು ಸಾಮಾನ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ನಿಧಾನವಾಗಿ ಆರೋಗ್ಯ ತಪಾಸಣೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು. ಈ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳು ಎಂದು ಹೇಳಬೇಕು , ಅಂದರೆ, ಅವಲಂಬನೆಗಳ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಲಾಗಿದೆ.
ಆದಾಗ್ಯೂ, ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿತ್ತು.
ನಂತರ, ಈಗಾಗಲೇ ಒತ್ತಡದ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ನಿದರ್ಶನಗಳಲ್ಲಿ ಒಂದು ನಿರ್ಣಾಯಕವಲ್ಲದ, ನಿಯಮಿತ ETL ಕ್ರಾನ್ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿತು. ಹೆಚ್ಚಿನ ಟ್ರಾಫಿಕ್ ಮತ್ತು ಕ್ರೋನ್‌ಜಾಬ್‌ನ ಸಂಯೋಜನೆಯು CPU ಬಳಕೆಯನ್ನು ಸುಮಾರು 100% ಗೆ ತಳ್ಳಿತು. CPU ಓವರ್ಲೋಡ್ ಆರೋಗ್ಯ ತಪಾಸಣೆಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಮತ್ತಷ್ಟು ನಿಧಾನಗೊಳಿಸಿತು, ಎಷ್ಟರಮಟ್ಟಿಗೆ ELB ನಿದರ್ಶನವು ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿತು. ನಿರೀಕ್ಷೆಯಂತೆ, ಬ್ಯಾಲೆನ್ಸರ್ ಅದಕ್ಕೆ ದಟ್ಟಣೆಯನ್ನು ವಿತರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿತು, ಇದು ಗುಂಪಿನಲ್ಲಿ ಉಳಿದಿರುವ ನಿದರ್ಶನಗಳ ಮೇಲೆ ಹೊರೆ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಯಿತು.
ಇದ್ದಕ್ಕಿದ್ದಂತೆ, ಇತರ ಎಲ್ಲಾ ನಿದರ್ಶನಗಳು ಸಹ ಆರೋಗ್ಯ ತಪಾಸಣೆ ವಿಫಲಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದವು.
ಹೊಸ ನಿದರ್ಶನವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವುದು ಮತ್ತು ಸ್ಥಾಪಿಸುವುದು ಅಗತ್ಯವಾಗಿದೆ ಮತ್ತು ಆಟೋಸ್ಕೇಲಿಂಗ್ ಗುಂಪಿನಲ್ಲಿ - ಒಂದೊಂದಾಗಿ - ಅವುಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ELB ತೆಗೆದುಕೊಂಡ ಸಮಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಶೀಘ್ರದಲ್ಲೇ ಇಡೀ ಪ್ರಕ್ರಿಯೆಯು ನಿರ್ಣಾಯಕ ಹಂತವನ್ನು ತಲುಪಿತು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.
ನಂತರ ನಾವು ಈ ಕೆಳಗಿನ ಅಂಶಗಳನ್ನು ಶಾಶ್ವತವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ:
- ಹೊಸ ನಿದರ್ಶನವನ್ನು ರಚಿಸುವಾಗ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವುದು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಬದಲಾಗದ ವಿಧಾನಕ್ಕೆ ಆದ್ಯತೆ ನೀಡುವುದು ಉತ್ತಮ .
- ಸಂಕೀರ್ಣ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಆರೋಗ್ಯ-ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ELB ಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಆದ್ಯತೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು - ಉಳಿದಿರುವ ನಿದರ್ಶನಗಳಿಗೆ ಜೀವನವನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸುವುದು ನಿಮಗೆ ಕೊನೆಯ ವಿಷಯವಾಗಿದೆ.
- ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳ ಸ್ಥಳೀಯ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆಯು ಬಹಳಷ್ಟು ಸಹಾಯ ಮಾಡುತ್ತದೆ (ಕೆಲವು ಸೆಕೆಂಡುಗಳವರೆಗೆ).
- ಕಠಿಣ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಕ್ರಾನ್ ಕಾರ್ಯಗಳು ಮತ್ತು ಇತರ ನಿರ್ಣಾಯಕವಲ್ಲದ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಡೆಸಬೇಡಿ - ಪ್ರಮುಖ ಕಾರ್ಯಗಳಿಗಾಗಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿಸಿ.
- ಆಟೋಸ್ಕೇಲಿಂಗ್ ಮಾಡುವಾಗ, ಚಿಕ್ಕ ನಿದರ್ಶನಗಳನ್ನು ಬಳಸಿ. 10 ಸಣ್ಣ ಮಾದರಿಗಳ ಗುಂಪು 4 ದೊಡ್ಡ ಗುಂಪುಗಳಿಗಿಂತ ಉತ್ತಮವಾಗಿದೆ; ಒಂದು ನಿದರ್ಶನ ವಿಫಲವಾದರೆ, ಮೊದಲ ಪ್ರಕರಣದಲ್ಲಿ 10% ದಟ್ಟಣೆಯನ್ನು 9 ಅಂಕಗಳ ಮೇಲೆ ವಿತರಿಸಲಾಗುತ್ತದೆ, ಎರಡನೆಯದರಲ್ಲಿ - 25% ದಟ್ಟಣೆಯು ಮೂರು ಪಾಯಿಂಟ್‌ಗಳ ಮೇಲೆ.
ಆದ್ದರಿಂದ, ಇದನ್ನು ಊಹಿಸಬಹುದಿತ್ತು ಮತ್ತು ಆದ್ದರಿಂದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಚಯಿಸುವ ಮೂಲಕ ತಡೆಯಬಹುದೇ?
ಹೌದು, ಮತ್ತು ಹಲವಾರು ವಿಧಗಳಲ್ಲಿ.
ಮೊದಲಿಗೆ, ಹೆಚ್ಚಿನ CPU ಬಳಕೆಯನ್ನು ಅನುಕರಿಸುವ ಮೂಲಕ ಉಪಕರಣಗಳನ್ನು ಬಳಸಿ ಅಥವಾ :
❯ stress-ng --matrix 1 -t 60s
ಒತ್ತಡ- ng
ಎರಡನೆಯದಾಗಿ, ನಿದರ್ಶನವನ್ನು ಓವರ್ಲೋಡ್ ಮಾಡುವ ಮೂಲಕ ಮತ್ತು ಇತರ ರೀತಿಯ ಉಪಯುಕ್ತತೆಗಳು:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
ಪ್ರಯೋಗಗಳು ತುಲನಾತ್ಮಕವಾಗಿ ಸರಳವಾಗಿದೆ, ಆದರೆ ನಿಜವಾದ ವೈಫಲ್ಯದ ಒತ್ತಡದ ಮೂಲಕ ಹೋಗದೆಯೇ ಚಿಂತನೆಗೆ ಕೆಲವು ಉತ್ತಮ ಆಹಾರವನ್ನು ಒದಗಿಸಬಹುದು.
ಆದಾಗ್ಯೂ, ಅಲ್ಲಿ ನಿಲ್ಲಬೇಡ. ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಕುಸಿತವನ್ನು ಪುನರುತ್ಪಾದಿಸಲು ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ಪ್ರಶ್ನೆಗೆ ನಿಮ್ಮ ಉತ್ತರವನ್ನು ಪರಿಶೀಲಿಸಿ "ದೋಷವನ್ನು ಪರಿಚಯಿಸುವ ಮೂಲಕ ಇದನ್ನು ಮುಂಗಾಣಲಾಗಿದೆ ಮತ್ತು ಆದ್ದರಿಂದ ತಡೆಯಬಹುದೆ?" ಇದು ಊಹೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗದಲ್ಲಿ ಮಿನಿ ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗವಾಗಿದೆ, ಆದರೆ ವೈಫಲ್ಯದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
ಇದು ಕನಸೇ, ಅಥವಾ ಅದು ನಿಜವಾಗಿಯೂ ಸಂಭವಿಸಿದೆಯೇ?
ಆದ್ದರಿಂದ ವೈಫಲ್ಯಗಳ ಇತಿಹಾಸವನ್ನು ಅಧ್ಯಯನ ಮಾಡಿ, ವಿಶ್ಲೇಷಿಸಿ ಸಿಒಇ, ಟ್ಯಾಗ್ ಮಾಡಿ ಮತ್ತು ಅವುಗಳನ್ನು "ಹಿಟ್ ರೇಡಿಯಸ್" ಮೂಲಕ ವರ್ಗೀಕರಿಸಿ-ಅಥವಾ ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಪರಿಣಾಮ ಬೀರುವ ಗ್ರಾಹಕರ ಸಂಖ್ಯೆ-ಮತ್ತು ನಂತರ ಮಾದರಿಗಳನ್ನು ನೋಡಿ. ಸಮಸ್ಯೆಯನ್ನು ಪರಿಚಯಿಸುವ ಮೂಲಕ ಇದನ್ನು ಊಹಿಸಲು ಮತ್ತು ತಡೆಯಲು ಸಾಧ್ಯವೇ ಎಂದು ನಿಮ್ಮನ್ನು ಕೇಳಿಕೊಳ್ಳಿ. ನಿಮ್ಮ ಉತ್ತರವನ್ನು ಪರಿಶೀಲಿಸಿ.
ನಂತರ ದೊಡ್ಡ ಶ್ರೇಣಿಯೊಂದಿಗೆ ಸಾಮಾನ್ಯ ಮಾದರಿಗಳಿಗೆ ಬದಲಿಸಿ.
2. ಅವಲಂಬನೆ ನಕ್ಷೆಯನ್ನು ನಿರ್ಮಿಸಿ
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಿ. ಅದರ ಅವಲಂಬನೆಗಳ ಸ್ಪಷ್ಟ ನಕ್ಷೆ ಇದೆಯೇ? ವಿಫಲವಾದರೆ ಅವು ಯಾವ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆಯೇ?
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಕೋಡ್‌ನೊಂದಿಗೆ ನೀವು ಹೆಚ್ಚು ಪರಿಚಿತರಾಗಿಲ್ಲದಿದ್ದರೆ ಅಥವಾ ಅದು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಕೋಡ್ ಏನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದರ ಅವಲಂಬನೆಗಳು ಏನೆಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಕಷ್ಟವಾಗಬಹುದು. ಈ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಬಳಕೆದಾರರ ಮೇಲೆ ಅವುಗಳ ಸಂಭವನೀಯ ಪ್ರಭಾವವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಗೊಂದಲಮಯ ಎಂಜಿನಿಯರಿಂಗ್‌ನೊಂದಿಗೆ ಎಲ್ಲಿ ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂದು ತಿಳಿಯುವುದು ನಿರ್ಣಾಯಕವಾಗಿದೆ: ಪ್ರಾರಂಭದ ಹಂತವು ದೊಡ್ಡ ಪ್ರಭಾವದ ತ್ರಿಜ್ಯದೊಂದಿಗೆ ಘಟಕವಾಗಿದೆ.
ಅವಲಂಬನೆಗಳನ್ನು ಗುರುತಿಸುವುದು ಮತ್ತು ದಾಖಲಿಸುವುದು ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ "ಅವಲಂಬನೆ ನಕ್ಷೆಯನ್ನು ನಿರ್ಮಿಸುವುದು» (ಅವಲಂಬನೆ ಮ್ಯಾಪಿಂಗ್). ಕೋಡ್ ಪ್ರೊಫೈಲಿಂಗ್ ಪರಿಕರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ದೊಡ್ಡ ಕೋಡ್ ಬೇಸ್ ಹೊಂದಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ. (ಕೋಡ್ ಪ್ರೊಫೈಲಿಂಗ್) ಮತ್ತು ಉಪಕರಣ (ವಾದ್ಯ). ನೆಟ್ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಮೂಲಕ ನೀವು ನಕ್ಷೆಯನ್ನು ಸಹ ರಚಿಸಬಹುದು.
ಆದಾಗ್ಯೂ, ಎಲ್ಲಾ ಅವಲಂಬನೆಗಳು ಒಂದೇ ಆಗಿರುವುದಿಲ್ಲ (ಇದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮತ್ತಷ್ಟು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ). ಕೆಲವು ನಿರ್ಣಾಯಕ, ಇತರೆ - ದ್ವಿತೀಯ (ಕನಿಷ್ಠ ಸೈದ್ಧಾಂತಿಕವಾಗಿ, ಕ್ರ್ಯಾಶ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಅವಲಂಬನೆಗಳ ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ ಸಂಭವಿಸುವುದರಿಂದ ನಿರ್ಣಾಯಕವಲ್ಲ ಎಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ).
ನಿರ್ಣಾಯಕ ಅವಲಂಬನೆಗಳಿಲ್ಲದೆ, ಸೇವೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ನಿರ್ಣಾಯಕವಲ್ಲದ ಅವಲಂಬನೆಗಳು "ಮಾಡಬಾರದು» ಕುಸಿತದ ಸಂದರ್ಭದಲ್ಲಿ ಸೇವೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಲು. ಅವಲಂಬನೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವ API ಗಳ ಬಗ್ಗೆ ನೀವು ಸ್ಪಷ್ಟವಾದ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿರಬೇಕು. ಇದು ತೋರುತ್ತಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ - ಕನಿಷ್ಠ ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ.
ಎಲ್ಲಾ API ಗಳ ಮೂಲಕ ಹೋಗುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ. ಹೆಚ್ಚಿನದನ್ನು ಹೈಲೈಟ್ ಮಾಡಿ ಗಮನಾರ್ಹ ಮತ್ತು ನಿರ್ಣಾಯಕ. ತೆಗೆದುಕೊಳ್ಳಿ ಅವಲಂಬನೆಗಳು ಕೋಡ್ ರೆಪೊಸಿಟರಿಯಿಂದ, ಅದನ್ನು ಪರಿಶೀಲಿಸಿ ಸಂಪರ್ಕ ದಾಖಲೆಗಳು, ನಂತರ ವೀಕ್ಷಿಸಿ ದಸ್ತಾವೇಜನ್ನು (ಸಹಜವಾಗಿ, ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ - ಇಲ್ಲದಿದ್ದರೆ ನೀವು ಇನ್ನೂ ಹೊಂದಿದ್ದೀರಿоದೊಡ್ಡ ಸಮಸ್ಯೆಗಳು). ಉಪಕರಣಗಳನ್ನು ಬಳಸಿ ಪ್ರೊಫೈಲಿಂಗ್ ಮತ್ತು ಟ್ರೇಸಿಂಗ್, ಬಾಹ್ಯ ಕರೆಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿ.
ನೀವು ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ಬಳಸಬಹುದು netstat - ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಎಲ್ಲಾ ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕಗಳ (ಸಕ್ರಿಯ ಸಾಕೆಟ್ಗಳು) ಪಟ್ಟಿಯನ್ನು ಪ್ರದರ್ಶಿಸುವ ಆಜ್ಞಾ ಸಾಲಿನ ಉಪಯುಕ್ತತೆ. ಉದಾಹರಣೆಗೆ, ಎಲ್ಲಾ ಪ್ರಸ್ತುತ ಸಂಪರ್ಕಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಲು, ಟೈಪ್ ಮಾಡಿ:
❯ netstat -a | more
AWS ನಲ್ಲಿ ನೀವು ಬಳಸಬಹುದು (ಫ್ಲೋ ಲಾಗ್‌ಗಳು) VPC ಎನ್ನುವುದು VPC ಯಲ್ಲಿನ ನೆಟ್ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್‌ಗಳಿಗೆ ಹೋಗುವ ಅಥವಾ IP ಟ್ರಾಫಿಕ್ ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಒಂದು ವಿಧಾನವಾಗಿದೆ. ಅಂತಹ ಲಾಗ್‌ಗಳು ಇತರ ಕಾರ್ಯಗಳಿಗೆ ಸಹ ಸಹಾಯ ಮಾಡಬಹುದು - ಉದಾಹರಣೆಗೆ, ಕೆಲವು ದಟ್ಟಣೆಯು ನಿದರ್ಶನವನ್ನು ಏಕೆ ತಲುಪುವುದಿಲ್ಲ ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು.
ನೀವು ಸಹ ಬಳಸಬಹುದು . ಎಕ್ಸ್-ರೇ ನಿಮಗೆ ವಿವರವಾದ, "ಅಂತಿಮ" ಪಡೆಯಲು ಅನುಮತಿಸುತ್ತದೆ (ಅಂತ್ಯದಿಂದ ಕೊನೆಯವರೆಗೆ) ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೂಲಕ ಚಲಿಸುವಾಗ ವಿನಂತಿಗಳ ಅವಲೋಕನ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಆಧಾರವಾಗಿರುವ ಘಟಕಗಳ ನಕ್ಷೆಯನ್ನು ಸಹ ನಿರ್ಮಿಸುತ್ತದೆ. ನೀವು ಅವಲಂಬನೆಗಳನ್ನು ಗುರುತಿಸಬೇಕಾದರೆ ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ.
AWS ಎಕ್ಸ್-ರೇ ಕನ್ಸೋಲ್
ನೆಟ್ವರ್ಕ್ ಅವಲಂಬನೆ ನಕ್ಷೆಯು ಕೇವಲ ಭಾಗಶಃ ಪರಿಹಾರವಾಗಿದೆ. ಹೌದು, ಇದು ಯಾವ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ಇತರ ಅವಲಂಬನೆಗಳಿವೆ.
ಅನೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಅವಲಂಬನೆಗಳಿಗೆ ಸಂಪರ್ಕಿಸಲು DNS ಅನ್ನು ಬಳಸುತ್ತವೆ, ಆದರೆ ಇತರರು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಲ್ಲಿ ಸೇವಾ ಶೋಧನೆ ಅಥವಾ ಹಾರ್ಡ್-ಕೋಡೆಡ್ IP ವಿಳಾಸಗಳನ್ನು ಬಳಸಬಹುದು (ಉದಾ. /etc/hosts).
ಉದಾಹರಣೆಗೆ, ನೀವು ರಚಿಸಬಹುದು ಸಹಾಯದಿಂದ iptables ಮತ್ತು ಏನು ಒಡೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ. ಇದನ್ನು ಮಾಡಲು, ಈ ಕೆಳಗಿನ ಆಜ್ಞೆಯನ್ನು ನಮೂದಿಸಿ:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS ಕಪ್ಪು ಕುಳಿ
ಸೈನ್ ಇನ್ ಆಗಿದ್ದರೆ /etc/hosts ಅಥವಾ ಇತರ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳು, ನಿಮಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲದ IP ವಿಳಾಸಗಳನ್ನು ನೀವು ಕಾಣಬಹುದು (ಹೌದು, ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಸಹ ಸಂಭವಿಸುತ್ತದೆ), ನೀವು ಮತ್ತೆ ರಕ್ಷಣೆಗೆ ಬರಬಹುದು iptables. ನೀವು ಕಂಡುಹಿಡಿದಿದ್ದೀರಿ ಎಂದು ಹೇಳೋಣ 8.8.8.8 ಮತ್ತು ಇದು Google ನ ಸಾರ್ವಜನಿಕ DNS ಸರ್ವರ್ ವಿಳಾಸ ಎಂದು ತಿಳಿದಿಲ್ಲ. ಬಳಸಿಕೊಂಡು iptables ಕೆಳಗಿನ ಆಜ್ಞೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಈ ವಿಳಾಸಕ್ಕೆ ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ದಟ್ಟಣೆಯನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದು:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
ಪ್ರವೇಶವನ್ನು ಮುಚ್ಚಲಾಗುತ್ತಿದೆ
ಮೊದಲ ನಿಯಮವು Google ನ ಸಾರ್ವಜನಿಕ DNS ನಿಂದ ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಬಿಡುತ್ತದೆ: ping ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸಲಾಗುವುದಿಲ್ಲ. ಎರಡನೆಯ ನಿಯಮವು ನಿಮ್ಮ ಸಿಸ್ಟಮ್‌ನಿಂದ ಹುಟ್ಟುವ ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು Google ನ ಸಾರ್ವಜನಿಕ DNS ಕಡೆಗೆ ಇಳಿಸುತ್ತದೆ - ಇದಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ping ನಾವು ಪಡೆಯುತ್ತೇವೆ ಕಾರ್ಯಾಚರಣೆಗೆ ಅನುಮತಿ ಇಲ್ಲ.
ಗಮನಿಸಿ: ಈ ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭದಲ್ಲಿ ಅದನ್ನು ಬಳಸುವುದು ಉತ್ತಮ whois 8.8.8.8, ಆದರೆ ಇದು ಕೇವಲ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ.
ನಾವು ಮೊಲದ ರಂಧ್ರದ ಕೆಳಗೆ ಇನ್ನೂ ಆಳವಾಗಿ ಹೋಗಬಹುದು, ಏಕೆಂದರೆ TCP ಮತ್ತು UDP ಅನ್ನು ಬಳಸುವ ಎಲ್ಲವೂ ವಾಸ್ತವವಾಗಿ IP ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, IP ಅನ್ನು ARP ಗೆ ಕಟ್ಟಲಾಗುತ್ತದೆ. ಫೈರ್‌ವಾಲ್‌ಗಳ ಬಗ್ಗೆ ಮರೆಯಬೇಡಿ...
ನೀವು ಕೆಂಪು ಮಾತ್ರೆ ತೆಗೆದುಕೊಂಡರೆ, ನೀವು ವಂಡರ್ಲ್ಯಾಂಡ್ನಲ್ಲಿ ಉಳಿಯುತ್ತೀರಿ ಮತ್ತು ಮೊಲದ ರಂಧ್ರವು ಎಷ್ಟು ಆಳವಾಗಿ ಹೋಗುತ್ತದೆ ಎಂದು ನಾನು ನಿಮಗೆ ತೋರಿಸುತ್ತೇನೆ.
ಹೆಚ್ಚು ಆಮೂಲಾಗ್ರ ವಿಧಾನವಾಗಿದೆ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಕಾರುಗಳು ಒಂದೊಂದಾಗಿ ಮತ್ತು ಮುರಿದುಹೋಗಿರುವುದನ್ನು ನೋಡಿ ... "ಅವ್ಯವಸ್ಥೆಯ ಮಂಕಿ." ಸಹಜವಾಗಿ, ಅನೇಕ ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಅಂತಹ ವಿವೇಚನಾರಹಿತ ಶಕ್ತಿ ದಾಳಿಗೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ಕನಿಷ್ಠ ಅದನ್ನು ಪರೀಕ್ಷಾ ವಾತಾವರಣದಲ್ಲಿ ಪ್ರಯತ್ನಿಸಬಹುದು.
ಅವಲಂಬನೆ ನಕ್ಷೆಯನ್ನು ನಿರ್ಮಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಬಹಳ ದೀರ್ಘವಾದ ಕಾರ್ಯವಾಗಿದೆ. ನೂರಾರು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳು ಮತ್ತು ಕಮಾಂಡ್‌ಗಳಿಗಾಗಿ ಅರೆ-ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅವಲಂಬಿತ ನಕ್ಷೆಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಸಾಧನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಸುಮಾರು 2 ವರ್ಷಗಳ ಕಾಲ ಕಳೆದ ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ನಾನು ಇತ್ತೀಚೆಗೆ ಮಾತನಾಡಿದ್ದೇನೆ.
ಆದಾಗ್ಯೂ, ಫಲಿತಾಂಶವು ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಮತ್ತು ಉಪಯುಕ್ತವಾಗಿದೆ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್, ಅದರ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಗಳ ಬಗ್ಗೆ ನೀವು ಬಹಳಷ್ಟು ಕಲಿಯುವಿರಿ. ಮತ್ತೊಮ್ಮೆ, ತಾಳ್ಮೆಯಿಂದಿರಿ: ಇದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ಪ್ರಯಾಣವಾಗಿದೆ.
3. ಅತಿಯಾದ ಆತ್ಮವಿಶ್ವಾಸದ ಬಗ್ಗೆ ಎಚ್ಚರದಿಂದಿರಿ
"ಯಾರು ಏನು ಕನಸು ಕಾಣುತ್ತಾರೆ, ಅದನ್ನು ನಂಬುತ್ತಾರೆ." - ಡೆಮೋಸ್ತನೀಸ್
ನೀವು ಎಂದಾದರೂ ಕೇಳಿದ್ದೀರಾ ಅತಿಯಾದ ಆತ್ಮವಿಶ್ವಾಸದ ಪರಿಣಾಮ?
ವಿಕಿಪೀಡಿಯಾದ ಪ್ರಕಾರ, ಅತಿಯಾದ ಆತ್ಮವಿಶ್ವಾಸದ ಪರಿಣಾಮವು "ಅವರ ಕಾರ್ಯಗಳು ಮತ್ತು ನಿರ್ಧಾರಗಳಲ್ಲಿ ವ್ಯಕ್ತಿಯ ವಿಶ್ವಾಸವು ಆ ತೀರ್ಪುಗಳ ವಸ್ತುನಿಷ್ಠ ನಿಖರತೆಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಿರುವ ಅರಿವಿನ ಪಕ್ಷಪಾತವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಮಟ್ಟವು ತುಲನಾತ್ಮಕವಾಗಿ ಹೆಚ್ಚಿರುವಾಗ."
ಪ್ರವೃತ್ತಿ ಮತ್ತು ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ...
ನನ್ನ ಅನುಭವದಿಂದ, ಈ ಅಸ್ಪಷ್ಟತೆಯು ಅವ್ಯವಸ್ಥೆಯ ಎಂಜಿನಿಯರಿಂಗ್‌ನೊಂದಿಗೆ ಎಲ್ಲಿ ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂಬುದರ ಉತ್ತಮ ಸುಳಿವು ಎಂದು ನಾನು ಹೇಳಬಲ್ಲೆ.
ಅತಿಯಾದ ಆತ್ಮವಿಶ್ವಾಸದ ಆಪರೇಟರ್ ಬಗ್ಗೆ ಎಚ್ಚರದಿಂದಿರಿ:
ಚಾರ್ಲಿ: "ಈ ವಿಷಯವು ಐದು ವರ್ಷಗಳಲ್ಲಿ ಬಿದ್ದಿಲ್ಲ, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿದೆ!"
ಕ್ರ್ಯಾಶ್: "ನಿರೀಕ್ಷಿಸಿ ... ನಾನು ಶೀಘ್ರದಲ್ಲೇ ಅಲ್ಲಿಗೆ ಬರುತ್ತೇನೆ!"
ಅತಿಯಾದ ಆತ್ಮವಿಶ್ವಾಸದ ಪರಿಣಾಮವಾಗಿ ಪಕ್ಷಪಾತವು ಕಪಟ ಮತ್ತು ಅಪಾಯಕಾರಿ ವಿಷಯವಾಗಿದೆ ಏಕೆಂದರೆ ಅದರ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವ ವಿವಿಧ ಅಂಶಗಳಿಂದಾಗಿ. ತಂಡದ ಸದಸ್ಯರು ತಮ್ಮ ಹೃದಯವನ್ನು ತಂತ್ರಜ್ಞಾನಕ್ಕೆ ಸುರಿದಾಗ ಅಥವಾ ಅದನ್ನು "ಫಿಕ್ಸಿಂಗ್" ಮಾಡಲು ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಕಳೆದಾಗ ಇದು ವಿಶೇಷವಾಗಿ ಸತ್ಯವಾಗಿದೆ.
ಒಟ್ಟುಗೂಡಿಸಲಾಗುತ್ತಿದೆ
ಅವ್ಯವಸ್ಥೆ ಇಂಜಿನಿಯರಿಂಗ್‌ಗಾಗಿ ಆರಂಭಿಕ ಹಂತಕ್ಕಾಗಿ ಹುಡುಕಾಟವು ಯಾವಾಗಲೂ ನಿರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚಿನ ಫಲಿತಾಂಶಗಳನ್ನು ತರುತ್ತದೆ ಮತ್ತು ವಿಷಯಗಳನ್ನು ಮುರಿಯಲು ಪ್ರಾರಂಭಿಸುವ ತಂಡಗಳು (ಅವ್ಯವಸ್ಥೆ-) ನ ಹೆಚ್ಚು ಜಾಗತಿಕ ಮತ್ತು ಆಸಕ್ತಿದಾಯಕ ಸಾರವನ್ನು ತ್ವರಿತವಾಗಿ ಕಳೆದುಕೊಳ್ಳುತ್ತವೆ.ಎಂಜಿನಿಯರಿಂಗ್ - ಸೃಜನಾತ್ಮಕ ಬಳಕೆ ವೈಜ್ಞಾನಿಕ ವಿಧಾನಗಳು и ಪ್ರಾಯೋಗಿಕ ಪುರಾವೆ (ಸಾಫ್ಟ್‌ವೇರ್) ವ್ಯವಸ್ಥೆಗಳ ವಿನ್ಯಾಸ, ಅಭಿವೃದ್ಧಿ, ಕಾರ್ಯಾಚರಣೆ, ನಿರ್ವಹಣೆ ಮತ್ತು ಸುಧಾರಣೆಗಾಗಿ.
ಇದು ಎರಡನೇ ಭಾಗವನ್ನು ಮುಕ್ತಾಯಗೊಳಿಸುತ್ತದೆ. ದಯವಿಟ್ಟು ವಿಮರ್ಶೆಗಳನ್ನು ಬರೆಯಿರಿ, ಅಭಿಪ್ರಾಯಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಿ ಅಥವಾ ನಿಮ್ಮ ಕೈಗಳನ್ನು ಚಪ್ಪಾಳೆ ತಟ್ಟಿರಿ . ಮುಂದಿನ ಭಾಗದಲ್ಲಿ ಐ ನಿಜವಾಗಿಯೂ ಸಿಸ್ಟಮ್ಗಳಲ್ಲಿ ವೈಫಲ್ಯಗಳನ್ನು ಪರಿಚಯಿಸುವ ಸಾಧನಗಳು ಮತ್ತು ವಿಧಾನಗಳನ್ನು ನಾನು ಪರಿಗಣಿಸುತ್ತೇನೆ. ತನಕ!
ಅನುವಾದಕರಿಂದ PS
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:
- «";
- «";
- «";
- «».
ಮೂಲ: www.habr.com