Highload IT 시스템 운영 및 지원 과정의 XNUMX가지 문제점

안녕, 하브르! 저는 1000년 동안 Highload IT 시스템을 지원해 왔습니다. XNUMX+ RPS 모드에서 작동하도록 nginx를 설정하는 문제나 기타 기술적인 문제에 대해서는 이 기사에서 쓰지 않겠습니다. 나는 그러한 시스템의 지원과 운영에서 발생하는 프로세스의 문제에 대해 내가 관찰한 내용을 공유할 것입니다.

모니터링

기술 지원은 "왜... 사이트가 다시 작동하지 않나요?"라는 내용의 요청이 도착할 때까지 기다리지 않습니다. 사이트가 충돌한 후 XNUMX분 이내에 지원팀이 이미 문제를 확인하고 해결하기 시작합니다. 하지만 사이트는 빙산의 일각. 가용성은 가장 먼저 모니터링되는 것 중 하나입니다.

온라인 상점의 남은 상품이 더 이상 ERP 시스템에서 도착하지 않는 상황은 어떻게 해야 합니까? 아니면 고객 할인을 계산하는 CRM 시스템이 응답을 멈췄나요? 사이트가 작동하는 것 같습니다. 조건부 Zabbix는 200 응답을 받습니다. 근무조는 모니터링으로부터 어떠한 통보도 받지 못한 채 왕좌의 게임 새 시즌의 첫 번째 에피소드를 즐겁게 시청하고 있습니다.

모니터링은 메모리, RAM 및 서버 프로세서 로드 상태만 측정하는 것으로 제한되는 경우가 많습니다. 그러나 비즈니스를 위해서는 웹사이트에서 제품 가용성을 확인하는 것이 훨씬 더 중요합니다. 클러스터의 한 가상 머신에 조건부 오류가 발생하면 해당 가상 머신으로의 트래픽 이동이 중단되고 다른 서버의 로드가 증가하게 됩니다. 회사는 돈을 잃지 않을 것입니다.

따라서 서버 운영 체제의 기술 매개변수를 모니터링하는 것 외에도 비즈니스 지표를 구성해야 합니다. 돈에 직접적인 영향을 미치는 지표. 외부 시스템(CRM, ERP 등)과의 다양한 상호 작용. 일정 기간 동안의 주문 수입니다. 성공 또는 실패 클라이언트 인증 및 기타 측정항목.

외부 시스템과의 상호 작용

연간 매출액이 XNUMX억 루블이 넘는 모든 웹사이트나 모바일 애플리케이션은 외부 시스템과 상호 작용합니다. 위에서 언급한 CRM 및 ERP에서 시작하여 구매 분석을 위해 판매 데이터를 외부 빅 데이터 시스템으로 전송하고 고객에게 확실히 구매할 제품을 제공하는 것(실제로는 구매하지 않음)으로 끝납니다. 이러한 각 시스템에는 자체 지원이 있습니다. 그리고 종종 이러한 시스템과의 통신은 고통을 야기합니다. 특히 문제가 전역적이어서 다른 시스템에서 분석해야 하는 경우에는 더욱 그렇습니다.

일부 시스템은 관리자에게 전화번호나 전보를 제공합니다. 관리자에게 편지를 쓰거나 외부 시스템의 버그 추적기로 이동해야 하는 곳이 있습니다. 하나의 대기업 내에서도 서로 다른 시스템이 서로 다른 애플리케이션 회계 시스템에서 작동하는 경우가 많습니다. 때로는 신청 상태를 추적하는 것이 불가능해지는 경우도 있습니다. 하나의 조건부 Jira로 요청을 받습니다. 그런 다음 이 첫 번째 Jira의 댓글에 다른 Jira의 문제에 대한 링크를 넣었습니다. 애플리케이션의 두 번째 Jira에서는 누군가 이미 다음과 같은 댓글을 작성하고 있습니다. 문제를 해결하려면 조건부 관리자 Andrey에게 전화해야 합니다. 등등.

