ಟಾಪ್ ಫಕಪೋವ್ ಸಯಾನ್

ಎಲ್ಲ ಚೆನ್ನಾಗಿದೆ! 

ನನ್ನ ಹೆಸರು ನಿಕಿತಾ, ನಾನು ಸಿಯಾನ್ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡದ ನಾಯಕ. ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಘಟನೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಶೂನ್ಯಕ್ಕೆ ತಗ್ಗಿಸುವುದು ಕಂಪನಿಯಲ್ಲಿ ನನ್ನ ಜವಾಬ್ದಾರಿಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.
ಕೆಳಗೆ ಚರ್ಚಿಸಲಾಗಿರುವುದು ನಮಗೆ ಬಹಳಷ್ಟು ನೋವನ್ನು ತಂದಿದೆ ಮತ್ತು ಈ ಲೇಖನದ ಉದ್ದೇಶವು ಇತರ ಜನರು ನಮ್ಮ ತಪ್ಪುಗಳನ್ನು ಪುನರಾವರ್ತಿಸುವುದನ್ನು ತಡೆಯುವುದು ಅಥವಾ ಕನಿಷ್ಠ ಅವರ ಪ್ರಭಾವವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು. 

ಮುನ್ನುಡಿ

ಬಹಳ ಹಿಂದೆಯೇ, ಸಿಯಾನ್ ಏಕಶಿಲೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವಾಗ ಮತ್ತು ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳ ಯಾವುದೇ ಸುಳಿವುಗಳು ಇನ್ನೂ ಇಲ್ಲದಿದ್ದಾಗ, ನಾವು 3-5 ಪುಟಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ಸಂಪನ್ಮೂಲದ ಲಭ್ಯತೆಯನ್ನು ಅಳೆಯುತ್ತೇವೆ. 

ಅವರು ಉತ್ತರಿಸುತ್ತಾರೆ - ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ, ಅವರು ದೀರ್ಘಕಾಲದವರೆಗೆ ಉತ್ತರಿಸದಿದ್ದರೆ - ಎಚ್ಚರಿಕೆ. ಇದನ್ನು ಘಟನೆ ಎಂದು ಪರಿಗಣಿಸಲು ಅವರು ಎಷ್ಟು ಸಮಯದವರೆಗೆ ಕೆಲಸದಿಂದ ಹೊರಗುಳಿಯಬೇಕು ಎಂದು ಸಭೆಗಳಲ್ಲಿ ಜನರು ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಇಂಜಿನಿಯರ್‌ಗಳ ತಂಡ ಯಾವಾಗಲೂ ಘಟನೆಯ ತನಿಖೆಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದೆ. ತನಿಖೆ ಪೂರ್ಣಗೊಂಡಾಗ, ಅವರು ಪೋಸ್ಟ್‌ಮಾರ್ಟಮ್ ಅನ್ನು ಬರೆದರು - ಸ್ವರೂಪದಲ್ಲಿ ಇಮೇಲ್ ಮೂಲಕ ಒಂದು ರೀತಿಯ ವರದಿ: ಏನಾಯಿತು, ಅದು ಎಷ್ಟು ಕಾಲ ನಡೆಯಿತು, ನಾವು ಈ ಕ್ಷಣದಲ್ಲಿ ಏನು ಮಾಡಿದ್ದೇವೆ, ಭವಿಷ್ಯದಲ್ಲಿ ನಾವು ಏನು ಮಾಡುತ್ತೇವೆ. 

