은행에 AIOps와 엄브렐라 모니터링이 필요한 이유는 무엇이며, 고객 관계는 무엇에 기반하여 구축됩니까?

Habr의 출판물에서 저는 이미 팀과의 파트너십 구축 경험에 대해 글을 썼습니다.여기에 (새로운 사업을 시작할 때 사업이 무너지지 않도록 파트너십 계약을 작성하는 방법에 대해 설명합니다.) 그리고 이제 고객과의 파트너십을 구축하는 방법에 대해 말씀드리고 싶습니다. 고객 없이는 무너질 것이 하나도 없기 때문입니다. 이 글이 대기업에 제품을 판매하기 시작하는 스타트업에 도움이 되기를 바랍니다.

저는 현재 MONQ Digital lab이라는 스타트업을 이끌고 있으며, 저와 제 팀은 기업 IT를 지원하고 운영하는 프로세스를 자동화하는 제품을 개발하고 있습니다. 시장에 진출하는 것은 쉬운 일이 아니기 때문에 우리는 먼저 약간의 사전 조사를 하고, 시장 전문가와 파트너를 살펴보고, 시장 세분화를 진행했습니다. 핵심 질문은 "누구의 고통을 가장 잘 치료할 수 있을까?"를 이해하는 것이었습니다.

은행은 TOP3 세그먼트에 진입했습니다. 물론 목록의 첫 번째는 팅코프와 스베르뱅크였습니다. 우리가 은행 시장 전문가를 방문했을 때, 그들은 이렇게 말했습니다. "거기에 당신의 상품을 소개하면 은행 시장으로 진출할 길이 열릴 것입니다." 우리는 두 곳 모두에 진출하려고 했지만 Sberbank는 실패했고 Tinkoff의 사람들은 러시아 스타트업과의 생산적인 소통에 훨씬 더 열려 있는 것으로 나타났습니다(아마도 당시 Sber가 샀다 (서구 경쟁사의 경우 거의 10억 달러에 가깝습니다). 한 달 안에 우리는 시범 프로젝트를 시작했습니다. 계속 읽어서 그 일이 어떻게 일어났는지 알아보세요.

저희는 수년간 운영 및 모니터링 문제를 다루어 왔으며, 현재 공공 부문, 보험, 은행, 통신 회사에 제품을 구현하고 있습니다. 한 가지 구현 사례는 항공사에 적용되었습니다(프로젝트 이전에는 항공업이 IT에 의존하는 산업이라고는 생각지도 못했습니다. 지금은 COVID에도 불구하고 이 회사가 성공하고 도약하기를 진심으로 바랍니다).

우리가 만드는 제품은 기업용 소프트웨어, AIOps 부문(IT 운영을 위한 인공 지능, 또는 ITOps)에 속합니다. 이러한 시스템을 구현하는 주요 목표는 회사 내 프로세스의 성숙도 수준을 높이는 것입니다.

1. 화재 진압: 실패를 파악하고, 쓰레기에서 경고 흐름을 제거하고, 책임자에게 작업과 사고를 할당합니다.
2. IT 서비스의 효율성을 높입니다. 사고 해결에 걸리는 시간을 줄이고, 장애 원인을 파악하고, IT 상태의 투명성을 높입니다.
3. 사업 효율성 증대: 수동 노동 감소, 위험 감소, 고객 충성도 증가

저희 경험에 따르면 은행은 모든 대형 IT 인프라와 공통적으로 다음과 같은 모니터링 "고민"을 겪습니다.

• "모두가 자기 일을 한다": 많은 기술 부서가 있고, 거의 모든 사람이 적어도 하나 이상의 자체 모니터링 시스템을 가지고 있으며, 대부분은 두 개 이상을 가지고 있다.
• "모기떼"와 같은 경보: 각 시스템은 수백 개의 경보를 생성하여 모든 책임 당사자에게 경보를 폭격합니다(때로는 부서 간에도 경보가 전달됩니다). 각 알림에 지속적으로 집중하는 것은 어렵고, 알림의 양이 너무 많아서 긴급성과 중요성이 무효화됩니다.
• 대형 은행이자 해당 부문의 선두주자인 이들은 시스템을 지속적으로 모니터링하여 오류가 있는 곳을 파악할 뿐만 아니라, 진정한 AI 마법을 통해 시스템을 자체 모니터링, 자체 예측 및 자체 수정하고자 합니다.

우리가 팅코프에서 첫 회의에 참석했을 때, 그들은 모니터링에 아무런 문제가 없으며 아무런 해도 없다고 즉시 말했고, 가장 중요한 질문은 "이미 잘하고 있는 사람들에게 우리가 무엇을 제공할 수 있을까?"였습니다.

대화는 길게 이어졌습니다. 마이크로서비스가 어떻게 구축되는지, 부서별 업무 방식, 어떤 인프라 문제가 더 민감한지, 사용자에게는 덜 민감한지, '맹점'은 어디인지, 목표와 SLA는 무엇인지 등에 대해 논의했습니다.

그런데 이 은행의 SLA는 정말 인상적이네요. 예를 들어, 네트워크 가용성과 관련된 우선순위 1 사고는 해결하는 데 몇 분밖에 주어지지 않습니다. 물론, 여기서 발생하는 오류와 가동 중지 비용은 상당합니다.

그 결과, 우리는 협력할 수 있는 몇 가지 분야를 파악했습니다.

1. 첫 번째 단계는 사고 해결 속도를 높이기 위한 엄브렐라 모니터링입니다.
2. 두 번째 단계는 IT 부서 확장에 따른 위험을 줄이고 비용을 절감하기 위한 프로세스 자동화입니다.

여러 모니터링 시스템에서 정보를 처리해야만 여러 개의 "흰 반점"을 밝은 경고 색상으로 칠할 수 있었습니다. 지표를 직접 측정하는 것은 불가능했고, 무슨 일이 일어나고 있는지에 대한 전반적인 그림을 이해하기 위해 다양한 모니터링 시스템의 데이터를 "한 화면"에 중앙 집중화해야 했습니다. 이 작업에는 "우산"이 적합했으며, 우리는 당시 이러한 요구 사항을 충족했습니다.

우리는 고객과의 관계에서 가장 중요한 것이 정직이라고 생각합니다. 라이선스 비용에 대한 첫 번째 대화와 계산 이후, 비용이 매우 낮으므로 바로 라이선스를 구매하는 것이 가치가 있을 것이라는 의견이 나왔습니다(위의 그린 뱅크에 대한 기사에서 언급한 Dynatrace Key-Astrom과 비교했을 때, 저희 라이선스 비용은 12억 루블이 아니라 1기가바이트당 한 달에 XNUMX루블입니다. Sber의 경우 비용이 몇 배나 적게 들 것입니다). 하지만 우리는 그들에게 우리가 무엇을 가지고 있고 무엇을 가지고 있지 않은지 즉시 말해주었습니다. 아마도 대형 통합업체의 영업 담당자라면 "물론 라이선스를 구매하면 모든 것을 할 수 있습니다"라고 말할 수 있었을 것입니다. 하지만 우리는 모든 것을 다 하기로 결정했습니다. 출시 당시, 저희 제품에는 Prometheus가 통합되어 있지 않았고, 자동화 하위 시스템이 포함된 새로운 버전이 출시되려고 했지만 아직 고객에게 배송하지 않았습니다.

시범 프로젝트가 시작되었고, 경계가 정의되었으며, 2개월의 시간이 주어졌습니다. 주요 목표는 다음과 같습니다.

• 플랫폼의 새로운 버전을 준비하고 은행 인프라에 배포합니다.
• 2개의 모니터링 시스템(Zabbix와 Prometheus)을 연결합니다.
• Slack과 SMS를 통해 담당자에게 알림을 보냅니다.
• 자동 복구 스크립트를 실행합니다.

시범 프로젝트의 첫 달은 시범 프로젝트의 요구에 맞춰 초고속 모드로 새로운 버전의 플랫폼을 준비하는 데 소요되었습니다. 새로운 버전에는 Prometheus와 자동 복구 기능이 즉시 통합되었습니다. 개발팀 덕분에 그들은 며칠 밤을 자지 않고도 이전에 약속한 다른 약속의 마감일을 놓치지 않고 약속한 것을 출시할 수 있었습니다.

파일럿 프로젝트를 설정하는 동안 프로젝트를 조기에 종료할 수도 있는 새로운 문제에 직면했습니다. 메신저와 SMS를 통해 알림을 보내려면 Microsoft Azure 서버로의 수신 및 발신 연결(당시에는 이 플랫폼을 사용하여 Slack으로 알림을 보냈습니다)과 외부 SMS 전송 서비스가 필요했습니다. 하지만 이 프로젝트에서는 안전에 특별히 중점을 두었습니다. 은행의 정책에 따라 이러한 "구멍"은 어떠한 경우에도 열 수 없습니다. 모든 것이 폐쇄 루프에서 작동해야 했습니다. Slack과 SMS로 알림을 보내는 자체 내부 서비스의 API를 사용하라는 제안이 있었지만, 그러한 서비스를 바로 연결할 기회가 없었습니다.

개발팀과의 토론을 통해 성공적인 해결책을 찾았다. 백로그를 파헤친 후, 우리는 시간도 우선순위도 없었던 하나의 작업을 발견했습니다. 구현 팀이나 클라이언트가 직접 애드온을 작성하여 플랫폼의 기능을 확장할 수 있는 플러그인 시스템을 만드는 것이었습니다.

하지만 자동화를 설치, 구성, 배포할 때까지 딱 한 달이 남았습니다.

우리의 수석 아키텍트인 세르게이에 따르면, 플러그인 시스템을 구현하는 데 최소한 한 달은 걸릴 것이라고 합니다.

시간이 없었어요...

해결책은 하나뿐이었습니다. 고객에게 가서 모든 사실을 그대로 말하는 것이었습니다. 연기에 대해 함께 논의해 보세요. 그리고 효과가 있었습니다. 우리에게는 2주가 더 주어졌습니다. 그들 역시 결과를 보여주기 위한 자체적인 마감일과 내부적 의무가 있었지만, 여유 시간이 2주나 있었습니다. 결국, 우리는 모든 것을 걸었습니다. 바보처럼 보일 방법은 없었습니다. 정직과 협력적 접근 방식이 다시 한번 성과를 거두었습니다.

시범 실험의 결과로 몇 가지 중요한 기술적 결과와 결론이 얻어졌습니다.

우리는 알림 처리의 새로운 기능을 테스트했습니다.

배포된 시스템은 Prometheus로부터 알림을 올바르게 수신하고 이를 그룹화하기 시작했습니다. Prometheus 클라이언트에서 문제에 대한 알림이 30초마다 전송되었고(시간 그룹화가 활성화되지 않음), 이를 "엄브렐라" 자체에서 그룹화하는 것이 가능할지 궁금했습니다. 이는 가능한 것으로 밝혀졌습니다. 플랫폼에서 알림 처리 구성은 스크립트를 통해 구현됩니다. 이를 통해 거의 모든 처리 논리를 구현하는 것이 가능해졌습니다. 우리는 이미 플랫폼에 템플릿 형태로 표준 로직을 구현했습니다. 직접 만들고 싶지 않다면 기성품을 사용하면 됩니다.

합성 트리거 인터페이스. 연결된 모니터링 시스템의 알림 처리 설정

시스템의 "건강" 상태를 구축했습니다.

알림은 구성 단위(CU)의 상태에 영향을 미치는 모니터링 이벤트를 생성하는 데 사용되었습니다. 우리는 내부 CMDB를 사용하거나 외부 CMDB에 연결할 수 있는 리소스 서비스 모델(RSM)을 구현하고 있습니다. 시범 프로젝트에서는 클라이언트가 CMDB를 연결하지 않았습니다.

리소스 서비스 모델을 사용하기 위한 인터페이스입니다. 파일럿 RSM.

사실, 클라이언트는 마침내 다양한 ​​시스템의 이벤트를 볼 수 있는 단일 모니터링 화면을 갖게 되었습니다. 현재 "엄브렐라"에는 Zabbix와 Prometheus라는 두 시스템과 플랫폼 자체의 내부 모니터링 시스템이 연결되어 있습니다.

분석 인터페이스. 단일 모니터링 화면.

프로세스 자동화 시작

이벤트 모니터링을 통해 사전 구성된 작업(알림 전송, 스크립트 실행, 인시던트 등록/보완)이 실행되었습니다. 후자는 이 특정 클라이언트에서는 시도되지 않았습니다. 그 이유는... 파일럿 프로젝트에는 서비스 데스크와의 통합이 포함되지 않았기 때문입니다.

동작 설정 인터페이스. Slack에 알림을 보내고 서버를 재부팅합니다.

제품의 기능을 확장했습니다

자동화 스크립트에 대해 논의할 때, 고객은 bаsh 지원과 이러한 스크립트를 편리하게 구성할 수 있는 인터페이스를 요청했습니다. 새로운 버전은 좀 더 많은 기능을 추가했습니다(cURL, SSH, SNMP를 지원하여 Lua로 본격적인 논리 구조를 작성하는 기능). 또한 스크립트 수명 주기를 관리할 수 있는 기능(생성, 편집, 버전 관리, 삭제, 보관)도 구현했습니다.

자동 복구 스크립트 작업을 위한 인터페이스입니다. SSH를 통해 서버를 재부팅하는 스크립트.

주요 결과

시범 운영 기간 동안 현재 기능을 개선하고 클라이언트의 가치를 높이는 사용자 스토리도 만들어졌습니다. 다음은 그중 일부입니다.

• 경고에서 자동 복구 스크립트로 직접 변수를 전달하는 기능을 구현합니다.
• Active Directory를 통해 플랫폼에 권한을 추가합니다.

그리고 우리는 다른 기능을 통해 제품을 "성장"시키기 위해 더 많은 글로벌 과제를 받았습니다.

• 규칙과 에이전트가 아닌 ML을 기반으로 리소스 서비스 모델을 자동으로 구축하는 것(아마도 지금의 주요 과제)
• 추가 스크립팅 및 논리 언어(JavaScript)에 대한 지원.

내 의견으로는 가장 중요한 것이 파일럿은 두 가지 사실을 보여줍니다.

1. 효과적인 의사소통이 정직과 개방성을 기반으로 구축되고, 고객이 짧은 시간 안에 의미 있는 성과를 이루는 팀의 일원이 될 때, 고객과의 파트너십은 효율성의 핵심입니다.
2. 어떠한 경우에도 "맞춤형"으로 만들거나 "치트"를 만들어서는 안 됩니다. 시스템적인 솔루션만 사용해야 합니다. 조금 더 시간을 투자하여 다른 클라이언트가 사용할 수 있는 체계적인 솔루션을 만드는 것이 좋습니다. 그런데 실제로 그런 일이 일어났습니다. 플러그인 시스템과 Azure에 대한 의존 거부는 다른 클라이언트에게 추가적인 가치를 제공했습니다(연방법 152호 참조).

출처 : habr.com