Bitrix24: “빠르게 올라간 것은 떨어진 것으로 간주되지 않습니다”

현재 Bitrix24 서비스에는 수백 기가비트의 트래픽이 없으며 대규모 서버도 없습니다(물론 기존 서버가 꽤 많지만). 그러나 많은 고객에게 이는 회사에서 업무를 수행하기 위한 주요 도구이며 실제로 비즈니스에 중요한 응용 프로그램입니다. 그러므로 넘어질 일이 없습니다. 충돌이 발생했지만 서비스가 너무 빨리 "복구"되어 아무도 눈치채지 못했다면 어떻게 될까요? 그리고 작업 품질과 클라이언트 수를 잃지 않고 장애 조치를 구현하는 것이 어떻게 가능합니까? Bitrix24의 클라우드 서비스 이사인 Alexander Demidov는 제품이 출시된 지 7년 동안 예약 시스템이 어떻게 발전했는지에 대해 블로그를 통해 설명했습니다.

“우리는 24년 전에 SaaS로 Bitrix7를 출시했습니다. 가장 큰 어려움은 아마도 다음과 같았을 것입니다. SaaS로 공개적으로 출시되기 전에는 이 제품이 단순히 박스형 솔루션 형식으로 존재했습니다. 고객은 우리에게서 이를 구입하여 서버에 호스팅하고 기업 포털을 설정했습니다. 이는 직원 커뮤니케이션, 파일 저장, 작업 관리, CRM 등을 위한 일반 솔루션입니다. 그리고 2012년까지 우리는 이를 SaaS로 출시하여 스스로 관리하고 내결함성과 안정성을 보장하기로 결정했습니다. 그 과정에서 우리는 경험을 얻었습니다. 왜냐하면 그때까지 우리는 경험이 없었기 때문입니다. 우리는 서비스 제공자가 아닌 소프트웨어 제조업체일 뿐이었습니다.

서비스를 출시할 때 가장 중요한 것은 서비스의 내결함성, 안정성 및 지속적인 가용성을 보장하는 것임을 이해했습니다. 한 시간 동안 고통을 받고 주문을 잃고 고객을 잃게 되지만 고객 자신에게는 이것이 그다지 중요하지 않습니다. 물론 그는 화가 났지만 다른 사이트에 가서 구입했습니다. 그리고 이것이 회사 내의 모든 작업, 커뮤니케이션, 의사 결정이 연결되는 응용 프로그램이라면 가장 중요한 것은 사용자의 신뢰를 얻는 것, 즉 사용자를 실망시키지 않고 넘어지지 않는 것입니다. 내부의 무언가가 작동하지 않으면 모든 작업이 중단될 수 있기 때문입니다.

SaaS로서의 Bitrix.24

우리는 공개 출시 2011년 전인 XNUMX년에 첫 번째 프로토타입을 조립했습니다. 우리는 약 일주일 만에 그것을 조립하고 살펴보고 빙빙 돌았습니다. 심지어 작동하고 있었습니다. 즉, 양식에 들어가서 거기에 포털 이름을 입력하면 새 포털이 열리고 사용자 기반이 생성됩니다. 우리는 그것을 보고, 원칙적으로 제품을 평가하고, 폐기하고, XNUMX년 동안 계속해서 개선했습니다. 우리에게는 큰 임무가 있었기 때문입니다. 두 개의 서로 다른 코드 베이스를 만들고 싶지 않았고, 별도의 패키지 제품, 별도의 클라우드 솔루션을 지원하고 싶지도 않았습니다. 이 모든 것을 하나의 코드 내에서 수행하고 싶었습니다.

당시 일반적인 웹 애플리케이션은 일부 PHP 코드가 실행되고, mysql 데이터베이스가 실행되고, 파일이 업로드되고, 문서, 사진이 업로드 폴더에 저장되는 하나의 서버였습니다. 모두 작동합니다. 아쉽게도 이를 사용하여 매우 안정적인 웹 서비스를 시작하는 것은 불가능합니다. 여기서는 분산 캐시가 지원되지 않으며 데이터베이스 복제도 지원되지 않습니다.