ಸೈಟ್ನ ಮುಖ್ಯ ಪುಟಗಳು ಅಥವಾ ನಾವು ಕೆಳಭಾಗವನ್ನು ಹೊಡೆದಿದ್ದೇವೆ ಎಂದು ನಾವು ಹೇಗೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ

 
ದೋಷದ ಆದ್ಯತೆಯನ್ನು ಹೇಗಾದರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ವ್ಯಾಪಾರ ಕಾರ್ಯಕ್ಕಾಗಿ ನಾವು ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಸೈಟ್ ಪುಟಗಳನ್ನು ಗುರುತಿಸಿದ್ದೇವೆ. ಅವುಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು ಯಶಸ್ವಿ/ವಿಫಲವಾದ ವಿನಂತಿಗಳು ಮತ್ತು ಸಮಯ ಮೀರುವಿಕೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಎಣಿಸುತ್ತೇವೆ. ಈ ರೀತಿ ನಾವು ಸಮಯವನ್ನು ಅಳೆಯುತ್ತೇವೆ. 

ಮುಖ್ಯ ಸೇವೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಸೈಟ್‌ನ ಹಲವಾರು ಪ್ರಮುಖ ವಿಭಾಗಗಳಿವೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ - ಜಾಹೀರಾತುಗಳನ್ನು ಹುಡುಕುವುದು ಮತ್ತು ಸಲ್ಲಿಸುವುದು. ವಿಫಲವಾದ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ 1% ಮೀರಿದರೆ, ಇದು ನಿರ್ಣಾಯಕ ಘಟನೆಯಾಗಿದೆ. ಅವಿಭಾಜ್ಯ ಸಮಯದಲ್ಲಿ 15 ನಿಮಿಷಗಳಲ್ಲಿ ದೋಷದ ಪ್ರಮಾಣವು 0,1% ಮೀರಿದರೆ, ಇದನ್ನು ನಿರ್ಣಾಯಕ ಘಟನೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಈ ಮಾನದಂಡಗಳು ಹೆಚ್ಚಿನ ಘಟನೆಗಳನ್ನು ಒಳಗೊಂಡಿವೆ; ಉಳಿದವು ಈ ಲೇಖನದ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿದೆ.

ಟಾಪ್ ಅತ್ಯುತ್ತಮ ಘಟನೆಗಳು ಸಯಾನ್

ಆದ್ದರಿಂದ, ಒಂದು ಘಟನೆ ಸಂಭವಿಸಿದೆ ಎಂಬ ಅಂಶವನ್ನು ನಿರ್ಧರಿಸಲು ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಕಲಿತಿದ್ದೇವೆ. 

ಈಗ ಪ್ರತಿಯೊಂದು ಘಟನೆಯನ್ನು ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ ಮತ್ತು ಜಿರಾ ಮಹಾಕಾವ್ಯದಲ್ಲಿ ಪ್ರತಿಫಲಿಸುತ್ತದೆ. ಮೂಲಕ: ಇದಕ್ಕಾಗಿ ನಾವು ಪ್ರತ್ಯೇಕ ಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಅದನ್ನು FAIL ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ - ಅದರಲ್ಲಿ ಮಹಾಕಾವ್ಯಗಳನ್ನು ಮಾತ್ರ ರಚಿಸಬಹುದು. 

ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಲ್ಲಿ ನೀವು ಎಲ್ಲಾ ವೈಫಲ್ಯಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, ನಾಯಕರು: 

• mssql ಸಂಬಂಧಿತ ಘಟನೆಗಳು;
• ಬಾಹ್ಯ ಅಂಶಗಳಿಂದ ಉಂಟಾಗುವ ಘಟನೆಗಳು;
• ನಿರ್ವಾಹಕ ದೋಷಗಳು.

ನಿರ್ವಾಹಕರ ತಪ್ಪುಗಳು ಮತ್ತು ಇತರ ಕೆಲವು ಆಸಕ್ತಿದಾಯಕ ವೈಫಲ್ಯಗಳನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ನೋಡೋಣ.

ಐದನೇ ಸ್ಥಾನ - "ಡಿಎನ್ಎಸ್ನಲ್ಲಿ ವಿಷಯಗಳನ್ನು ಕ್ರಮವಾಗಿ ಇರಿಸುವುದು"

ಅದು ಬಿರುಗಾಳಿಯ ಮಂಗಳವಾರ. DNS ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕ್ರಮವನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. 

