인프라의 레거시 서비스

안녕하세요! 제 이름은 Pasha Chernyak이고 QIWI의 선도적인 개발자입니다. 오늘은 피할 수 없는 일에 대해 이야기하고 싶습니다. 레거시에 대해.

질문부터 시작해 보겠습니다. 레거시 서비스란 무엇입니까? 레거시 서비스는 개발자가 일주일/월/년 동안 손대지 않은 서비스인가요? 아니면 경험이 부족한 프로그래머, 예를 들어 귀하가 XNUMX년 전에 작성한 서비스입니까? 이제 당신은 더 멋지고 경험도 많아졌습니다. 아니면 레거시 서비스가 다시는 커밋하지 않기로 결정하고 천천히 대체 서비스를 준비하고 있는 서비스인가요? 어쨌든 이런 서비스를 방치하고 업데이트하지 않는 것은 나중에 터질 수 있는 시한폭탄이다.

QIWI가 레거시 서비스를 어떻게 사용하는지 살펴보기 전에 월렛 서비스에 질서를 부여한 방법을 알려드리겠습니다. 이제 11년 동안 나는 그 성과를 책임져 왔습니다. 문제가 있으면 항상 나한테 먼저 전화를 해준다. 저는 보통 오후 XNUMX시에 다른 사람에게 전화할 용기가 없어서 앉아서 우리 도메인의 모든 서비스를 알아내야 했습니다.

하지만 나도 누구처럼 밤에 자는 걸 좋아해서 착취에 대처하려고 노력했다. “얘들아, 왜 나한테 전화하는 거야?” 이에 대해 나는 “또 누구요?”와 같은 매우 간결한 대답을 받았습니다. 내가 서비스를 수리하는데 직원들이 누구에게 전화해야 할지 모르기 때문입니다.

따라서 Wallet 백엔드 팀의 회고 중 하나에서 우리는 서비스, 마이크로서비스 및 지갑 모놀리스 목록과 이를 담당하는 사람들의 목록을 서명해야 한다고 결정했습니다. 징후는 합리적인 한도 내에서 일반적으로 유용합니다.

누가 무엇을 책임지고 있는지에 대한 정보 외에도 서비스 소유자는 누구인지, 서비스 개발, 아키텍처 및 라이프사이클을 담당하는 사람은 누구인지에 대한 답변이 있습니다. 이 서비스를 담당하는 사람은 문제가 발생하면 이를 해결할 수 있는 사람입니다. 서비스 소유자는 커밋에 +2를 남길 권리가 있으며, 이 서비스가 새로운 커밋을 수락하기 전에 책임자도 검토에 참석해야 합니다.

시간이 지남에 따라 Kubernetes로의 마이그레이션, 모든 종류의 체크 스타일, 스팟 버그, ktlint, Kibana의 로그 존재, 주소 및 기타 유용한 항목을 직접 지정하는 대신 자동 검색 서비스와 같은 새로운 관행이 적용되기 시작했습니다. 그리고 우리 테이블을 통해 모든 곳에서 서비스의 관련성을 유지할 수 있었습니다. 우리에게 이는 이 서비스가 이를 수행할 수 있지만 아직은 수행하지 않는다는 일종의 체크리스트입니다. 그러나 우리는 서비스 소스가 어디에 있는지 모니터링하는 서비스에 대한 정보가 부족하다는 것을 깨닫고 계속 진행했습니다. TeamCity에서 조립 작업이 시작되는 위치, 배포 방법, end2end 테스트 소스가 저장되는 위치, 아키텍처에 대한 정리 세션의 사진, 내린 결정에 대한 사진입니다. 이상적으로는 이 모든 정보가 어딘가에 놓여 필요할 때 바로 사용할 수 있기를 바랍니다. 그리하여 우리의 간판은 정보탐색의 출발점이 되었습니다.

