ನಾನು SRE ಇಂಜಿನಿಯರ್ ಇಂಟರ್ನ್ ಆಗಿ ಒಂದು ವಾರವನ್ನು ಹೇಗೆ ಕಳೆದೆ. ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರ್‌ನ ದೃಷ್ಟಿಯಲ್ಲಿ ಕರ್ತವ್ಯ

ನಾನು SRE ಇಂಜಿನಿಯರ್ ಇಂಟರ್ನ್ ಆಗಿ ಒಂದು ವಾರವನ್ನು ಹೇಗೆ ಕಳೆದೆ. ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರ್‌ನ ದೃಷ್ಟಿಯಲ್ಲಿ ಕರ್ತವ್ಯ

SRE ಇಂಜಿನಿಯರ್ - ತರಬೇತುದಾರ

ಮೊದಲಿಗೆ, ನಾನು ನನ್ನನ್ನು ಪರಿಚಯಿಸುತ್ತೇನೆ. ನಾನು - @tristan.ಓದಿ, ಗುಂಪಿನಲ್ಲಿ ಫ್ರಂಟ್ ಎಂಡ್ ಇಂಜಿನಿಯರ್ ಮಾನಿಟರ್:: ಆರೋಗ್ಯ GitLab. ಕಳೆದ ವಾರ ನಮ್ಮ ಆನ್-ಕಾಲ್ SRE ಇಂಜಿನಿಯರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರೊಂದಿಗೆ ಇಂಟರ್ನಿಂಗ್ ಮಾಡುವ ಗೌರವ ನನಗೆ ಸಿಕ್ಕಿತು. ಕರ್ತವ್ಯ ನಿರತ ಅಧಿಕಾರಿಯು ದಿನನಿತ್ಯದ ಘಟನೆಗಳಿಗೆ ಹೇಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾನೆ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮತ್ತು ಕೆಲಸದಲ್ಲಿ ನಿಜ ಜೀವನದ ಅನುಭವವನ್ನು ಪಡೆಯುವುದು ಗುರಿಯಾಗಿತ್ತು. ನಮ್ಮ ಎಂಜಿನಿಯರ್‌ಗಳು ಬಳಕೆದಾರರ ಅಗತ್ಯಗಳನ್ನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ ಕಾರ್ಯಗಳು ಮಾನಿಟರ್:: ಆರೋಗ್ಯ.

ನಾನು SRE ಇಂಜಿನಿಯರ್ ಅನ್ನು ಒಂದು ವಾರದವರೆಗೆ ಎಲ್ಲೆಡೆ ಅನುಸರಿಸಬೇಕಾಗಿತ್ತು. ಅಂದರೆ, ಹಸ್ತಾಂತರದಲ್ಲಿ ನಾನು ಹಾಜರಿದ್ದೆ, ಅದೇ ಎಚ್ಚರಿಕೆಯ ಚಾನಲ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಘಟನೆಗಳು ಸಂಭವಿಸಿದಾಗ ಮತ್ತು ಅವುಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿದೆ.

ಘಟನೆಗಳು

ಒಂದು ವಾರದಲ್ಲಿ 2 ಘಟನೆಗಳು ನಡೆದಿವೆ.

1. ಕ್ರಿಪ್ಟೋಮಿನರ್

GitLab.com ಬುಧವಾರದಂದು ಬಳಕೆಯಲ್ಲಿ ಜಿಗಿತವನ್ನು ಕಂಡಿತು GitLab ರನ್ನರ್'a, ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿಯನ್ನು ಗಣಿಗಾರಿಕೆ ಮಾಡಲು ಓಟಗಾರನ ನಿಮಿಷಗಳನ್ನು ಬಳಸುವ ಪ್ರಯತ್ನಗಳಿಂದ ಉಂಟಾಗುತ್ತದೆ. ನಮ್ಮದೇ ಆದ ಉಲ್ಲಂಘನೆ ನ್ಯೂಟ್ರಾಲೈಸೇಶನ್ ಟೂಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಈ ಘಟನೆಯನ್ನು ವ್ಯವಹರಿಸಲಾಗಿದೆ, ಇದು ರನ್ನರ್ ಕಾರ್ಯಗಳನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಯೋಜನೆ ಮತ್ತು ಖಾತೆಯನ್ನು ಅಳಿಸುತ್ತದೆ.