ನಾನು ಆಂತರಿಕ DNS ಸರ್ವರ್‌ಗಳನ್ನು ಬೈಂಡ್‌ನಿಂದ powerdns ಗೆ ವರ್ಗಾಯಿಸಲು ಬಯಸುತ್ತೇನೆ, ಇದಕ್ಕಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕ ಸರ್ವರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತೇನೆ, ಅಲ್ಲಿ DNS ಹೊರತುಪಡಿಸಿ ಏನೂ ಇಲ್ಲ. 

ನಮ್ಮ DC ಗಳ ಪ್ರತಿಯೊಂದು ಸ್ಥಳದಲ್ಲಿ ನಾವು ಒಂದು DNS ಸರ್ವರ್ ಅನ್ನು ಇರಿಸಿದ್ದೇವೆ ಮತ್ತು ಜೋನ್‌ಗಳನ್ನು ಬೈಂಡ್‌ನಿಂದ powerdns ಗೆ ಸರಿಸಲು ಮತ್ತು ಮೂಲಸೌಕರ್ಯವನ್ನು ಹೊಸ ಸರ್ವರ್‌ಗಳಿಗೆ ಬದಲಾಯಿಸುವ ಕ್ಷಣ ಬಂದಿದೆ. 

ನಡೆಸುವಿಕೆಯ ಮಧ್ಯದಲ್ಲಿ, ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಸ್ಥಳೀಯ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆ ಬೈಂಡ್‌ಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ, ಕೇವಲ ಒಂದು ಮಾತ್ರ ಉಳಿದಿದೆ, ಅದು ಸೇಂಟ್ ಪೀಟರ್ಸ್‌ಬರ್ಗ್‌ನ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿದೆ. ಈ ಡಿಸಿಯನ್ನು ಆರಂಭದಲ್ಲಿ ನಮಗೆ ನಾನ್ ಕ್ರಿಟಿಕಲ್ ಎಂದು ಘೋಷಿಸಲಾಯಿತು, ಆದರೆ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಒಂದು ವೈಫಲ್ಯದ ಬಿಂದುವಾಯಿತು.
ಈ ಸ್ಥಳಾಂತರದ ಅವಧಿಯಲ್ಲಿ ಮಾಸ್ಕೋ ಮತ್ತು ಸೇಂಟ್ ಪೀಟರ್ಸ್ಬರ್ಗ್ ನಡುವಿನ ಕಾಲುವೆ ಕುಸಿಯಿತು. ನಾವು ಐದು ನಿಮಿಷಗಳ ಕಾಲ DNS ಇಲ್ಲದೆ ಉಳಿದಿದ್ದೇವೆ ಮತ್ತು ಹೋಸ್ಟರ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದಾಗ ನಾವು ಹಿಂತಿರುಗಿದ್ದೇವೆ. 

ತೀರ್ಮಾನಗಳು:

ಮೊದಲು ನಾವು ಕೆಲಸಕ್ಕೆ ತಯಾರಿ ಮಾಡುವಾಗ ಬಾಹ್ಯ ಅಂಶಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದ್ದರೆ, ಈಗ ಅವುಗಳನ್ನು ನಾವು ಸಿದ್ಧಪಡಿಸುತ್ತಿರುವ ಪಟ್ಟಿಯಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ. ಮತ್ತು ಈಗ ನಾವು ಎಲ್ಲಾ ಘಟಕಗಳನ್ನು n-2 ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ ಮತ್ತು ಕೆಲಸದ ಸಮಯದಲ್ಲಿ ನಾವು ಈ ಮಟ್ಟವನ್ನು n-1 ಗೆ ಇಳಿಸಬಹುದು.

