모든 것에 영향을 미친 출시 스토리

현실의 적 12f-2까지

XNUMX월 말, 화이트 워커가 윈터펠을 포위하고 있는 동안 우리에게 더 흥미로운 일이 일어났습니다. 원칙적으로 우리는 다른 모든 사람들과 마찬가지로 지속적으로 새로운 기능을 프로덕션에 출시하고 있습니다. 하지만 이번은 달랐다. 그 규모는 우리가 저지를 수 있는 잠재적인 실수가 우리의 모든 서비스와 사용자에게 영향을 미칠 정도였습니다. 그 결과, 우리는 판매에 아무런 영향을 주지 않고 계획되고 발표된 가동 중지 기간 내에 계획에 따라 모든 것을 출시했습니다. 이 기사는 우리가 이것을 어떻게 달성했는지, 그리고 누구나 집에서 그것을 반복할 수 있는 방법에 관한 것입니다.

이제 우리가 내린 아키텍처 및 기술 결정을 설명하거나 모든 것이 어떻게 작동하는지 설명하지 않겠습니다. 이것은 가장 어려운 출시 중 하나가 어떻게 발생했는지에 대한 여백의 메모입니다. 제가 관찰하고 직접 참여했습니다. 나는 완전성이나 기술적 세부 사항을 주장하지 않으며 아마도 다른 기사에 나타날 것입니다.

배경 + 어떤 기능인가요?

클라우드 플랫폼을 구축하고 있습니다 Mail.ru 클라우드 솔루션 (MCS)에서 저는 기술 디렉터로 일하고 있습니다. 이제 모든 사용자 계정, 사용자, 비밀번호, 역할, 서비스 등에 대한 통합 관리를 제공하는 IAM(ID 및 액세스 관리)을 플랫폼에 추가할 차례입니다. 클라우드에 이것이 필요한 이유는 분명한 질문입니다. 모든 사용자 정보가 클라우드에 저장됩니다.

일반적으로 이러한 것들은 프로젝트 시작 초기에 구축되기 시작합니다. 그러나 역사적으로 MCS에서는 상황이 약간 달랐습니다. MCS는 두 부분으로 구성되었습니다.

• 자체 Keystone 인증 모듈을 갖춘 OpenStack,
• Mail.ru Cloud 프로젝트를 기반으로 하는 Hotbox(S3 스토리지),

새로운 서비스가 등장했습니다.

본질적으로 이는 두 가지 다른 유형의 승인이었습니다. 또한 Horizon 패널에 SSO(종단 간 인증)가 제공된 덕분에 일반 Mail.ru 비밀번호 저장소와 자체 작성 openid 커넥터와 같은 몇 가지 별도의 Mail.ru 개발을 사용했습니다. 가상 머신(네이티브 OpenStack UI).

우리를 위해 IAM을 만든다는 것은 모든 것을 완전히 우리 자신의 단일 시스템에 연결하는 것을 의미했습니다. 동시에 우리는 그 과정에서 어떠한 기능도 잃지 않을 것이며, 리팩토링 없이 투명하게 개선하고 기능 측면에서 확장할 수 있는 미래를 위한 기반을 마련할 것입니다. 또한 처음에는 사용자에게 서비스(중앙 RBAC, 역할 기반 액세스 제어) 및 기타 사소한 액세스에 대한 역할 모델이 있었습니다.

작업은 Python과 Perl, 여러 백엔드, 독립적으로 작성된 서비스, 여러 개발 팀 및 관리자 등 사소한 것이 아닌 것으로 나타났습니다. 그리고 가장 중요한 것은 전투 생산 시스템에 수천 명의 실제 사용자가 있다는 것입니다. 이 모든 것은 기록되어야 했고, 가장 중요한 것은 사상자 없이 출시되어야 했습니다.

우리는 무엇을 출시할 예정인가요?

대략적으로 말하자면, 약 4개월 동안 우리는 다음과 같은 것들을 준비했습니다.