ಈ ಈವೆಂಟ್ ಅನ್ನು ಗಮನಿಸದಿದ್ದರೆ, ಸ್ವಯಂಚಾಲಿತ ಸಾಧನವು ಅದನ್ನು ಹಿಡಿಯುತ್ತಿತ್ತು, ಆದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ, SRE ಇಂಜಿನಿಯರ್ ಮೊದಲು ಉಲ್ಲಂಘನೆಯನ್ನು ಗಮನಿಸಿದರು. ಘಟನೆಯ ಕಾರ್ಯವನ್ನು ರಚಿಸಲಾಗಿದೆ, ಆದರೆ ಅದರ ಮಾಹಿತಿಯನ್ನು ಮುಚ್ಚಲಾಗಿದೆ.

2. ಕ್ಯಾನರಿ ಮತ್ತು ಮುಖ್ಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಕಾರ್ಯಕ್ಷಮತೆ ಅವನತಿ

Gitlab.com ನಲ್ಲಿನ ಕ್ಯಾನರಿ ಮತ್ತು ಮುಖ್ಯ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿನ ನಿಧಾನಗತಿಗಳು ಮತ್ತು ದೋಷಗಳ ಹೆಚ್ಚಿದ ಆವರ್ತನದಿಂದ ಈ ಘಟನೆಯು ಸಂಭವಿಸಿದೆ. ಹಲವಾರು ಆಪ್ಡೆಕ್ಸ್ ಮೌಲ್ಯಗಳನ್ನು ಉಲ್ಲಂಘಿಸಲಾಗಿದೆ.

ಘಟನೆಯ ಕಾರ್ಯವನ್ನು ತೆರೆಯಿರಿ: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

ಪ್ರಮುಖ ಸಂಶೋಧನೆಗಳು

ನನ್ನ ಕರ್ತವ್ಯದ ವಾರದಲ್ಲಿ ನಾನು ಕಲಿತ ಕೆಲವು ವಿಷಯಗಳು ಇಲ್ಲಿವೆ.

1. ರೂಢಿಯಿಂದ ವಿಚಲನಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವಾಗ ಎಚ್ಚರಿಕೆಗಳು ಹೆಚ್ಚು ಉಪಯುಕ್ತವಾಗಿವೆ.

ಎಚ್ಚರಿಕೆಗಳನ್ನು ಹಲವಾರು ವಿಧಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:

  • "ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 10 5xx ದೋಷಗಳು ಸಂಭವಿಸಿವೆ" ನಂತಹ ನಿರ್ದಿಷ್ಟ ಮಿತಿ ಮೌಲ್ಯವನ್ನು ಆಧರಿಸಿ ಎಚ್ಚರಿಕೆಗಳು.
  • "ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಮಯದಲ್ಲಿ ವಿನಂತಿಗಳ ಒಟ್ಟು ಪರಿಮಾಣದ 5% ಪ್ರತಿ 10xx ದೋಷಗಳ ಆವರ್ತನ" ದಂತಹ ಶೇಕಡಾವಾರು ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುವ ಎಚ್ಚರಿಕೆಗಳು.
  • "5ನೇ ಪರ್ಸೆಂಟೈಲ್‌ನಲ್ಲಿ 90xx ದೋಷಗಳು" ನಂತಹ ಐತಿಹಾಸಿಕ ಸರಾಸರಿಯನ್ನು ಆಧರಿಸಿ ಎಚ್ಚರಿಕೆಗಳು.