• ಕ್ರಿಯಾ ಯೋಜನೆಯನ್ನು ರಚಿಸುವಾಗ, ಸೇವೆಯು ವಿಫಲಗೊಳ್ಳಬಹುದಾದ ಬಿಂದುಗಳನ್ನು ಗುರುತಿಸಿ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಮುಂಚಿತವಾಗಿ "ಕೆಟ್ಟದಿಂದ ಕೆಟ್ಟದಕ್ಕೆ" ಹೋದ ಸನ್ನಿವೇಶದ ಮೂಲಕ ಯೋಚಿಸಿ.
• ವಿವಿಧ ಜಿಯೋಲೊಕೇಶನ್‌ಗಳು/ಡೇಟಾ ಸೆಂಟರ್‌ಗಳು/ರಾಕ್‌ಗಳು/ಸ್ವಿಚ್‌ಗಳು/ಇನ್‌ಪುಟ್‌ಗಳಾದ್ಯಂತ ಆಂತರಿಕ DNS ಸರ್ವರ್‌ಗಳನ್ನು ವಿತರಿಸಿ.
• ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ, ಸ್ಥಳೀಯ ಕ್ಯಾಶಿಂಗ್ DNS ಸರ್ವರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ, ಇದು ಮುಖ್ಯ DNS ಸರ್ವರ್‌ಗಳಿಗೆ ವಿನಂತಿಗಳನ್ನು ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ಅದು ಸಂಗ್ರಹದಿಂದ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. 

ನಾಲ್ಕನೇ ಸ್ಥಾನ - "Nginx ನಲ್ಲಿ ವಸ್ತುಗಳನ್ನು ಕ್ರಮವಾಗಿ ಇರಿಸುವುದು"

ಒಂದು ಉತ್ತಮ ದಿನ, ನಮ್ಮ ತಂಡವು "ನಾವು ಇದನ್ನು ಸಾಕಷ್ಟು ಹೊಂದಿದ್ದೇವೆ" ಎಂದು ನಿರ್ಧರಿಸಿದೆ ಮತ್ತು nginx ಸಂರಚನೆಗಳನ್ನು ಮರುಫಲಕ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯು ಪ್ರಾರಂಭವಾಯಿತು. ಸಂರಚನೆಗಳನ್ನು ಅರ್ಥಗರ್ಭಿತ ರಚನೆಗೆ ತರುವುದು ಮುಖ್ಯ ಗುರಿಯಾಗಿದೆ. ಹಿಂದೆ, ಎಲ್ಲವನ್ನೂ "ಐತಿಹಾಸಿಕವಾಗಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ" ಮತ್ತು ಯಾವುದೇ ತರ್ಕವನ್ನು ಹೊಂದಿಲ್ಲ. ಈಗ ಪ್ರತಿಯೊಂದು ಸರ್ವರ್_ಹೆಸರನ್ನು ಅದೇ ಹೆಸರಿನ ಫೈಲ್‌ಗೆ ಸರಿಸಲಾಗಿದೆ ಮತ್ತು ಎಲ್ಲಾ ಸಂರಚನೆಗಳನ್ನು ಫೋಲ್ಡರ್‌ಗಳಾಗಿ ವಿತರಿಸಲಾಗಿದೆ. ಮೂಲಕ, ಸಂರಚನೆಯು 253949 ಸಾಲುಗಳು ಅಥವಾ 7836520 ಅಕ್ಷರಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಸುಮಾರು 7 ಮೆಗಾಬೈಟ್ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಉನ್ನತ ಮಟ್ಟದ ರಚನೆ: 

Nginx ರಚನೆ

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

ಇದು ಹೆಚ್ಚು ಉತ್ತಮವಾಯಿತು, ಆದರೆ ಸಂರಚನೆಗಳನ್ನು ಮರುಹೆಸರಿಸುವ ಮತ್ತು ವಿತರಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ಅವುಗಳಲ್ಲಿ ಕೆಲವು ತಪ್ಪಾದ ವಿಸ್ತರಣೆಯನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಇವುಗಳನ್ನು *.conf ನಿರ್ದೇಶನದಲ್ಲಿ ಸೇರಿಸಲಾಗಿಲ್ಲ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಕೆಲವು ಹೋಸ್ಟ್‌ಗಳು ಲಭ್ಯವಿಲ್ಲ ಮತ್ತು 301 ಅನ್ನು ಮುಖ್ಯ ಪುಟಕ್ಕೆ ಹಿಂತಿರುಗಿಸಿದರು. ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್ 5xx/4xx ಅಲ್ಲ ಎಂಬ ಕಾರಣದಿಂದಾಗಿ, ಇದು ತಕ್ಷಣವೇ ಗಮನಿಸಲಿಲ್ಲ, ಆದರೆ ಬೆಳಿಗ್ಗೆ ಮಾತ್ರ. ಅದರ ನಂತರ, ನಾವು ಮೂಲಸೌಕರ್ಯ ಘಟಕಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.