우리는 요구 사항을 공식화했습니다. 이는 서로 다른 위치에 위치할 수 있고, 복제를 지원하며, 이상적으로는 지리적으로 분산된 서로 다른 데이터 센터에 위치할 수 있는 능력입니다. 제품 로직과 실제로 데이터 저장소를 분리하세요. 로드에 따라 동적으로 확장할 수 있고 정적을 모두 허용할 수 있습니다. 실제로 이러한 고려 사항을 통해 제품에 대한 요구 사항이 나타났고, 우리는 이를 1년 동안 개선했습니다. 이 기간 동안 박스형 솔루션, 자체 서비스 등 통합된 플랫폼에서 우리는 필요한 사항을 지원했습니다. 제품 자체 수준에서 mysql 복제 지원: 즉, 코드를 작성하는 개발자는 자신의 요청이 어떻게 배포될지 생각하지 않고 우리의 API를 사용하며 마스터 간에 쓰기 및 읽기 요청을 올바르게 배포하는 방법을 알고 있습니다. 그리고 노예.

우리는 Google Storage, Amazon s3, 오픈 스택 Swift 지원 등 다양한 클라우드 객체 스토리지를 제품 수준에서 지원했습니다. 따라서 이는 서비스로서 우리와 패키지 솔루션으로 작업하는 개발자 모두에게 편리했습니다. 업무에 API를 사용하는 경우 파일이 궁극적으로 파일 시스템에 로컬로 저장될 위치나 로컬에 저장될 위치에 대해 생각하지 않습니다. 개체 파일 저장소에 .

그 결과 우리는 전체 데이터 센터 수준에서 예약하기로 즉시 결정했습니다. 우리는 이미 이 플랫폼에 대한 경험이 있었고 우리 웹 사이트도 그곳에서 호스팅되었기 때문에 2012년에 완전히 Amazon AWS에서 출시했습니다. 우리는 각 지역마다 Amazon에 여러 개의 가용 영역이 있다는 사실에 매료되었습니다. 실제로 (그 용어로는) 서로 어느 정도 독립적이며 전체 데이터 센터 수준에서 예약할 수 있는 여러 데이터 센터가 있습니다. 갑자기 실패하면 데이터베이스가 마스터-마스터로 복제되고, 웹 애플리케이션 서버가 백업되며, 정적 데이터가 s3 객체 스토리지로 이동됩니다. 로드 밸런싱이 이루어졌습니다. 당시에는 Amazon elb에 의해 이루어졌지만 조금 후에 더 복잡한 로직이 필요했기 때문에 자체 로드 밸런서를 사용하게 되었습니다.

그들이 원하는 것은 그들이 얻은 것입니다 ...

서버 자체의 내결함성, 웹 애플리케이션, 데이터베이스 등 우리가 보장하고자 했던 모든 기본 사항이 모두 잘 작동했습니다. 가장 간단한 시나리오: 웹 애플리케이션 중 하나가 실패하면 모든 것이 간단합니다. 균형 조정이 꺼집니다.

밸런서(당시 Amazon의 elb)는 고장난 시스템을 비정상으로 표시하고 해당 시스템에 대한 부하 분산을 껐습니다. Amazon 자동 크기 조정이 작동했습니다. 로드가 증가하면 새 시스템이 자동 크기 조정 그룹에 추가되고 로드가 새 시스템에 분산되어 모든 것이 정상이었습니다. 밸런서의 논리는 거의 동일합니다. 애플리케이션 서버에 문제가 발생하면 요청을 제거하고 해당 머신을 버리고 새 머신을 시작하고 작업을 계속합니다. 이 계획은 수년에 걸쳐 조금씩 변경되었지만 계속 작동합니다. 간단하고 이해하기 쉬우며 어려움이 없습니다.

우리는 전 세계에서 일하고 있으며, 고객 로드 피크는 완전히 다르며, 우호적인 방식으로 고객이 눈치채지 못하게 언제든지 시스템의 모든 구성 요소에 대해 특정 서비스 작업을 수행할 수 있어야 합니다. 따라서 데이터베이스 운영을 중단하고 두 번째 데이터 센터에 로드를 재분배할 수 있는 기회가 있습니다.