하지만 QIWI는 스타트업 정신을 그대로 유지하면서도 대기업입니다. 우리는 이미 12살이 되었고 팀은 변화하고 있습니다. 사람들은 떠나고, 사람들은 오고, 새로운 팀이 형성됩니다. 그리고 우리는 상속받은 도메인에서 여러 서비스를 발견했습니다. 일부는 다른 팀의 개발자에게서 왔고, 일부는 단순히 월렛과 간접적으로 관련되어 있었기 때문에 이제 대차대조표에 서비스가 포함되었습니다. 무엇이 어떻게 작동하는지 이해 - 왜? 서비스는 작동하며 확실히 개선해야 할 제품 기능이 있습니다.

어떻게 일어나는가

그러나 어느 시점에서 우리는 서비스가 기능 수행을 중단하고 무언가가 손상되었음을 발견합니다. 이러한 상황에서는 어떻게 해야 합니까? 서비스가 단순히 작동을 멈췄습니다. 조금도. 그리고 우리는 이것에 대해 첫째로 우연히 알게 되었고 둘째로 XNUMX개월 후에 알게 되었습니다. 그런 일이 일어난다. 우리가 아는 유일한 것은 서비스가 배포될 가상 머신, 해당 소스가 어디에 있는지, 그게 전부였습니다. 우리는 git clone을 하고 몇 년 전에 이 글을 쓴 사람의 마음 속으로 들어가지만, 우리는 무엇을 보게 될까요? 우리에게 친숙한 Spring Boot는 없습니다. 비록 우리가 모든 것에 익숙하더라도 우리는 전체 스택과 그 모든 것을 가지고 있습니다. 어쩌면 거기에 Spring Framework가 있을까요? 하지만.

이 모든 것을 쓴 사람은 힘든 사람이었고 모든 것을 순수 Java로 썼습니다. 개발자를 위한 일반적인 도구가 없으며 아이디어가 떠오릅니다. 이 모든 것을 다시 작성해야 합니다. 우리는 마이크로서비스를 가지고 있으며 모든 토스터에서 "얘들아, 마이크로서비스가 바로 당신에게 필요한 거야!"라는 말이 나옵니다. 갑자기 문제가 발생하면 침착하게 어떤 언어를 사용하든 모든 것이 잘 될 것입니다.

문제는 이제 이 서비스를 담당하는 고객이 없다는 것입니다. 그에게는 어떤 비즈니스 요구 사항이 있었고, 이 서비스는 어떤 역할을 해야 합니까? 그리고 이 서비스는 비즈니스 프로세스에 긴밀하게 통합됩니다.

이제 비즈니스 요구 사항을 알지 못한 채 서비스를 다시 작성하는 것이 얼마나 쉬운가요? 서비스가 어떻게 기록되는지 명확하지 않으며 측정항목이 있는지 여부도 알 수 없습니다. 그것이 무엇인지는 더욱 알 수 없습니다. 동시에 서비스에는 이해할 수 없는 비즈니스 논리 클래스가 엄청나게 많이 포함되어 있습니다. 어떤 종류의 데이터베이스에는 우리가 아직 아무것도 모르는 것이 포함되어 있습니다.

어디서부터 시작해야할까요?

가장 논리적인 관점에서 보면 테스트의 가용성입니다. 일반적으로 거기에는 최소한 몇 가지 논리가 작성되어 있으며 무슨 일이 일어나고 있는지 결론을 내릴 수 있습니다. 이제 TDD는 유행이지만 5년 전에는 모든 것이 지금과 거의 같았습니다. 단위 테스트도 거의 없고 우리에게 아무 것도 알려주지 않습니다. 글쎄, 아마도 일종의 확인을 제외하고 일부 XML이 일부 사용자 정의 인증서로 서명되는 방법입니다.

