엔지니어가 애플리케이션 모니터링에 관심을 두지 않는 이유는 무엇입니까?

모두 즐거운 금요일 보내! 친구 여러분, 오늘 우리는 코스 전용 출판물 시리즈를 계속합니다 "DevOps 사례 및 도구", 그 강좌의 새로운 그룹의 수업이 다음 주 말에 시작되기 때문입니다. 자, 시작해 봅시다!

모니터링은 막. 이것은 알려진 사실입니다. Nagios를 실행하고, 원격 시스템에서 NRPE를 실행하고, NRPE TCP 포트 5666에서 Nagios를 구성하면 모니터링이 가능합니다.

너무 쉬워서 흥미롭지 않네요. 이제 Nagios 및 NRPE에 기본적으로 제공되는 CPU 시간, 디스크 하위 시스템, RAM에 대한 기본 메트릭이 있습니다. 그러나 이것은 실제로 "모니터링"이 아닙니다. 이것은 시작에 불과합니다.

(보통 PNP4Nagios, RRDtool 및 Thruk를 설치하고 Slack에서 알림을 설정한 후 바로 nagiosexchange로 이동하지만 지금은 그대로 두겠습니다.)

좋은 모니터링 실제로는 매우 복잡하므로 모니터링하는 애플리케이션의 내부를 알아야 합니다.

모니터링이 어려운가요?

Linux이든 Windows이든 모든 서버는 정의상 어떤 목적으로 사용됩니다. Apache, Samba, Tomcat, 파일 저장소, LDAP - 이러한 모든 서비스는 하나 이상의 측면에서 다소 독특합니다. 각각은 고유한 기능과 특성을 가지고 있습니다. 서버에 부하가 걸릴 때 관심을 끄는 지표인 KPI(핵심 성과 지표)를 얻는 방법에는 여러 가지가 있습니다.

사진 작성자 루크 체서 에 Unsplash

(내 대시보드가 ​​네온 블루였으면 좋겠다 - 몽환적인 한숨 -... 흠...)

서비스를 제공하는 모든 소프트웨어에는 메트릭을 수집하는 메커니즘이 있어야 합니다. Apache에는 모듈이 있습니다 mod-status, 서버 상태 페이지를 표시합니다. Nginx는 - stub_status. Tomcat에는 주요 측정항목을 표시하는 JMX 또는 사용자 정의 웹 애플리케이션이 있습니다. MySQL에는 "전역 상태 표시" 등의 명령이 있습니다.
그렇다면 개발자는 자신이 만드는 애플리케이션에 유사한 메커니즘을 구축하지 않는 이유는 무엇입니까?

개발자만 이런 일을 하고 있나요?

측정항목 삽입에 대한 일정 수준의 무관심은 개발자에게만 국한되지 않습니다. 나는 Tomcat을 사용하여 애플리케이션을 개발하는 회사에서 일했으며 일반적인 Tomcat 오류 로그를 제외하고 자체 측정 항목과 서비스 활동 로그를 제공하지 않았습니다. 일부 개발자는 운이 좋지 않아 새벽 3시 15분에 로그를 읽을 수 있는 시스템 관리자에게는 아무 의미도 없는 로그를 많이 생성합니다.

사진 작성자 팀 고우 에 Unsplash

이러한 제품이 출시될 수 있도록 하는 시스템 엔지니어도 이번 상황에 대해 어느 정도 책임을 져야 합니다. 메트릭의 컨텍스트와 애플리케이션 활동을 고려하여 이를 해석할 수 있는 능력 없이 로그에서 의미 있는 메트릭을 추출하려고 시도할 시간이나 주의를 기울이는 시스템 엔지니어는 거의 없습니다. 어떤 사람들은 "뭔가 현재(또는 곧) 잘못될 것입니다"라는 표시 외에는 이를 통해 어떻게 이익을 얻을 수 있는지 이해하지 못합니다.

메트릭의 필요성에 대한 생각의 변화는 개발자뿐만 아니라 시스템 엔지니어 사이에서도 일어나야 합니다.

중요한 이벤트에 대응할 뿐만 아니라 이러한 이벤트가 발생하지 않도록 해야 하는 시스템 엔지니어의 경우 일반적으로 측정항목의 부족이 이를 수행하는 데 장애가 됩니다.

그러나 시스템 엔지니어는 일반적으로 회사를 위해 돈을 벌기 위해 코드를 수정하지 않습니다. 문제를 식별하고 성능 문제에 대한 인식을 높이는 데 있어 시스템 엔지니어의 책임이 얼마나 중요한지 이해하는 수석 개발자가 필요합니다.

이건 데브옵스야

데브옵스 사고방식은 개발(dev) 사고와 운영(ops) 사고 사이의 시너지 효과를 설명합니다. "개발 작업 수행"을 주장하는 모든 회사는 다음을 수행해야 합니다.

1. 그들이 아마 하지 않을 말을 하는 것(The Princess Bride meme 참조 - "나는 그것이 당신이 생각하는 것을 의미한다고 생각하지 않습니다!")
2. 지속적인 제품 개선에 대한 태도를 장려합니다.