ಸಾಮಾನ್ಯವಾಗಿ ಹೇಳುವುದಾದರೆ, 2 ಮತ್ತು 3 ವಿಧಗಳು ಕರ್ತವ್ಯದಲ್ಲಿರುವ SRE ಗಳಿಗೆ ಹೆಚ್ಚು ಉಪಯುಕ್ತವಾಗಿವೆ, ಏಕೆಂದರೆ ಅವರು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿನ ರೂಢಿಯಿಂದ ವಿಚಲನಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತಾರೆ.

2. ಅನೇಕ ಎಚ್ಚರಿಕೆಗಳು ಘಟನೆಗಳಿಗೆ ಎಂದಿಗೂ ಉಲ್ಬಣಗೊಳ್ಳುವುದಿಲ್ಲ.

SR ಇಂಜಿನಿಯರ್‌ಗಳು ಎಚ್ಚರಿಕೆಗಳ ನಿರಂತರ ಸ್ಟ್ರೀಮ್‌ನೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತಾರೆ, ಅವುಗಳಲ್ಲಿ ಹಲವು ವಾಸ್ತವವಾಗಿ ನಿರ್ಣಾಯಕವಲ್ಲ.

ಹಾಗಾದರೆ ಎಚ್ಚರಿಕೆಗಳನ್ನು ನಿಜವಾಗಿಯೂ ಮುಖ್ಯವಾದವುಗಳಿಗೆ ಮಾತ್ರ ಏಕೆ ಸೀಮಿತಗೊಳಿಸಬಾರದು? ಆದಾಗ್ಯೂ, ಈ ವಿಧಾನದೊಂದಿಗೆ, ಸ್ನೋಬಾಲ್ ನಿಜವಾದ ಸಮಸ್ಯೆಯಾಗಿ ಪ್ರಮುಖ ಹಾನಿಯನ್ನು ಬೆದರಿಸುವ ಆರಂಭಿಕ ಲಕ್ಷಣಗಳನ್ನು ನೀವು ಗುರುತಿಸದಿರಬಹುದು.

ಆನ್-ಕಾಲ್ SRE ಯ ಕೆಲಸವೆಂದರೆ ಯಾವ ಎಚ್ಚರಿಕೆಗಳು ನಿಜವಾಗಿಯೂ ಗಂಭೀರವಾದದ್ದನ್ನು ಸೂಚಿಸುತ್ತವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಉಲ್ಬಣಗೊಳಿಸಬೇಕು ಮತ್ತು ವ್ಯವಹರಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು. ಇದು ಎಚ್ಚರಿಕೆಗಳ ನಮ್ಯತೆಯ ಕಾರಣದಿಂದಾಗಿರುತ್ತದೆ ಎಂದು ನಾನು ಅನುಮಾನಿಸುತ್ತೇನೆ: ಮೇಲೆ ವಿವರಿಸಿದ ಪರಿಸ್ಥಿತಿಗೆ ಅನುಗುಣವಾಗಿ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಹಲವಾರು ಹಂತಗಳು ಅಥವಾ "ಸ್ಮಾರ್ಟ್" ಮಾರ್ಗಗಳಿದ್ದರೆ ಅದು ಉತ್ತಮವಾಗಿರುತ್ತದೆ.

ವೈಶಿಷ್ಟ್ಯ ಸಲಹೆ: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. ಕರ್ತವ್ಯದಲ್ಲಿರುವ ನಮ್ಮ SRE ಗಳು ಬಹಳಷ್ಟು ಸಾಧನಗಳನ್ನು ಬಳಸುತ್ತಾರೆ.