어떻게 작동하나요? — 우리는 트래픽을 작동 중인 데이터 센터로 전환합니다. 데이터 센터에서 사고가 발생하면 완전히, 이것이 하나의 데이터베이스에 대한 계획된 작업이라면 이러한 클라이언트에 서비스를 제공하는 트래픽의 일부를 두 번째 데이터 센터로 전환하여 일시 중지합니다. 복제다. 두 번째 데이터 센터의 로드가 증가하여 웹 애플리케이션에 새 시스템이 필요한 경우 자동으로 시작됩니다. 작업을 마치고 복제가 복원된 다음 전체 로드가 다시 반환됩니다. 예를 들어 시스템 업데이트를 설치하거나 두 번째 데이터베이스의 설정을 변경하는 등 두 번째 DC에서 일부 작업을 미러링해야 하는 경우 일반적으로 다른 방향으로 동일한 작업을 반복합니다. 이것이 사고라면 우리는 모든 일을 간단하게 처리합니다. 즉, 모니터링 시스템에서 이벤트 처리기 메커니즘을 사용합니다. 여러 검사가 트리거되고 상태가 위험으로 전환되면 특정 로직을 실행할 수 있는 핸들러인 이 핸들러를 실행합니다. 각 데이터베이스에 대해 장애 조치 서버를 지정하고, 사용할 수 없는 경우 트래픽을 전환해야 하는 위치를 지정합니다. 역사적으로 우리는 nagios 또는 일부 포크를 어떤 형태로든 사용했습니다. 원칙적으로 거의 모든 모니터링 시스템에 유사한 메커니즘이 존재합니다. 아직 더 복잡한 것을 사용하지는 않지만 언젠가는 사용하게 될 것입니다. 이제 모니터링은 가용성이 없을 때 시작되며 무언가를 전환할 수 있습니다.

우리 다 예약했어?

우리는 미국의 많은 고객, 유럽의 많은 고객, 일본, 싱가포르 등 동양에 더 가까운 많은 고객을 보유하고 있습니다. 물론 러시아 고객의 상당 부분이 러시아에 있습니다. 즉, 작업이 한 지역에 있지 않습니다. 사용자는 빠른 응답을 원하고 다양한 현지 법률을 준수해야 하는 요구 사항이 있으며 각 지역 내에 두 개의 데이터 센터를 보유하고 있으며 한 지역 내에 배치하는 것이 편리한 몇 가지 추가 서비스도 있습니다. 이 지역이 일하고 있어요. REST 핸들러, 권한 부여 서버는 클라이언트 전체의 작동에 덜 중요합니다. 약간의 허용 가능한 지연으로 전환할 수 있지만 모니터링 방법과 수행할 작업에 대한 바퀴를 재발명하고 싶지는 않습니다. 그들과 함께. 그래서 우리는 추가 제품에 대한 어떤 역량을 개발하기보다는 기존 솔루션을 최대한 활용하려고 노력하고 있습니다. 그리고 어딘가에서는 DNS 수준에서 전환을 사소하게 사용하고 동일한 DNS로 서비스의 활성 상태를 결정합니다. Amazon에는 Route 53 서비스가 있지만 이는 단순히 항목을 입력할 수 있는 DNS만이 아니라 훨씬 더 유연하고 편리합니다. 이를 통해 지리적 위치를 사용하여 지리적 분산 서비스를 구축할 수 있으며, 이를 사용하여 클라이언트가 어디에서 왔는지 확인하고 특정 기록을 제공할 수 있습니다. 이를 통해 장애 조치 아키텍처를 구축할 수 있습니다. Route 53 자체에서도 동일한 상태 확인이 구성됩니다. 모니터링할 엔드포인트를 설정하고, 지표를 설정하고, 서비스의 "활성"을 결정하는 프로토콜(tcp, http, https)을 설정합니다. 서비스가 활성 상태인지 여부를 확인하는 확인 빈도를 설정합니다. 그리고 DNS 자체에서는 기본이 무엇인지, 보조가 무엇인지, 상태 확인이 경로 53 내에서 트리거되는 경우 전환할 위치를 지정합니다. 이 모든 작업은 다른 도구를 사용하여 수행할 수 있지만 이것이 편리한 이유는 무엇입니까? 설정했습니다. 한 번만 확인하고 전환하는 방법에 대해 전혀 생각하지 마십시오. 모든 것이 자체적으로 작동합니다.