• 우리는 이전에 인프라의 여러 부분에서 작동했던 기능을 집계하는 몇 가지 새로운 데몬을 만들었습니다. 나머지 서비스에는 이러한 악마의 형태로 새로운 백엔드가 규정되었습니다.
• 우리는 모든 서비스에 사용할 수 있고 필요에 따라 자유롭게 수정할 수 있는 비밀번호와 키의 중앙 저장소를 자체적으로 작성했습니다.
• 우리는 처음부터 Keystone을 위한 4개의 새로운 백엔드(사용자, 프로젝트, 역할, 역할 할당)를 작성했는데, 이는 실제로 데이터베이스를 대체했으며 이제 사용자 비밀번호를 위한 단일 저장소 역할을 합니다.
• 우리는 모든 Openstack 서비스에 각 서버에서 이러한 정책을 로컬로 읽는 대신 정책에 대해 타사 정책 서비스로 이동하도록 가르쳤습니다(예, 이것이 Openstack이 기본적으로 작동하는 방식입니다!)

이러한 대규모 재작업에는 서로 다른 개발 팀이 작성한 여러 시스템의 크고 복잡하며 가장 중요한 동시 변경이 필요합니다. 일단 조립되면 전체 시스템이 작동해야 합니다.

그러한 변경 사항을 적용하고 망치지 않는 방법은 무엇입니까? 먼저 우리는 미래를 조금 살펴보기로 결정했습니다.

출시 전략

• 여러 단계에 걸쳐 제품을 출시할 수도 있지만 이렇게 하면 개발 시간이 XNUMX배나 늘어납니다. 또한 한동안 데이터베이스의 데이터가 완전히 비동기화될 것입니다. 자신만의 동기화 도구를 작성하고 오랫동안 여러 데이터 저장소를 사용해야 합니다. 그리고 이는 다양한 위험을 야기합니다.
• 사용자를 위해 투명하게 준비할 수 있는 모든 것은 사전에 이루어졌습니다. 2개월이 걸렸습니다.
• 우리는 사용자 작업이 리소스를 생성하고 변경하는 경우에만 몇 시간 동안 가동 중지 시간을 허용했습니다.
• 이미 생성된 모든 리소스를 운영하려면 다운타임이 허용되지 않습니다. 우리는 롤아웃 중에 리소스가 다운타임 없이 작동하고 클라이언트에 영향을 미치도록 계획했습니다.
• 문제가 발생할 경우 고객에게 미치는 영향을 줄이기 위해 일요일 저녁에 출시하기로 결정했습니다. 밤에 가상 머신을 관리하는 고객은 거의 없습니다.
• 우리는 출시를 위해 선택한 기간 동안 서비스 관리가 불가능할 것임을 모든 고객에게 경고했습니다.

여담: 롤아웃이란 무엇입니까?

<주의, 철학>

모든 IT 전문가는 롤아웃이 무엇인지 쉽게 답할 수 있습니다. CI/CD를 설치하면 모든 것이 자동으로 매장에 전달됩니다. 🙂

물론 이것은 사실이다. 그러나 문제는 최신 코드 전달 자동화 도구를 사용하면 롤아웃 자체에 대한 이해가 상실된다는 것입니다. 현대 교통수단을 볼 때 바퀴 발명의 장엄함을 어떻게 잊습니까? 모든 것이 너무 자동화되어 전체 그림을 이해하지 못한 채 롤아웃이 수행되는 경우가 많습니다.

그리고 전체적인 그림은 이렇습니다. 롤아웃은 다음과 같은 네 가지 주요 측면으로 구성됩니다.

1. 데이터 수정을 포함한 코드 전달. 예를 들어 마이그레이션이 있습니다.
2. 코드 롤백은 문제가 발생한 경우 다시 돌아갈 수 있는 기능입니다. 예를 들어 백업 생성을 통해.
3. 각 롤아웃/롤백 작업의 시간입니다. 처음 두 지점의 작업 타이밍을 이해해야 합니다.
4. 영향을 받는 기능. 예상되는 긍정적인 효과와 가능한 부정적인 효과를 모두 평가할 필요가 있습니다.