이 문제에 대한 가장 좋은 해결책은 Slack과 같이 커뮤니케이션을 위한 단일 공간을 만드는 것입니다. 외부 시스템을 운영하는 과정에 참여하는 모든 참여자를 초대합니다. 또한 응용 프로그램을 중복하지 않도록 단일 추적기도 있습니다. 모니터링 알림부터 향후 버그 솔루션 출력까지 애플리케이션을 한 곳에서 추적해야 합니다. 당신은 이것이 비현실적이며 역사적으로 우리가 하나의 추적기에서 일하고 다른 추적기에서 일하는 일이 일어났다고 말할 것입니다. 다양한 시스템이 등장했고 자체 자율 IT 팀이 있었습니다. 동의합니다. 따라서 문제는 CIO 또는 제품 소유자 수준에서 위에서부터 해결되어야 합니다.

상호작용하는 모든 시스템은 우선순위에 따라 문제를 해결하기 위해 명확한 SLA를 갖춘 서비스형 지원을 제공해야 합니다. 조건부 관리자 Andrey가 잠시 시간을 내줄 때는 아닙니다.

병목 현상 남자

프로젝트(또는 제품)에 참여하는 모든 사람에게 휴가로 인해 상사 사이에 경련을 일으키는 사람이 있습니까? 이는 DevOps 엔지니어, 분석가 또는 개발자일 수 있습니다. 결국 데브옵스 엔지니어만이 어떤 서버에 어떤 컨테이너가 설치되어 있는지, 문제 발생 시 컨테이너를 재부팅하는 방법을 알고 있으며 일반적으로 그 없이는 복잡한 문제를 해결할 수 없습니다. 분석가는 복잡한 메커니즘이 어떻게 작동하는지 아는 유일한 사람입니다. 어떤 데이터 스트림이 어디로 가는지. 어떤 서비스에 대한 요청의 어떤 매개변수에 따라 어떤 서비스에 대한 응답을 받게 될까요?
로그에 오류가 있는 이유를 빨리 이해하고 제품의 심각한 버그를 즉시 수정하는 사람은 누구입니까? 물론 같은 개발자입니다. 다른 것들도 있지만 어떤 이유로 그는 시스템의 다양한 모듈이 어떻게 작동하는지 이해합니다.

이 문제의 근본 원인은 문서의 부족입니다.. 결국, 시스템의 모든 서비스가 설명되었다면 분석가 없이도 문제를 처리하는 것이 가능할 것입니다. 데브옵스가 바쁜 일정 속에서도 며칠의 시간을 내어 일반적인 문제를 해결하기 위한 모든 서버, 서비스 및 지침을 설명했다면, 데브옵스가 없을 때의 문제는 데브옵스 없이도 해결될 수 있었습니다. 휴가 중에 해변에서 맥주를 ​​빨리 마시고 문제 해결을 위해 Wi-Fi를 찾을 필요가 없습니다.

지원 직원의 역량과 책임

대규모 프로젝트에서 기업은 개발자 급여를 인색하지 않습니다. 그들은 유사한 프로젝트에서 값비싼 중간 또는 선배를 찾고 있습니다. 지원을 받으면 상황이 조금 다릅니다. 그들은 가능한 모든 방법으로 이러한 비용을 줄이려고 노력하고 있습니다. 기업들은 어제의 에니키 노동자들을 값싸게 고용하고 과감하게 전투에 나선다. 이 전략은 Zelenograd에 있는 공장의 명함 웹사이트에 대해 이야기하는 경우 가능합니다.

대규모 온라인 상점에 대해 이야기하고 있다면 가동 중지 시간의 매 시간 비용은 Enikey 관리자의 월급보다 더 높습니다. 연간 매출액 1억 루블을 출발점으로 삼아 보겠습니다. 이는 등급에 따른 모든 온라인 상점의 최소 매출액입니다. 100년 TOP 2018. 이 금액을 연간 시간 수로 나누면 100 루블 이상의 순 손실을 얻을 수 있습니다. 야간 시간을 계산하지 않으면 안전하게 금액을 두 배로 늘릴 수 있습니다.

하지만 중요한 것은 돈이 아니죠? (아니요, 물론 중요한 것은) 평판 손실도 있습니다. 잘 알려진 온라인 상점의 몰락으로 인해 소셜 네트워크에 대한 리뷰가 급증하고 주제별 미디어에 출판물이 게재될 수 있습니다. 그리고 주방에서 친구들이 "거기서 아무것도 사지 마세요. 그 사이트는 항상 다운되어 있어요"라는 스타일로 나누는 대화는 전혀 측정할 수 없습니다.