첫 번째 "하지만": Route 53 자체를 어떻게, 무엇으로 예약합니까? 그에게 무슨 일이 생기면 어쩌지 누가 알겠어요? 다행스럽게도 우리는 이 갈퀴를 밟은 적이 없지만, 왜 아직도 예약이 필요하다고 생각했는지에 대한 이야기를 다시 한번 말씀드리겠습니다. 여기서 우리는 미리 빨대를 배치했습니다. 우리는 하루에 여러 번 Route 53에 있는 모든 구역을 완전히 언로드합니다. Amazon의 API를 사용하면 JSON으로 쉽게 보낼 수 있으며, 이를 변환하고 구성 형식으로 업로드하며 대략적으로 말하면 백업 구성을 갖는 여러 백업 서버가 있습니다. 어떤 일이 발생하면 DNS 설정 데이터를 잃지 않고 수동으로 신속하게 배포할 수 있습니다.

두 번째 "그러나": 이 사진에서 아직 예약되지 않은 것은 무엇인가요? 밸런서 그 자체! 지역별 고객 분포는 매우 간단합니다. 우리는 bitrix24.ru, bitrix24.com, .de 도메인을 보유하고 있습니다. 이제 다양한 영역에서 작동하는 13개의 도메인이 있습니다. 우리는 다음과 같은 결과를 얻었습니다. 각 지역에는 자체 밸런서가 있습니다. 이렇게 하면 네트워크의 최대 로드 위치에 따라 여러 지역에 분산하는 것이 더 편리해집니다. 단일 밸런서 수준에서 오류가 발생한 경우 서비스가 중단되고 DNS에서 제거됩니다. 밸런서 그룹에 문제가 있는 경우 다른 사이트에 백업하고 이들 사이의 전환은 동일한 경로를 사용하여 수행됩니다53. 짧은 TTL로 인해 최대 2, 3, 5분 내에 전환이 발생하기 때문입니다. .

세 번째 "하지만": 아직 예약되지 않은 것은 무엇입니까? S3, 맞습니다. 우리가 사용자를 위해 s3에 저장한 파일을 배치했을 때 우리는 그것이 갑옷을 뚫는 것이며 거기에 아무것도 예약할 필요가 없다고 진심으로 믿었습니다. 그러나 역사는 상황이 다르게 일어난다는 것을 보여줍니다. 일반적으로 Amazon은 S3를 기본 서비스로 설명합니다. 왜냐하면 Amazon 자체는 S3를 사용하여 머신 이미지, 구성, AMI 이미지, 스냅샷 등을 저장하기 때문입니다. 그리고 s3가 충돌하는 경우(우리가 사용해 온 7년 동안 한 번 발생함) bitrix24, 팬처럼 따라옵니다. 가상 머신을 시작할 수 없음, API 오류 등 많은 문제가 발생합니다.

그리고 S3가 떨어질 수 있습니다. 한 번 일어났습니다. 따라서 우리는 다음과 같은 계획에 이르렀습니다. 몇 년 전 러시아에는 심각한 공공 물건 보관 시설이 없었으며 우리 스스로 뭔가를 하는 옵션을 고려했습니다... 다행스럽게도 우리는 이 일을 시작하지 않았습니다. 우리가 가지고 있지 않은 전문 지식을 파헤쳐 아마도 엉망이 될 것입니다. 이제 Mail.ru에는 s3 호환 스토리지가 있고 Yandex에도 있고 다른 여러 제공업체에도 있습니다. 우리는 결국 첫째로 백업을 원하고 둘째로 로컬 복사본으로 작업할 수 있는 기능을 원한다는 아이디어에 도달했습니다. 특히 러시아 지역의 경우 s3와 API 호환되는 Mail.ru Hotbox 서비스를 사용합니다. 우리는 애플리케이션 내부의 코드를 크게 수정할 필요가 없었으며 다음과 같은 메커니즘을 만들었습니다. s3에는 객체 생성/삭제를 트리거하는 트리거가 있고 Amazon에는 Lambda라는 서비스가 있습니다. 이는 서버리스 코드 실행입니다. 특정 트리거가 트리거될 때만 실행됩니다.