ಆಂತರಿಕ:

  • GitLab ಇನ್ಫ್ರಾ ಪ್ರಾಜೆಕ್ಟ್: ರನ್‌ಬುಕ್‌ಗಳು ಇಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ, ಶಿಫ್ಟ್/ವಾರದ ಕಾರ್ಯಯೋಜನೆಗಳು, ಘಟನೆಯ ಪ್ರತಿಕ್ರಿಯೆ ಕಾರ್ಯಗಳು.
  • GitLab ಸಮಸ್ಯೆಗಳು: ಸಮಸ್ಯೆಗಳಲ್ಲಿ ತನಿಖೆಗಳು, ವಿಮರ್ಶೆಗಳು ಮತ್ತು ನಿರ್ವಹಣೆಯನ್ನು ಸಹ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ.
  • GitLab ಲೇಬಲ್‌ಗಳು: ನಿರ್ದಿಷ್ಟ ಲೇಬಲ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಕಾರ್ಯಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ, ಇದು ಕಾರ್ಯ ಚಟುವಟಿಕೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಬಾಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ.

ಬಾಹ್ಯ:

  • ಪೇಜರ್‌ಡ್ಯೂಟಿ: ಎಚ್ಚರಿಕೆಗಳು
  • ಸ್ಲಾಕ್: ಪೇಜರ್ ಡ್ಯೂಟಿ/ಅಲರ್ಟ್ ಮ್ಯಾನೇಜರ್ ಸಂದೇಶ ಹರಿವು ಇಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ. ಎಚ್ಚರಿಕೆಯನ್ನು ಮುಚ್ಚುವುದು ಅಥವಾ ಘಟನೆಗೆ ಉಲ್ಬಣಗೊಳಿಸುವಂತಹ ವಿವಿಧ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸ್ಲಾಶ್ ಆಜ್ಞೆಗಳೊಂದಿಗೆ ಏಕೀಕರಣ.
  • ಗ್ರಾಫನಾ: ದೀರ್ಘಕಾಲೀನ ಪ್ರವೃತ್ತಿಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವ ಮೆಟ್ರಿಕ್‌ಗಳ ದೃಶ್ಯೀಕರಣ.
  • ಕಿಬಾನಾ: ದೃಶ್ಯೀಕರಣ/ಲಾಗ್ ಹುಡುಕಾಟ, ನಿರ್ದಿಷ್ಟ ಘಟನೆಗಳನ್ನು ಆಳವಾಗಿ ಅಗೆಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀಡುತ್ತದೆ.
  • ಜೂಮ್: ಜೂಮ್‌ನಲ್ಲಿ ನಿರಂತರವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವ "ಬ್ರೇಕ್‌ಔಟ್ ರೂಮ್" ಇದೆ. ಇದು SRE ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಕೋಣೆಯನ್ನು ರಚಿಸುವ ಮತ್ತು ಭಾಗವಹಿಸುವವರನ್ನು ಲಿಂಕ್ ಮಾಡುವ ಅಮೂಲ್ಯ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡದೆ ಈವೆಂಟ್‌ಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಚರ್ಚಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

ಮತ್ತು ಅನೇಕ ಇತರರು.

4. GitLab ನೊಂದಿಗೆ GitLab.com ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ವೈಫಲ್ಯದ ಏಕೈಕ ಅಂಶವಾಗಿದೆ

GitLab.com ಪ್ರಮುಖ ಸೇವೆ ಸ್ಥಗಿತವನ್ನು ಅನುಭವಿಸಿದರೆ, ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ನಮ್ಮ ಸಾಮರ್ಥ್ಯದ ಮೇಲೆ ಅದು ಪರಿಣಾಮ ಬೀರಲು ನಾವು ಬಯಸುವುದಿಲ್ಲ. GitLab.com ಅನ್ನು ನಿರ್ವಹಿಸಲು ಎರಡನೇ GitLab ನಿದರ್ಶನವನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೂಲಕ ಇದನ್ನು ನಿಲ್ಲಿಸಬಹುದು. ವಾಸ್ತವವಾಗಿ, ಇದು ಈಗಾಗಲೇ ನಮಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ: https://ops.gitlab.net/.

