ಸೂಚನೆ. ಅನುವಾದ.: AWS - ಆಡ್ರಿಯನ್ ಹಾರ್ನ್ಸ್ಬಿಯಿಂದ ಹಿರಿಯ ತಂತ್ರಜ್ಞಾನ ಸುವಾರ್ತಾಬೋಧಕರಿಂದ ಅದ್ಭುತವಾದ ವಸ್ತುಗಳ ಅನುವಾದವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾವು ಸಂತೋಷಪಡುತ್ತೇವೆ. ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ಐಟಿ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿನ ವೈಫಲ್ಯಗಳ ಪರಿಣಾಮಗಳನ್ನು ತಗ್ಗಿಸಲು ಪ್ರಯೋಗದ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಅವರು ವಿವರಿಸುತ್ತಾರೆ. ನೀವು ಬಹುಶಃ ಚೋಸ್ ಮಂಕಿ ಬಗ್ಗೆ ಈಗಾಗಲೇ ಕೇಳಿದ್ದೀರಾ (ಅಥವಾ ಇದೇ ರೀತಿಯ ಪರಿಹಾರಗಳನ್ನು ಸಹ ಬಳಸಲಾಗಿದೆ)? ಇಂದು, ಅಂತಹ ಪರಿಕರಗಳನ್ನು ರಚಿಸುವ ವಿಧಾನಗಳು ಮತ್ತು ವಿಶಾಲವಾದ ಸಂದರ್ಭದಲ್ಲಿ ಅವುಗಳ ಅನುಷ್ಠಾನವನ್ನು ಚೋಸ್ ಎಂಜಿನಿಯರಿಂಗ್ ಎಂಬ ಚಟುವಟಿಕೆಯ ಚೌಕಟ್ಟಿನೊಳಗೆ ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ. ಈ ಲೇಖನದಲ್ಲಿ ಅದರ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ಓದಿ.
"ಆದರೆ ಈ ಎಲ್ಲಾ ಸೌಂದರ್ಯದ ಹಿಂದೆ ಅವ್ಯವಸ್ಥೆ ಮತ್ತು ಹುಚ್ಚು ಅಡಗಿದೆ." - ಟ್ಯಾನರ್ ವಾಲಿಂಗ್
ಅಗ್ನಿಶಾಮಕ ದಳದವರು. ಈ ಹೆಚ್ಚು ತರಬೇತಿ ಪಡೆದ ವೃತ್ತಿಪರರು ಪ್ರತಿದಿನ ಬೆಂಕಿಯ ವಿರುದ್ಧ ಹೋರಾಡಲು ತಮ್ಮ ಪ್ರಾಣವನ್ನು ಪಣಕ್ಕಿಡುತ್ತಾರೆ. ಅಗ್ನಿಶಾಮಕ ದಳದವನಾಗುವ ಮೊದಲು ನೀವು ಕನಿಷ್ಟ 600 ಗಂಟೆಗಳ ತರಬೇತಿಯನ್ನು ಕಳೆಯಬೇಕು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆಯೇ? ಮತ್ತು ಇದು ಕೇವಲ ಪ್ರಾರಂಭವಾಗಿದೆ. ವರದಿಗಳ ಪ್ರಕಾರ, ಅಗ್ನಿಶಾಮಕ ದಳದವರು ತಮ್ಮ ಕೆಲಸದ ಸಮಯದ 80% ವರೆಗೆ ತರಬೇತಿ ನೀಡುತ್ತಾರೆ.
ಯಾಕೆ?
ಅಗ್ನಿಶಾಮಕ ದಳವು ನಿಜವಾದ ಬೆಂಕಿಯೊಂದಿಗೆ ಹೋರಾಡುತ್ತಿರುವಾಗ, ಅವನಿಗೆ ಸೂಕ್ತವಾದದ್ದು ಬೇಕಾಗುತ್ತದೆ ಅಂತಃಪ್ರಜ್ಞೆ. ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು, ನೀವು ಗಂಟೆಗಟ್ಟಲೆ ತರಬೇತಿ ನೀಡಬೇಕು. ಅವರು ಹೇಳಿದಂತೆ, ಅಭ್ಯಾಸವು ಅದ್ಭುತಗಳನ್ನು ಮಾಡುತ್ತದೆ.
“ಅವರು ಬೆಂಕಿಯ ಸಾರವನ್ನು ಭೇದಿಸುವಂತೆ ತೋರುತ್ತಾರೆ; ಜ್ವಾಲೆಗಾಗಿ ಡಾ. ಫಿಲ್ನಂತೆ." -
ಸೂಚನೆ. ಅನುವಾದ.: ಫಿಲಿಪ್ ಕ್ಯಾಲ್ವಿನ್ "ಫಿಲ್" ಮೆಕ್ಗ್ರಾ ಒಬ್ಬ ಅಮೇರಿಕನ್ ಮನಶ್ಶಾಸ್ತ್ರಜ್ಞ, ಬರಹಗಾರ ಮತ್ತು ಜನಪ್ರಿಯ ದೂರದರ್ಶನ ಕಾರ್ಯಕ್ರಮ ಡಾ. ಫಿಲ್ನ ನಿರೂಪಕ, ಇದರಲ್ಲಿ ಹೋಸ್ಟ್ ತನ್ನ ಭಾಗವಹಿಸುವವರಿಗೆ ಅವರ ಸಮಸ್ಯೆಗಳಿಗೆ ಪರಿಹಾರಗಳನ್ನು ನೀಡುತ್ತದೆ.
ಒನ್ಸ್ ಅಪಾನ್ ಎ ಟೈಮ್ ಇನ್ ಸಿಯಾಟಲ್
2000 ರ ದಶಕದ ಆರಂಭದಲ್ಲಿ , ಅವರು ಅಧಿಕೃತ ಶೀರ್ಷಿಕೆಯೊಂದಿಗೆ ಅಮೆಜಾನ್ನಲ್ಲಿ ಸ್ಥಾನವನ್ನು ಹೊಂದಿದ್ದರು ದುರಂತದ ಮಾಸ್ಟರ್, ಗೇಮ್ಡೇ ಕಾರ್ಯಕ್ರಮವನ್ನು ರಚಿಸಿದರು ಮತ್ತು ಮುನ್ನಡೆಸಿದರು. ಇದು ಅಗ್ನಿಶಾಮಕ ದಳದ ಅವರ ಅನುಭವವನ್ನು ಆಧರಿಸಿದೆ. GameDay ಅಮೆಜಾನ್ನ ವಿವಿಧ ವ್ಯವಸ್ಥೆಗಳು, ಸಾಫ್ಟ್ವೇರ್ ಮತ್ತು ಜನರನ್ನು ಸಂಭಾವ್ಯ ಬಿಕ್ಕಟ್ಟಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಲು, ತರಬೇತಿ ನೀಡಲು ಮತ್ತು ಸಿದ್ಧಪಡಿಸಲು ಉದ್ದೇಶಿಸಲಾಗಿದೆ.
ಅಗ್ನಿಶಾಮಕ ದಳದವರು ಬೆಂಕಿಯ ವಿರುದ್ಧ ಹೋರಾಡಲು ಅಂತಃಪ್ರಜ್ಞೆಯನ್ನು ಬೆಳೆಸಿಕೊಳ್ಳುವಂತೆಯೇ, ದೊಡ್ಡ ಪ್ರಮಾಣದ ದುರಂತ ಘಟನೆಗಳನ್ನು ಎದುರಿಸಲು ಅವರ ತಂಡವು ಅಂತಃಪ್ರಜ್ಞೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಸಹಾಯ ಮಾಡಲು ಜೆಸ್ಸಿ ಬಯಸಿದ್ದರು.
"ಗೇಮ್ಡೇ: ವಿನಾಶದ ಮೂಲಕ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ರಚಿಸುವುದು" - ಜೆಸ್ಸಿ ರಾಬಿನ್ಸ್
ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ಣಾಯಕ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ದೋಷಗಳನ್ನು ಪರಿಚಯಿಸುವ ಮೂಲಕ Amazon ಚಿಲ್ಲರೆ ಸೈಟ್ನ ಸ್ಥಿರತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.
GameDay ಒಂದು ಡ್ರಿಲ್ ಅನ್ನು ಯೋಜಿಸಲಾಗಿದೆ ಎಂದು ಇಡೀ ಕಂಪನಿಗೆ ಪ್ರಕಟಣೆಗಳ ಸರಣಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಯಿತು - ಕೆಲವೊಮ್ಮೆ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಸಂಪೂರ್ಣ ಡೇಟಾ ಕೇಂದ್ರವನ್ನು ಮುಚ್ಚುವುದು. ಯೋಜಿತ ಸ್ಥಗಿತದ ಬಗ್ಗೆ ಕನಿಷ್ಠ ವಿವರಗಳನ್ನು ಒದಗಿಸಲಾಗಿದೆ ಮತ್ತು ತಂಡಕ್ಕೆ ತಯಾರಿಸಲು ಹಲವಾರು ತಿಂಗಳುಗಳನ್ನು ನೀಡಲಾಯಿತು. ಸಿಬ್ಬಂದಿ ಸ್ಥಳೀಯ ಬಿಕ್ಕಟ್ಟನ್ನು ನಿಭಾಯಿಸಬಹುದೇ ಮತ್ತು ಅದರ ಪರಿಣಾಮಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪರಿಹರಿಸಬಹುದೇ ಎಂದು ಪರೀಕ್ಷಿಸುವುದು ವ್ಯಾಯಾಮದ ಮುಖ್ಯ ಉದ್ದೇಶವಾಗಿದೆ.
ಈ ವ್ಯಾಯಾಮಗಳ ಸಮಯದಲ್ಲಿ, ಘಟನೆಯ ಪ್ರತಿಕ್ರಿಯೆ ಕಾರ್ಯವಿಧಾನಗಳಲ್ಲಿನ ದೋಷಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಮತ್ತು ಗುರುತಿಸಲು ಮೇಲ್ವಿಚಾರಣೆ, ಎಚ್ಚರಿಕೆಗಳು ಮತ್ತು ತುರ್ತು ಕರೆಗಳಂತಹ ನಿರ್ದಿಷ್ಟ ಪರಿಕರಗಳು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಬಳಸಲಾಗಿದೆ. ಇದು ಬದಲಾದಂತೆ, ಕ್ಲಾಸಿಕ್ ವಾಸ್ತುಶಿಲ್ಪದ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸುವಲ್ಲಿ GameDay ಉತ್ತಮವಾಗಿದೆ. ಕೆಲವೊಮ್ಮೆ "ಸುಪ್ತ ದೋಷಗಳು" ಎಂದು ಕರೆಯಲ್ಪಡುವದನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಹ ಸಾಧ್ಯವಾಯಿತು - ಘಟನೆಯ ನಿಶ್ಚಿತಗಳಿಂದಾಗಿ ಸ್ವತಃ ಪ್ರಕಟವಾಗುವ ಸಮಸ್ಯೆಗಳು. ಉದಾಹರಣೆಗೆ, ಮಾನವ ನಿರ್ಮಿತ ಸಮಸ್ಯೆಯಿಂದ ಉಂಟಾದ ಅನಿರೀಕ್ಷಿತ ಅಡ್ಡ ಪರಿಣಾಮಗಳಿಂದಾಗಿ ಚೇತರಿಕೆಯ ಪ್ರಕ್ರಿಯೆಗೆ ನಿರ್ಣಾಯಕವಾದ ಘಟನೆ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳು ವಿಫಲವಾಗಿವೆ.
ಕಂಪನಿಯು ಬೆಳೆದಂತೆ, GameDay ನ ಸೈದ್ಧಾಂತಿಕ ಬ್ಲಾಸ್ಟ್ ತ್ರಿಜ್ಯವು ವಿಸ್ತರಿಸಿತು. ಅಂತಿಮವಾಗಿ, ಈ ವ್ಯಾಯಾಮಗಳನ್ನು ಕೈಬಿಡಲಾಯಿತು ಏಕೆಂದರೆ ಯೋಜನೆಗೆ ಅನುಗುಣವಾಗಿ ಕೆಲಸ ಮಾಡದಿದ್ದರೆ ಕಂಪನಿಗೆ ಸಂಭವನೀಯ ಹಾನಿ ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ. ಅಲ್ಲಿಂದೀಚೆಗೆ, ಬಿಕ್ಕಟ್ಟಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸಿಬ್ಬಂದಿಗೆ ತರಬೇತಿ ನೀಡಲು ಕಾರ್ಯಕ್ರಮವು ವಿಭಿನ್ನವಾದ, ವ್ಯಾಪಾರ-ಪರಿಣಾಮವಿಲ್ಲದ ಪ್ರಯೋಗಗಳ ಸರಣಿಯಾಗಿ ಕ್ಷೀಣಿಸಿದೆ. ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ಪ್ರಯೋಗಗಳ ಬಗ್ಗೆ ವಿವರವಾಗಿ ಹೋಗುವುದಿಲ್ಲ, ಆದರೆ ಭವಿಷ್ಯದಲ್ಲಿ ನಾನು ಹಾಗೆ ಮಾಡುತ್ತೇನೆ. ಈ ಬಾರಿ ನಾನು ಗೇಮ್ಡೇಗೆ ಆಧಾರವಾಗಿರುವ ಪ್ರಮುಖ ವಿಚಾರವನ್ನು ಚರ್ಚಿಸಲು ಬಯಸುತ್ತೇನೆ: ವಿಶ್ವಾಸಾರ್ಹತೆ ಎಂಜಿನಿಯರಿಂಗ್ (ಸ್ಥಿತಿಸ್ಥಾಪಕ ಎಂಜಿನಿಯರಿಂಗ್), ಚೋಸ್ ಎಂಜಿನಿಯರಿಂಗ್ ಎಂದೂ ಕರೆಯುತ್ತಾರೆ ().
ಮಂಗಗಳ ಉದಯ
ಆನ್ಲೈನ್ ವೀಡಿಯೊ ವಿಷಯ ಪೂರೈಕೆದಾರರಾದ ನೆಟ್ಫ್ಲಿಕ್ಸ್ ಬಗ್ಗೆ ನೀವು ಬಹುಶಃ ಕೇಳಿರಬಹುದು. ನೆಟ್ಫ್ಲಿಕ್ಸ್ ತನ್ನ ಸ್ವಂತ ಡೇಟಾ ಕೇಂದ್ರದಿಂದ AWS ಕ್ಲೌಡ್ಗೆ ಆಗಸ್ಟ್ 2008 ರಲ್ಲಿ ಚಲಿಸಲು ಪ್ರಾರಂಭಿಸಿತು. ಈ ಕ್ರಮವು ಗಂಭೀರವಾದ ಡೇಟಾಬೇಸ್ ಭ್ರಷ್ಟಾಚಾರದಿಂದ ಪ್ರೇರೇಪಿಸಲ್ಪಟ್ಟಿದೆ, ಅದು DVD ಸಾಗಣೆಯನ್ನು ಮೂರು ದಿನಗಳವರೆಗೆ ವಿಳಂಬಗೊಳಿಸಿತು (ಹೌದು, ನೆಟ್ಫ್ಲಿಕ್ಸ್ ಸ್ನೇಲ್ ಮೇಲ್ ಮೂಲಕ ಚಲನಚಿತ್ರಗಳನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸಿತು). ಕ್ಲೌಡ್ಗೆ ವಲಸೆಯು ಹೆಚ್ಚಿನ ಸ್ಟ್ರೀಮಿಂಗ್ ಲೋಡ್ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯದಿಂದ ನಡೆಸಲ್ಪಟ್ಟಿದೆ, ಜೊತೆಗೆ ಏಕಶಿಲೆಯ ವಾಸ್ತುಶಿಲ್ಪದಿಂದ ದೂರವಿರಲು ಮತ್ತು ಬಳಕೆದಾರರ ಸಂಖ್ಯೆ ಮತ್ತು ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡದ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿ ಸುಲಭವಾಗಿ ಅಳೆಯಬಹುದಾದ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ಗಳ ಕಡೆಗೆ ಚಲಿಸುವ ಬಯಕೆಯಿಂದ ನಡೆಸಲ್ಪಟ್ಟಿದೆ. ಸ್ಟ್ರೀಮಿಂಗ್ ಸೇವೆಯ ಗ್ರಾಹಕರ ಭಾಗವು 2010 ಮತ್ತು 2011 ರ ನಡುವೆ ಮೊದಲು AWS ಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿತು, ನಂತರ ಎಂಟರ್ಪ್ರೈಸ್ IT ಮತ್ತು ಎಲ್ಲಾ ಇತರ ರಚನೆಗಳು. ನೆಟ್ಫ್ಲಿಕ್ಸ್ನ ಸ್ವಂತ ಡೇಟಾ ಸೆಂಟರ್ 2016 ರಲ್ಲಿ ಮುಚ್ಚಲ್ಪಟ್ಟಿದೆ. ಕಂಪನಿಯು ಲಭ್ಯತೆಯನ್ನು ಒಂದು ಚಲನಚಿತ್ರವನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಯಶಸ್ವಿ ಪ್ರಯತ್ನಗಳ ಸಂಖ್ಯೆಯ ಅನುಪಾತವಾಗಿ ಒಟ್ಟು ಸಂಖ್ಯೆಗೆ ಅಳೆಯುತ್ತದೆ. ಆಗಾಗ್ಗೆ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ). ನೆಟ್ಫ್ಲಿಕ್ಸ್ನ ಜಾಗತಿಕ ವಾಸ್ತುಶಿಲ್ಪವು ಮೂರು AWS ಪ್ರದೇಶಗಳನ್ನು ವ್ಯಾಪಿಸಿದೆ. ಹೀಗಾಗಿ, ಒಂದು ಪ್ರದೇಶದಲ್ಲಿ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಿದರೆ, ಬಳಕೆದಾರರನ್ನು ಇತರರಿಗೆ ಮರುನಿರ್ದೇಶಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಕಂಪನಿಯು ಹೊಂದಿದೆ.
ನನ್ನ ನೆಚ್ಚಿನ ಉಲ್ಲೇಖಗಳಲ್ಲಿ ಒಂದನ್ನು ನಾನು ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ:
“ಅಡೆತಡೆಗಳು ಅನಿವಾರ್ಯ; ಅಂತಿಮವಾಗಿ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯು ಕಾಲಾನಂತರದಲ್ಲಿ ಕುಸಿಯುತ್ತದೆ. - ವರ್ನರ್ ವೋಗೆಲ್ಸ್
ವಾಸ್ತವವಾಗಿ, ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿನ ವೈಫಲ್ಯಗಳು, ವಿಶೇಷವಾಗಿ ದೊಡ್ಡ-ಪ್ರಮಾಣದವುಗಳು, ಕ್ಲೌಡ್ನಲ್ಲಿಯೂ ಸಹ ಅನಿವಾರ್ಯವಾಗಿವೆ. ಆದಾಗ್ಯೂ, AWS ಕ್ಲೌಡ್ ಮತ್ತು ಅದರ ಪುನರುಕ್ತಿ ಮೂಲಗಳು-ನಿರ್ದಿಷ್ಟವಾಗಿ , ಇದನ್ನು ನಿರ್ಮಿಸಿದ ಮೇಲೆ, ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ ಸೇವೆಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲು ಯಾರಿಗಾದರೂ ಅನುಮತಿಸುತ್ತದೆ.
ಪುನರುಕ್ತಿ ತತ್ವಗಳನ್ನು ಬಳಸುವುದು (ಪುನರುಕ್ತಿ) ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕತೆಯಲ್ಲಿ ಕ್ರಮೇಣ ಕುಸಿತ (ಸುಂದರವಾದ ಅವನತಿ), ನೆಟ್ಫ್ಲಿಕ್ಸ್ ಅಂತಿಮ ಬಳಕೆದಾರರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದೆ.
ಮೊದಲಿನಿಂದಲೂ, ನೆಟ್ಫ್ಲಿಕ್ಸ್ ಕಟ್ಟುನಿಟ್ಟಾದ ವಾಸ್ತುಶಿಲ್ಪದ ತತ್ವಗಳಿಗೆ ಬದ್ಧವಾಗಿದೆ. AWS ನಲ್ಲಿ ಅವರು ನಿಯೋಜಿಸಿದ ಮೊದಲ ಅಪ್ಲಿಕೇಶನ್ಗಳಲ್ಲಿ ಒಂದು ಅವರದು — ಸ್ವಯಂ-ಸ್ಕೇಲಿಂಗ್ ಸ್ಟೇಟ್ಲೆಸ್ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ಗಳನ್ನು ಬೆಂಬಲಿಸಲು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಯಾವುದೇ ನಿದರ್ಶನವನ್ನು ನಿಲ್ಲಿಸಬಹುದು ಮತ್ತು ಯಾವುದೇ ಸ್ಥಿತಿಯ ನಷ್ಟವಿಲ್ಲದೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬದಲಾಯಿಸಬಹುದು. ಚೋಸ್ ಮಂಕಿ ಯಾರೂ ಈ ತತ್ವವನ್ನು ಉಲ್ಲಂಘಿಸುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಸೂಚನೆ. ಅನುವಾದ.: ಮೂಲಕ, ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಎಂಬ ಅನಲಾಗ್ ಇದೆ , ಅವರ ಅಭಿವೃದ್ಧಿ ಈ ವರ್ಷದ ಮಾರ್ಚ್ನಲ್ಲಿ ನಿಂತುಹೋಗಿದೆ.
ನೆಟ್ಫ್ಲಿಕ್ಸ್ ಪ್ರತಿ ಸೇವೆಯನ್ನು ಮೂರು ಲಭ್ಯತೆಯ ವಲಯಗಳಲ್ಲಿ ವಿತರಿಸುವ ಮತ್ತೊಂದು ನಿಯಮವನ್ನು ಹೊಂದಿದೆ. ಅವುಗಳಲ್ಲಿ ಎರಡು ಮಾತ್ರ ಲಭ್ಯವಿದ್ದರೆ ಅದು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಬೇಕು. ಈ ನಿಯಮವನ್ನು ಅನುಸರಿಸುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಲಭ್ಯತೆಯ ವಲಯಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಹೆಚ್ಚು ಜಾಗತಿಕ ಮಟ್ಟದಲ್ಲಿ ಎಲ್ಲಾ ನೆಟ್ಫ್ಲಿಕ್ಸ್ ಬಳಕೆದಾರರಿಗೆ ಯಾವುದೇ ಮೂರು ಪ್ರದೇಶಗಳಿಂದ ಸೇವೆ ಸಲ್ಲಿಸಬಹುದೆಂದು ಖಚಿತಪಡಿಸಲು ಸಂಪೂರ್ಣ AWS ಪ್ರದೇಶವನ್ನು ಮುಚ್ಚುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ಅವರು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಪ್ರತಿ ಕೆಲವು ವಾರಗಳಿಗೊಮ್ಮೆ ಈ ವ್ಯಾಪಕ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುತ್ತಾರೆ.
ಅಂತಿಮವಾಗಿ, ನೆಟ್ಫ್ಲಿಕ್ಸ್ ಹೆಚ್ಚು ಕೇಂದ್ರೀಕೃತವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಮತ್ತು ಸ್ಟೋರೇಜ್ ಆರ್ಕಿಟೆಕ್ಚರ್ನೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಲು ಸಹಾಯ ಮಾಡಲು. ಚೋಸ್ ಇಂಜಿನಿಯರಿಂಗ್ ಪುಸ್ತಕದಲ್ಲಿ ನೀವು ಈ ತಂತ್ರಗಳ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳಬಹುದು, ಈ ವಿಷಯದಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿರುವ ಯಾರಿಗಾದರೂ ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.
"ಪ್ರಾದೇಶಿಕ ಸ್ಥಗಿತಗಳನ್ನು ಅನುಕರಿಸುವ ನಿಯಮಿತ ಆಧಾರದ ಮೇಲೆ ಪ್ರಯೋಗಗಳನ್ನು ನಡೆಸುವ ಮೂಲಕ, ನಾವು ವಿವಿಧ ಸಿಸ್ಟಮ್ ನ್ಯೂನತೆಗಳನ್ನು ಮೊದಲೇ ಗುರುತಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಾಯಿತು." -
ಇಂದು ಅವ್ಯವಸ್ಥೆಯ ಎಂಜಿನಿಯರಿಂಗ್ ತತ್ವಗಳು ; ಅವರಿಗೆ ಈ ಕೆಳಗಿನ ವ್ಯಾಖ್ಯಾನವನ್ನು ನೀಡಲಾಗಿದೆ:
"ಚೋಸ್ ಎಂಜಿನಿಯರಿಂಗ್ ಎನ್ನುವುದು ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ಉದ್ಭವಿಸುವ ವಿವಿಧ ಅಡಚಣೆಗಳನ್ನು ತಡೆದುಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಪ್ರಯೋಗಗಳನ್ನು ನಡೆಸುವುದನ್ನು ಒಳಗೊಂಡಿರುವ ಒಂದು ವಿಧಾನವಾಗಿದೆ." -
ಆದಾಗ್ಯೂ, ಅವನಲ್ಲಿ ಅವ್ಯವಸ್ಥೆ ಎಂಜಿನಿಯರಿಂಗ್ಗೆ ಸಮರ್ಪಿಸಲಾಗಿದೆ, , ನೆಟ್ಫ್ಲಿಕ್ಸ್ನ ಕ್ಲೌಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ನ ಮಾಜಿ ಸೃಷ್ಟಿಕರ್ತರು ಕಂಪನಿಯು ಎಲ್ಲಾ-ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಹೋಗಲು ಸಹಾಯ ಮಾಡಿದರು, ಅವ್ಯವಸ್ಥೆ ಎಂಜಿನಿಯರಿಂಗ್ನ ಪರ್ಯಾಯ ವ್ಯಾಖ್ಯಾನವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಿದರು. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಇದು ಹೆಚ್ಚು ನಿಖರ ಮತ್ತು ಸ್ಥಾಪಿತವಾಗಿದೆ:
"ಚೋಸ್ ಎಂಜಿನಿಯರಿಂಗ್ ವೈಫಲ್ಯದ ಪರಿಣಾಮಗಳನ್ನು ತಗ್ಗಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಪ್ರಯೋಗವಾಗಿದೆ."
ವಾಸ್ತವವಾಗಿ, ವೈಫಲ್ಯಗಳು ಸಾರ್ವಕಾಲಿಕ ಸಂಭವಿಸುತ್ತವೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ. ಸರಿಯಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಿದಾಗ, ಅವರು ಅಂತಿಮ ಬಳಕೆದಾರರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಾರದು. ಅವ್ಯವಸ್ಥೆ ಎಂಜಿನಿಯರಿಂಗ್ನ ಮುಖ್ಯ ಗುರಿಯು ಸರಿಯಾಗಿ ಪರಿಹರಿಸಲಾಗದ ಸಮಸ್ಯೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು.
ಅವ್ಯವಸ್ಥೆಯನ್ನು ಸೃಷ್ಟಿಸಲು ಅಗತ್ಯವಾದ ಪರಿಸ್ಥಿತಿಗಳು
ನೀವು ಅವ್ಯವಸ್ಥೆ ಎಂಜಿನಿಯರಿಂಗ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ಸಂಸ್ಥೆಯ ಎಲ್ಲಾ ಹಂತಗಳಲ್ಲಿ ಸುಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಕೆಲಸವನ್ನು ನೀವು ಮಾಡಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ದೋಷ-ಸಹಿಷ್ಣು ವ್ಯವಸ್ಥೆಗಳನ್ನು ರಚಿಸುವುದು ಕೇವಲ ಸಾಫ್ಟ್ವೇರ್ ಬಗ್ಗೆ ಅಲ್ಲ. ಇದು ಮಟ್ಟದಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮೂಲಸೌಕರ್ಯ, ಮೇಲೆ ಹರಡುತ್ತದೆ ನೆಟ್ವರ್ಕ್ ಮತ್ತು ಡೇಟಾ, ರಚನೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಅನ್ವಯಗಳನ್ನು, ಮತ್ತು ಅಂತಿಮವಾಗಿ ಆವರಿಸುತ್ತದೆ ಜನರು ಮತ್ತು ಸಂಸ್ಕೃತಿ. ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ ಮಾದರಿಗಳು ಮತ್ತು ವೈಫಲ್ಯಗಳ ಬಗ್ಗೆ ನಾನು ಹಿಂದೆ ವ್ಯಾಪಕವಾಗಿ ಬರೆದಿದ್ದೇನೆ (, , и ) ಮತ್ತು ನಾನು ಈಗ ಇದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಸ್ವಲ್ಪ ಜ್ಞಾಪನೆ ಇಲ್ಲದೆ ನಾನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಅವ್ಯವಸ್ಥೆಯನ್ನು ಪರಿಚಯಿಸುವ ಮೊದಲು ಅಗತ್ಯವಿರುವ ಕೆಲವು ಅಂಶಗಳು (ಪಟ್ಟಿಯು ಸಮಗ್ರವಾಗಿಲ್ಲ)
ಅವ್ಯವಸ್ಥೆಯ ಎಂಜಿನಿಯರಿಂಗ್ನ ಹಂತಗಳು
ಅವ್ಯವಸ್ಥೆಯ ಎಂಜಿನಿಯರಿಂಗ್ನ ಮೂಲತತ್ವವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ ಅಲ್ಲ ಮಂಗಗಳನ್ನು ಕಾಡಿಗೆ ಬಿಡುವುದು ಮತ್ತು ಯಾವುದೇ ಉದ್ದೇಶವಿಲ್ಲದೆ ಎಲ್ಲವನ್ನೂ ನಾಶಮಾಡಲು ಬಿಡುವುದು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕ್ಷುಬ್ಧ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ತಡೆದುಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂದು ನೋಡಲು ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಪ್ರಯೋಗಗಳ ಮೂಲಕ ನಿಯಂತ್ರಿತ ಪರಿಸರದಲ್ಲಿ ಸಿಸ್ಟಮ್ನ ಕೆಲವು ಅಂಶಗಳನ್ನು ಅಡ್ಡಿಪಡಿಸುವುದು ಈ ಶಿಸ್ತಿನ ಅಂಶವಾಗಿದೆ.
ಇದನ್ನು ಮಾಡಲು, ಕೆಳಗಿನ ಚಿತ್ರದಲ್ಲಿ ವಿವರಿಸಿರುವ ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ, ಔಪಚಾರಿಕ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನೀವು ಅನುಸರಿಸಬೇಕು. ನಿಮ್ಮ ಸಿಸ್ಟಂನ ಸ್ಥಿರ ಸ್ಥಿತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದರಿಂದ ಊಹೆಯನ್ನು ರೂಪಿಸಲು, ಅದನ್ನು ಪರೀಕ್ಷಿಸಲು ಮತ್ತು ಅಂತಿಮವಾಗಿ ಪ್ರಯೋಗದಿಂದ ಪಡೆದ ಅನುಭವವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಮತ್ತು ಸಿಸ್ಟಮ್ನ ಸ್ಥಿರತೆಯನ್ನು ಸುಧಾರಿಸಲು ಇದು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಅವ್ಯವಸ್ಥೆಯ ಎಂಜಿನಿಯರಿಂಗ್ನ ಹಂತಗಳು
1. ಸ್ಥಿರ ಸ್ಥಿತಿ
ಅವ್ಯವಸ್ಥೆ ಎಂಜಿನಿಯರಿಂಗ್ನ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ವ್ಯವಸ್ಥೆಯ ನಡವಳಿಕೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು.
ಯಾಕೆ? ಇದು ಸರಳವಾಗಿದೆ: ಕೃತಕ ವೈಫಲ್ಯವನ್ನು ಪರಿಚಯಿಸಿದ ನಂತರ, ಸಿಸ್ಟಮ್ ಚೆನ್ನಾಗಿ ಅಧ್ಯಯನ ಮಾಡಿದ ಸ್ಥಿರ ಸ್ಥಿತಿಗೆ ಮರಳಿದೆ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಪ್ರಯೋಗವು ಇನ್ನು ಮುಂದೆ ಅದರ ಸಾಮಾನ್ಯ ನಡವಳಿಕೆಯನ್ನು ಹಸ್ತಕ್ಷೇಪ ಮಾಡುವುದಿಲ್ಲ.
ಆಂತರಿಕ ಸಿಸ್ಟಮ್ ಗುಣಲಕ್ಷಣಗಳ ಮೇಲೆ (ಪ್ರೊಸೆಸರ್, ಮೆಮೊರಿ, ಇತ್ಯಾದಿ) ಗಮನಹರಿಸದೆ, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಬಳಕೆದಾರರ ಅನುಭವಕ್ಕೆ ಲಿಂಕ್ ಮಾಡುವ ಅಳೆಯಬಹುದಾದ ಔಟ್ಪುಟ್ಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವುದು ಇಲ್ಲಿ ಪ್ರಮುಖವಾಗಿದೆ. ಈ ಔಟ್ಪುಟ್ಗಳು ಸ್ಥಿರ ಸ್ಥಿತಿಯಲ್ಲಿರಲು, ಸಿಸ್ಟಮ್ನ ಗಮನಿಸಿದ ನಡವಳಿಕೆಯು ಊಹಿಸಬಹುದಾದ ಮಾದರಿಯನ್ನು ಹೊಂದಿರಬೇಕು, ಆದರೆ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ವೈಫಲ್ಯ ಸಂಭವಿಸಿದಾಗ ಗಮನಾರ್ಹವಾಗಿ ಬದಲಾಗುತ್ತದೆ.
ಗಮನದಲ್ಲಿಟ್ಟುಕೊಳ್ಳುವುದು , ಮೇಲೆ ಆಡ್ರಿಯನ್ ಕಾಕ್ಕ್ರಾಫ್ಟ್ ಪ್ರಸ್ತಾಪಿಸಿದ್ದಾರೆ, ನಿಯಂತ್ರಣವಿಲ್ಲದ ಗ್ಲಿಚ್ ಅನಿರೀಕ್ಷಿತ ಸಮಸ್ಯೆಯನ್ನು ಉಂಟುಮಾಡಿದಾಗ ಈ ಸ್ಥಿರ ಸ್ಥಿತಿ ಬದಲಾಗುತ್ತದೆ ಮತ್ತು ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗವನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಬೇಕು ಎಂದು ಸಂಕೇತಿಸುತ್ತದೆ.
ಸ್ಥಿರ ಸ್ಥಿತಿಗಳ ಉದಾಹರಣೆಯಾಗಿ, ಅಮೆಜಾನ್ನ ಅನುಭವವನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ. ಕಂಪನಿಯು ತನ್ನ ಸ್ಥಿರ ಸ್ಥಿತಿಯ ಮೆಟ್ರಿಕ್ಗಳಲ್ಲಿ ಒಂದಾಗಿ ಆದೇಶದ ಪರಿಮಾಣವನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಉತ್ತಮ ಕಾರಣಕ್ಕಾಗಿ. 2007 ರಲ್ಲಿ, ಹಿಂದೆ ಅಮೆಜಾನ್ನ ಗ್ರೆಗ್ ಲಿಂಡೆನ್, ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರಯೋಗವನ್ನು ಹೇಗೆ ವಿವರಿಸಿದರು ನಾನು ವೆಬ್ಸೈಟ್ ಪುಟಗಳ ಲೋಡಿಂಗ್ ಸಮಯವನ್ನು 100 ಎಂಎಸ್ ಹೆಚ್ಚಳದಲ್ಲಿ ನಿಧಾನಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸಿದೆ ಮತ್ತು ಸಣ್ಣ ವಿಳಂಬಗಳು ಸಹ ಆದಾಯದಲ್ಲಿ ಗಂಭೀರ ಕುಸಿತಕ್ಕೆ ಕಾರಣವಾಗುತ್ತವೆ ಎಂದು ಕಂಡುಕೊಂಡೆ. 100 ms ಮೂಲಕ ಲೋಡಿಂಗ್ ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚಳದೊಂದಿಗೆ, ಆದೇಶಗಳ ಸಂಖ್ಯೆ (ಮತ್ತು ಆದ್ದರಿಂದ ಮಾರಾಟ) 1% ರಷ್ಟು ಕಡಿಮೆಯಾಗಿದೆ. ಇದಕ್ಕಾಗಿಯೇ ಆದೇಶಗಳ ಸಂಖ್ಯೆಯು ಸ್ಥಿರ ಸ್ಥಿತಿಯ ಮೆಟ್ರಿಕ್ಗಳಿಗೆ ಅತ್ಯುತ್ತಮ ಅಭ್ಯರ್ಥಿಯಾಗಿದೆ.
ನೆಟ್ಫ್ಲಿಕ್ಸ್ ಪ್ಲೇಬ್ಯಾಕ್ ಪ್ರಾರಂಭದೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಸರ್ವರ್-ಸೈಡ್ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಬಳಸುತ್ತದೆ - "ಪ್ಲೇ" ಬಟನ್ನಲ್ಲಿನ ಕ್ಲಿಕ್ಗಳ ಸಂಖ್ಯೆ. ಅವರು SPS ನ ನಡವಳಿಕೆಯಲ್ಲಿನ ಮಾದರಿಯನ್ನು ಗಮನಿಸಿದರು (ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಪ್ರಾರಂಭ) ಸೂಚಕ ಮತ್ತು ಸಿಸ್ಟಮ್ ವೈಫಲ್ಯಗಳು ಸಂಭವಿಸಿದಾಗ ಅದರ ಗಮನಾರ್ಹ ಏರಿಳಿತಗಳು. ಮೆಟ್ರಿಕ್ ಅನ್ನು "ನೆಟ್ಫ್ಲಿಕ್ಸ್ ಪಲ್ಸ್" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ().
ಅಮೆಜಾನ್ನ ಆರ್ಡರ್ ಸಂಖ್ಯೆಗಳು ಮತ್ತು ನೆಟ್ಫ್ಲಿಕ್ಸ್ನ ಪಲ್ಸ್ ಸ್ಥಿರ ಸ್ಥಿತಿಯ ಅತ್ಯುತ್ತಮ ಬ್ಯಾರೋಮೀಟರ್ಗಳಾಗಿವೆ ಏಕೆಂದರೆ ಅವುಗಳು ಬಳಕೆದಾರರ ಅನುಭವ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಒಂದೇ, ಅಳೆಯಬಹುದಾದ ಮತ್ತು ಹೆಚ್ಚು ಊಹಿಸಬಹುದಾದ ಮೆಟ್ರಿಕ್ಗೆ ಸಂಯೋಜಿಸುತ್ತವೆ.
ಅಳೆಯಿರಿ, ಅಳೆಯಿರಿ ಮತ್ತು ಮತ್ತೆ ಅಳೆಯಿರಿ
ನೀವು ಸಿಸ್ಟಮ್ನ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಸರಿಯಾಗಿ ಸೆರೆಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಸ್ಥಿರ ಸ್ಥಿತಿಯಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು (ಅಥವಾ ಪತ್ತೆಹಚ್ಚಲು) ನಿಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಎಂದು ಹೇಳದೆ ಹೋಗುತ್ತದೆ. ನೆಟ್ವರ್ಕ್, ಹಾರ್ಡ್ವೇರ್ನಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಜನರಿಗೆ ಎಲ್ಲಾ ನಿಯತಾಂಕಗಳು/ಸೂಚಕಗಳನ್ನು ಓದಲು ವಿಶೇಷ ಗಮನ ಕೊಡಿ. ಈ ಅಳತೆಗಳ ಗ್ರಾಫ್ಗಳನ್ನು ಬರೆಯಿರಿ, ಅವು ಕಾಲಾನಂತರದಲ್ಲಿ ಬದಲಾಗದಿದ್ದರೂ ಸಹ. ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲದ ಪರಸ್ಪರ ಸಂಬಂಧಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಿಮಗೆ ಆಶ್ಚರ್ಯವಾಗುತ್ತದೆ.
"ಎಂಜಿನಿಯರ್ಗಳು ಅವರು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬಹುದಾದ ಅಥವಾ ಗ್ರಾಫ್ ಮಾಡಬಹುದಾದ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾದಷ್ಟು ಸುಲಭಗೊಳಿಸಿ." -
2. ಕಲ್ಪನೆ
ಸ್ಥಿರ ಸ್ಥಿತಿಯೊಂದಿಗೆ ವ್ಯವಹರಿಸಿದ ನಂತರ, ನೀವು ಊಹೆಯನ್ನು ರೂಪಿಸಲು ಮುಂದುವರಿಯಬಹುದು.
- ಶಿಫಾರಸು ಎಂಜಿನ್ ನಿಂತರೆ ಏನು?
- ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಕಡಿಮೆಯಾದರೆ ಏನು?
- ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು ವಿಫಲವಾದರೆ ಏನು?
- ಲೇಟೆನ್ಸಿ 300ms ಹೆಚ್ಚಾದರೆ ಏನು?
- ಮಾಸ್ಟರ್ ಡೇಟಾಬೇಸ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ ಏನು?
ಸಹಜವಾಗಿ, ನೀವು ಕೇವಲ ಒಂದು ಊಹೆಯನ್ನು ಮಾತ್ರ ಆರಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಅನಗತ್ಯವಾಗಿ ಸಂಕೀರ್ಣಗೊಳಿಸಬಾರದು. ಚಿಕ್ಕದಾಗಿ ಪ್ರಾರಂಭಿಸಿ. ನಾನು ಸಿಬ್ಬಂದಿ ಊಹೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲು ಇಷ್ಟಪಡುತ್ತೇನೆ. ಬಗ್ಗೆ ಕೇಳಿದ್ದೀರಾ ಬಸ್ ಅಂಶ ()? ಬಸ್ ಅಂಶವು ತಂಡದ ಸದಸ್ಯರ ನಡುವೆ ಅಸಮಾನವಾಗಿ ವಿತರಿಸಲ್ಪಟ್ಟ ಜ್ಞಾನಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಅಪಾಯದ ಅಳತೆಯಾಗಿದೆ. ಅದರ ಭಾಗವಹಿಸುವವರ ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯನ್ನು ಲೆಕ್ಕಹಾಕಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಹಠಾತ್ ನಷ್ಟದ ನಂತರ ಜ್ಞಾನ ಅಥವಾ ಅನುಭವದ ಕೊರತೆಯಿಂದಾಗಿ ಯೋಜನೆಯು ನಿಲ್ಲುತ್ತದೆ.
ಅನೇಕ ಕಂಪನಿಗಳು ತಾಂತ್ರಿಕ ತಜ್ಞರನ್ನು ಹೊಂದಿದ್ದು, ಅವರ ಹಠಾತ್ ಕಣ್ಮರೆ ("ಬಸ್ನಿಂದ ಹೊಡೆಯುವುದು") ಯೋಜನೆ ಮತ್ತು ತಂಡದ ಮೇಲೆ ವಿನಾಶಕಾರಿ ಪರಿಣಾಮವನ್ನು ಬೀರುತ್ತದೆ. ಈ ಜನರನ್ನು ಗುರುತಿಸಿ ಮತ್ತು ಅವರ ಮೇಲೆ ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗಗಳನ್ನು ನಡೆಸಿ: ಉದಾಹರಣೆಗೆ, ಅವರ ಕಂಪ್ಯೂಟರ್ಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಹೋಗಿ ಮತ್ತು ದಿನಕ್ಕೆ ಅವರನ್ನು ಮನೆಗೆ ಕಳುಹಿಸಿ, ನಂತರ (ಸಾಮಾನ್ಯವಾಗಿ ಅಸ್ತವ್ಯಸ್ತವಾಗಿರುವ) ಫಲಿತಾಂಶಗಳನ್ನು ಗಮನಿಸಿ.
ಸಮಸ್ಯೆಯನ್ನು ಎಲ್ಲರಿಗೂ ಸಾಮಾನ್ಯಗೊಳಿಸಿ!
ಆಕರ್ಷಿಸು ಇಡೀ ತಂಡ ಒಂದು ಊಹೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು. ಪ್ರತಿಯೊಬ್ಬರೂ ಬುದ್ದಿಮತ್ತೆಯಲ್ಲಿ ಭಾಗವಹಿಸಲಿ: ಉತ್ಪನ್ನ ಮಾಲೀಕರು, ತಾಂತ್ರಿಕ ವ್ಯವಸ್ಥಾಪಕರು, ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು ಮುಂಭಾಗದ ಡೆವಲಪರ್ಗಳು, ವಿನ್ಯಾಸಕರು, ವಾಸ್ತುಶಿಲ್ಪಿಗಳು, ಇತ್ಯಾದಿ. ಉತ್ಪನ್ನದೊಂದಿಗೆ ಒಂದಲ್ಲ ಒಂದು ರೀತಿಯಲ್ಲಿ ಸಂಪರ್ಕ ಹೊಂದಿರುವ ಪ್ರತಿಯೊಬ್ಬರೂ.
ಮೊದಲಿಗೆ, "ಏನಾದರೆ...?" ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಪ್ರತಿಯೊಬ್ಬರೂ ತಮ್ಮದೇ ಆದ ಉತ್ತರವನ್ನು ಬರೆಯಲು ಹೇಳಿ. ಒಂದು ಕಾಗದದ ಮೇಲೆ. ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಪ್ರತಿಯೊಬ್ಬರೂ ವಿಭಿನ್ನ ಉತ್ತರವನ್ನು ಹೊಂದಿರುತ್ತಾರೆ ಎಂದು ನೀವು ನೋಡುತ್ತೀರಿ ಮತ್ತು ತಂಡದ ಕೆಲವರು ಇಲ್ಲಿಯವರೆಗೆ ಈ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಯೋಚಿಸಿಲ್ಲ ಎಂದು ನೀವು ತಿಳಿದುಕೊಳ್ಳುತ್ತೀರಿ.
ಈ ಹಂತದಲ್ಲಿ ವಿರಾಮಗೊಳಿಸಿ ಮತ್ತು ಉತ್ಪನ್ನವು "ಏನಾದರೆ...?" ನಲ್ಲಿ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ತಂಡದ ಸದಸ್ಯರು ವಿಭಿನ್ನ ಆಲೋಚನೆಗಳನ್ನು ಏಕೆ ಹೊಂದಿದ್ದಾರೆಂದು ಚರ್ಚಿಸಿ. ಅದರ ವಿಶೇಷಣಗಳಿಗೆ ಹಿಂತಿರುಗಿ ಮತ್ತು ಮುಂದೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಒಳ್ಳೆಯ ಕಲ್ಪನೆ ಇದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
ಉದಾಹರಣೆಗೆ, ಮೇಲೆ ತಿಳಿಸಿದ Amazon ಚಿಲ್ಲರೆ ಸೈಟ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ. ಮುಖಪುಟದಲ್ಲಿ ವರ್ಗದ ಪ್ರಕಾರ ಶಾಪ್ ಲೋಡ್ ಆಗುವುದನ್ನು ನಿಲ್ಲಿಸಿದರೆ ಏನು?
ನಾನು 404 ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕೇ? ಕೆಳಗಿನ ಸ್ಕ್ರೀನ್ಶಾಟ್ನಲ್ಲಿರುವಂತೆ ಖಾಲಿ ಜಾಗವನ್ನು ಬಿಟ್ಟು ಪುಟವನ್ನು ಲೋಡ್ ಮಾಡುವುದು ಯೋಗ್ಯವಾಗಿದೆಯೇ?
ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ತ್ಯಾಗ ಮಾಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ ಮತ್ತು ಉದಾಹರಣೆಗೆ, ಪುಟವನ್ನು ವಿಸ್ತರಿಸಲು ಮತ್ತು ದೋಷವನ್ನು ಮರೆಮಾಡಲು ಅನುಮತಿಸುವುದೇ?
ಮತ್ತು ಅದು UI ಬದಿಯಲ್ಲಿದೆ. ಬ್ಯಾಕೆಂಡ್ನಲ್ಲಿ ಏನಾಗಬೇಕು? ಎಚ್ಚರಿಕೆಗಳನ್ನು ಕಳುಹಿಸಬೇಕೇ? ಬಳಕೆದಾರರು ಮುಖಪುಟವನ್ನು ಲೋಡ್ ಮಾಡಿದಾಗಲೆಲ್ಲಾ ವಿಫಲವಾದ ಸೇವೆಯು ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ಮುಂದುವರಿಸಬೇಕೇ ಅಥವಾ ಬ್ಯಾಕೆಂಡ್ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕಡಿತಗೊಳಿಸಬೇಕೇ?
ಮತ್ತು ಕೊನೆಯ ವಿಷಯ. ತೊಂದರೆಯನ್ನುಂಟುಮಾಡುತ್ತದೆ ಎಂದು ನಿಮಗೆ ಮೊದಲೇ ತಿಳಿದಿರುವ ಊಹೆಯನ್ನು ದಯವಿಟ್ಟು ರೂಪಿಸಬೇಡಿ! ನೀವು ಸ್ಥಿರವೆಂದು ಭಾವಿಸುವ ವ್ಯವಸ್ಥೆಯ ಭಾಗಗಳೊಂದಿಗೆ ಪ್ರಯೋಗ ಮಾಡಿ - ಎಲ್ಲಾ ನಂತರ, ಇದು ಪ್ರಯೋಗದ ಸಂಪೂರ್ಣ ಅಂಶವಾಗಿದೆ.
3. ಪ್ರಯೋಗವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿ ಮತ್ತು ನಡೆಸುವುದು
- ಒಂದು ಊಹೆಯನ್ನು ಆರಿಸಿ;
- ಪ್ರಯೋಗದ ವ್ಯಾಪ್ತಿಯನ್ನು ವಿವರಿಸಿ;
- ಮಾಪನ ಮಾಡಲಾಗುವ ಸಂಬಂಧಿತ ಸೂಚಕಗಳನ್ನು ಗುರುತಿಸಿ;
- ಸಂಸ್ಥೆಗೆ ಸೂಚಿಸಿ.
ಇಂದು ಅನೇಕ ಜನರು, ಹಾಗೆಯೇ ಸೈಟ್ , ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅವ್ಯವಸ್ಥೆ ಎಂಜಿನಿಯರಿಂಗ್ ಕಲ್ಪನೆಯನ್ನು ಉತ್ತೇಜಿಸಿ. ಇದು ಅಂತಿಮ ಗುರಿಯಾಗಿದ್ದರೂ, ಹೆಚ್ಚಿನ ಸಂಸ್ಥೆಗಳು ಈ ವಿಧಾನದಿಂದ ಬೆದರುತ್ತವೆ, ಆದ್ದರಿಂದ ಪ್ರಾರಂಭಿಸಲು ಇದು ಉತ್ತಮ ಸ್ಥಳವಲ್ಲ.
ನನಗೆ, ಅವ್ಯವಸ್ಥೆ ಎಂಜಿನಿಯರಿಂಗ್ ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಗಳ ವಿವಿಧ ಅಂಶಗಳ ನಾಶ ಮಾತ್ರವಲ್ಲ. ಇದೊಂದು ಪ್ರಯಾಣ. ಜ್ಞಾನದ ಜಗತ್ತಿನಲ್ಲಿ ಒಂದು ಪ್ರಯಾಣ, ನಿಯಂತ್ರಿತ ಪರಿಸರದಲ್ಲಿ ವ್ಯವಸ್ಥೆಗಳ ನಾಶದಂತಹ ಚಟುವಟಿಕೆಯೊಂದಿಗೆ ಬೇರ್ಪಡಿಸಲಾಗದಂತೆ ಸಂಬಂಧ ಹೊಂದಿದೆ - ಯಾವುದೇ ಪರಿಸರ, ಅದು ಸ್ಥಳೀಯ ದೇವ್ ಪರಿಸರ, ಬೀಟಾ, ಸ್ಟೇಜಿಂಗ್ ಅಥವಾ ಪ್ರಾಡ್ ಆಗಿರಬಹುದು. ಪ್ರಕ್ಷುಬ್ಧ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ತಡೆದುಕೊಳ್ಳುವ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನ ಸಾಮರ್ಥ್ಯದಲ್ಲಿ ವಿಶ್ವಾಸವನ್ನು ಬೆಳೆಸಲು ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಪ್ರಯೋಗಗಳ ಮೂಲಕ ಅಡ್ಡಿಪಡಿಸಿ. "ವಿಶ್ವಾಸವನ್ನು ನಿರ್ಮಿಸುವುದು” ಇಲ್ಲಿ ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ಗೊಂದಲಮಯ ಎಂಜಿನಿಯರಿಂಗ್ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಅಭ್ಯಾಸಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅಗತ್ಯವಿರುವ ಸಾಂಸ್ಕೃತಿಕ ಬದಲಾವಣೆಗಳಿಗೆ ಪೂರ್ವಗಾಮಿಯಾಗಿದೆ.
ಪ್ರಾಮಾಣಿಕವಾಗಿ, ಹೆಚ್ಚಿನ ತಂಡಗಳು ಉತ್ಪಾದನೆಯಲ್ಲದ ವಾತಾವರಣದಲ್ಲಿಯೂ ಸಹ ವಿಷಯಗಳನ್ನು ಒಡೆಯುವುದರಿಂದ ಬಹಳಷ್ಟು ಕಲಿಯುತ್ತವೆ. ಕೇವಲ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿ docker stop database ನಿಮ್ಮ ಸ್ಥಳೀಯ ಪರಿಸರದಲ್ಲಿ ಮತ್ತು ಯಾವುದೇ ಪರಿಣಾಮಗಳಿಲ್ಲದೆ ನೀವು ಈ ಸಮಸ್ಯೆಯನ್ನು ನಿಭಾಯಿಸಬಹುದೇ ಎಂದು ನೋಡಿ. ಹಾಗಾಗದಿರಲು ಹೆಚ್ಚಿನ ಅವಕಾಶವಿದೆ.
ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಿಲ್ಲಿಸುವುದು - ಉದಾಹರಣೆ
ಚಿಕ್ಕದಾಗಿ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಕ್ರಮೇಣ ನಿಮ್ಮ ತಂಡ ಮತ್ತು ಸಂಸ್ಥೆಯೊಳಗೆ ವಿಶ್ವಾಸವನ್ನು ಬೆಳೆಸಿಕೊಳ್ಳಿ. "ಸಿಸ್ಟಮ್ ನಡವಳಿಕೆಯನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಸೆರೆಹಿಡಿಯುವ ಏಕೈಕ ಮಾರ್ಗವೆಂದರೆ ನಿಜವಾದ ಉತ್ಪಾದನಾ ದಟ್ಟಣೆ" ಎಂದು ಜನರು ನಿಮಗೆ ತಿಳಿಸುತ್ತಾರೆ. ಆಲಿಸಿ, ಕಿರುನಗೆ ಮತ್ತು ನಿಧಾನವಾಗಿ ನೀವು ಮಾಡುತ್ತಿರುವುದನ್ನು ಮುಂದುವರಿಸಿ. ನೀವು ಮಾಡಬಹುದಾದ ಕೆಟ್ಟ ಕೆಲಸವೆಂದರೆ ಉತ್ಪಾದನೆಗೆ ಅವ್ಯವಸ್ಥೆ ಎಂಜಿನಿಯರಿಂಗ್ ಅನ್ನು ಅನ್ವಯಿಸುವುದು ಮತ್ತು ಶೋಚನೀಯವಾಗಿ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ಇದರ ನಂತರ, ಯಾರೂ ನಿಮ್ಮನ್ನು ನಂಬುವುದಿಲ್ಲ, ಮತ್ತು "ಅವ್ಯವಸ್ಥೆಯ ಕೋತಿಗಳ" ಬಗ್ಗೆ ನೀವು ಶಾಶ್ವತವಾಗಿ ಮರೆಯಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ.
ಮೊದಲನೆಯದಾಗಿ, ನಂಬಿಕೆಯನ್ನು ಗಳಿಸಿ. ನೀವು ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ ಎಂದು ಸಂಸ್ಥೆ ಮತ್ತು ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳಿಗೆ ತೋರಿಸಿ. ಅಗ್ನಿಶಾಮಕ ದಳದವರಾಗಿ ಮತ್ತು ಲೈವ್ ಅಗ್ನಿಶಾಮಕ ತರಬೇತಿಗೆ ತೆರಳುವ ಮೊದಲು ಜ್ವಾಲೆಗಳ ಬಗ್ಗೆ ನಿಮಗೆ ಎಷ್ಟು ಸಾಧ್ಯವೋ ಅಷ್ಟು ಕಲಿಯಿರಿ. ನಿಮ್ಮ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಗಳಿಸಿ. ನೆನಪಿರಲಿ ಆಮೆ ಮತ್ತು ಮೊಲದ ಕಥೆ? ನಿಧಾನ ಮತ್ತು ತಾಳ್ಮೆಯು ಯಾವಾಗಲೂ ಓಟವನ್ನು ಗೆಲ್ಲುತ್ತದೆ.
ಪ್ರಯೋಗದ ಸಮಯದಲ್ಲಿ ಒಂದು ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಸಾಮರ್ಥ್ಯವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹಾನಿ ತ್ರಿಜ್ಯ ನೀವು ಪರಿಚಯಿಸುವ ವೈಫಲ್ಯ ಮತ್ತು ಅದರ ಕಡಿಮೆಗೊಳಿಸುವಿಕೆಯಿಂದ. ಈ ಕೆಳಗಿನ ಪ್ರಶ್ನೆಗಳನ್ನು ನೀವೇ ಕೇಳಿಕೊಳ್ಳಿ:
- ಪ್ರಯೋಗದಿಂದ ಎಷ್ಟು ಗ್ರಾಹಕರು ಪ್ರಭಾವಿತರಾಗುತ್ತಾರೆ?
- ಯಾವ ಕಾರ್ಯಚಟುವಟಿಕೆಯು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?
- ಯಾವ ಸ್ಥಳಗಳು ಪರಿಣಾಮ ಬೀರುತ್ತವೆ?
"ಕಿಲ್ ಬಟನ್" ಅಥವಾ ಪ್ರಯೋಗವನ್ನು ತಕ್ಷಣವೇ ಸ್ಥಗಿತಗೊಳಿಸಲು ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಸ್ಥಿರ ಸ್ಥಿತಿಗೆ ಮರಳಲು ಒಂದು ಮಾರ್ಗವನ್ನು ಯೋಚಿಸಿ. ನಾನು ಕರೆಯಲ್ಪಡುವ ಪ್ರಯೋಗಗಳನ್ನು ನಡೆಸಲು ಇಷ್ಟಪಡುತ್ತೇನೆ. "ಕ್ಯಾನರಿ" ರೋಲ್ಔಟ್ಗಳು. ಈ ತಂತ್ರವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ನ ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ ವೈಫಲ್ಯದ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಕ್ರಮೇಣ ಬಳಕೆದಾರರ ಸಣ್ಣ ಉಪವಿಭಾಗಕ್ಕೆ ಬದಲಾವಣೆಗಳನ್ನು ರೋಲಿಂಗ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಸಂಪೂರ್ಣ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ನಿಧಾನವಾಗಿ ಪ್ರಚಾರ ಮಾಡುತ್ತದೆ. ನಾನು ಕ್ಯಾನರಿ ರೋಲ್ಔಟ್ಗಳನ್ನು ಇಷ್ಟಪಡುತ್ತೇನೆ ಏಕೆಂದರೆ ಅವು ತತ್ವವನ್ನು ಪೂರೈಸುತ್ತವೆ , ಮತ್ತು ಪ್ರಯೋಗವನ್ನು ಸ್ವತಃ ನಿಲ್ಲಿಸಲು ತುಂಬಾ ಸುಲಭ.
ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗಗಳಿಗಾಗಿ DNS-ಆಧಾರಿತ ಕ್ಯಾನರಿ ರೋಲ್ಔಟ್ನ ಉದಾಹರಣೆ
ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವ (ಸಂಗ್ರಹ ಅಥವಾ ಡೇಟಾಬೇಸ್) ಅಥವಾ ಹಿಂತಿರುಗಿಸಲಾಗದ (ಸುಲಭವಾಗಿ ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ) ಪ್ರಯೋಗಗಳ ಬಗ್ಗೆ ಜಾಗರೂಕರಾಗಿರಿ.
ಕುತೂಹಲಕಾರಿಯಾಗಿ, ನೆಟ್ಫ್ಲಿಕ್ಸ್ NoSQL ಡೇಟಾಬೇಸ್ಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಲು ಒಂದು ಕಾರಣವೆಂದರೆ ಅವರು ಬದಲಾವಣೆಗಳು ಅಥವಾ ರೋಲ್ಬ್ಯಾಕ್ಗಳಿಗೆ ಯಾವುದೇ ಸ್ಕೀಮಾವನ್ನು ಹೊಂದಿಲ್ಲ ಎಂದು ಆಡ್ರಿಯನ್ ಕಾಕ್ಕ್ರಾಫ್ಟ್ ನನಗೆ ಹೇಳಿದರು, ಆದ್ದರಿಂದ ವೈಯಕ್ತಿಕ ಡೇಟಾ ದಾಖಲೆಗಳನ್ನು ಹೆಚ್ಚಿಸುವುದು ಅಥವಾ ಸರಿಪಡಿಸುವುದು ತುಂಬಾ ಸುಲಭವಾಗಿದೆ (ಅಂದರೆ ಅವರು ಗೊಂದಲಮಯ ಎಂಜಿನಿಯರಿಂಗ್ಗೆ ಹೆಚ್ಚು ಸ್ನೇಹಪರರಾಗಿದ್ದರು) .
4. ಗಮನಿಸಿ ಮತ್ತು ಕಲಿಯಿರಿ
ಹೊಸದನ್ನು ಕಲಿಯಲು ಮತ್ತು ಪ್ರಯೋಗದ ಪ್ರಗತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು, ನೀವು ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಮೊದಲೇ ಹೇಳಿದಂತೆ, ಎಲ್ಲಾ ರೀತಿಯ ಮೆಟ್ರಿಕ್ಗಳು ಮತ್ತು ನಿಯತಾಂಕಗಳಿಗೆ ಗರಿಷ್ಠ ಗಮನ ಕೊಡಿ! ನಂತರ ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರಮಾಣೀಕರಿಸಿ ಮತ್ತು ಯಾವಾಗಲೂ - ಯಾವಾಗಲೂ! - ಸಮಸ್ಯೆಯ ಮೊದಲ ಚಿಹ್ನೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುವ ಮೊದಲು ಸಮಯವನ್ನು ಗಮನಿಸಿ. ನನ್ನ ಇತಿಹಾಸದಲ್ಲಿ ಎಚ್ಚರಿಕೆಯ ವ್ಯವಸ್ಥೆಗಳು ವಿಫಲವಾದವು ಮತ್ತು ಗ್ರಾಹಕರು ಮೊದಲು ಸಮಸ್ಯೆಯ ಕುರಿತು ಟ್ವೀಟ್ ಮಾಡಿದ್ದಾರೆ... ನನ್ನನ್ನು ನಂಬಿರಿ, ನೀವು ಆ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳಲು ಬಯಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಎಚ್ಚರಿಕೆ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗಗಳನ್ನು ಬಳಸಿ ಚೆನ್ನಾಗಿ.
- ಪತ್ತೆಹಚ್ಚುವವರೆಗೆ ಸಮಯ?
- ಅಧಿಸೂಚನೆಯ ಮೊದಲು ಮತ್ತು ಸಕ್ರಿಯ ಕ್ರಿಯೆಗಳ ಪ್ರಾರಂಭದ ಸಮಯ?
- ಸಾರ್ವಜನಿಕ ಸೂಚನೆಗೆ ಸಮಯ?
- ಕ್ರಿಯಾತ್ಮಕತೆಯ ಭಾಗಶಃ ನಷ್ಟವಾಗುವವರೆಗೆ ಸಮಯ?
- ಸ್ವಯಂ-ಗುಣಪಡಿಸುವ ಅವಧಿಯು ಎಷ್ಟು ಕಾಲ ಇರುತ್ತದೆ?
- ಪೂರ್ಣ ಅಥವಾ ಭಾಗಶಃ ಚೇತರಿಕೆಯಾಗುವವರೆಗೆ ಸಮಯ?
- ಬಿಕ್ಕಟ್ಟಿನ ಅಂತ್ಯದವರೆಗೆ ಸಮಯ ಮತ್ತು ಸ್ಥಿರ ಸ್ಥಿತಿಗೆ ಮರಳುವುದೇ?
ವೈಫಲ್ಯಕ್ಕೆ ಯಾವುದೇ ಪ್ರತ್ಯೇಕ ಕಾರಣವಿಲ್ಲ ಎಂದು ನೆನಪಿಡಿ. ದೊಡ್ಡ ಅಪಘಾತಗಳು ಯಾವಾಗಲೂ ಹಲವಾರು ಸಣ್ಣ ವೈಫಲ್ಯಗಳ ಪರಿಣಾಮವಾಗಿದೆ, ಅದು ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಬಿಕ್ಕಟ್ಟಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಪ್ರತಿ ಪ್ರಯೋಗದ ವಿವರವಾದ ಮರಣೋತ್ತರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ನಡೆಸುವುದು!
AWS ನಲ್ಲಿ, ಪತ್ತೆಯಾದ ವೈಫಲ್ಯಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಮತ್ತು ಅವುಗಳಿಗೆ ಕಾರಣವೇನು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಾವು ಹೆಚ್ಚಿನ ಒತ್ತು ನೀಡುತ್ತೇವೆ ಆದ್ದರಿಂದ ನಾವು ಭವಿಷ್ಯದಲ್ಲಿ ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ತಡೆಯಬಹುದು. ಪ್ರಯೋಗದ ಎಲ್ಲಾ ತೀರ್ಮಾನಗಳು ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ತಿದ್ದುಪಡಿ-ದೋಷಗಳ (COE) ಎಂಬ ಡಾಕ್ಯುಮೆಂಟ್ನಲ್ಲಿ ಸಂಕ್ಷೇಪಿಸಲಾಗಿದೆ. COE ನಮ್ಮ ತಪ್ಪುಗಳಿಂದ ಕಲಿಯಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಅವುಗಳು ತಂತ್ರಜ್ಞಾನ, ಪ್ರಕ್ರಿಯೆ, ಅಥವಾ ಸಂಸ್ಥೆಯಲ್ಲಿನ ದೋಷಗಳು. ಸ್ಥಗಿತಗಳ ಮೂಲ ಕಾರಣಗಳನ್ನು ತೊಡೆದುಹಾಕಲು ಮತ್ತು ನಿರಂತರವಾಗಿ ಸುಧಾರಿಸಲು ನಾವು ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸುತ್ತೇವೆ.
ಈ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಯಶಸ್ಸಿನ ಕೀಲಿಯು ಮುಕ್ತತೆ ಮತ್ತು ತಪ್ಪಾದ ಬಗ್ಗೆ ಪಾರದರ್ಶಕತೆಯಾಗಿದೆ. ಉತ್ತಮ COE ಅನ್ನು ಬರೆಯುವಲ್ಲಿ ಪ್ರಮುಖ ತತ್ವವೆಂದರೆ ನಿಷ್ಪಕ್ಷಪಾತ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಜನರನ್ನು ಉಲ್ಲೇಖಿಸುವುದನ್ನು ತಪ್ಪಿಸುವುದು. ಅಂತಹ ನಡವಳಿಕೆಯನ್ನು ನಿರುತ್ಸಾಹಗೊಳಿಸುವ ಮತ್ತು ವೈಫಲ್ಯದ ಸಾಧ್ಯತೆಯನ್ನು ಅನುಮತಿಸದ ಪರಿಸರದಲ್ಲಿ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ. Amazon "ನಾಯಕತ್ವ ತತ್ವಗಳ" ಸಂಗ್ರಹವನ್ನು ಬಳಸುತ್ತದೆ () ಅಂತಹ ನಡವಳಿಕೆಯನ್ನು ಪ್ರೋತ್ಸಾಹಿಸಲು - ಉದಾ. ಸ್ವಯಂ ಟೀಕೆ, ವಿಶ್ಲೇಷಣಾತ್ಮಕ ವಿಧಾನ, ಅತ್ಯುನ್ನತ ಮಾನದಂಡಗಳಿಗೆ ಬದ್ಧತೆ ಮತ್ತು ಜವಾಬ್ದಾರಿ COE ಪ್ರಕ್ರಿಯೆಯ ಪ್ರಮುಖ ಅಂಶಗಳಾಗಿವೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಕಾರ್ಯಾಚರಣೆಯ ಶ್ರೇಷ್ಠತೆ.
COE ವರದಿಯು ಐದು ಮುಖ್ಯ ವಿಭಾಗಗಳನ್ನು ಹೊಂದಿದೆ:
- ಏನಾಯಿತು (ಕಾಲಾನುಕ್ರಮದ ಕ್ರಮ)?
- ಗ್ರಾಹಕರ ಮೇಲೆ ಯಾವ ಪರಿಣಾಮ ಬೀರಿತು?
- ದೋಷ ಏಕೆ ಸಂಭವಿಸಿತು? ()
- ನಾವು ಏನು ಕಲಿತಿದ್ದೇವೆ?
- ಭವಿಷ್ಯದಲ್ಲಿ ಇದನ್ನು ತಡೆಯುವುದು ಹೇಗೆ?
ಈ ಪ್ರಶ್ನೆಗಳು ಮೊದಲ ನೋಟದಲ್ಲಿ ತೋರುವುದಕ್ಕಿಂತ ಉತ್ತರಿಸಲು ಹೆಚ್ಚು ಕಷ್ಟ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದು ಅಸ್ಪಷ್ಟ/ಅಜ್ಞಾತ ಬಿಂದುವನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಅಧ್ಯಯನ ಮಾಡಲಾಗಿದೆ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು.
COE ಕಾರ್ಯವಿಧಾನವನ್ನು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಪ್ರಕ್ರಿಯೆಯಾಗಿ ಪರಿವರ್ತಿಸಲು, ಕಾರ್ಯಾಚರಣೆಯ ಮೆಟ್ರಿಕ್ಗಳ ಕಡ್ಡಾಯ ವಿಶ್ಲೇಷಣೆಯೊಂದಿಗೆ ನಾವು ಸಾಪ್ತಾಹಿಕ ಸಭೆಗಳ ರೂಪದಲ್ಲಿ ನಿರಂತರವಾಗಿ ವಿಮರ್ಶೆಗಳನ್ನು ನಡೆಸುತ್ತೇವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ತಾಂತ್ರಿಕ ನಾಯಕರು ಸಂಪೂರ್ಣ AWS ಸಿಬ್ಬಂದಿಯೊಂದಿಗೆ ಸಾಪ್ತಾಹಿಕ ಮೆಟ್ರಿಕ್ಸ್ ವಿಮರ್ಶೆಗಳನ್ನು ನಡೆಸುತ್ತಾರೆ.
5. ಸರಿಪಡಿಸಿ ಮತ್ತು ಸುಧಾರಿಸಿ!
ಇಲ್ಲಿ ಮುಖ್ಯ ಪಾಠ ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗಗಳ ಸಮಯದಲ್ಲಿ ಗುರುತಿಸಲಾದ ಸಮಸ್ಯೆಗಳನ್ನು ಮೊದಲು ಸರಿಪಡಿಸಿ, ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯನ್ನು ನೀಡಿ. ಈ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಹಿರಿಯ ನಿರ್ವಹಣೆಯನ್ನು ತೊಡಗಿಸಿಕೊಳ್ಳಿ ಮತ್ತು ಹೊಸ ಕಾರ್ಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದಕ್ಕಿಂತ ಪ್ರಸ್ತುತ ಸಮಸ್ಯೆಗಳನ್ನು ಸರಿಪಡಿಸುವುದು ಹೆಚ್ಚು ಮುಖ್ಯ ಎಂಬ ಕಲ್ಪನೆಯನ್ನು ಅವರಲ್ಲಿ ಮೂಡಿಸಿ.
ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗವನ್ನು ಬಳಸಿಕೊಂಡು ನಿರ್ಣಾಯಕ ಸ್ಥಿರತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಲು ನಾನು ಒಮ್ಮೆ ಕ್ಲೈಂಟ್ಗೆ ಸಹಾಯ ಮಾಡಿದೆ, ಆದರೆ ಮಾರಾಟ ತಂಡದಿಂದ ಒತ್ತಡದಿಂದಾಗಿ, ಪರಿಹಾರಗಳನ್ನು ಆದ್ಯತೆಯಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಮತ್ತು ಗ್ರಾಹಕರಿಗೆ "ನಿರ್ಣಾಯಕವಾಗಿ ಮುಖ್ಯವಾದ" ಹೊಸ ವಿಷಯವನ್ನು ಪರಿಚಯಿಸಲು ಎಲ್ಲಾ ಪ್ರಯತ್ನಗಳು ಕೇಂದ್ರೀಕೃತವಾಗಿವೆ. ಎರಡು ವಾರಗಳ ನಂತರ, 16-ಗಂಟೆಗಳ ಅಲಭ್ಯತೆಯು ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗದ ಸಮಯದಲ್ಲಿ ನಾವು ಗುರುತಿಸಿದ ಅದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಕಂಪನಿಯನ್ನು ಒತ್ತಾಯಿಸಿತು. ನಷ್ಟ ಮಾತ್ರ ಹೆಚ್ಚು ಎಂದು ಬದಲಾಯಿತು.
ಚೋಸ್ ಎಂಜಿನಿಯರಿಂಗ್ನ ಪ್ರಯೋಜನಗಳು
ಅನೇಕ ಅನುಕೂಲಗಳಿವೆ. ನಾನು ಎರಡು ಹೈಲೈಟ್ ಮಾಡುತ್ತೇನೆ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಅತ್ಯಂತ ಮುಖ್ಯವಾದದ್ದು:
ಮೊದಲನೆಯದಾಗಿ, ಅವ್ಯವಸ್ಥೆ ಎಂಜಿನಿಯರಿಂಗ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಅಪರಿಚಿತ ಸಮಸ್ಯೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ಉತ್ಪಾದನೆಯು ಕ್ರ್ಯಾಶ್ ಆಗುವ ಮೊದಲು ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಅಂದರೆ, ಭಾನುವಾರದಂದು 3 ಗಂಟೆಗೆ. ಅಂದರೆ, ಅವನು ವೈಫಲ್ಯಗಳಿಗೆ ಪ್ರತಿರೋಧವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ವಾಸ್ತವವಾಗಿ, ನಿದ್ರೆಯ ಗುಣಮಟ್ಟ.
ಎರಡನೆಯದಾಗಿ, ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಡೆಸಿದ ಅವ್ಯವಸ್ಥೆಯ ಪ್ರಯೋಗಗಳು ಯಾವಾಗಲೂ ನಿರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚು ವ್ಯಾಪಕವಾದ ಬದಲಾವಣೆಗಳನ್ನು (ಮುಖ್ಯವಾಗಿ ಸಾಂಸ್ಕೃತಿಕ) ಉಂಟುಮಾಡುತ್ತವೆ. ಪ್ರಾಯಶಃ ಇವುಗಳಲ್ಲಿ ಪ್ರಮುಖವಾದದ್ದು ನೈಸರ್ಗಿಕ ವಿಕಾಸವಾಗಿದೆ "ಮುಗ್ಧ" (ದೂಷಣೆ ಮಾಡದ) ಸಂಸ್ಕೃತಿ, "ನೀವು ಅದನ್ನು ಏಕೆ ಮಾಡಿದ್ದೀರಿ?" ಎಂಬ ಪ್ರಶ್ನೆ ಬಂದಾಗ "ಭವಿಷ್ಯದಲ್ಲಿ ನಾವು ಇದನ್ನು ಹೇಗೆ ತಪ್ಪಿಸಬಹುದು?" ಫಲಿತಾಂಶವು ಸಂತೋಷದಾಯಕ, ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ, ಹೆಚ್ಚು ತೊಡಗಿಸಿಕೊಂಡಿರುವ ಮತ್ತು ಹೆಚ್ಚು ಯಶಸ್ವಿ ತಂಡವಾಗಿದೆ. ಮತ್ತು ಅದು ಅದ್ಭುತವಾಗಿದೆ!
ಇದು ಮೊದಲ ಭಾಗವನ್ನು ಮುಕ್ತಾಯಗೊಳಿಸುತ್ತದೆ. ನೀವು ಅದನ್ನು ಇಷ್ಟಪಟ್ಟಿದ್ದೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ದಯವಿಟ್ಟು ವಿಮರ್ಶೆಗಳನ್ನು ಬರೆಯಿರಿ, ಅಭಿಪ್ರಾಯಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಿ ಅಥವಾ ನಿಮ್ಮ ಕೈಗಳನ್ನು ಚಪ್ಪಾಳೆ ತಟ್ಟಿರಿ . ಮುಂದಿನ ಭಾಗದಲ್ಲಿ, ಸಿಸ್ಟಮ್ಗಳಲ್ಲಿ ದೋಷಗಳನ್ನು ಪರಿಚಯಿಸುವ ಉಪಕರಣಗಳು ಮತ್ತು ತಂತ್ರಗಳನ್ನು ನಾನು ನೋಡುತ್ತೇನೆ. ತನಕ!
ಎರಡನೇ ಭಾಗವನ್ನು ಓದಲು ಉತ್ಸುಕರಾಗಿರುವವರಿಗೆ, ಓಸ್ಲೋದಲ್ಲಿನ ಎನ್ಡಿಸಿಯಲ್ಲಿ ಅವ್ಯವಸ್ಥೆಯ ಎಂಜಿನಿಯರಿಂಗ್ ವಿಷಯದ ಕುರಿತು ನಾನು ನನ್ನ ಭಾಷಣವನ್ನು ನೀಡುತ್ತೇನೆ. ಅದರಲ್ಲಿ ನಾನು ನನ್ನ ಮೆಚ್ಚಿನ ಅನೇಕ ಸಾಧನಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ:
ಅನುವಾದಕರಿಂದ PS
ಇಂಗ್ಲಿಷ್ನಲ್ಲಿ ಲೇಖನದ ಎರಡನೇ ಭಾಗ ಮತ್ತು ಈ ವಸ್ತುವಿನಲ್ಲಿ ಹಬ್ರ್ ಓದುಗರಿಂದ ಸಾಕಷ್ಟು ಆಸಕ್ತಿಯನ್ನು ನಾವು ನೋಡಿದರೆ ನಾವು ಅದನ್ನು ಅನುವಾದಿಸುತ್ತೇವೆ - ಲೇಖನದ ಕುರಿತು ಸೂಕ್ತವಾದ ಕಾಮೆಂಟ್ಗಳು ಸ್ವಾಗತಾರ್ಹ!
ನಮ್ಮ ಬ್ಲಾಗ್ನಲ್ಲಿಯೂ ಓದಿ:
- «";
- «";
- «».
ಮೂಲ: www.habr.com