우리는 매우 간단하게 작업을 수행했습니다. 트리거가 실행되면 개체를 Mail.ru 저장소에 복사하는 코드를 실행합니다. 로컬 데이터 복사본으로 작업을 완전히 시작하려면 러시아 부문에 있는 클라이언트가 더 가까운 스토리지로 작업할 수 있도록 역동기화도 필요합니다. 메일이 저장소에서 트리거를 완료하려고 합니다. 인프라 수준에서 역동기화를 수행하는 것이 가능하지만 지금은 자체 코드 수준에서 이 작업을 수행하고 있습니다. 클라이언트가 파일을 게시한 것을 확인하면 코드 수준에서 이벤트를 대기열에 배치하고 처리한 다음 역방향 복제를 수행합니다. 나쁜 이유: 제품 외부의 개체를 사용하여 어떤 종류의 작업을 수행하는 경우, 즉 일부 외부 수단을 사용하면 이를 고려하지 않습니다. 따라서 스토리지 수준에 트리거가 나타날 때까지 기다리므로 코드를 어디에서 실행하든 우리에게 온 개체가 다른 방향으로 복사됩니다.

코드 수준에서는 각 클라이언트에 대해 두 저장소를 모두 등록합니다. 하나는 기본 저장소로 간주되고 다른 하나는 백업 저장소로 간주됩니다. 모든 것이 괜찮다면 우리는 우리에게 더 가까운 스토리지를 사용하여 작업합니다. 즉, Amazon에 있는 고객은 S3를 사용하고 러시아에서 일하는 고객은 Hotbox를 사용합니다. 플래그가 트리거되면 장애 조치가 연결되어야 하며 클라이언트를 다른 스토리지로 전환합니다. 이 상자를 지역별로 독립적으로 선택하고 앞뒤로 전환할 수 있습니다. 아직 실제로 이것을 사용하지는 않았지만 이 메커니즘을 제공했으며 언젠가는 바로 이 스위치가 필요하고 유용할 것이라고 생각합니다. 이런 일은 이미 한 번 일어났습니다.

아 그리고 아마존은 도망갔어...

올해 4월은 러시아에서 텔레그램 차단이 시작된 지 1주년이 되는 날입니다. 이에 따라 가장 큰 영향을 받는 공급자는 Amazon입니다. 그리고 불행하게도 전 세계를 위해 일했던 러시아 기업들은 더 많은 고통을 겪었습니다.

회사가 글로벌이고 러시아가 3-5%로 매우 작은 부문이라면 어떤 식으로든 희생할 수 있습니다.

이것이 순전히 러시아 회사라면-현지에 위치해야한다고 확신합니다-음, 단순히 사용자 자신에게 편리하고 편안하며 위험이 더 적을 것입니다.

이것이 전 세계적으로 운영되고 러시아와 전 세계 어디에서나 대략 동일한 수의 고객을 보유하고 있는 회사라면 어떨까요? 세그먼트의 연결성은 중요하며 어떤 방식으로든 서로 작동해야 합니다.