ತೀರ್ಮಾನಗಳು: 

• ನಿಮ್ಮ ಸಂರಚನೆಗಳನ್ನು ಸರಿಯಾಗಿ ರೂಪಿಸಿ (ಕೇವಲ nginx ಅಲ್ಲ) ಮತ್ತು ಯೋಜನೆಯ ಆರಂಭಿಕ ಹಂತದಲ್ಲಿ ರಚನೆಯ ಮೂಲಕ ಯೋಚಿಸಿ. ಈ ರೀತಿಯಲ್ಲಿ ನೀವು ಅವರನ್ನು ತಂಡಕ್ಕೆ ಹೆಚ್ಚು ಅರ್ಥವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ, ಇದು TTM ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
• ಕೆಲವು ಮೂಲಸೌಕರ್ಯ ಘಟಕಗಳಿಗೆ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಿರಿ. ಉದಾಹರಣೆಗೆ: ಎಲ್ಲಾ ಪ್ರಮುಖ ಸರ್ವರ್_ಹೆಸರುಗಳು ಸರಿಯಾದ ಸ್ಥಿತಿ + ಪ್ರತಿಕ್ರಿಯೆ ದೇಹವನ್ನು ನೀಡುತ್ತವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವುದು. ಘಟಕದ ಮೂಲ ಕಾರ್ಯಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಕೆಲವು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಕೈಯಲ್ಲಿ ಹೊಂದಿದ್ದರೆ ಸಾಕು, ಆದ್ದರಿಂದ ಬೆಳಿಗ್ಗೆ 3 ಗಂಟೆಗೆ ಉದ್ರಿಕ್ತವಾಗಿ ನೆನಪಿಟ್ಟುಕೊಳ್ಳದಿರಲು ಇನ್ನೇನು ಪರಿಶೀಲಿಸಬೇಕು. 

ಮೂರನೇ ಸ್ಥಾನ - "ಕಸ್ಸಂದ್ರದಲ್ಲಿ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಸ್ಥಳಾವಕಾಶವಿಲ್ಲ"

ಡೇಟಾವು ಸ್ಥಿರವಾಗಿ ಬೆಳೆಯಿತು, ಮತ್ತು ಕಸ್ಸಂದ್ರ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ದೊಡ್ಡ ಕೇಸ್‌ಸ್ಪೇಸ್‌ಗಳ ದುರಸ್ತಿ ವಿಫಲಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದ ಕ್ಷಣದವರೆಗೂ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿತ್ತು, ಏಕೆಂದರೆ ಅವುಗಳ ಮೇಲೆ ಸಂಕೋಚನವು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. 

ಒಂದು ಬಿರುಗಾಳಿಯ ದಿನ ಕ್ಲಸ್ಟರ್ ಬಹುತೇಕ ಕುಂಬಳಕಾಯಿಯಾಗಿ ಬದಲಾಯಿತು, ಅವುಗಳೆಂದರೆ:

• ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಒಟ್ಟು ಜಾಗದ ಸುಮಾರು 20% ಉಳಿದಿದೆ;
• ನೋಡ್‌ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸೇರಿಸುವುದು ಅಸಾಧ್ಯ, ಏಕೆಂದರೆ ವಿಭಾಗಗಳ ಮೇಲೆ ಸ್ಥಳಾವಕಾಶದ ಕೊರತೆಯಿಂದಾಗಿ ನೋಡ್ ಅನ್ನು ಸೇರಿಸಿದ ನಂತರ ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆಯು ಹಾದುಹೋಗುವುದಿಲ್ಲ;
• ಸಂಕೋಚನವು ಕಾರ್ಯನಿರ್ವಹಿಸದ ಕಾರಣ ಉತ್ಪಾದಕತೆಯು ಕ್ರಮೇಣ ಕಡಿಮೆಯಾಗುತ್ತದೆ; 
• ಕ್ಲಸ್ಟರ್ ತುರ್ತು ಕ್ರಮದಲ್ಲಿದೆ.

ನಿರ್ಗಮಿಸಿ - ನಾವು ಸ್ವಚ್ಛಗೊಳಿಸದೆಯೇ ನಾವು 5 ಹೆಚ್ಚು ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ, ಅದರ ನಂತರ ನಾವು ಅವುಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ನಿಂದ ವ್ಯವಸ್ಥಿತವಾಗಿ ತೆಗೆದುಹಾಕಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಸ್ಥಳಾವಕಾಶವಿಲ್ಲದ ಖಾಲಿ ನೋಡ್‌ಗಳಂತೆ ಅವುಗಳನ್ನು ಮರು-ನಮೂದಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ನಾವು ಬಯಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ಕಳೆದಿದೆ. ಕ್ಲಸ್ಟರ್‌ನ ಭಾಗಶಃ ಅಥವಾ ಸಂಪೂರ್ಣ ಅಲಭ್ಯತೆಯ ಅಪಾಯವಿತ್ತು. 

ತೀರ್ಮಾನಗಳು:

• ಎಲ್ಲಾ ಕಸಂಡ್ರಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ, ಪ್ರತಿ ವಿಭಾಗದಲ್ಲಿ 60% ಕ್ಕಿಂತ ಹೆಚ್ಚು ಜಾಗವನ್ನು ಆಕ್ರಮಿಸಬಾರದು. 
• ಅವುಗಳನ್ನು 50% ಸಿಪಿಯುಗಿಂತ ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಬಾರದು.
• ಸಾಮರ್ಥ್ಯದ ಯೋಜನೆ ಬಗ್ಗೆ ನೀವು ಮರೆಯಬಾರದು ಮತ್ತು ಅದರ ನಿಶ್ಚಿತಗಳ ಆಧಾರದ ಮೇಲೆ ಪ್ರತಿ ಘಟಕಕ್ಕೆ ಅದರ ಮೂಲಕ ಯೋಚಿಸಬೇಕು.
• ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ ಹೆಚ್ಚು ನೋಡ್ಗಳು, ಉತ್ತಮ. ಸಣ್ಣ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಹೊಂದಿರುವ ಸರ್ವರ್‌ಗಳು ವೇಗವಾಗಿ ಓವರ್‌ಲೋಡ್ ಆಗುತ್ತವೆ ಮತ್ತು ಅಂತಹ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪುನರುಜ್ಜೀವನಗೊಳಿಸಲು ಸುಲಭವಾಗಿದೆ. 

ಎರಡನೇ ಸ್ಥಾನ - “ಕನ್ಸಲ್ ಕೀ ಮೌಲ್ಯ ಸಂಗ್ರಹಣೆಯಿಂದ ಡೇಟಾ ಕಣ್ಮರೆಯಾಯಿತು”