5. GitLab ಗೆ ಸೇರಿಸುವುದನ್ನು ಪರಿಗಣಿಸಲು ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳು

  • ಬಹು-ಬಳಕೆದಾರ ಕಾರ್ಯ ಸಂಪಾದನೆ, Google ಡಾಕ್ಸ್ ಅನ್ನು ಹೋಲುತ್ತದೆ. ಇದು ಈವೆಂಟ್‌ನಲ್ಲಿನ ಘಟನೆಗಳ ಕುರಿತು ಕಾರ್ಯಗಳಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಜೊತೆಗೆ ಡಿಬ್ರೀಫಿಂಗ್‌ನಲ್ಲಿನ ಕಾರ್ಯಗಳಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಹಲವಾರು ಭಾಗವಹಿಸುವವರು ನೈಜ ಸಮಯದಲ್ಲಿ ಏನನ್ನಾದರೂ ಸೇರಿಸಬೇಕಾಗಬಹುದು.
  • ಕಾರ್ಯಗಳಿಗಾಗಿ ಇನ್ನಷ್ಟು ವೆಬ್‌ಹೂಕ್‌ಗಳು. ಒಳಗಿನಿಂದ ವಿಭಿನ್ನ GitLab ವರ್ಕ್‌ಫ್ಲೋ ಹಂತಗಳನ್ನು ಚಲಾಯಿಸುವ ಸಾಮರ್ಥ್ಯವು ಸ್ಲಾಕ್ ಏಕೀಕರಣಗಳ ಮೇಲಿನ ನಿಮ್ಮ ಅವಲಂಬನೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, GitLab ಸಂಚಿಕೆಯಲ್ಲಿ ಸ್ಲಾಶ್ ಆಜ್ಞೆಯ ಮೂಲಕ ಪೇಜರ್‌ಡ್ಯೂಟಿಯಲ್ಲಿ ಎಚ್ಚರಿಕೆಯನ್ನು ಅನುಮತಿಸುವ ಸಾಮರ್ಥ್ಯ.
    ತೀರ್ಮಾನಕ್ಕೆ

SRE ಇಂಜಿನಿಯರ್‌ಗಳು ಬಹಳಷ್ಟು ಸಂಕೀರ್ಣತೆಗಳೊಂದಿಗೆ ಕಠಿಣ ಸಮಯವನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಹೆಚ್ಚಿನ GitLab ಉತ್ಪನ್ನಗಳನ್ನು ನೋಡಲು ಇದು ಉತ್ತಮವಾಗಿದೆ. ನಾವು ಈಗಾಗಲೇ ಉತ್ಪನ್ನಕ್ಕೆ ಕೆಲವು ಸೇರ್ಪಡೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ ಅದು ಮೇಲೆ ತಿಳಿಸಲಾದ ಕೆಲಸದ ಹರಿವುಗಳನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ. ವಿವರಗಳು ಇಲ್ಲಿ ಲಭ್ಯವಿದೆ Ops ಉತ್ಪನ್ನ ದೃಷ್ಟಿ ವಿಭಾಗ.

ಈ ಎಲ್ಲಾ ಉತ್ತಮ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಒಟ್ಟಿಗೆ ತರಲು ನಾವು 2020 ರಲ್ಲಿ ತಂಡವನ್ನು ವಿಸ್ತರಿಸುತ್ತಿದ್ದೇವೆ. ಆಸಕ್ತಿ ಇದ್ದರೆ, ದಯವಿಟ್ಟು ಪರಿಶೀಲಿಸಿ ಖಾಲಿ ಹುದ್ದೆಗಳು, ಮತ್ತು ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ನಮ್ಮ ತಂಡದಲ್ಲಿರುವ ಯಾರನ್ನಾದರೂ ಸಂಪರ್ಕಿಸಲು ಮುಕ್ತವಾಗಿರಿ.

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