성공적인 출시를 위해서는 이러한 모든 측면을 고려해야 합니다. 일반적으로 첫 번째 또는 기껏해야 두 번째 지점만 평가된 다음 롤아웃이 성공한 것으로 간주됩니다. 그러나 세 번째와 네 번째가 훨씬 더 중요합니다. 롤아웃이 3분이 아닌 XNUMX시간이 걸린다면 어떤 사용자가 좋아할까요? 아니면 출시 중에 불필요한 것이 영향을 받는 경우가 있나요? 아니면 한 서비스의 가동 중지 시간이 예측할 수 없는 결과를 초래할까요?

Act 1..n, 출시 준비

처음에 나는 우리의 회의를 간략하게 설명하려고 생각했습니다. 전체 팀, 팀의 일부, 커피 포인트에서의 수많은 토론, 논쟁, 테스트, 브레인스토밍. 그렇다면 불필요하다고 생각했습니다. XNUMX개월의 개발은 항상 이것으로 구성됩니다. 특히 지속적으로 제공할 수 있는 무언가를 작성하는 것이 아니라 라이브 시스템의 큰 기능 중 하나를 작성하는 경우 더욱 그렇습니다. 이는 모든 서비스에 영향을 미치지만 "웹 인터페이스의 버튼 하나"를 제외하고는 사용자에게 변경되는 사항이 없습니다.

새로운 회의를 할 때마다 롤아웃 방법에 대한 우리의 이해가 상당히 바뀌었습니다. 예를 들어 전체 청구 데이터베이스를 업데이트하려고 했습니다. 그러나 우리는 시간을 계산해 본 결과 합리적인 출시 시간 내에 이를 수행하는 것이 불가능하다는 것을 깨달았습니다. 청구 데이터베이스를 분할하고 보관하는 데 거의 일주일이 더 걸렸습니다. 그리고 예상되는 출시 속도가 여전히 만족스럽지 못했을 때 우리는 전체 베이스를 끌었던 더욱 강력한 하드웨어를 추가로 주문했습니다. 이 작업을 더 빨리 수행하고 싶지는 않았지만 현재 출시해야 하는 상황으로 인해 선택의 여지가 없었습니다.

우리 중 한 명이 롤아웃이 가상 머신의 가용성에 영향을 미칠 수 있다는 의심을 품었을 때 테스트, 실험, 코드 분석을 수행하는 데 일주일을 보냈고 이것이 우리 프로덕션에서는 일어나지 않을 것이라는 명확한 이해를 얻었으며 가장 의심스러운 사람들조차도 동의했습니다. 이것으로.

그 동안 기술 지원팀은 출시 후 변경될 예정인 연결 방법에 대한 지침을 고객에게 작성하기 위해 자체적으로 독립적인 실험을 수행했습니다. 사용자 UX 작업도 하고, 설명서도 준비하고, 개인 상담도 해주셨어요.

우리는 가능한 모든 롤아웃 작업을 자동화했습니다. 모든 작업은 가장 간단한 작업까지 스크립트로 작성되었으며 테스트는 지속적으로 실행되었습니다. 그들은 서비스를 끄는 가장 좋은 방법에 대해 논쟁했습니다. 즉, 데몬을 생략하거나 방화벽을 사용하여 서비스에 대한 액세스를 차단하는 것입니다. 우리는 각 출시 단계에 대한 팀 체크리스트를 작성하고 지속적으로 업데이트했습니다. 우리는 모든 출시 작업에 대해 시기와 함께 Gantt 차트를 그리고 지속적으로 업데이트했습니다.

그래서 ...

출시 전 마지막 행위

...이제 출시할 시간입니다.

사람들이 말했듯이, 예술 작품은 완성될 수 없으며 단지 작업을 마친 것뿐입니다. 당신은 모든 것을 찾을 수 없다는 것을 이해하고 모든 합리적인 가정을 하고, 가능한 모든 경우에 대해 제공하고, 모든 중요한 버그를 닫았으며, 모든 참가자가 할 수 있는 모든 것을 했다고 믿고 의지의 노력을 기울여야 합니다. 더 많은 코드를 출시할수록 이를 확신하기가 더 어려워집니다(게다가 모든 것을 예측하는 것이 불가능하다는 것을 모두가 이해합니다).