우리는 코드에서 아무것도 이해할 수 없었기 때문에 가상 머신에 무엇이 있는지 확인하러갔습니다. 서비스 로그를 열어보니 http 클라이언트 오류가 발견되었으며, 애플리케이션 리소스에 내장된 자체 서명 인증서가 뻔뻔스럽게 썩었습니다. 우리는 분석가에게 연락하여 새 인증서를 요청하고 이를 발행했으며 서비스가 다시 작동하고 있습니다. 그게 전부인 것 같습니다. 아니면? 결국 서비스는 작동하고 비즈니스에 필요한 일부 기능을 수행합니다. 우리는 애플리케이션 개발을 위한 특정 표준을 갖고 있으며, 아마도 여러분도 마찬가지일 것입니다. 예를 들어 노드의 로그를 폴더에 저장하지 말고 Elastic 같은 일종의 저장소에 저장하고 Kibana에서 살펴보세요. 황금 지표를 기억할 수도 있습니다. 즉, 서비스 부하, 서비스 요청 수, 생존 여부, 상태 점검 진행 상황 등입니다. 최소한 이러한 지표는 명확한 양심을 가지고 언제 서비스를 중단하고 나쁜 꿈처럼 잊혀질 수 있는지를 아는 데 도움이 될 것입니다.

무엇을

따라서 우리는 이러한 오래된 서비스를 테이블에 추가한 다음 서비스를 관리하고 정리할 개발자 중에서 자원 봉사자를 찾습니다. 그들은 서비스에 대한 최소한의 정보를 작성하고 링크를 추가합니다. grafana의 대시보드, 어셈블리 작업에 이르기까지 애플리케이션 배포 방법을 이해하고 FTP를 사용하여 파일을 수동으로 업로드하지 마십시오.

가장 중요한 것은 이 모든 유용한 자원 봉사 활동이 얼마나 오래 걸릴 것인가입니다. 예를 들어 기술 부채가 20%인 동안 경험이 어느 정도 있는 개발자를 위한 스프린트 XNUMX회. 특정 국가 시스템과의 의사소통에 내재된 논리를 모두 이해하고 이를 새로운 기술로 가져오는 데 얼마나 시간이 걸렸나요? 나는 이것을 보증할 수 없습니다. 아마도 한 달 또는 두 달 정도 팀 작업이 필요할 것입니다. 나는 현재 새로운 서비스와의 통합 경험을 통해 이렇게 말합니다.

동시에 비즈니스 가치의 공개는 없습니다. 조금도. 지원을 위해 서비스를 고용하고 이에 약간의 시간을 투자하는 것은 정상입니다. 그러나 표준 서비스와 함께 춤을 추고 나면 이를 테이블에 추가하고 이에 대한 정보를 추가했으며 아마도 언젠가 다시 작성할 것입니다. 하지만 이제는 우리의 서비스 표준을 충족합니다.

이에 레거시 서비스를 어떻게 할 것인지에 대한 계획을 세워보고자 합니다.

레거시를 처음부터 다시 작성하는 것은 나쁜 생각입니다.
진지하게, 그것에 대해 생각할 필요조차 없습니다. 내가 그것을 좋아한다는 것은 분명하고 몇 가지 장점이 있지만 일반적으로 자신을 포함하여 누구도 필요하지 않습니다.

핸드북
애플리케이션의 소스 코드를 찾아내고, 무엇이 어디에 있고 어떻게 작동하는지 알려주는 참조서를 만들고, 거기에 프로젝트에 대한 설명(조건부 readme.md)을 입력하여 로그와 메트릭이 있는 위치를 빠르게 이해하세요. 이 문제를 처리해 줄 개발자는 감사 인사만 전할 것입니다.

도메인 이해
도메인을 소유하고 있다면 최신 정보를 계속 확인하세요. 사소하게 들리겠지만 모든 사람이 서비스가 단일 키에 있는지 확인하는 것은 아닙니다. 그러나 하나의 표준으로 작업하는 것이 실제로 훨씬 쉽습니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

당신은 당신의 유산으로 무엇을 합니까?

• 31.5%처음부터 다시 쓰는 중인데 더 정확해요 12

• 52.6%너랑 거의 똑같아20

• 10.5%우리는 유산이 없습니다. 우리는 위대합니다4

• 5.2%댓글로 쓸게요2

38명의 사용자가 투표했습니다. 20명의 사용자가 기권했습니다.

출처 : habr.com