2018년 3월 말, Roskomnadzor는 Zello 메신저를 차단하기 위해 수백만 개의 Amazon IP를 차단할 계획이라는 내용의 편지를 최대 규모 운영자에게 보냈습니다. 이러한 동일한 제공자 덕분에 그들은 모든 사람에게 편지를 성공적으로 유출했으며 Amazon과의 연결이 무너질 수 있다는 것을 이해했습니다. 금요일이었는데, 우리는 server.ru에서 동료들에게 당황하여 다음과 같이 말했습니다. "친구 여러분, 러시아나 Amazon이 아닌 예를 들어 암스테르담 어딘가에 위치할 서버가 여러 대 필요합니다." 우리가 어떤 식으로든 영향을 미칠 수 없는 일부 엔드포인트(예: 동일한 sXNUMX의 엔드포인트)에 대해 최소한 어떻게든 자체 VPN과 프록시를 설치할 수 있도록 하기 위해 - 새로운 서비스를 생성하고 다른 서비스를 얻을 수는 없습니다. ip, 아직 거기까지 가야 해요. 단 며칠 만에 우리는 이러한 서버를 설정하고 실행했으며 일반적으로 차단이 시작되는 순간에 대비했습니다. 소란과 패닉을 지켜보던 RKN이 "아니요, 이제 아무것도 차단하지 않겠습니다"라고 말한 것도 궁금하다. (그러나 이것은 정확히 Telegram이 차단되기 시작한 순간까지입니다.) 우회 기능을 설정하고 차단이 도입되지 않았다는 것을 깨달았지만 우리는 전체 문제를 정리하기 시작하지 않았습니다. 네, 만일을 대비해서요.

그리고 2019년 현재 우리는 여전히 차단된 상태에 살고 있습니다. 어젯밤에 확인해 보니 약 백만 개의 IP가 계속 차단되어 있습니다. 사실, Amazon은 거의 완전히 차단 해제되었으며 정점에는 20천만 개의 주소에 도달했습니다.... 일반적으로 현실은 일관성, 좋은 일관성이 없을 수 있다는 것입니다. 갑자기. 화재, 굴착기 등 기술적인 이유로 존재하지 않을 수도 있습니다. 또는 우리가 본 것처럼 완전히 기술적인 것은 아닙니다. 따라서 자체 AS를 가진 크고 큰 사람은 아마도 다른 방법으로 이를 관리할 수 있을 것입니다. 직접 연결 및 기타 사항은 이미 l2 수준에 있습니다. 그러나 우리와 같은 간단한 버전이나 더 작은 버전에서는 만일을 대비하여 VPN, 프록시를 미리 구성하고 해당 세그먼트에서 구성을 신속하게 전환할 수 있는 기능을 통해 다른 곳에 있는 서버 수준에서 중복성을 가질 수 있습니다. 이는 연결에 매우 중요합니다. 최악의 시나리오에서 Amazon의 차단이 시작되었을 때 우리는 이를 통해 S3 트래픽만 허용했지만 점차적으로 이 모든 것이 해결되었습니다.

전체 공급자를 예약하는 방법은 무엇입니까?

현재로서는 Amazon 전체가 다운될 경우를 대비한 시나리오가 없습니다. 러시아에도 비슷한 시나리오가 있습니다. 러시아에서는 한 제공업체에 의해 호스팅되었으며 그 제공업체로부터 여러 사이트를 보유하기로 결정했습니다. 그리고 1년 전에 우리는 문제에 직면했습니다. 두 개의 데이터 센터라 할지라도 공급자의 네트워크 구성 수준에서 이미 두 데이터 센터 모두에 영향을 미치는 문제가 있을 수 있습니다. 그리고 두 사이트 모두에서 서비스를 이용할 수 없게 될 수도 있습니다. 물론 그런 일이 일어났습니다. 우리는 결국 내부 아키텍처를 재검토하게 되었습니다. 크게 변경되지는 않았지만 러시아의 경우 이제 동일한 공급자가 아닌 서로 다른 두 사이트의 두 사이트가 있습니다. 하나가 실패하면 다른 것으로 전환할 수 있습니다.

가정적으로 Amazon의 경우 다른 공급자 수준에서 예약 가능성을 고려하고 있습니다. 아마도 Google일 수도 있고, 어쩌면 다른 사람일 수도 있습니다. 하지만 지금까지 우리는 실제로 Amazon이 하나의 가용 영역 수준에서 사고가 발생하는 반면 전체 지역 수준에서 사고가 발생하는 경우는 매우 드물다는 것을 관찰했습니다. 따라서 우리는 이론적으로는 “아마존은 아마존이 아니다”라고 예약할 수 있다는 생각을 가지고 있지만 실제로는 아직 그렇지 않습니다.

자동화에 대한 몇 마디

자동화는 항상 필요한가? 여기서 더닝-크루거 효과(Dunning-Kruger Effect)를 떠올려 보는 것이 적절합니다. “x”축은 우리가 얻은 지식과 경험이고, “y”축은 우리의 행동에 대한 자신감입니다. 처음에 우리는 아무것도 모르고 전혀 확신하지 못합니다. 그런 다음 우리는 조금 알고 엄청난 자신감을 갖게됩니다. 이것은 "치매와 용기"라는 그림으로 잘 설명되는 소위 "어리석음의 정점"입니다. 그러면 우리는 조금 배웠고 전투에 나갈 준비가 되었습니다. 그러다가 우리는 아주 심각한 실수를 밟고 절망의 계곡에 빠지게 됩니다. 뭔가 아는 것처럼 보이지만 실제로는 아는 것이 별로 없는 때입니다. 그러다가 경험이 쌓이면서 우리는 더 자신감을 갖게 됩니다.

특정 사고로의 다양한 자동 전환에 대한 우리의 논리는 이 그래프에 매우 잘 설명되어 있습니다. 우리는 시작했습니다. 아무것도 할 줄 몰랐고 거의 모든 작업이 손으로 이루어졌습니다. 그러다가 우리는 모든 것에 자동화를 적용하고 평화롭게 잠을 잘 수 있다는 것을 깨달았습니다. 그리고 갑자기 우리는 큰 갈퀴를 밟습니다. 잘못된 긍정이 발생하고 좋은 방법으로 이 작업을 수행하지 말았어야 할 때 트래픽을 앞뒤로 전환합니다. 결과적으로 복제가 무너지거나 다른 일이 발생하는 것이 바로 절망의 계곡입니다. 그러면 우리는 모든 것에 현명하게 접근해야 한다는 것을 이해하게 됩니다. 즉, 잘못된 경보 가능성을 제공하는 자동화에 의존하는 것이 합리적입니다. 하지만! 결과가 심각할 수 있다면 근무 교대 근무자, 근무 중인 엔지니어에게 맡기는 것이 더 낫습니다. 근무 중인 엔지니어는 실제로 사고가 발생했는지 확인하고 모니터링하며 필요한 조치를 수동으로 수행합니다.

결론

7년에 걸쳐 우리는 무언가가 떨어졌을 때 공황 상태가 발생했다는 사실에서 문제가 존재하지 않고 작업만 있으며 해결해야 하고 해결할 수 있다는 사실을 이해하게 되었습니다. 서비스를 구축할 때 위에서부터 살펴보고 발생할 수 있는 모든 위험을 평가하세요. 즉시 확인되면 사전에 중복성과 내결함성 인프라 구축 가능성을 제공하십시오. 실패하고 서비스 작동 불능으로 이어질 수 있는 모든 지점은 확실히 그렇게 되기 때문입니다. 그리고 s3와 같은 일부 인프라 요소가 확실히 실패하지 않을 것처럼 보이더라도 여전히 실패할 수 있다는 점을 명심하세요. 그리고 적어도 이론상으로는 무슨 일이 생기면 어떻게 할 것인지 생각해 보세요. 위험 관리 계획을 가지고 있습니다. 모든 것을 자동으로 또는 수동으로 수행하려고 할 때 위험을 평가하십시오. 자동화가 모든 것을 전환하기 시작하면 어떻게 될까요? 이것이 사고에 비해 더 나쁜 상황으로 이어지지 않을까요? 아마도 어딘가에서는 자동화 사용과 근무 중인 엔지니어의 반응 사이에 합리적인 절충안을 사용해야 할 것입니다. 엔지니어는 실제 상황을 평가하고 현장에서 무언가를 전환해야 하는지 또는 "예, 하지만 지금은 아닙니다"를 이해할 것입니다.

완벽주의와 당신이 결국 갖게 될 계획에 쓸 수 있는 실제 노력, 시간, 돈 사이의 합리적인 절충안입니다.

이 텍스트는 Alexander Demidov가 회의에서 발표한 보고서의 업데이트되고 확장된 버전입니다. 가동 시간 4일.

출처 : habr.com