우리는 예상치 못한 영향 및 가동 중지 시간과 관련된 사용자의 모든 위험을 처리하기 위해 가능한 모든 조치를 취했다는 확신이 들었을 때 출시할 준비가 되었다고 결정했습니다. 즉, 다음을 제외한 모든 것이 잘못될 수 있습니다.

1. (우리에게 신성한, 가장 소중한) 사용자 인프라에 영향을 미치며,
2. 기능: 출시 후 서비스 이용은 출시 전과 동일해야 합니다.

출시

8롤, XNUMX은 방해하지 않아

우리는 사용자의 모든 요청에 ​​대해 7시간 동안 다운타임을 갖습니다. 현재로서는 롤아웃 계획과 롤백 계획이 모두 있습니다.

• 롤아웃 자체에는 약 3시간이 소요됩니다.
• 테스트하는데 2시간.
• 2시간 - 변경 사항을 롤백할 수 있도록 예약합니다.

각 작업, 소요 시간, 순차적으로 발생하는 작업, 병렬로 수행되는 작업에 대해 간트 차트가 작성되었습니다.

초기 버전 중 하나인 롤아웃 간트 차트(병렬 실행 없음)의 일부입니다. 가장 가치 있는 동기화 도구

모든 참가자는 롤아웃에서 자신의 역할, 수행하는 작업, 책임이 무엇인지 결정됩니다. 우리는 각 단계를 자동으로 진행하고, 출시하고, 롤백하고, 피드백을 수집하고, 다시 출시하려고 노력합니다.

사건의 연대기

그래서 15월 29일 일요일 밤 10시에 XNUMX명이 출근했습니다. 주요 참가자들 외에도 단순히 팀을 지원하기 위해 일부 사람들이 왔는데, 그들에게 특별한 감사를 드립니다.

주요 테스터가 휴가 중이라는 점도 언급할 가치가 있습니다. 테스트 없이 출시하는 것은 불가능하며 옵션을 탐색 중입니다. 한 동료가 휴가 중에 우리를 테스트하기로 동의했고 이에 대해 팀 전체로부터 엄청난 감사를 받았습니다.

00:00. 멈추다
우리는 사용자 요청을 중단하고 기술적 작업을 알리는 표시를 끊습니다. 모니터링이 비명을 지르지만 모든 것이 정상입니다. 넘어져야 할 것 외에 아무것도 떨어지지 않았는지 확인합니다. 그리고 마이그레이션 작업을 시작합니다.

모든 사람은 단계별로 인쇄된 출시 계획을 갖고 있으며, 누가 언제 무엇을 하고 있는지 모두가 알고 있습니다. 각 작업 후에는 타이밍을 확인하여 이를 초과하지 않도록 하고 모든 것이 계획대로 진행됩니다. 현 단계에서 직접 출시에 참여하지 않는 분들은 동료들에게 방해가 되지 않도록 온라인 장난감(Xonotic, 3종 돌팔이)을 출시하여 준비하고 있습니다. 🙂

02:00. 출시
놀랍게도 데이터베이스 및 마이그레이션 스크립트 최적화로 인해 롤아웃을 한 시간 일찍 완료했습니다. 일반적인 외침은 "롤아웃!" 모든 새로운 기능은 프로덕션 단계에 있지만 지금까지는 인터페이스에서만 볼 수 있습니다. 모두가 테스트 모드로 들어가 그룹별로 분류하고 결국 무슨 일이 일어났는지 확인하기 시작합니다.

별로 좋지 않은 결과가 나왔지만, 팀 구성원의 프로젝트에서 아무 것도 연결되지 않거나 작업 중이 아닌 10분 후에 이것을 깨달았습니다. 빠른 동기화를 통해 우리는 문제를 말하고, 우선순위를 설정하고, 팀을 구성하여 디버깅에 들어갑니다.

02:30. 두 가지 큰 문제와 네 개의 눈
우리는 두 가지 큰 문제를 발견했습니다. 우리는 고객이 연결된 일부 서비스를 볼 수 없으며 파트너 계정에 문제가 발생할 수 있다는 것을 깨달았습니다. 둘 다 일부 극단적인 경우에 대한 불완전한 마이그레이션 스크립트로 인해 발생합니다. 지금 당장 고쳐야 합니다.