제품이 현재 어떻게 작동하는지 모른다면 제품을 개선할 수 없으며 제품이 개선되었음을 알 수도 없습니다. 구성 요소의 작동 방식, 제품이 의존하는 서비스, 주요 문제점 및 병목 현상을 이해하지 못하면 제품 작동 방식을 알 수 없습니다.
잠재적인 병목 현상을 감시하지 않으면 사후 분석을 작성할 때 Five Whys 기술을 따를 수 없습니다. 제품이 어떻게 작동하는지 확인하거나 "정상적이고 만족스러운" 모습을 확인하기 위해 모든 것을 한 화면에 표시할 수는 없습니다.

왼쪽으로 이동, 왼쪽으로 이동, I SAID LEEEE—

제가 보기에 Devops의 핵심 원칙 중 하나는 "왼쪽으로 이동"입니다. 이 맥락에서 왼쪽으로 이동하는 것은 가능성(책임 없음, 그러나 기능만) 성능 지표 생성, 로그를 보다 효율적으로 사용하는 등 시스템 엔지니어가 일반적으로 관심을 갖는 작업을 소프트웨어 제공 수명 주기의 왼쪽에서 수행합니다.

사진 작성자 제조사 별 NESA 에 Unsplash

소프트웨어 개발자는 모든 형태, 메트릭, 로깅, 모니터링 인터페이스 및 가장 중요한 모니터링을 수행하기 위해 회사에서 사용하는 모니터링 도구를 사용하고 알 수 있어야 합니다. 제품이 생산 과정에서 어떻게 작동하는지 살펴보세요. 개발자가 측정항목을 확인하고 모양, 제품 소유자가 다음 브리핑에서 CTO에게 이를 제시하는 방법 등에 영향을 미칠 수 있을 때까지 모니터링에 노력과 시간을 투자하도록 할 수는 없습니다.

곧

1. 말을 물가로 인도하세요. 개발자에게 스스로 피할 수 있는 문제의 양을 보여주고, 응용 프로그램에 대한 올바른 KPI와 지표를 식별하도록 도와 CTO에게 야유를 받는 제품 소유자의 야유를 줄이는 일이 없도록 하세요. 그들을 부드럽고 차분하게 빛 속으로 데려오십시오. 그래도 작동하지 않으면 그들이나 제품 소유자에게 뇌물을 주고 위협하고 회유하여 가능한 한 빨리 애플리케이션에서 이러한 측정 항목을 가져오도록 구현한 다음 다이어그램을 그립니다. 이는 우선순위로 간주되지 않고 제품 로드맵에 많은 수익 창출 프로젝트가 보류되어 있기 때문에 어려울 것입니다. 따라서 제품에 모니터링을 구현하는 데 소요되는 시간과 비용을 정당화하려면 비즈니스 사례가 필요합니다.
2. 시스템 엔지니어가 숙면을 취할 수 있도록 도와주세요. 출시되는 모든 제품에 대해 "출시하자" 체크리스트를 사용하는 것이 좋은 것임을 보여주세요. 그리고 프로덕션 중인 모든 애플리케이션에 메트릭이 포함되어 있는지 확인하면 개발자가 무엇이 잘못되었는지, 어디서 잘못되었는지 확인할 수 있어 밤에 잠을 더 잘 잘 수 있도록 도와줄 것입니다. 그러나 개발자, 제품 소유자 또는 CTO를 짜증나게 하고 좌절시키는 올바른 방법은 지속하고 저항하는 것입니다. 이 동작은 다시 마지막 순간까지 기다리면 모든 제품의 출시 날짜에 영향을 미치므로 다시 왼쪽으로 이동하여 이러한 문제를 가능한 한 빨리 프로젝트 계획에 포함시키십시오. 필요한 경우 제품 회의에 참여하세요. 가짜 콧수염과 펠트 등을 착용하면 절대로 실패하지 않습니다. 귀하의 우려 사항을 전달하고, 명확한 이점을 보여주고, 복음을 전하십시오.
3. 개발(dev)과 운영(ops) 모두 제품 지표가 위험 영역으로 이동하는 의미와 결과를 이해하는지 확인하십시오. Ops를 제품 상태의 유일한 보호자로 두지 말고 개발자도 참여하도록 하십시오(#productsquads).
4. 로그는 훌륭한 것이지만 측정항목도 마찬가지입니다. 그것들을 결합하고 로그가 쓸모없는 거대한 불타는 공 속에서 쓰레기가 되지 않도록 하십시오. 왜 아무도 자신의 로그를 이해하지 못하는지 개발자에게 설명하고 보여주고, 새벽 3시 15분에 쓸모없는 로그를 보는 것이 어떤 것인지 보여줍니다.

사진 작성자 마르코 호르바트 에 Unsplash

그게 다야. 다음주에 새로운 자료가 공개될 예정입니다. 본 과정에 대해 더 자세히 알고 싶으시면 다음으로 초대합니다. 오픈 데이, 월요일에 진행됩니다. 이제 우리는 전통적으로 귀하의 의견을 기다리고 있습니다.

출처 : habr.com