ಸೇವೆಯ ಅನ್ವೇಷಣೆಗಾಗಿ, ನಾವು ಅನೇಕರಂತೆ ಕಾನ್ಸಲ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಆದರೆ ಏಕಶಿಲೆಯ ನೀಲಿ-ಹಸಿರು ವಿನ್ಯಾಸಕ್ಕಾಗಿ ನಾವು ಅದರ ಕೀ-ಮೌಲ್ಯವನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದು ಸಕ್ರಿಯ ಮತ್ತು ನಿಷ್ಕ್ರಿಯ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಇದು ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಸ್ಥಳಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, KV ಯೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ನಿಯೋಜನೆ ಸೇವೆಯನ್ನು ಬರೆಯಲಾಗಿದೆ. ಕೆಲವು ಹಂತದಲ್ಲಿ, KV ಯಿಂದ ಡೇಟಾ ಕಣ್ಮರೆಯಾಯಿತು. ಮೆಮೊರಿಯಿಂದ ಮರುಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಆದರೆ ಹಲವಾರು ದೋಷಗಳೊಂದಿಗೆ. ಪರಿಣಾಮವಾಗಿ, ಅಪ್‌ಲೋಡ್ ಸಮಯದಲ್ಲಿ, ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗಳಲ್ಲಿನ ಲೋಡ್ ಅನ್ನು ಅಸಮಾನವಾಗಿ ವಿತರಿಸಲಾಯಿತು ಮತ್ತು CPU ನಲ್ಲಿ ಬ್ಯಾಕೆಂಡ್‌ಗಳು ಓವರ್‌ಲೋಡ್ ಆಗಿರುವುದರಿಂದ ನಾವು ಅನೇಕ 502 ದೋಷಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಕಾನ್ಸಲ್ ಕೆವಿಯಿಂದ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿದ್ದೇವೆ, ಅಲ್ಲಿಂದ ಅವುಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ಇನ್ನು ಮುಂದೆ ಅಷ್ಟು ಸುಲಭವಲ್ಲ.  

ತೀರ್ಮಾನಗಳು:

• ಯಾವುದೇ ಅನುಮತಿಯಿಲ್ಲದ ಸೇವೆಗಳು ಸೈಟ್‌ನ ಕಾರ್ಯಾಚರಣೆಗೆ ನಿರ್ಣಾಯಕ ಡೇಟಾವನ್ನು ಹೊಂದಿರಬಾರದು. ಉದಾಹರಣೆಗೆ, ನೀವು ES ನಲ್ಲಿ ದೃಢೀಕರಣವನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಅಗತ್ಯವಿರುವ ಎಲ್ಲಿಂದಲಾದರೂ ನೆಟ್‌ವರ್ಕ್ ಮಟ್ಟದಲ್ಲಿ ಪ್ರವೇಶವನ್ನು ನಿರಾಕರಿಸುವುದು ಉತ್ತಮವಾಗಿದೆ, ಅಗತ್ಯವಿರುವದನ್ನು ಮಾತ್ರ ಬಿಡಿ, ಮತ್ತು action.destructive_requires_name: true.
• ಮುಂಚಿತವಾಗಿ ನಿಮ್ಮ ಬ್ಯಾಕಪ್ ಮತ್ತು ಮರುಪಡೆಯುವಿಕೆ ಕಾರ್ಯವಿಧಾನವನ್ನು ಅಭ್ಯಾಸ ಮಾಡಿ. ಉದಾಹರಣೆಗೆ, ಮುಂಚಿತವಾಗಿ ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿ (ಉದಾಹರಣೆಗೆ, ಪೈಥಾನ್‌ನಲ್ಲಿ) ಬ್ಯಾಕಪ್ ಮತ್ತು ಮರುಸ್ಥಾಪಿಸಬಹುದು.

ಮೊದಲ ಸ್ಥಾನ - "ಕ್ಯಾಪ್ಟನ್ ಅಸ್ಪಷ್ಟ" 