우리는 최소한 4개의 눈으로 이를 기록하는 쿼리를 작성합니다. 우리는 사전 제작 중에 테스트하여 제대로 작동하는지, 어떤 문제도 발생하지 않는지 확인합니다. 계속할 수 있습니다. 동시에 정기적인 통합 테스트를 실행하여 몇 가지 문제를 더 드러냈습니다. 모두 작지만 수리가 필요합니다.

03:00. -2문제 +2문제
이전의 두 가지 큰 문제가 수정되었으며 거의 ​​모든 사소한 문제도 수정되었습니다. 수정 작업에 비어 있는 모든 사람들은 자신의 계정에서 적극적으로 작업하고 발견한 내용을 보고하고 있습니다. 우선순위를 정하여 팀별로 배분하고, 중요하지 않은 품목은 아침에 남겨둡니다.

테스트를 다시 실행한 결과 두 가지 새로운 큰 문제가 발견되었습니다. 모든 서비스 정책이 올바르게 도착하지 않았기 때문에 일부 사용자 요청이 인증을 통과하지 못했습니다. 또한 파트너 계정에 새로운 문제가 있습니다. 서둘러 살펴 보겠습니다.

03:20. 긴급 동기화
새로운 문제 XNUMX개가 해결되었습니다. 두 번째로 긴급 동기화를 구성하고 있습니다. 우리는 무슨 일이 일어나고 있는지 이해합니다. 이전 수정으로 한 가지 문제가 해결되었지만 또 다른 문제가 발생했습니다. 우리는 결과 없이 올바르게 수행하는 방법을 알아내기 위해 잠시 휴식을 취합니다.

03:30. 여섯 개의 눈
우리는 모든 파트너가 모든 일을 잘 수행할 수 있도록 기지의 최종 상태가 어떻게 되어야 하는지 이해합니다. 우리는 6개의 눈으로 요청을 작성하고, 사전 제작 단계에서 출시하고, 테스트하고, 프로덕션 단계에서 출시합니다.

04:00. 모든 것이 작동 중입니다.
모든 테스트를 통과했으며 심각한 문제는 눈에 띄지 않습니다. 때때로 팀의 어떤 일이 누군가에게 효과가 없을 경우 우리는 신속하게 대응합니다. 대부분의 경우 경보는 거짓입니다. 하지만 가끔 뭔가가 도착하지 않거나 별도의 페이지가 작동하지 않는 경우가 있습니다. 우리는 앉아서 고치고 고치고 또 고칩니다. 별도의 팀이 마지막 주요 기능인 결제를 출시합니다.

04:30. 돌아올 수 없는 지점
돌아올 수 없는 지점, 즉 롤백을 시작하면 주어진 다운타임을 충족할 수 없는 시점이 다가오고 있습니다. 모든 것을 알고 기록하지만 고객의 돈을 탕감하는 것을 고집스럽게 거부하는 청구서에 문제가 있습니다. 개별 페이지, 작업 및 상태에 몇 가지 버그가 있습니다. 주요 기능이 작동하고 모든 테스트가 성공적으로 통과되었습니다. 우리는 롤아웃이 이루어졌다고 결정하고 롤백하지 않을 것입니다.

06:00. UI에서 모든 사람에게 공개
버그가 수정되었습니다. 사용자의 관심을 끌지 못하는 일부는 나중을 위해 남겨 둡니다. 우리는 모든 사람에게 인터페이스를 공개합니다. 우리는 계속해서 청구 작업을 진행하고 있으며 사용자 피드백을 기다리고 결과를 모니터링하고 있습니다.

07:00. API 로드 문제
API에 대한 로드를 약간 잘못 계획하고 이 로드를 테스트했지만 문제를 식별할 수 없다는 것이 분명해졌습니다. 결과적으로 요청의 약 5%가 실패합니다. 동원해서 원인을 찾아보자.

청구는 완고하고 일하기를 원하지 않습니다. 변화를 차분하게 진행하기 위해 다음으로 연기하기로 결정했습니다. 즉, 모든 리소스가 축적되지만 고객의 상각은 진행되지 않습니다. 물론 이게 문제이긴 하지만 일반 출시에 비하면 별거 아닌 것 같습니다.