이제 책임을 맡습니다. 실제로는 모니터링 시스템에서 사이트를 사용할 수 없다는 알림을 당직 관리자가 제때에 응답하지 않는 경우가있었습니다. 기분 좋은 여름날의 금요일 저녁, 모스크바의 한 유명 온라인 상점 웹사이트가 조용히 누워 있었습니다. 토요일 아침, 이 사이트의 제품 관리자는 사이트가 왜 열리지 않는지 이해하지 못했고 Slack의 지원 및 긴급 알림 채팅에도 침묵이 있었습니다. 그러한 실수로 인해 우리는 여섯 자릿수 금액의 손실을 입었고 이 담당관은 그의 직업이었습니다.

책임감은 개발하기 어려운 기술입니다. 사람이 그것을 가지고 있든 없든. 그래서 인터뷰를 할 때 그 사람이 책임을 지는 데 익숙해졌는지 간접적으로 보여주는 다양한 질문으로 그 존재감을 확인하려고 노력한다. 만약 어떤 사람이 부모가 시켜서 대학을 선택했다고 대답하거나, 아내가 돈을 많이 벌지 못한다고 해서 이직했다고 대답한다면 그런 사람들과는 관계를 맺지 않는 것이 좋습니다.

개발팀과의 상호작용

사용자가 제품을 작동하는 동안 간단한 문제가 발생하면 지원팀에서 스스로 문제를 해결합니다. 문제 재현을 시도하고 로그를 분석하는 등의 작업을 수행합니다. 그런데 제품에 버그가 나타나면 어떻게 해야 할까요? 이 경우 지원팀에서는 개발자에게 작업을 할당하고 여기서부터 재미가 시작됩니다.

개발자는 지속적으로 과부하 상태입니다. 그들은 새로운 기능을 만들고 있습니다. 판매 관련 버그를 수정하는 것은 가장 흥미로운 활동이 아닙니다. 다음 스프린트를 완료하기 위한 마감일이 다가오고 있습니다. 그리고 지원팀의 불쾌한 사람들이 와서 "모든 것을 즉시 종료하세요. 문제가 있습니다. "라고 말합니다. 이러한 작업의 우선 순위는 최소화됩니다. 특히 문제가 가장 심각하지 않고 사이트의 주요 기능이 작동하는 경우, 릴리스 관리자가 눈을 부릅뜨고 뛰어다니지 않고 "이 작업을 다음 릴리스나 핫픽스에 긴급하게 추가하세요."라고 적는 경우에는 더욱 그렇습니다.

우선순위가 보통이거나 낮은 문제는 릴리스에서 릴리스로 이동됩니다. “작업은 언제 완료됩니까?”라는 질문에 "죄송합니다. 지금은 할 일이 많습니다. 팀 리더나 릴리스 관리자에게 문의하세요."라는 스타일로 답변을 받게 됩니다.

새로운 기능을 만드는 것보다 생산성 문제가 더 중요합니다. 사용자가 지속적으로 버그를 발견하면 나쁜 리뷰는 오래 가지 않을 것입니다. 손상된 평판은 회복하기 어렵습니다.

개발과 지원 간의 상호 작용 문제는 DevOps에 의해 해결됩니다. 이 약어는 개발을 위한 테스트 환경을 만드는 데 도움을 주고 CICD 파이프라인을 구축하며 테스트된 코드를 신속하게 프로덕션에 가져오는 특정 사람의 형태로 자주 사용됩니다. DevOps는 프로세스의 모든 참가자가 서로 긴밀하게 상호 작용하고 소프트웨어 제품 및 서비스를 신속하게 생성하고 업데이트하는 데 도움이 되는 소프트웨어 개발에 대한 접근 방식입니다. 분석가, 개발자, 테스터 및 지원을 의미합니다.

이 접근 방식에서 지원과 개발은 각자의 목표와 목표를 가진 서로 다른 부서가 아닙니다. 개발은 운영에 포함되며 그 반대도 마찬가지입니다. 분산된 팀의 유명한 문구: "문제는 내 편이 아닙니다."는 더 이상 채팅에 자주 나타나지 않으며 최종 사용자는 조금 더 행복해집니다.

출처 : habr.com