ಕೆಲವು ಹಂತದಲ್ಲಿ, ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ 10+ ಸರ್ವರ್‌ಗಳಿರುವ ಸಂದರ್ಭಗಳಲ್ಲಿ nginx ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗಳಲ್ಲಿ ಲೋಡ್‌ನ ಅಸಮ ವಿತರಣೆಯನ್ನು ನಾವು ಗಮನಿಸಿದ್ದೇವೆ. ರೌಂಡ್-ರಾಬಿನ್ 1 ರಿಂದ ಕೊನೆಯ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಿರುವುದರಿಂದ ಮತ್ತು ಪ್ರತಿ nginx ಮರುಲೋಡ್ ಪ್ರಾರಂಭವಾದ ಕಾರಣ, ಮೊದಲ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗಳು ಯಾವಾಗಲೂ ಉಳಿದವುಗಳಿಗಿಂತ ಹೆಚ್ಚಿನ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ. ಪರಿಣಾಮವಾಗಿ, ಅವರು ನಿಧಾನವಾಗಿ ಕೆಲಸ ಮಾಡಿದರು ಮತ್ತು ಇಡೀ ಸೈಟ್‌ಗೆ ತೊಂದರೆಯಾಯಿತು. ಸಂಚಾರ ದಟ್ಟಣೆ ಹೆಚ್ಚಾದಂತೆ ಇದು ಹೆಚ್ಚು ಗಮನಕ್ಕೆ ಬಂತು. ಯಾದೃಚ್ಛಿಕ ಸಕ್ರಿಯಗೊಳಿಸಲು nginx ಅನ್ನು ಸರಳವಾಗಿ ನವೀಕರಿಸುವುದು ಕೆಲಸ ಮಾಡಲಿಲ್ಲ - ನಾವು ಆವೃತ್ತಿ 1.15 (ಆ ಕ್ಷಣದಲ್ಲಿ) ತೆಗೆದುಕೊಳ್ಳದ ಲುವಾ ಕೋಡ್‌ನ ಗುಂಪನ್ನು ಮತ್ತೆ ಮಾಡಬೇಕಾಗಿದೆ. ನಾವು ನಮ್ಮ nginx 1.14.2 ಅನ್ನು ಪ್ಯಾಚ್ ಮಾಡಬೇಕಾಗಿತ್ತು, ಅದರಲ್ಲಿ ಯಾದೃಚ್ಛಿಕ ಬೆಂಬಲವನ್ನು ಪರಿಚಯಿಸಲಾಯಿತು. ಇದರಿಂದ ಸಮಸ್ಯೆ ಪರಿಹಾರವಾಯಿತು. ಈ ದೋಷವು "ಕ್ಯಾಪ್ಟನ್ ನಾನ್-ಸ್ಪಷ್ಟತೆ" ವರ್ಗವನ್ನು ಗೆಲ್ಲುತ್ತದೆ.

ತೀರ್ಮಾನಗಳು:

ಈ ದೋಷವನ್ನು ಅನ್ವೇಷಿಸಲು ಇದು ತುಂಬಾ ಆಸಕ್ತಿದಾಯಕ ಮತ್ತು ಉತ್ತೇಜಕವಾಗಿದೆ). 

• ನಿಮ್ಮ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಆಯೋಜಿಸಿ ಇದರಿಂದ ಅಂತಹ ಏರಿಳಿತಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಕಂಡುಹಿಡಿಯಲು ಇದು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಪ್ರತಿ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನ ಪ್ರತಿ ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ rps ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ನೀವು ELK ಅನ್ನು ಬಳಸಬಹುದು, nginx ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಅವರ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಮಸ್ಯೆಯನ್ನು ಗುರುತಿಸಲು ಇದು ನಮಗೆ ಸಹಾಯ ಮಾಡಿತು. 

ಪರಿಣಾಮವಾಗಿ, ನೀವು ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದರ ಬಗ್ಗೆ ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮವಾದ ವಿಧಾನದೊಂದಿಗೆ ಹೆಚ್ಚಿನ ವೈಫಲ್ಯಗಳನ್ನು ತಪ್ಪಿಸಬಹುದಿತ್ತು. ನಾವು ಯಾವಾಗಲೂ ಮರ್ಫಿ ನಿಯಮವನ್ನು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು: ಯಾವುದಾದರೂ ತಪ್ಪಾಗಬಹುದು, ಅದು ತಪ್ಪಾಗುತ್ತದೆ, ಮತ್ತು ಅದರ ಆಧಾರದ ಮೇಲೆ ಘಟಕಗಳನ್ನು ನಿರ್ಮಿಸಿ. 

ಮೂಲ: www.habr.com