08:00. API 수정
우리는 부하에 대한 수정 사항을 출시했고 오류가 사라졌습니다. 우리는 집에 가기 시작합니다.

10:00. 모두
모든 것이 해결되었습니다. 모니터링도 조용하고 고객의 자리에서는 팀도 점차 잠에 들어갑니다. 결제가 남아있습니다. 내일 복원해드리겠습니다.

그런 다음 낮에는 일부 클라이언트에 대한 로그, 알림, 반환 코드 및 사용자 정의를 수정하는 롤아웃이 있었습니다.

그래서 출시는 성공적이었습니다! 물론 더 나을 수도 있지만 완벽을 달성하기에는 무엇이 충분하지 않은지에 대한 결론을 내렸습니다.

전체로

2개월간 출시를 적극적으로 준비하는 동안 43개의 작업이 완료되었으며, 이는 몇 시간에서 며칠까지 지속되었습니다.

출시 중:

• 신규 및 변경된 악마 - 5개 조각, 2개의 단일체 교체;
• 데이터베이스 내 변경 사항 - 사용자 데이터가 포함된 6개의 데이터베이스가 모두 영향을 받았으며 XNUMX개의 기존 데이터베이스에서 XNUMX개의 새 데이터베이스로 다운로드가 이루어졌습니다.
• 완전히 새롭게 디자인된 프런트엔드;
• 다운로드된 코드의 양 - 새 코드 33줄, 테스트 중인 코드 3줄, 마이그레이션 코드 5줄
• 모든 데이터는 손상되지 않았으며 단일 고객의 가상 머신도 손상되지 않았습니다. 🙂

좋은 출시를 위한 모범 사례

이 어려운 상황에서 우리를 인도해 주셨습니다. 그러나 일반적으로 롤아웃 중에 이를 따르는 것이 유용합니다. 그러나 출시가 복잡할수록 역할도 커집니다.

1. 가장 먼저 해야 할 일은 출시가 사용자에게 어떤 영향을 미칠 수 있는지 이해하는 것입니다. 다운타임이 발생하나요? 그렇다면 가동 중지 시간은 얼마나 됩니까? 이것이 사용자에게 어떤 영향을 미치나요? 가능한 최선의 시나리오와 최악의 시나리오는 무엇입니까? 그리고 위험을 감수하세요.
2. 모든 것을 계획하세요. 각 단계에서 출시의 모든 측면을 이해해야 합니다.
   • 코드 전달;
   • 코드 롤백;
   • 각 작업 시간;
   • 영향을 받는 기능.
3. 출시의 모든 단계와 각 단계의 위험이 명확해질 때까지 시나리오를 플레이해 보세요. 의심스러운 부분이 있으면 잠시 쉬면서 의심스러운 단계를 따로 살펴보시면 됩니다.
4. 각 단계는 사용자에게 도움이 된다면 개선될 수 있고 개선되어야 합니다. 예를 들어 가동 중지 시간을 줄이거나 일부 위험을 제거합니다.
5. 롤백 테스트는 코드 전달 테스트보다 훨씬 더 중요합니다. 롤백 결과 시스템이 원래 상태로 돌아가는지 확인하고 테스트를 통해 이를 확인해야 합니다.
6. 자동화할 수 있는 모든 것은 자동화되어야 합니다. 자동화할 수 없는 모든 항목은 미리 치트 시트에 작성해야 합니다.
7. 성공 기준을 기록합니다. 어떤 기능을 언제 사용할 수 있어야 합니까? 이런 일이 발생하지 않으면 롤백 계획을 실행하십시오.
8. 그리고 가장 중요한 것은 - 사람입니다. 모든 사람은 자신이 무엇을 하고 있는지, 출시 과정에서 자신의 행동에 따라 무엇이 달라지는지, 왜 그리고 무엇인지 알고 있어야 합니다.

한 문장으로, 좋은 계획과 정교함을 통해 판매에 미치는 영향 없이 원하는 모든 것을 출시할 수 있습니다. 심지어 프로덕션의 모든 서비스에 영향을 미칠 수도 있습니다.

출처 : habr.com