Banki.ru ಪೋರ್ಟಲ್‌ನ ಕಾರ್ಯಾಚರಣೆಯ ನಿರ್ದೇಶಕ ಆಂಡ್ರೆ ನಿಕೋಲ್ಸ್ಕಿ ಕಳೆದ ವರ್ಷದ ಸಮ್ಮೇಳನದಲ್ಲಿ ಮಾತನಾಡಿದರು ಅನಾಥ ಸೇವೆಗಳ ಬಗ್ಗೆ: ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಅನಾಥರನ್ನು ಹೇಗೆ ಗುರುತಿಸುವುದು, ಅನಾಥ ಸೇವೆಗಳು ಏಕೆ ಕೆಟ್ಟದಾಗಿವೆ, ಅವರೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು ಮತ್ತು ಏನೂ ಸಹಾಯ ಮಾಡದಿದ್ದರೆ ಏನು ಮಾಡಬೇಕು.
ಕಟ್ ಕೆಳಗೆ ವರದಿಯ ಪಠ್ಯ ಆವೃತ್ತಿಯಾಗಿದೆ.
ಹಲೋ ಸಹೋದ್ಯೋಗಿಗಳು! ನನ್ನ ಹೆಸರು ಆಂಡ್ರೆ, ನಾನು Banki.ru ನಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಗೆ ಮುಖ್ಯಸ್ಥನಾಗಿದ್ದೇನೆ.
ನಾವು ದೊಡ್ಡ ಸೇವೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇವುಗಳು ಅಂತಹ ಏಕಶಿಲೆಯ ಸೇವೆಗಳು, ಹೆಚ್ಚು ಶಾಸ್ತ್ರೀಯ ಅರ್ಥದಲ್ಲಿ ಸೇವೆಗಳಿವೆ ಮತ್ತು ಬಹಳ ಚಿಕ್ಕದಾಗಿದೆ. ನನ್ನ ಕಾರ್ಮಿಕ-ರೈತ ಪರಿಭಾಷೆಯಲ್ಲಿ, ಸೇವೆಯು ಸರಳ ಮತ್ತು ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ಅದು ಸೂಕ್ಷ್ಮ ಮತ್ತು ಅದು ತುಂಬಾ ಸರಳ ಮತ್ತು ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ಅದು ಕೇವಲ ಸೇವೆ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ.
ಸೇವೆಗಳ ಸಾಧಕ
ನಾನು ಸೇವೆಗಳ ಅನುಕೂಲಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತೇನೆ.
ಮೊದಲನೆಯದು ಸ್ಕೇಲಿಂಗ್. ನೀವು ತ್ವರಿತವಾಗಿ ಸೇವೆಯಲ್ಲಿ ಏನನ್ನಾದರೂ ಮಾಡಬಹುದು ಮತ್ತು ಉತ್ಪಾದನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು. ನೀವು ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೀರಿ, ನೀವು ಸೇವೆಯನ್ನು ಕ್ಲೋನ್ ಮಾಡಿದ್ದೀರಿ. ನೀವು ಹೆಚ್ಚು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ, ನೀವು ಅದನ್ನು ಕ್ಲೋನ್ ಮಾಡಿದ್ದೀರಿ ಮತ್ತು ಅದರೊಂದಿಗೆ ಬದುಕುತ್ತೀರಿ. ಇದು ಉತ್ತಮ ಬೋನಸ್ ಆಗಿದೆ, ಮತ್ತು, ತಾತ್ವಿಕವಾಗಿ, ನಾವು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಇದು ನಮಗೆ ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದು ಪರಿಗಣಿಸಲ್ಪಟ್ಟಿದೆ, ನಾವು ಇದನ್ನೆಲ್ಲ ಏಕೆ ಮಾಡುತ್ತಿದ್ದೇವೆ.
ಎರಡನೆಯದಾಗಿ, ಪ್ರತ್ಯೇಕವಾದ ಅಭಿವೃದ್ಧಿ, ನೀವು ಹಲವಾರು ಅಭಿವೃದ್ಧಿ ತಂಡಗಳನ್ನು ಹೊಂದಿರುವಾಗ, ಪ್ರತಿ ತಂಡದಲ್ಲಿ ಹಲವಾರು ವಿಭಿನ್ನ ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು ಪ್ರತಿ ತಂಡವು ತನ್ನದೇ ಆದ ಸೇವೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತದೆ.
ತಂಡಗಳೊಂದಿಗೆ ಒಂದು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವಿದೆ. ಡೆವಲಪರ್‌ಗಳು ವಿಭಿನ್ನವಾಗಿವೆ. ಮತ್ತು ಇವೆ, ಉದಾಹರಣೆಗೆ, . ನಾನು ಇದನ್ನು ಮೊದಲು ಮ್ಯಾಕ್ಸಿಮ್ ಡೊರೊಫೀವ್ ಅವರೊಂದಿಗೆ ನೋಡಿದೆ. ಕೆಲವೊಮ್ಮೆ ಸ್ನೋಫ್ಲೇಕ್ ಜನರು ಕೆಲವು ತಂಡಗಳಲ್ಲಿರುತ್ತಾರೆ ಮತ್ತು ಇತರರ ಮೇಲೆ ಅಲ್ಲ. ಇದು ಕಂಪನಿಯಾದ್ಯಂತ ಬಳಸುವ ವಿವಿಧ ಸೇವೆಗಳನ್ನು ಸ್ವಲ್ಪ ಅಸಮಗೊಳಿಸುತ್ತದೆ.
ಚಿತ್ರವನ್ನು ನೋಡಿ: ಇದು ಉತ್ತಮ ಡೆವಲಪರ್, ಅವರು ದೊಡ್ಡ ಕೈಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಅವರು ಬಹಳಷ್ಟು ಮಾಡಬಹುದು. ಈ ಕೈಗಳು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ ಎಂಬುದು ಮುಖ್ಯ ಸಮಸ್ಯೆ.
ಸೇವೆಗಳು ವಿಭಿನ್ನ ಕಾರ್ಯಗಳಿಗೆ ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ವಿಭಿನ್ನ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ಕೆಲವು ಸೇವೆಯು ಗೋದಲ್ಲಿದೆ, ಕೆಲವು ಎರ್ಲಾಂಗ್‌ನಲ್ಲಿದೆ, ಕೆಲವು ರೂಬಿಯಲ್ಲಿದೆ, ಯಾವುದೋ ಪಿಎಚ್‌ಪಿಯಲ್ಲಿದೆ, ಯಾವುದೋ ಪೈಥಾನ್‌ನಲ್ಲಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ನೀವು ಬಹಳ ವ್ಯಾಪಕವಾಗಿ ವಿಸ್ತರಿಸಬಹುದು. ಇಲ್ಲಿಯೂ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ.
ಸೇವಾ-ಆಧಾರಿತ ವಾಸ್ತುಶಿಲ್ಪವು ಪ್ರಾಥಮಿಕವಾಗಿ ಡೆವೊಪ್ಸ್‌ಗೆ ಸಂಬಂಧಿಸಿದೆ. ಅಂದರೆ, ನೀವು ಯಾಂತ್ರೀಕರಣವನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಯಾವುದೇ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯಿಲ್ಲ, ನೀವು ಅದನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದರೆ, ನಿಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು ಸೇವಾ ನಿದರ್ಶನದಿಂದ ನಿದರ್ಶನಕ್ಕೆ ಬದಲಾಗಬಹುದು ಮತ್ತು ಏನನ್ನಾದರೂ ಮಾಡಲು ನೀವು ಅಲ್ಲಿಗೆ ಹೋಗಬೇಕಾಗುತ್ತದೆ, ಆಗ ನೀವು ನರಕದಲ್ಲಿದ್ದೀರಿ.
ಉದಾಹರಣೆಗೆ, ನೀವು 20 ಸೇವೆಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ನೀವು ಕೈಯಿಂದ ನಿಯೋಜಿಸಬೇಕಾಗಿದೆ, ನೀವು 20 ಕನ್ಸೋಲ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ನೀವು ಏಕಕಾಲದಲ್ಲಿ ನಿಂಜಾದಂತೆ "ಎಂಟರ್" ಅನ್ನು ಒತ್ತಿರಿ. ಇದು ತುಂಬಾ ಒಳ್ಳೆಯದಲ್ಲ.
ಪರೀಕ್ಷೆಯ ನಂತರ ನೀವು ಸೇವೆಯನ್ನು ಹೊಂದಿದ್ದರೆ (ಪರೀಕ್ಷೆ ಇದ್ದರೆ, ಸಹಜವಾಗಿ), ಮತ್ತು ನೀವು ಅದನ್ನು ಇನ್ನೂ ಫೈಲ್‌ನೊಂದಿಗೆ ಪೂರ್ಣಗೊಳಿಸಬೇಕಾದರೆ ಅದು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ನಾನು ನಿಮಗಾಗಿ ಕೆಟ್ಟ ಸುದ್ದಿಯನ್ನು ಸಹ ಹೊಂದಿದ್ದೇನೆ.
ನೀವು ನಿರ್ದಿಷ್ಟ ಅಮೆಜಾನ್ ಸೇವೆಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತಿದ್ದರೆ ಮತ್ತು ರಷ್ಯಾದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ಎರಡು ತಿಂಗಳ ಹಿಂದೆ ನೀವು "ಸುತ್ತಮುತ್ತಲಿನ ಎಲ್ಲವೂ ಬೆಂಕಿಯಲ್ಲಿದೆ, ನಾನು ಚೆನ್ನಾಗಿದ್ದೇನೆ, ಎಲ್ಲವೂ ತಂಪಾಗಿದೆ" ಎಂದು ನೀವು ಹೊಂದಿದ್ದೀರಿ.
ನಿಯೋಜನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ನಾವು ಅನ್ಸಿಬಲ್, ಒಮ್ಮುಖವಾಗಲು ಪಪೆಟ್, ನಿಯೋಜನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಬಿದಿರು ಮತ್ತು ಎಲ್ಲವನ್ನೂ ವಿವರಿಸಲು ಸಂಗಮವನ್ನು ಬಳಸುತ್ತೇವೆ.
ನಾನು ಇದರ ಬಗ್ಗೆ ವಿವರವಾಗಿ ವಾಸಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ವರದಿಯು ಸಂವಹನ ಅಭ್ಯಾಸಗಳ ಬಗ್ಗೆ ಹೆಚ್ಚು, ಮತ್ತು ತಾಂತ್ರಿಕ ಅನುಷ್ಠಾನದ ಬಗ್ಗೆ ಅಲ್ಲ.
ಉದಾಹರಣೆಗೆ, ಸರ್ವರ್‌ನಲ್ಲಿನ ಪಪಿಟ್ ರೂಬಿ 2 ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸಮಸ್ಯೆಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ, ಆದರೆ ಕೆಲವು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರೂಬಿ 1.8 ಗಾಗಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಅವು ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಅಲ್ಲಿ ಏನೋ ತಪ್ಪಾಗಿದೆ. ಮತ್ತು ನೀವು ಒಂದು ಗಣಕದಲ್ಲಿ ರೂಬಿಯ ಬಹು ಆವೃತ್ತಿಗಳನ್ನು ಚಲಾಯಿಸಬೇಕಾದಾಗ, ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ.
ಉದಾಹರಣೆಗೆ, ನಾವು ಪ್ರತಿಯೊಬ್ಬ ಡೆವಲಪರ್‌ಗೆ ವೇದಿಕೆಯನ್ನು ನೀಡುತ್ತೇವೆ, ಅದರ ಮೇಲೆ ನಮ್ಮಲ್ಲಿರುವ ಸರಿಸುಮಾರು ಎಲ್ಲವೂ, ಅಭಿವೃದ್ಧಿಪಡಿಸಬಹುದಾದ ಎಲ್ಲಾ ಸೇವೆಗಳು, ಇದರಿಂದ ಅವನು ಪ್ರತ್ಯೇಕವಾದ ವಾತಾವರಣವನ್ನು ಹೊಂದಿದ್ದಾನೆ, ಅವನು ಅದನ್ನು ಮುರಿದು ತನಗೆ ಬೇಕಾದಂತೆ ನಿರ್ಮಿಸಬಹುದು.
ಅಲ್ಲಿ ಏನಾದರೂ ಬೆಂಬಲದೊಂದಿಗೆ ನಿಮಗೆ ವಿಶೇಷವಾಗಿ ಸಂಕಲಿಸಲಾದ ಪ್ಯಾಕೇಜ್ ಅಗತ್ಯವಿದೆ ಎಂದು ಅದು ಸಂಭವಿಸುತ್ತದೆ. ಇದು ಸಾಕಷ್ಟು ಕಠಿಣವಾಗಿದೆ. ಡಾಕರ್ ಚಿತ್ರವು 45 GB ತೂಗುವ ವರದಿಯನ್ನು ನಾನು ಆಲಿಸಿದೆ. ಲಿನಕ್ಸ್‌ನಲ್ಲಿ, ಸಹಜವಾಗಿ, ಇದು ಸರಳವಾಗಿದೆ, ಅಲ್ಲಿ ಎಲ್ಲವೂ ಚಿಕ್ಕದಾಗಿದೆ, ಆದರೆ ಇನ್ನೂ, ಸಾಕಷ್ಟು ಸ್ಥಳಾವಕಾಶವಿರುವುದಿಲ್ಲ.
ಅಲ್ಲದೆ, ಸಂಘರ್ಷದ ಅವಲಂಬನೆಗಳಿವೆ, ಯೋಜನೆಯ ಒಂದು ಭಾಗವು ಒಂದು ಆವೃತ್ತಿಯ ಗ್ರಂಥಾಲಯವನ್ನು ಅವಲಂಬಿಸಿದ್ದಾಗ, ಯೋಜನೆಯ ಇನ್ನೊಂದು ಭಾಗವು ಮತ್ತೊಂದು ಆವೃತ್ತಿಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಮತ್ತು ಗ್ರಂಥಾಲಯಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸ್ಥಾಪಿಸಲಾಗಿಲ್ಲ.
ನಾವು PHP 5.6 ನಲ್ಲಿ ಸೈಟ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ಅವರಿಗೆ ನಾಚಿಕೆಪಡುತ್ತೇವೆ, ಆದರೆ ನಾವು ಏನು ಮಾಡಬಹುದು? ಇದು ನಮ್ಮ ಒಂದು ಸೈಟ್ ಆಗಿದೆ. PHP 7 ನಲ್ಲಿ ಸೈಟ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳಿವೆ, ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವುಗಳಿವೆ, ನಾವು ಅವರ ಬಗ್ಗೆ ನಾಚಿಕೆಪಡುವುದಿಲ್ಲ. ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬ ಡೆವಲಪರ್ ತನ್ನದೇ ಆದ ನೆಲೆಯನ್ನು ಹೊಂದಿದ್ದಾನೆ, ಅಲ್ಲಿ ಅವನು ಸಂತೋಷದಿಂದ ನೋಡುತ್ತಾನೆ.
ನೀವು ಒಂದು ಭಾಷೆಯಲ್ಲಿ ಕಂಪನಿಯಲ್ಲಿ ಬರೆದರೆ, ಪ್ರತಿ ಡೆವಲಪರ್‌ಗೆ ಮೂರು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಸಾಮಾನ್ಯವೆಂದು ತೋರುತ್ತದೆ. ನೀವು ವಿಭಿನ್ನ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ಪರಿಸ್ಥಿತಿಯು ಹದಗೆಡುತ್ತದೆ.
ನೀವು ಇದರ ಮೇಲೆ ಸೈಟ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ, ನಂತರ Go ಗಾಗಿ ಮತ್ತೊಂದು ಸೈಟ್, ರೂಬಿಗಾಗಿ ಒಂದು ಸೈಟ್ ಮತ್ತು ಬದಿಯಲ್ಲಿ ಕೆಲವು ಇತರ ರೆಡಿಗಳು. ಪರಿಣಾಮವಾಗಿ, ಇದೆಲ್ಲವೂ ಬೆಂಬಲಕ್ಕಾಗಿ ದೊಡ್ಡ ಕ್ಷೇತ್ರವಾಗಿ ಬದಲಾಗುತ್ತದೆ, ಮತ್ತು ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಅದರಲ್ಲಿ ಕೆಲವು ಮುರಿಯಬಹುದು.
ಆದ್ದರಿಂದ, ನಾವು ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯ ಪ್ರಯೋಜನಗಳನ್ನು ವಿಭಿನ್ನ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳ ಬಳಕೆಯಿಂದ ಬದಲಾಯಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ PHP ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು ವಿಭಿನ್ನವಾಗಿವೆ, ಅವುಗಳು ವಿಭಿನ್ನ ಸಾಮರ್ಥ್ಯಗಳು, ವಿಭಿನ್ನ ಸಮುದಾಯಗಳು ಮತ್ತು ವಿಭಿನ್ನ ಬೆಂಬಲವನ್ನು ಹೊಂದಿವೆ. ಮತ್ತು ನೀವು ಸೇವೆಯನ್ನು ಬರೆಯಬಹುದು ಇದರಿಂದ ನೀವು ಈಗಾಗಲೇ ಏನನ್ನಾದರೂ ಸಿದ್ಧಪಡಿಸಿದ್ದೀರಿ.
ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ತನ್ನದೇ ಆದ ತಂಡವನ್ನು ಹೊಂದಿದೆ
ಹಲವಾರು ವರ್ಷಗಳಿಂದ ಸ್ಫಟಿಕೀಕರಣಗೊಂಡ ನಮ್ಮ ಮುಖ್ಯ ಪ್ರಯೋಜನವೆಂದರೆ ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ತನ್ನದೇ ಆದ ತಂಡವನ್ನು ಹೊಂದಿದೆ. ಇದು ದೊಡ್ಡ ಯೋಜನೆಗೆ ಅನುಕೂಲಕರವಾಗಿದೆ, ನೀವು ದಸ್ತಾವೇಜನ್ನು ಸಮಯವನ್ನು ಉಳಿಸಬಹುದು, ವ್ಯವಸ್ಥಾಪಕರು ತಮ್ಮ ಯೋಜನೆಯನ್ನು ಚೆನ್ನಾಗಿ ತಿಳಿದಿದ್ದಾರೆ.
ಬೆಂಬಲದಿಂದ ನೀವು ಸುಲಭವಾಗಿ ಕಾರ್ಯಗಳನ್ನು ಸಲ್ಲಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ವಿಮಾ ಸೇವೆ ಮುರಿಯಿತು. ಮತ್ತು ತಕ್ಷಣವೇ ವಿಮೆಯೊಂದಿಗೆ ವ್ಯವಹರಿಸುವ ತಂಡವು ಅದನ್ನು ಸರಿಪಡಿಸಲು ಹೋಗುತ್ತದೆ.
ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ತ್ವರಿತವಾಗಿ ರಚಿಸಲಾಗುತ್ತಿದೆ, ಏಕೆಂದರೆ ನೀವು ಒಂದು ಪರಮಾಣು ಸೇವೆಯನ್ನು ಹೊಂದಿರುವಾಗ, ನೀವು ಅದರಲ್ಲಿ ಏನನ್ನಾದರೂ ತ್ವರಿತವಾಗಿ ತಿರುಗಿಸಬಹುದು.
ಮತ್ತು ನಿಮ್ಮ ಸೇವೆಯನ್ನು ನೀವು ಮುರಿದಾಗ ಮತ್ತು ಇದು ಅನಿವಾರ್ಯವಾಗಿ ಸಂಭವಿಸಿದಾಗ, ನೀವು ಇತರ ಜನರ ಸೇವೆಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಮತ್ತು ಇತರ ತಂಡಗಳ ಡೆವಲಪರ್‌ಗಳು ಬಿಟ್‌ಗಳೊಂದಿಗೆ ನಿಮ್ಮ ಬಳಿಗೆ ಓಡಿ ಬರುವುದಿಲ್ಲ: "ಅಯ್-ಅಯ್, ಅದನ್ನು ಮಾಡಬೇಡಿ."
ಯಾವಾಗಲೂ ಹಾಗೆ, ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ. ನಾವು ಸ್ಥಿರ ತಂಡಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಿರ್ವಾಹಕರನ್ನು ತಂಡಕ್ಕೆ ಹೊಡೆಯಲಾಗುತ್ತದೆ. ಸ್ಪಷ್ಟ ದಾಖಲೆಗಳಿವೆ, ವ್ಯವಸ್ಥಾಪಕರು ಎಲ್ಲವನ್ನೂ ನಿಕಟವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಾರೆ. ಮ್ಯಾನೇಜರ್ ಹೊಂದಿರುವ ಪ್ರತಿಯೊಂದು ತಂಡವು ಹಲವಾರು ಸೇವೆಗಳನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಸಾಮರ್ಥ್ಯದ ನಿರ್ದಿಷ್ಟ ಅಂಶವಿದೆ.
ತಂಡಗಳು ತೇಲುತ್ತಿದ್ದರೆ (ನಾವು ಕೆಲವೊಮ್ಮೆ ಇದನ್ನು ಬಳಸುತ್ತೇವೆ), "ಸ್ಟಾರ್ ಮ್ಯಾಪ್" ಎಂಬ ಉತ್ತಮ ವಿಧಾನವಿದೆ.
ನೀವು ಸೇವೆಗಳು ಮತ್ತು ಜನರ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದ್ದೀರಿ. ನಕ್ಷತ್ರ ಚಿಹ್ನೆ ಎಂದರೆ ವ್ಯಕ್ತಿಯು ಈ ಸೇವೆಯಲ್ಲಿ ಪರಿಣಿತನಾಗಿದ್ದಾನೆ, ಪುಸ್ತಕ ಎಂದರೆ ವ್ಯಕ್ತಿಯು ಈ ಸೇವೆಯನ್ನು ಅಧ್ಯಯನ ಮಾಡುತ್ತಿದ್ದಾನೆ. ನಕ್ಷತ್ರ ಚಿಹ್ನೆಗಾಗಿ ಬುಕ್ಲೆಟ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು ವ್ಯಕ್ತಿಯ ಕಾರ್ಯವಾಗಿದೆ. ಮತ್ತು ಸೇವೆಯ ಮುಂದೆ ಏನನ್ನೂ ಬರೆಯದಿದ್ದರೆ, ಸಮಸ್ಯೆಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ, ಅದನ್ನು ನಾನು ಮತ್ತಷ್ಟು ಮಾತನಾಡುತ್ತೇನೆ.
ಅನಾಥ ಸೇವೆಗಳು ಹೇಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ?
ಮೊದಲ ಸಮಸ್ಯೆ, ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಅನಾಥ ಸೇವೆಯನ್ನು ಪಡೆಯುವ ಮೊದಲ ಮಾರ್ಗವೆಂದರೆ ಜನರನ್ನು ವಜಾ ಮಾಡುವುದು. ಕಾರ್ಯಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಮೊದಲು ಯಾರಾದರೂ ವ್ಯಾಪಾರ ಭೇಟಿಯ ಗಡುವನ್ನು ಹೊಂದಿದ್ದೀರಾ? ಕೆಲವೊಮ್ಮೆ ಗಡುವುಗಳು ಬಿಗಿಯಾಗಿರುತ್ತವೆ ಮತ್ತು ದಾಖಲಾತಿಗೆ ಸಾಕಷ್ಟು ಸಮಯವಿಲ್ಲ. "ನಾವು ಸೇವೆಯನ್ನು ಉತ್ಪಾದನೆಗೆ ಹಸ್ತಾಂತರಿಸಬೇಕಾಗಿದೆ, ನಂತರ ನಾವು ಅದನ್ನು ಸೇರಿಸುತ್ತೇವೆ."
ತಂಡವು ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ಎಲ್ಲವನ್ನೂ ಬರೆಯುವ ಒಬ್ಬ ಡೆವಲಪರ್ ಇದ್ದಾನೆ ಎಂದು ಅದು ಸಂಭವಿಸುತ್ತದೆ, ಉಳಿದವರು ರೆಕ್ಕೆಗಳಲ್ಲಿದ್ದಾರೆ. "ನಾನು ಮೂಲ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಬರೆದಿದ್ದೇನೆ, ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಸೇರಿಸೋಣ." ನಂತರ ಕೆಲವು ಹಂತದಲ್ಲಿ ಮ್ಯಾನೇಜರ್, ಉದಾಹರಣೆಗೆ, ಹೊರಡುತ್ತಾನೆ. ಮತ್ತು ಈ ಅವಧಿಯಲ್ಲಿ, ಮ್ಯಾನೇಜರ್ ತೊರೆದಾಗ ಮತ್ತು ಹೊಸದನ್ನು ಇನ್ನೂ ನೇಮಿಸದಿದ್ದಾಗ, ಸೇವೆಯು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತಿದೆ ಮತ್ತು ಅಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅಭಿವರ್ಧಕರು ಸ್ವತಃ ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಮತ್ತು ನಮಗೆ ತಿಳಿದಿರುವಂತೆ (ಕೆಲವು ಸ್ಲೈಡ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸೋಣ), ಕೆಲವು ತಂಡಗಳಲ್ಲಿ ಸ್ನೋಫ್ಲೇಕ್ ಜನರಿದ್ದಾರೆ, ಕೆಲವೊಮ್ಮೆ ಸ್ನೋಫ್ಲೇಕ್ ತಂಡದ ನಾಯಕ. ನಂತರ ಅವನು ತ್ಯಜಿಸುತ್ತಾನೆ, ಮತ್ತು ನಾವು ಅನಾಥ ಸೇವೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಬೆಂಬಲ ಮತ್ತು ವ್ಯವಹಾರದಿಂದ ಕಾರ್ಯಗಳು ಕಣ್ಮರೆಯಾಗುವುದಿಲ್ಲ; ಅವು ಬ್ಯಾಕ್‌ಲಾಗ್‌ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ಸೇವೆಯ ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ಯಾವುದೇ ವಾಸ್ತು ದೋಷಗಳಿದ್ದರೆ, ಅವುಗಳು ಸಹ ಬ್ಯಾಕ್‌ಲಾಗ್‌ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ಸೇವೆ ನಿಧಾನವಾಗಿ ಕ್ಷೀಣಿಸುತ್ತಿದೆ.
ಅನಾಥರನ್ನು ಗುರುತಿಸುವುದು ಹೇಗೆ?
ಈ ಪಟ್ಟಿಯು ಪರಿಸ್ಥಿತಿಯನ್ನು ಚೆನ್ನಾಗಿ ವಿವರಿಸುತ್ತದೆ. ಅವರ ಮೂಲಸೌಕರ್ಯಗಳ ಬಗ್ಗೆ ಯಾರು ಏನನ್ನೂ ಕಲಿತರು?
ದಾಖಲಿತ ಕೆಲಸದ ಸುತ್ತಿನ ಬಗ್ಗೆ: ಒಂದು ಸೇವೆ ಇದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅದರೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು ಎರಡು ಪುಟಗಳ ಕೈಪಿಡಿಯನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಅದು ಒಳಗೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಯಾರಿಗೂ ತಿಳಿದಿಲ್ಲ.
ಅಥವಾ, ಉದಾಹರಣೆಗೆ, ಕೆಲವು ರೀತಿಯ ಲಿಂಕ್ ಶಾರ್ಟ್ನರ್ ಇದೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಪ್ರಸ್ತುತ ವಿಭಿನ್ನ ಸೇವೆಗಳಲ್ಲಿ ವಿಭಿನ್ನ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಬಳಕೆಯಲ್ಲಿರುವ ಮೂರು ಲಿಂಕ್ ಶಾರ್ಟ್‌ನರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಇವು ಕೇವಲ ಪರಿಣಾಮಗಳು.
ಈಗ ನಾನು ಸ್ಪಷ್ಟ ನಾಯಕನಾಗುತ್ತೇನೆ. ಏನು ಮಾಡಬೇಕು? ಮೊದಲಿಗೆ, ನಾವು ಸೇವೆಯನ್ನು ಮತ್ತೊಂದು ಮ್ಯಾನೇಜರ್, ಇನ್ನೊಂದು ತಂಡಕ್ಕೆ ವರ್ಗಾಯಿಸಬೇಕಾಗಿದೆ. ನಿಮ್ಮ ಟೀಮ್ ಲೀಡ್ ಇನ್ನೂ ತೊರೆಯದಿದ್ದರೆ, ಈ ಇತರ ತಂಡದಲ್ಲಿ, ಸೇವೆಯು ಅನಾಥವಾಗಿದೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಾಗ, ಅದರ ಬಗ್ಗೆ ಏನನ್ನಾದರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಯಾರನ್ನಾದರೂ ನೀವು ಸೇರಿಸಿಕೊಳ್ಳಬೇಕು.
ಮುಖ್ಯ ವಿಷಯ: ನೀವು ರಕ್ತದಲ್ಲಿ ಬರೆಯಲಾದ ವರ್ಗಾವಣೆ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಹೊಂದಿರಬೇಕು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನಾನು ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇನೆ, ಏಕೆಂದರೆ ನನಗೆ ಕೆಲಸ ಮಾಡಲು ಇದು ಬೇಕಾಗುತ್ತದೆ. ನಿರ್ವಾಹಕರು ಅದನ್ನು ತ್ವರಿತವಾಗಿ ತಲುಪಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ನಂತರ ಏನಾಗುತ್ತದೆ ಎಂಬುದು ಅವರಿಗೆ ಇನ್ನು ಮುಂದೆ ಅಷ್ಟು ಮುಖ್ಯವಲ್ಲ.
ಅನಾಥರನ್ನು ಮಾಡುವ ಮುಂದಿನ ಮಾರ್ಗವೆಂದರೆ "ನಾವು ಅದನ್ನು ಹೊರಗುತ್ತಿಗೆ ಮಾಡುತ್ತೇವೆ, ಅದು ವೇಗವಾಗಿರುತ್ತದೆ ಮತ್ತು ನಂತರ ನಾವು ಅದನ್ನು ತಂಡಕ್ಕೆ ಹಸ್ತಾಂತರಿಸುತ್ತೇವೆ." ಪ್ರತಿಯೊಬ್ಬರೂ ತಂಡದಲ್ಲಿ ಕೆಲವು ಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಒಂದು ತಿರುವು. ಸಾಮಾನ್ಯವಾಗಿ ವ್ಯಾಪಾರ ಗ್ರಾಹಕರು ಕಂಪನಿಯು ಹೊಂದಿರುವ ತಾಂತ್ರಿಕ ವಿಭಾಗದಂತೆಯೇ ಹೊರಗುತ್ತಿಗೆದಾರರು ಮಾಡುತ್ತಾರೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಅವರ ಪ್ರೇರಣೆಗಳು ವಿಭಿನ್ನವಾಗಿದ್ದರೂ ಸಹ. ಹೊರಗುತ್ತಿಗೆಯಲ್ಲಿ ವಿಚಿತ್ರವಾದ ತಾಂತ್ರಿಕ ಪರಿಹಾರಗಳು ಮತ್ತು ವಿಚಿತ್ರ ಅಲ್ಗಾರಿದಮಿಕ್ ಪರಿಹಾರಗಳಿವೆ.
ಉದಾಹರಣೆಗೆ, ನಾವು ವಿವಿಧ ಅನಿರೀಕ್ಷಿತ ಸ್ಥಳಗಳಲ್ಲಿ ಸಿಂಹನಾರಿ ಹೊಂದಿರುವ ಸೇವೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾನು ಏನು ಮಾಡಬೇಕೆಂದು ನಂತರ ಹೇಳುತ್ತೇನೆ.
ಹೊರಗುತ್ತಿಗೆದಾರರು ಸ್ವಯಂ-ಲಿಖಿತ ಚೌಕಟ್ಟುಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಇದು ಹಿಂದಿನ ಪ್ರಾಜೆಕ್ಟ್‌ನಿಂದ ಕಾಪಿ-ಪೇಸ್ಟ್‌ನೊಂದಿಗೆ ಕೇವಲ PHP ಆಗಿದೆ, ಅಲ್ಲಿ ನೀವು ಎಲ್ಲಾ ರೀತಿಯ ವಿಷಯಗಳನ್ನು ಕಾಣಬಹುದು. ಕೆಲವು ಫೈಲ್‌ಗಳಲ್ಲಿ ಹಲವಾರು ಸಾಲುಗಳನ್ನು ಬದಲಾಯಿಸಲು ನೀವು ಕೆಲವು ಸಂಕೀರ್ಣವಾದ ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬಳಸಬೇಕಾದಾಗ ನಿಯೋಜನೆ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ದೊಡ್ಡ ನ್ಯೂನತೆಯಾಗಿದೆ ಮತ್ತು ಈ ನಿಯೋಜನೆ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಕೆಲವು ಮೂರನೇ ಸ್ಕ್ರಿಪ್ಟ್‌ನಿಂದ ಕರೆಯಲಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ನೀವು ನಿಯೋಜನೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತೀರಿ, ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಆಯ್ಕೆ ಮಾಡಿ, ಹಾಪ್ ಮಾಡಿ, ಆದರೆ ನಿಮ್ಮ ಸೇವೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಏಕೆಂದರೆ ಅಲ್ಲಿ ಬೇರೆ ಬೇರೆ ಫೋಲ್ಡರ್‌ಗಳ ನಡುವೆ ಇನ್ನೂ 8 ಲಿಂಕ್‌ಗಳನ್ನು ಹಾಕುವ ಅಗತ್ಯವಿತ್ತು. ಅಥವಾ ಸಾವಿರ ದಾಖಲೆಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಆದರೆ ನೂರು ಸಾವಿರ ಇನ್ನು ಮುಂದೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
ನಾನು ನಾಯಕನಾಗಿ ಮುಂದುವರಿಯುತ್ತೇನೆ. ಹೊರಗುತ್ತಿಗೆ ಸೇವೆಯನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವುದು ಕಡ್ಡಾಯ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ. ಯಾರಾದರೂ ಹೊರಗುತ್ತಿಗೆ ಸೇವೆಯನ್ನು ತಲುಪಿದ್ದಾರೆಯೇ ಮತ್ತು ಎಲ್ಲಿಯೂ ಸ್ವೀಕರಿಸಲಿಲ್ಲವೇ? ಇದು ಅನಾಥ ಸೇವೆಯಾಗಿ ಜನಪ್ರಿಯವಾಗಿಲ್ಲ, ಆದರೆ ಇನ್ನೂ.
ಸೇವೆಯನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾಗಿದೆ, ಸೇವೆಯನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾಗಿದೆ, ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ. ಅವರು ನಮಗೆ ಸೇವೆಯನ್ನು ನೀಡಿದಾಗ ನಾವು ಒಂದು ಪ್ರಕರಣವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಿರ್ವಾಹಕ ಫಲಕವಿದೆ “ಲಾಗಿನ್ ಆಗಿದ್ದರೆ == 'ನಿರ್ವಹಣೆ' && ಪಾಸ್‌ವರ್ಡ್ == 'ನಿರ್ವಾಹಕ'...", ಅದನ್ನು ಕೋಡ್‌ನಲ್ಲಿಯೇ ಬರೆಯಲಾಗಿದೆ. ನಾವು ಕುಳಿತು ಯೋಚಿಸುತ್ತೇವೆ ಮತ್ತು ಜನರು ಇದನ್ನು 2018 ರಲ್ಲಿ ಬರೆಯುತ್ತಾರೆಯೇ?
ಶೇಖರಣಾ ಸಾಮರ್ಥ್ಯವನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಸಹ ಅಗತ್ಯ ವಿಷಯವಾಗಿದೆ. ನೀವು ಈ ಸೇವೆಯನ್ನು ಎಲ್ಲೋ ಉತ್ಪಾದನೆಗೆ ಹಾಕುವ ಮೊದಲು, ನೂರು ಸಾವಿರ ದಾಖಲೆಗಳಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬೇಕು.
ಸುಧಾರಣೆಗಾಗಿ ಸೇವೆಯನ್ನು ಕಳುಹಿಸಲು ನಾಚಿಕೆಪಡಬಾರದು. ನೀವು ಹೇಳಿದಾಗ: "ನಾವು ಈ ಸೇವೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ, ನಮಗೆ 20 ಕಾರ್ಯಗಳಿವೆ, ಅವುಗಳನ್ನು ಮಾಡಿ, ನಂತರ ನಾವು ಸ್ವೀಕರಿಸುತ್ತೇವೆ" ಇದು ಸಾಮಾನ್ಯವಾಗಿದೆ. ನೀವು ಮ್ಯಾನೇಜರ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತಿದ್ದೀರಿ ಅಥವಾ ವ್ಯವಹಾರವು ಹಣವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತಿದೆ ಎಂಬ ಅಂಶದಿಂದ ನಿಮ್ಮ ಆತ್ಮಸಾಕ್ಷಿಯು ನೋಯಿಸಬಾರದು. ವ್ಯಾಪಾರವು ನಂತರ ಹೆಚ್ಚು ಖರ್ಚು ಮಾಡುತ್ತದೆ.
ಪೈಲಟ್ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಹೊರಗುತ್ತಿಗೆ ಮಾಡಲು ನಾವು ನಿರ್ಧರಿಸಿದಾಗ ನಾವು ಒಂದು ಪ್ರಕರಣವನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಇದು ಸಮಯಕ್ಕೆ ತಲುಪಿಸಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಇದು ಏಕೈಕ ಗುಣಮಟ್ಟದ ಮಾನದಂಡವಾಗಿದೆ. ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಮತ್ತೊಂದು ಪ್ರಾಯೋಗಿಕ ಯೋಜನೆಯನ್ನು ಮಾಡಿದ್ದೇವೆ, ಅದು ಇನ್ನು ಮುಂದೆ ಪೈಲಟ್ ಆಗಿರಲಿಲ್ಲ. ಈ ಸೇವೆಗಳನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಮತ್ತು ಆಡಳಿತಾತ್ಮಕ ವಿಧಾನಗಳ ಮೂಲಕ ಅವರು ಹೇಳಿದರು, ಇಲ್ಲಿ ನಿಮ್ಮ ಕೋಡ್, ಇಲ್ಲಿ ತಂಡ, ಇಲ್ಲಿ ನಿಮ್ಮ ಮ್ಯಾನೇಜರ್. ಸೇವೆಗಳು ಈಗಾಗಲೇ ಲಾಭ ಗಳಿಸಲು ಪ್ರಾರಂಭಿಸಿವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ವಾಸ್ತವವಾಗಿ, ಅವರು ಇನ್ನೂ ಅನಾಥರಾಗಿದ್ದಾರೆ, ಅವರು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಎಂಬುದನ್ನು ಯಾರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ವ್ಯವಸ್ಥಾಪಕರು ತಮ್ಮ ಕಾರ್ಯಗಳನ್ನು ನಿರಾಕರಿಸಲು ತಮ್ಮ ಕೈಲಾದಷ್ಟು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ.
ಮತ್ತೊಂದು ದೊಡ್ಡ ಪರಿಕಲ್ಪನೆ ಇದೆ - ಗೆರಿಲ್ಲಾ ಅಭಿವೃದ್ಧಿ. ಕೆಲವು ಇಲಾಖೆ, ಸಾಮಾನ್ಯವಾಗಿ ಮಾರ್ಕೆಟಿಂಗ್ ವಿಭಾಗ, ಒಂದು ಊಹೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಬಯಸಿದಾಗ ಮತ್ತು ಸಂಪೂರ್ಣ ಸೇವೆಯನ್ನು ಹೊರಗುತ್ತಿಗೆಗೆ ಆದೇಶಿಸುತ್ತದೆ. ದಟ್ಟಣೆಯು ಅದರೊಳಗೆ ಸುರಿಯಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಅವರು ದಾಖಲೆಗಳನ್ನು ಮುಚ್ಚುತ್ತಾರೆ, ಗುತ್ತಿಗೆದಾರರೊಂದಿಗೆ ದಾಖಲೆಗಳಿಗೆ ಸಹಿ ಮಾಡಿ, ಕಾರ್ಯಾಚರಣೆಗೆ ಬರುತ್ತಾರೆ ಮತ್ತು ಹೇಳುತ್ತಾರೆ: "ಸ್ನೇಹಿತರೇ, ನಾವು ಇಲ್ಲಿ ಸೇವೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದು ಈಗಾಗಲೇ ದಟ್ಟಣೆಯನ್ನು ಹೊಂದಿದೆ, ಅದು ನಮಗೆ ಹಣವನ್ನು ತರುತ್ತದೆ, ಅದನ್ನು ಸ್ವೀಕರಿಸೋಣ." ನಾವು, "ಅಪ್ಪಾ, ಅದು ಹೇಗೆ ಆಗಬಹುದು."
ಮತ್ತು ಅನಾಥ ಸೇವೆಯನ್ನು ಪಡೆಯಲು ಇನ್ನೊಂದು ಮಾರ್ಗ: ಕೆಲವು ತಂಡವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಲೋಡ್ ಆಗಿರುವುದನ್ನು ಕಂಡುಕೊಂಡಾಗ, ನಿರ್ವಹಣೆಯು ಹೀಗೆ ಹೇಳುತ್ತದೆ: "ಈ ತಂಡದ ಸೇವೆಯನ್ನು ಮತ್ತೊಂದು ತಂಡಕ್ಕೆ ವರ್ಗಾಯಿಸೋಣ, ಅದು ಕಡಿಮೆ ಹೊರೆ ಹೊಂದಿದೆ." ತದನಂತರ ನಾವು ಅದನ್ನು ಮೂರನೇ ತಂಡಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತೇವೆ ಮತ್ತು ಮ್ಯಾನೇಜರ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ. ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ನಾವು ಮತ್ತೆ ಅನಾಥರನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಅನಾಥ ಮಕ್ಕಳ ಸಮಸ್ಯೆ ಏನು?
ಯಾರಿಗೆ ಗೊತ್ತಿಲ್ಲ, ಇದು ಸ್ವೀಡನ್‌ನಲ್ಲಿ ಬೆಳೆದ ವಾಸಾ ಯುದ್ಧನೌಕೆಯಾಗಿದೆ, ಇದು ಉಡಾವಣೆಯಾದ 5 ನಿಮಿಷಗಳ ನಂತರ ಮುಳುಗಿತು ಎಂಬ ಅಂಶಕ್ಕೆ ಹೆಸರುವಾಸಿಯಾಗಿದೆ. ಮತ್ತು ಸ್ವೀಡನ್ ರಾಜ, ಇದಕ್ಕಾಗಿ ಯಾರನ್ನೂ ಗಲ್ಲಿಗೇರಿಸಲಿಲ್ಲ. ಅಂತಹ ಹಡಗುಗಳನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಬೇಕೆಂದು ತಿಳಿದಿಲ್ಲದ ಎರಡು ತಲೆಮಾರಿನ ಎಂಜಿನಿಯರ್‌ಗಳು ಇದನ್ನು ನಿರ್ಮಿಸಿದ್ದಾರೆ. ನೈಸರ್ಗಿಕ ಪರಿಣಾಮ.
ಹಡಗು ತುಂಬಾ ಕೆಟ್ಟದಾಗಿ ಮುಳುಗಿರಬಹುದು, ಉದಾಹರಣೆಗೆ, ರಾಜನು ಈಗಾಗಲೇ ಚಂಡಮಾರುತದಲ್ಲಿ ಎಲ್ಲೋ ಅದರ ಮೇಲೆ ಸವಾರಿ ಮಾಡುತ್ತಿದ್ದಾಗ. ಆದ್ದರಿಂದ, ಅವನು ಈಗಿನಿಂದಲೇ ಮುಳುಗಿದನು, ಅಗೈಲ್ ಪ್ರಕಾರ ಬೇಗನೆ ವಿಫಲವಾಗುವುದು ಒಳ್ಳೆಯದು.
ನಾವು ಬೇಗನೆ ವಿಫಲವಾದರೆ, ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಸ್ವೀಕಾರದ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಪರಿಷ್ಕರಣೆಗಾಗಿ ಕಳುಹಿಸಲಾಗಿದೆ. ಆದರೆ ನಾವು ಈಗಾಗಲೇ ಉತ್ಪಾದನೆಯಲ್ಲಿ ವಿಫಲವಾದರೆ, ಹಣವನ್ನು ಹೂಡಿಕೆ ಮಾಡಿದಾಗ, ಸಮಸ್ಯೆಗಳಿರಬಹುದು. ಪರಿಣಾಮಗಳು, ಅವುಗಳನ್ನು ವ್ಯವಹಾರದಲ್ಲಿ ಕರೆಯಲಾಗುತ್ತದೆ.
ಅನಾಥ ಸೇವೆಗಳು ಏಕೆ ಅಪಾಯಕಾರಿ:
- ಸೇವೆಯು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಮುರಿಯಬಹುದು.
- ಸೇವೆಯು ದುರಸ್ತಿ ಮಾಡಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಅಥವಾ ದುರಸ್ತಿ ಮಾಡಲಾಗುವುದಿಲ್ಲ.
- ಸುರಕ್ಷತಾ ಸಮಸ್ಯೆಗಳು.
- ಸುಧಾರಣೆಗಳು ಮತ್ತು ನವೀಕರಣಗಳೊಂದಿಗೆ ತೊಂದರೆಗಳು.
- ಪ್ರಮುಖ ಸೇವೆಯು ಮುರಿದುಹೋದರೆ, ಕಂಪನಿಯ ಖ್ಯಾತಿಗೆ ಹಾನಿಯಾಗುತ್ತದೆ.
ಅನಾಥ ಸೇವೆಗಳೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು?
ಮತ್ತೆ ಏನು ಮಾಡಬೇಕೆಂದು ನಾನು ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ. ಮೊದಲಿಗೆ, ದಾಖಲೆಗಳು ಇರಬೇಕು. Banki.ru ನಲ್ಲಿ 7 ವರ್ಷಗಳು ಪರೀಕ್ಷಕರು ಡೆವಲಪರ್‌ಗಳ ಮಾತನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಾರದು ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಗಳು ಪ್ರತಿಯೊಬ್ಬರ ಮಾತನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಾರದು ಎಂದು ನನಗೆ ಕಲಿಸಿದರು. ನಾವು ಪರಿಶೀಲಿಸಬೇಕಾಗಿದೆ.
ಎರಡನೆಯದಾಗಿ, ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ರೇಖಾಚಿತ್ರಗಳನ್ನು ಬರೆಯುವುದು ಅವಶ್ಯಕ, ಏಕೆಂದರೆ ಉತ್ತಮವಾಗಿ ಸ್ವೀಕರಿಸದ ಸೇವೆಗಳು ಯಾರೂ ಹೇಳದ ಅವಲಂಬನೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಡೆವಲಪರ್‌ಗಳು ಕೆಲವು Yandex.Maps ಅಥವಾ Dadata ಗೆ ತಮ್ಮ ಕೀಲಿಯಲ್ಲಿ ಸೇವೆಯನ್ನು ಸ್ಥಾಪಿಸಿದ್ದಾರೆ. ನೀವು ಉಚಿತ ಮಿತಿಯನ್ನು ಮೀರಿದ್ದೀರಿ, ಎಲ್ಲವೂ ಮುರಿದುಹೋಗಿದೆ ಮತ್ತು ಏನಾಯಿತು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲ. ಅಂತಹ ಎಲ್ಲಾ ರೇಕ್‌ಗಳನ್ನು ವಿವರಿಸಬೇಕು: ಸೇವೆಯು ದಡಾಟಾ, SMS, ಯಾವುದನ್ನಾದರೂ ಬಳಸುತ್ತದೆ.
ಮೂರನೆಯದಾಗಿ, ತಾಂತ್ರಿಕ ಸಾಲದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು. ನೀವು ಕೆಲವು ರೀತಿಯ ಊರುಗೋಲುಗಳನ್ನು ಮಾಡಿದಾಗ ಅಥವಾ ಸೇವೆಯನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಮತ್ತು ಏನನ್ನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ಹೇಳಿದಾಗ, ಅದು ಮುಗಿದಿದೆ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಏಕೆಂದರೆ ಸಣ್ಣ ರಂಧ್ರವು ಅಷ್ಟು ಚಿಕ್ಕದಲ್ಲ ಎಂದು ಅದು ತಿರುಗಬಹುದು ಮತ್ತು ನೀವು ಅದರ ಮೂಲಕ ಬೀಳುತ್ತೀರಿ.
ವಾಸ್ತುಶಿಲ್ಪದ ಕಾರ್ಯಗಳೊಂದಿಗೆ, ನಾವು ಸಿಂಹನಾರಿ ಬಗ್ಗೆ ಒಂದು ಕಥೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಸೇವೆಗಳಲ್ಲಿ ಒಂದು ಪಟ್ಟಿಗಳನ್ನು ನಮೂದಿಸಲು ಸಿಂಹನಾರಿಯನ್ನು ಬಳಸಿದೆ. ಕೇವಲ ಪುಟದ ಪಟ್ಟಿ, ಆದರೆ ಅದನ್ನು ಪ್ರತಿ ರಾತ್ರಿ ಮರು-ಸೂಚಿಸಲಾಯಿತು. ಇದನ್ನು ಎರಡು ಸೂಚ್ಯಂಕಗಳಿಂದ ಜೋಡಿಸಲಾಗಿದೆ: ಒಂದು ದೊಡ್ಡದನ್ನು ಪ್ರತಿ ರಾತ್ರಿಯೂ ಸೂಚ್ಯಂಕಗೊಳಿಸಲಾಯಿತು, ಮತ್ತು ಅದಕ್ಕೆ ತಿರುಗಿಸಲಾದ ಒಂದು ಸಣ್ಣ ಸೂಚ್ಯಂಕವೂ ಇತ್ತು. ಪ್ರತಿದಿನ, 50% ರಷ್ಟು ಬಾಂಬ್ ದಾಳಿ ಅಥವಾ ಇಲ್ಲದಿರುವ ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ, ಲೆಕ್ಕಾಚಾರದ ಸಮಯದಲ್ಲಿ ಸೂಚ್ಯಂಕವು ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಸುದ್ದಿ ಮುಖ್ಯ ಪುಟದಲ್ಲಿ ನವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿತು. ಮೊದಲಿಗೆ ಸೂಚ್ಯಂಕವು ಮರು-ಸೂಚ್ಯಂಕಕ್ಕೆ 5 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು, ನಂತರ ಸೂಚ್ಯಂಕವು ಬೆಳೆಯಿತು ಮತ್ತು ಕೆಲವು ಹಂತದಲ್ಲಿ ಮರು-ಸೂಚ್ಯಂಕಕ್ಕೆ 40 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾರಂಭಿಸಿತು. ನಾವು ಇದನ್ನು ಕತ್ತರಿಸಿದಾಗ, ನಾವು ನೆಮ್ಮದಿಯ ನಿಟ್ಟುಸಿರು ಬಿಟ್ಟೆವು, ಏಕೆಂದರೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಮಯ ಕಳೆದುಹೋಗುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಸೂಚ್ಯಂಕವು ಪೂರ್ಣ ಸಮಯಕ್ಕೆ ಮರು-ಸೂಚಿಸಲ್ಪಡುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಇದು ನಮ್ಮ ಪೋರ್ಟಲ್‌ಗೆ ವಿಫಲವಾಗಿದೆ, ಎಂಟು ಗಂಟೆಗಳವರೆಗೆ ಯಾವುದೇ ಸುದ್ದಿ ಇಲ್ಲ - ಅಷ್ಟೇ, ವ್ಯವಹಾರವು ಸ್ಥಗಿತಗೊಂಡಿದೆ.
ಅನಾಥ ಸೇವೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಯೋಜನೆ
ವಾಸ್ತವವಾಗಿ, ಇದನ್ನು ಮಾಡಲು ತುಂಬಾ ಕಷ್ಟ, ಏಕೆಂದರೆ devops ಸಂವಹನದ ಬಗ್ಗೆ. ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳೊಂದಿಗೆ ನೀವು ಉತ್ತಮ ಸಂಬಂಧವನ್ನು ಹೊಂದಲು ಬಯಸುತ್ತೀರಿ ಮತ್ತು ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳು ಮತ್ತು ವ್ಯವಸ್ಥಾಪಕರನ್ನು ನಿಯಮಗಳ ಮೂಲಕ ತಲೆಯ ಮೇಲೆ ಹೊಡೆದಾಗ, ಅವರು ಇದನ್ನು ಮಾಡುವ ಜನರ ಬಗ್ಗೆ ಸಂಘರ್ಷದ ಭಾವನೆಗಳನ್ನು ಹೊಂದಿರಬಹುದು.
ಈ ಎಲ್ಲಾ ಅಂಶಗಳ ಜೊತೆಗೆ, ಮತ್ತೊಂದು ಪ್ರಮುಖ ವಿಷಯವಿದೆ: ಪ್ರತಿ ನಿರ್ದಿಷ್ಟ ಸೇವೆಗೆ, ನಿಯೋಜನೆಯ ಕಾರ್ಯವಿಧಾನದ ಪ್ರತಿಯೊಂದು ನಿರ್ದಿಷ್ಟ ವಿಭಾಗಕ್ಕೆ ನಿರ್ದಿಷ್ಟ ಜನರು ಜವಾಬ್ದಾರರಾಗಿರಬೇಕು. ಜನರಿಲ್ಲದಿದ್ದಾಗ ಮತ್ತು ಈ ಸಂಪೂರ್ಣ ವಿಷಯವನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ನೀವು ಇತರ ಜನರನ್ನು ಆಕರ್ಷಿಸಬೇಕಾದರೆ, ಅದು ಕಷ್ಟಕರವಾಗುತ್ತದೆ.
ಇದೆಲ್ಲವೂ ಸಹಾಯ ಮಾಡದಿದ್ದರೆ, ಮತ್ತು ನಿಮ್ಮ ಅನಾಥ ಸೇವೆ ಇನ್ನೂ ಅನಾಥವಾಗಿದ್ದರೆ, ಯಾರೂ ಅದನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಬಯಸುವುದಿಲ್ಲ, ದಸ್ತಾವೇಜನ್ನು ಬರೆಯಲಾಗಿಲ್ಲ, ಈ ಸೇವೆಗೆ ಕರೆದ ತಂಡವು ಏನನ್ನೂ ಮಾಡಲು ನಿರಾಕರಿಸುತ್ತದೆ, ಸರಳ ಮಾರ್ಗವಿದೆ - ಮತ್ತೆ ಮಾಡಲು ಎಲ್ಲವೂ .
ಅಂದರೆ, ನೀವು ಸೇವೆಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ಹೊಸದಾಗಿ ತೆಗೆದುಕೊಂಡು ಹೊಸ ಸೇವೆಯನ್ನು ಬರೆಯಿರಿ, ಉತ್ತಮವಾದ ವೇದಿಕೆಯಲ್ಲಿ, ವಿಚಿತ್ರವಾದ ತಾಂತ್ರಿಕ ಪರಿಹಾರಗಳಿಲ್ಲದೆ. ಮತ್ತು ನೀವು ಯುದ್ಧದಲ್ಲಿ ಅದಕ್ಕೆ ವಲಸೆ ಹೋಗುತ್ತೀರಿ.
ನಾವು Yii 1 ನಲ್ಲಿ ಸೇವೆಯನ್ನು ತೆಗೆದುಕೊಂಡಾಗ ಮತ್ತು ನಾವು ಅದನ್ನು ಮತ್ತಷ್ಟು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಅರಿತುಕೊಂಡಾಗ ನಾವು ಪರಿಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನಾವು Yii 1 ನಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಬರೆಯಬಲ್ಲ ಡೆವಲಪರ್‌ಗಳ ಕೊರತೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಎಲ್ಲಾ ಡೆವಲಪರ್‌ಗಳು Symfony XNUMX ನಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಬರೆಯುತ್ತಾರೆ. ಏನ್ ಮಾಡೋದು? ನಾವು ಸಮಯವನ್ನು ನಿಗದಿಪಡಿಸಿದ್ದೇವೆ, ತಂಡವನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ, ವ್ಯವಸ್ಥಾಪಕರನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ, ಯೋಜನೆಯನ್ನು ಪುನಃ ಬರೆದಿದ್ದೇವೆ ಮತ್ತು ಅದಕ್ಕೆ ಸಂಚಾರವನ್ನು ಸುಗಮವಾಗಿ ಬದಲಾಯಿಸಿದ್ದೇವೆ.
ಇದರ ನಂತರ, ಹಳೆಯ ಸೇವೆಯನ್ನು ಅಳಿಸಬಹುದು. ಇದು ನನ್ನ ನೆಚ್ಚಿನ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ, ನೀವು ಕಾನ್ಫಿಗರೇಶನ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಸಿಸ್ಟಮ್‌ನಿಂದ ಕೆಲವು ಸೇವೆಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಮತ್ತು ನಂತರ ಹೋಗಿ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಕಾರುಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ನೋಡಿ, ಇದರಿಂದ ಡೆವಲಪರ್‌ಗಳು ಯಾವುದೇ ಕುರುಹುಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ರೆಪೊಸಿಟರಿಯು Git ನಲ್ಲಿ ಉಳಿದಿದೆ.
ನಾನು ಮಾತನಾಡಲು ಬಯಸಿದ್ದು ಇದನ್ನೇ, ನಾನು ಚರ್ಚಿಸಲು ಸಿದ್ಧನಿದ್ದೇನೆ, ವಿಷಯವು ಹೋಲಿವರ್ ಆಗಿದೆ, ಅನೇಕರು ಅದರಲ್ಲಿ ಈಜಿದ್ದಾರೆ.
ನೀವು ಭಾಷೆಗಳನ್ನು ಏಕೀಕರಿಸಿದ್ದೀರಿ ಎಂದು ಸ್ಲೈಡ್‌ಗಳು ಹೇಳಿವೆ. ಚಿತ್ರಗಳ ಮರುಗಾತ್ರಗೊಳಿಸುವಿಕೆಯು ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ಅದನ್ನು ಒಂದು ಭಾಷೆಗೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸೀಮಿತಗೊಳಿಸುವುದು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದೆಯೇ? ಏಕೆಂದರೆ PHP ಯಲ್ಲಿ ಚಿತ್ರದ ಮರುಗಾತ್ರಗೊಳಿಸುವಿಕೆಯನ್ನು ವಾಸ್ತವವಾಗಿ ಗೋಲಾಂಗ್‌ನಲ್ಲಿ ಮಾಡಬಹುದು.
ವಾಸ್ತವವಾಗಿ, ಇದು ಎಲ್ಲಾ ಅಭ್ಯಾಸಗಳಂತೆ ಐಚ್ಛಿಕವಾಗಿರುತ್ತದೆ. ಬಹುಶಃ, ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಇದು ಅನಪೇಕ್ಷಿತವಾಗಿದೆ. ಆದರೆ ನೀವು 50 ಜನರ ಕಂಪನಿಯಲ್ಲಿ ತಾಂತ್ರಿಕ ವಿಭಾಗವನ್ನು ಹೊಂದಿದ್ದರೆ, ಅವರಲ್ಲಿ 45 ಜನರು ಪಿಎಚ್‌ಪಿ ತಜ್ಞರು, ಇನ್ನೂ 3 ಪೈಥಾನ್, ಅನ್ಸಿಬಲ್, ಪಪಿಟ್ ಮತ್ತು ಅಂತಹದನ್ನು ತಿಳಿದಿರುವ ಡೆವೊಪ್‌ಗಳು ಮತ್ತು ಅವರಲ್ಲಿ ಒಬ್ಬರು ಮಾತ್ರ ಕೆಲವರಲ್ಲಿ ಬರೆಯುತ್ತಾರೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಕೆಲವು ರೀತಿಯ ಭಾಷೆ. ಕೆಲವು Go ಇಮೇಜ್ ಮರುಗಾತ್ರಗೊಳಿಸುವ ಸೇವೆ, ನಂತರ ಅದು ತೊರೆದಾಗ, ಪರಿಣತಿಯು ಅದರೊಂದಿಗೆ ಹೋಗುತ್ತದೆ. ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ, ಈ ಭಾಷೆಯನ್ನು ತಿಳಿದಿರುವ ಮಾರುಕಟ್ಟೆ-ನಿರ್ದಿಷ್ಟ ಡೆವಲಪರ್‌ಗಾಗಿ ನೀವು ನೋಡಬೇಕಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಇದು ಅಪರೂಪವಾಗಿದ್ದರೆ. ಅಂದರೆ, ಸಾಂಸ್ಥಿಕ ದೃಷ್ಟಿಕೋನದಿಂದ, ಇದು ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ. devops ದೃಷ್ಟಿಕೋನದಿಂದ, ಸೇವೆಗಳನ್ನು ನಿಯೋಜಿಸಲು ನೀವು ಬಳಸುವ ಕೆಲವು ಸಿದ್ಧ-ಸಿದ್ಧ ಪ್ಲೇಬುಕ್‌ಗಳನ್ನು ಕ್ಲೋನ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ನೀವು ಅವುಗಳನ್ನು ಮತ್ತೆ ಬರೆಯಬೇಕಾಗುತ್ತದೆ.
ನಾವು ಪ್ರಸ್ತುತ Node.js ನಲ್ಲಿ ಸೇವೆಯನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಇದು ಪ್ರತ್ಯೇಕ ಭಾಷೆಯೊಂದಿಗೆ ಪ್ರತಿ ಡೆವಲಪರ್‌ಗೆ ಹತ್ತಿರದ ವೇದಿಕೆಯಾಗಿದೆ. ಆದರೆ ಆಟವು ಮೇಣದಬತ್ತಿಯ ಯೋಗ್ಯವಾಗಿದೆ ಎಂದು ನಾವು ಕುಳಿತುಕೊಂಡೆವು. ಅಂದರೆ, ನೀವು ಕುಳಿತು ಯೋಚಿಸಬೇಕಾದ ಪ್ರಶ್ನೆ ಇದು.
ನಿಮ್ಮ ಸೇವೆಗಳನ್ನು ನೀವು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೀರಿ? ನೀವು ಲಾಗ್‌ಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸುತ್ತೀರಿ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೀರಿ?
ನಾವು ಎಲಾಸ್ಟಿಕ್ ಸರ್ಚ್‌ನಲ್ಲಿ ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಕಿಬಾನಾದಲ್ಲಿ ಇರಿಸುತ್ತೇವೆ ಮತ್ತು ಅದು ಉತ್ಪಾದನೆ ಅಥವಾ ಪರೀಕ್ಷಾ ಪರಿಸರವೇ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿ, ವಿವಿಧ ಸಂಗ್ರಾಹಕಗಳನ್ನು ಅಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ಎಲ್ಲೋ ಲುಂಬರ್ಜಾಕ್, ಎಲ್ಲೋ ಬೇರೆ ಯಾವುದೋ, ನನಗೆ ನೆನಪಿಲ್ಲ. ಮತ್ತು ನಾವು ಟೆಲಿಗ್ರಾಫ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಮತ್ತು ಬೇರೆಡೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಶೂಟ್ ಮಾಡುವ ಕೆಲವು ಸೇವೆಗಳಲ್ಲಿ ಇನ್ನೂ ಕೆಲವು ಸ್ಥಳಗಳಿವೆ.
ಒಂದೇ ಪರಿಸರದಲ್ಲಿ ಪಪಿಟ್ ಮತ್ತು ಅನ್ಸಿಬಲ್ ಜೊತೆ ಬದುಕುವುದು ಹೇಗೆ?
ವಾಸ್ತವವಾಗಿ, ನಾವು ಈಗ ಎರಡು ಪರಿಸರವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಒಂದು ಪಪಿಟ್, ಇನ್ನೊಂದು ಅನ್ಸಿಬಲ್. ಅವುಗಳನ್ನು ಹೈಬ್ರಿಡೈಸ್ ಮಾಡುವ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ. ಆರಂಭಿಕ ಸೆಟಪ್‌ಗೆ ಅನ್ಸಿಬಲ್ ಉತ್ತಮ ಫ್ರೇಮ್‌ವರ್ಕ್ ಆಗಿದೆ, ಆರಂಭಿಕ ಸೆಟಪ್‌ಗೆ ಪಪಿಟ್ ಕೆಟ್ಟ ಚೌಕಟ್ಟಾಗಿದೆ ಏಕೆಂದರೆ ಇದಕ್ಕೆ ನೇರವಾಗಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಪಪಿಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಒಮ್ಮುಖವನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಇದರರ್ಥ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತನ್ನನ್ನು ತಾನೇ ನವೀಕೃತ ಸ್ಥಿತಿಯಲ್ಲಿ ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಸಂಯೋಜಿತ ಯಂತ್ರವನ್ನು ನವೀಕೃತವಾಗಿ ಇರಿಸಿಕೊಳ್ಳಲು, ನೀವು ಕೆಲವು ಆವರ್ತನದೊಂದಿಗೆ ಪ್ಲೇಬುಕ್‌ಗಳನ್ನು ಸಾರ್ವಕಾಲಿಕ ಚಾಲನೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಅಷ್ಟೇ ವ್ಯತ್ಯಾಸ.
ನೀವು ಹೊಂದಾಣಿಕೆಯನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತೀರಿ? ನೀವು ಅನ್ಸಿಬಲ್ ಮತ್ತು ಪಪಿಟ್ ಎರಡರಲ್ಲೂ ಸಂರಚನೆಗಳನ್ನು ಹೊಂದಿದ್ದೀರಾ?
ಇದು ನಮ್ಮ ದೊಡ್ಡ ನೋವು, ನಾವು ನಮ್ಮ ಕೈಗಳಿಂದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಎಲ್ಲೋ ಈಗ ಎಲ್ಲಿಂದ ಹೋಗಬೇಕೆಂದು ಯೋಚಿಸುತ್ತೇವೆ. ಪಪಿಟ್ ಪ್ಯಾಕೇಜುಗಳನ್ನು ಹೊರತರುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿ ಕೆಲವು ಲಿಂಕ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅನ್ಸಿಬಲ್, ಉದಾಹರಣೆಗೆ, ಕೋಡ್ ಅನ್ನು ಹೊರತರುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿ ಇತ್ತೀಚಿನ ಅಪ್ಲಿಕೇಶನ್ ಕಾನ್ಫಿಗರ್‌ಗಳನ್ನು ಸರಿಹೊಂದಿಸುತ್ತದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.
ಪ್ರಸ್ತುತಿಯು ರೂಬಿಯ ವಿವಿಧ ಆವೃತ್ತಿಗಳ ಕುರಿತಾಗಿತ್ತು. ಏನು ಪರಿಹಾರ?
ನಾವು ಇದನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಎದುರಿಸಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಅದನ್ನು ಯಾವಾಗಲೂ ನಮ್ಮ ತಲೆಯಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳಬೇಕು. ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗದ ರೂಬಿಯಲ್ಲಿ ಚಲಿಸುವ ಭಾಗವನ್ನು ನಾವು ಸರಳವಾಗಿ ಆಫ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿದ್ದೇವೆ.
ಈ ವರ್ಷದ ಸಮ್ಮೇಳನ ಡಿಸೆಂಬರ್ 7 ರಂದು ಟೆಕ್ನೋಪೊಲಿಸ್ ನಲ್ಲಿ ನಡೆಯಲಿದೆ. ನಾವು ನವೆಂಬರ್ 11 ರವರೆಗೆ ವರದಿಗಳಿಗಾಗಿ ಅರ್ಜಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿದ್ದೇವೆ. ನೀವು ಮಾತನಾಡಲು ಬಯಸಿದರೆ ನಮಗೆ.
ಭಾಗವಹಿಸುವವರ ನೋಂದಣಿ ಮುಕ್ತವಾಗಿದೆ, ನಮ್ಮೊಂದಿಗೆ ಸೇರಿಕೊಳ್ಳಿ!
ಮೂಲ: www.habr.com