ಒಂದು AI-ಚಾಲಿತ ಸಹಾಯಕನು ಏಳು ದಿನಗಳ ಕಾಲ ನನ್ನ ಆನ್-ಕಾಲ್ (on-call) ಕರ್ತವ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಿದನು, 11 ಅಲರ್ಟ್ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದನು ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಲು ತಗಲುವ ನನ್ನ ಸರಾಸರಿ ಸಮಯವನ್ನು 45 ನಿಮಿಷಗಳಿಂದ 20 ನಿಮಿಷಗಳಿಗೆ ಇಳಿಸಿದನು. ಈ ಪ್ರಯೋಗವು ಮುಖ್ಯವಾದುದು ಏಕೆಂದರೆ ಮಿತವಾದ ವ್ಯಾಪ್ತಿಯ ಭಾಷಾ ಮಾದರಿಯು (language model) ಕಟ್ಟುನಿಟ್ಟಾದ ಮಾನವ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಬಯಸುತ್ತಾ, ಘಟನೆಗಳ ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಯವನ್ನು (incident response) ಅರ್ಧ ಗಂಟೆ ಕಡಿಮೆ ಮಾಡಬಲ್ಲದು.
ನಾನು ಯಾಕೆ AI ಅನ್ನು ಆನ್-ಕಾಲ್ನಲ್ಲಿ ಇರಿಸಿದೆ ಎಂದರೆ
ಕ್ಲೌಡ್ ತಂಡಗಳು ತಮ್ಮ ಶಿಫ್ಟ್ನ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ಲಾಗ್ಗಳನ್ನು (logs) ಹುಡುಕುವಲ್ಲಿ, ಇತ್ತೀಚಿನ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ಗಳನ್ನು (deployments) ಪರಿಶೀಲಿಸುವಲ್ಲಿ ಮತ್ತು ಸ್ಕೇಲಿಂಗ್ ವಿನಂತಿಯು ಸುರಕ್ಷಿತವಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವಲ್ಲಿ ಕಳೆಯುತ್ತವೆ. ಆ "ಬೋರಿಂಗ್" ಕೆಲಸಗಳು ಪುನರಾವರ್ತಿತವಾಗಿರುತ್ತವೆ, ದತ್ತಾಂಶದ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿರುತ್ತವೆ ಮತ್ತು ಮಾನವನ ಸುಸ್ತಿಗೆ ಒಳಗಾಗುವ ಸಾಧ್ಯತೆ ಇರುತ್ತದೆ. ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ಗಳ (large language models) ಇತ್ತೀಚಿನ ಪ್ರಗತಿಯು ಇಂತಹವೇ ಪ್ಯಾಟರ್ನ್-ಮ್ಯಾಚಿಂಗ್ ಕೆಲಸಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಭರವಸೆ ನೀಡಿದೆ, ಆದರೆ ಹೆಚ್ಚಿನ ಸಾರ್ವಜನಿಕ ಪ್ರಾತ್ಯಕ್ಷಿಕೆಗಳು ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ (sandbox) ಪರಿಸರದಲ್ಲಿ ನಡೆಯುತ್ತವೆ. ಪಾವತಿಸುವ ಗ್ರಾಹಕರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವ ಪ್ರೊಡಕ್ಷನ್-ಗ್ರೇಡ್ ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ (production-grade cluster) ಈ ಹೈಪ್ ನಿಜವಾಗಿಯೂ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ನಾನು ನೋಡಲು ಬಯಸಿದೆ.
ಪರೀಕ್ಷೆಯ ಸಿದ್ಧತೆ
- Access (ಪ್ರವೇಶ) – ಏಜೆಂಟ್ ಪ್ರತಿಯೊಂದು ಮೆಟ್ರಿಕ್, ಲಾಗ್ ಮತ್ತು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ವ್ಯಾಖ್ಯಾನವನ್ನು ಓದಬಲ್ಲದು. ಇದು ಕೇವಲ ನಿರ್ದಿಷ್ಟ ವೈಟ್ಲಿಸ್ಟ್ಗೆ (whitelist) ಮಾತ್ರ ಬರೆಯಬಲ್ಲದು: ಪಾಡ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು (restart a pod), ರೆಪ್ಲಿಕಾ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದು ಅಥವಾ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಅನ್ನು ಸ್ಕೇಲ್ ಮಾಡುವುದು. ಈ ಕ್ರಮಗಳ ಹೊರತಾದ ಯಾವುದೇ ಕೆಲಸಕ್ಕೆ ನನ್ನ ಸ್ಪಷ್ಟ ಅನುಮೋದನೆಯ ಅಗತ್ಯವಿತ್ತು.
- Role (ಪಾತ್ರ) – ನಾನು ಈ ಮಾಡೆಲ್ ಅನ್ನು ತನ್ನ ಮೊದಲ ಆನ್-ಕಾಲ್ ಶಿಫ್ಟ್ನಲ್ಲಿರುವ ಜೂನಿಯರ್ ಇಂಜಿನಿಯರ್ ಎಂದು ಪರಿಗಣಿಸಿದೆ. ಇದು ಅಲರ್ಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ತನ್ನ ವಿಶ್ಲೇಷಣೆಯನ್ನು ನಡೆಸುತ್ತದೆ ಮತ್ತು ಇನ್ಸಿಡೆಂಟ್ ಚಾನೆಲ್ನಲ್ಲಿ (incident channel) ಶಿಫಾರಸನ್ನು ಪೋಸ್ಟ್ ಮಾಡುತ್ತದೆ.
- Safety nets (ಸುರಕ್ಷತಾ ಜಾಲಗಳು) – ಎಲ್ಲಾ ಬರವಣಿಗೆಯ ಕ್ರಮಗಳು (write actions) ಮ್ಯಾನುಯಲ್ "ಹೌದು/ಅಲ್ಲ" ಪ್ರಾಂಪ್ಟ್ ಮೂಲಕ ನಿಯಂತ್ರಿಸಲ್ಪಟ್ಟಿದ್ದವು. ವೆಚ್ಚವನ್ನು ಊಹಿಸಬಹುದಾದ ಮಟ್ಟದಲ್ಲಿಡಲು ನಾನು ಮಾಡೆಲ್ನ ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಮಿತಿಗೊಳಿಸಿದೆ.
AI ಎಲ್ಲಿ ಮಿಂಚಿತು
ಏಜೆಂಟ್ನ ವೇಗವು ಅತ್ಯಂತ ಗಮನಾರ್ಹವಾದ ಲಾಭವಾಗಿತ್ತು. ಅಲರ್ಟ್ ಬಂದ ತಕ್ಷಣವೇ, ಅದು ಸಂಬಂಧಿತ ಲಾಗ್ಗಳನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತದೆ, ಇತ್ತೀಚಿನ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಪ್ಲಾಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕೊನೆಯ ಮೂರು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ನಾನು ನನ್ನ ಲ್ಯಾಪ್ಟಾಪ್ ತೆರೆಯುವಷ್ಟರಲ್ಲಿ, ಆರಂಭಿಕ ತನಿಖೆಯ ಕೆಲಸವು ಈಗಾಗಲೇ ಮುಗಿದಿರುತ್ತಿತ್ತು. 11 ಅಲರ್ಟ್ಗಳಲ್ಲಿ:
- 8 ಅಲರ್ಟ್ಗಳು ದಿನನಿತ್ಯದ ಸಮಸ್ಯೆಗಳಾಗಿದ್ದವು (ಮೆಮೊರಿ ಸ್ಪೈಕ್ಸ್, ಕಂಟೇನರ್ ಮರುಪ್ರಾರಂಭಗಳು, ಸರಳ ತಪ್ಪು ಕಾನ್ಫಿಗರೇಶನ್ಗಳು). AI ಪ್ರತಿ ಬಾರಿಯೂ ಮೂಲ ಕಾರಣವನ್ನು ಸರಿಯಾಗಿ ಗುರುತಿಸಿತು.
- ಸಮಸ್ಯೆ ಬೆಳಿಗ್ಗೆ 2 ಗಂಟೆಯ ಅವಧಿಯಲ್ಲಿ ದೊಡ್ಡ ಮಟ್ಟದ ಸ್ಥಗಿತಕ್ಕೆ (outage) ಕಾರಣವಾಗುವ ಮೊದಲೇ, ಇದು ಮೈಕ್ರೋಸರ್ವಿಸ್ನಲ್ಲಿನ ಕ್ರಮೇಣ ಹೆಚ್ಚುತ್ತಿರುವ ಮೆಮೊರಿಯನ್ನು ಗುರುತಿಸಿತು, ಇದರಿಂದ ತಂಡವು ಮೊದಲೇ ಮಧ್ಯಪ್ರವೇಶಿಸಲು ಅವಕಾಶ ಸಿಕ್ಕಿತು.
- ಇಡೀ ವಾರದ ಟೋಕನ್ ಬಳಕೆ ಸುಮಾರು $30 ರಷ್ಟಿತ್ತು, ಇದು ಮಿತಿಗೊಳಿಸಿದಾಗ ಸಾಮಾನ್ಯ ಆನ್-ಕಾಲ್ ಬಜೆಟ್ನಲ್ಲೇ ಇತ್ತು.
ಈ ಫಲಿತಾಂಶಗಳು ಮೀನ್ ಟೈಮ್ ಟು ರೆಸಲ್ಯೂಶನ್ (MTTR) ಅನ್ನು 45 ನಿಮಿಷಗಳಿಂದ 20 ನಿಮಿಷಗಳಿಗೆ ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡಿವೆ, ಇದರಿಂದ ಇಂಜಿನಿಯರ್ಗಳು ಹೆಚ್ಚಿನ ಪ್ರಭಾವ ಬೀರುವ ಕೆಲಸಗಳ ಮೇಲೆ ಗಮನ ಹರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಎಲ್ಲಿ ತಪ್ಪು ಮಾಡಿತು
ಆತ್ಮವಿಶ್ವಾಸ ಎಂದರೆ ಸರಿ ಎನ್ನುವುದಲ್ಲ. 11 ಅಲರ್ಟ್ಗಳಲ್ಲಿ 3 ಅಲರ್ಟ್ಗಳಲ್ಲಿ AI ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ತಪ್ಪು ಮಾಡಿದೆ:
- ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಟಿವಿಟಿ ವೈಫಲ್ಯಕ್ಕೆ ಇತ್ತೀಚಿನ ಕೋಡ್ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಕಾರಣ ಎಂದು ಅದು ದೂಷಿಸಿತು, ಆದರೆ ಆ ವಿವರಣೆ ತಪ್ಪಾಗಿತ್ತು.
- ಪರಿಚಯವಿಲ್ಲದ ನೆಟ್ವರ್ಕಿಂಗ್ ಅನಾಮಧೇಯತೆಯನ್ನು (networking anomaly) ಎದುರಿಸಿದಾಗ, ಅದು ಮೂಲ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸದ ಸಾಮಾನ್ಯ ಪರಿಹಾರಗಳನ್ನು ನೀಡಿತು.
- ಲೋಡ್ಗೆ ಸಂಬಂಧಿಸಿದ ಅಲರ್ಟ್ ಸಮಯದಲ್ಲಿ, ಅದು ಸೇವೆಯನ್ನು 3 ರಿಂದ 30 ರೆಪ್ಲಿಕಾಗಳಿಗೆ ಸ್ಕೇಲ್ ಮಾಡಲು ಸೂಚಿಸಿತು. ಸಮಸ್ಯೆ ಲೋಡ್ ಆಗಿರಲಿಲ್ಲ; ತಪ್ಪು ಕಾನ್ಫಿಗರೇಶನ್ ಆಗಿತ್ತು.
ಯಾವುದೇ ಬರವಣಿಗೆಯ ಕಾರ್ಯಾಚರಣೆಗೆ (write operation) ನನ್ನ ಗಾರ್ಡ್ರೈಲ್ಗಳು (guardrails) ಮ್ಯಾನುಯಲ್ ಅನುಮೋದನೆಯನ್ನು ಬಯಸಿದ್ದರಿಂದ, ಮಾಡೆಲ್ನ ತಪ್ಪುಗಳು ಹಾನಿ ಉಂಟುಮಾಡುವ ಮೊದಲೇ ಪತ್ತೆಯಾದವು. ಆದರೂ, ಈ ಘಟನೆಯು ಒಂದು ಪ್ರಮುಖ ಅಪಾಯವನ್ನು ಎತ್ತಿ ತೋರಿಸಿದೆ: ಮಾಡೆಲ್ ಕೇಳಲು ನಂಬಲರ್ಹವಾಗಿರುವ ಆದರೆ ನಿಖರವಲ್ಲದ ಶಿಫಾರಸುಗಳನ್ನು ನೀಡಬಹುದು, ವಿಶೇಷವಾಗಿ ಹೊಸ ಸಮಸ್ಯೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ.
ವೆಚ್ಚ ಮತ್ತು ಅಪಾಯ ನಿರ್ವಹಣೆ
$30 ಟೋಕನ್ ಬಿಲ್ ತೋರಿಸುವಂತೆ, ಬಳಕೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದರೆ ಪ್ರೊಡಕ್ಷನ್ ಲೂಪ್ನಲ್ಲಿ LLM ಅನ್ನು ಚಲಾಯಿಸುವುದು ಅಗ್ಗವಾಗಬಹುದು. ಆದಾಗ್ಯೂ, ನಿಜವಾದ ವೆಚ್ಚವೆಂದರೆ ಕಾರ್ಯಾಚರಣೆಯ ಅಪಾಯ (operational risk). ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಅನ್ನು ತಪ್ಪಾಗಿ ಸ್ಕೇಲ್ ಮಾಡುವುದು ಅತಿಯಾದ ಕ್ಲೌಡ್ ವೆಚ್ಚಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು ಮತ್ತು ಉತ್ತಮ ರಿಲೀಸ್ ಅನ್ನು ರೋಲ್ ಬ್ಯಾಕ್ (roll back) ಮಾಡುವುದು ಗ್ರಾಹಕರ ನಂಬಿಕೆಯನ್ನು ಕುಗ್ಗಿಸಬಹುದು. ಈ ಪ್ರಯೋಗವು ಎರಡು ಸುರಕ್ಷತಾ ಕ್ರಮಗಳನ್ನು ಬಲಪಡಿಸಿತು:
- Action gating (ಕ್ರಿಯೆ ನಿಯಂತ್ರಣ) – ಹೆಚ್ಚಿನ ಪ್ರಭಾವ ಬೀರುವ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡೆಲ್ ಕೇವಲ ಸೂಚಿಸಲು ಮಾತ್ರ ಅನುಮತಿಸಿ, ಮನುಷ್ಯನ ಕ್ಲಿಕ್ ಇಲ್ಲದೆ ಎಂದಿಗೂ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಬಿಡಬೇಡಿ.
- Budget caps (ಬಜೆಟ್ ಮಿತಿಗಳು) – ಟೋಕನ್ ಬಳಕೆಯ ಮೇಲೆ ಕಟ್ಟುನಿಟ್ಟಾದ ಮಿತಿಗಳನ್ನು ನಿಗದಿಪಡಿಸಿ ಮತ್ತು ಮಾಡೆಲ್ ಮಿತಿಯ ಸಮೀಪಿಸಿದಾಗ ತಂಡಕ್ಕೆ ಎಚ್ಚರಿಕೆ ನೀಡಿ.
ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು
ಅಲ್ಲಿಯವರೆಗೆ, ತಂಡಗಳು ಇವುಗಳನ್ನು ಮಾಡಬೇಕು:
- ಮ್ಯಾನುಯಲ್ ಓವರ್ರೈಡ್ (manual override) ಅಗತ್ಯವಿರುವ AI-ಸೃಷ್ಟಿತ ಶಿಫಾರಸುಗಳ ಪ್ರಮಾಣವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ.
- ವಿವಿಧ ಇನ್ಸಿಡೆಂಟ್ ವರ್ಗಗಳಲ್ಲಿ (ದಿನನಿತ್ಯದ ವರ್ಸಸ್ ಹೊಸದು) MTTR ಮೇಲೆ ಬೀರುವ ಪರಿಣಾಮವನ್ನು ಅಳೆಯಿರಿ.
- ಪ್ರೊಡಕ್ಷನ್ ಬರವಣಿಗೆಯ ಹಕ್ಕುಗಳನ್ನು (production write rights) ನೀಡುವ ಮೊದಲು ಸಿಂಥೆಟಿಕ್ ಅಲರ್ಟ್ಗಳೊಂದಿಗೆ ಸ್ಟೇಜಿಂಗ್ ಪರಿಸರದಲ್ಲಿ (staging environment) ಮಾಡೆಲ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ.
ಆಪ್ಸ್ (ops) ತಂಡಗಳಿಗಾಗಿ ಪ್ರಮುಖ ಅಂಶಗಳು
- ಬೋರಿಂಗ್ 80% ಅನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿ – ಲಾಗ್ ಅಗ್ಲಿಗೇಶನ್ (log aggregation), ಮೆಟ್ರಿಕ್ ಕೊರಿಲೇಶನ್ (metric correlation) ಮತ್ತು ಆರಂಭಿಕ ಹೈಪೋಥೆಸಿಸ್ ತಯಾರಿಕೆಗೆ AI ಅನ್ನು ಬಳಸಿ.
- ಅಪಾಯಕಾರಿ 20% ಅನ್ನು ಮನುಷ್ಯರಿಗಾಗಿ ಮೀಸಲಿಡಿ – ಮಿತಿಗಿಂತ ಹೆಚ್ಚಿನ ಸ್ಕೇಲಿಂಗ್, ರೋಲ್ಬಾಕ್ಗಳು ಮತ್ತು ಡಿಲೀಟ್ಗಳು ಮ್ಯಾನುಯಲ್ ಅನುಮೋದನೆಯ ಹಂತದ ಅಡಿಯಲ್ಲಿರಲಿ.
- ಮಾಡೆಲ್ ಅನ್ನು ಪಾಲುದಾರನನ್ನಾಗಿ ಪರಿಗಣಿಸಿ, ಬದಲಾವಣೆಯಾಗಿ ಅಲ್ಲ – ಸಿಸ್ಟಮ್ ಬಗ್ಗೆ ತಿಳಿದಿರುವ ಇಂಜಿನಿಯರ್ ಹೊಸಬರಿಗಿಂತ ವೇಗವಾಗಿ AI ಔಟ್ಪುಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬಹುದು, ಇದು ಸಹಾಯಕನನ್ನು ಶಕ್ತಿಯನ್ನು ಹೆಚ್ಚಿಸುವ ಸಾಧನವನ್ನಾಗಿ (force multiplier) ಪರಿವರ್ತಿಸುತ್ತದೆ.
ಒಂದು AI ಏಜೆಂಟ್ ಇನ್ನೂ ಏಕಾಂಗಿಯಾಗಿ ಕ್ಲೌಡ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಡೆಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ಟ್ರೈಯೇಜ್ ಪಾಲುದಾರನಾಗಿ (triage partner) ಇದು ಈಗಾಗಲೇ ಗಮನಾರ್ಹ ವೇಗದ ಹೆಚ್ಚಳವನ್ನು ನೀಡುತ್ತಿದೆ. ವಿಶ್ವಾಸವನ್ನು ನಿಯಂತ್ರಣದಲ್ಲಿಡುವುದು, ಕಟ್ಟುನಿಟ್ಟಾದ ಗಾರ್ಡ್ರೈಲ್ಗಳನ್ನು (guardrails) ಜಾರಿಗೆ ತರುವುದು ಮತ್ತು ಮಾನವ ಪರಿಣತಿಯು ನಿರ್ಣಾಯಕ ನಿರ್ಧಾರಗಳನ್ನು ನಿರ್ದೇಶಿಸುವಾಗ, ಮಾಡೆಲ್ ಅನ್ನು ಪುನರಾವರ್ತಿತ ಏಕತಾನತೆಯ ಕೆಲಸಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಬಿಡುವುದೇ ಇದರ ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ.