DRP 준비 - 운석을 고려하는 것을 잊지 마십시오

재해가 발생하더라도 차 한잔의 여유는 항상 있습니다.

DRP (재해 복구 계획)은 이상적으로는 절대 필요하지 않은 것입니다. 그러나 짝짓기 시즌에 이동하는 비버가 갑자기 주 광섬유를 갉아먹거나 하급 관리자가 생산 기반을 떨어뜨리면 이 모든 치욕을 어떻게 처리할 것인지에 대한 미리 만들어진 계획이 있는지 확인하고 싶을 것입니다.

당황한 고객이 기술 지원에 전화하기 시작하고 후배가 청산가리를 찾고 있는 동안 당신은 현명하게 빨간 봉투를 열고 모든 것을 정리하기 시작합니다.

이번 포스팅에서는 DRP 작성 방법과 DRP에 포함되어야 할 내용에 대한 권장 사항을 공유하고 싶습니다. 다음 사항도 살펴보겠습니다.

1. 악당처럼 생각하는 법을 배우자.
2. 종말 동안 차 한 잔의 이점을 분석해 봅시다.
3. 편리한 DRP 구조를 생각해 봅시다
4. 어떻게 테스트하는지 살펴보자

어떤 회사에 유용할까요?

IT 부서가 이러한 것들을 필요로 하기 시작하면 선을 긋기가 매우 어렵습니다. 다음과 같은 경우 DRP가 반드시 필요하다고 말하고 싶습니다.

• 서버나 애플리케이션을 중지하거나 일부 데이터베이스를 손실하면 비즈니스 전체에 상당한 손실이 발생합니다.
• 본격적인 IT 부서가 있습니다. 네트워크를 구축하고 바이러스를 청소하고 프린터를 다시 채우는 피곤한 직원 몇 명이 아닌 자체 예산을 갖춘 회사의 본격적인 단위 형태의 부서라는 의미입니다.
• 긴급 상황 발생 시 최소한 부분적인 중복성을 확보할 수 있는 현실적인 예산이 있습니다.

IT 부서가 몇 달 동안 백업을 위해 오래된 서버에 대해 최소한 두 개의 HDD를 구걸했다면, 타락한 서비스를 예비 용량으로 전면적으로 재배치하는 것은 불가능할 것입니다. 여기서도 문서가 불필요하지는 않습니다.

문서화가 중요하다

문서화부터 시작하세요. 귀하의 서비스가 XNUMX세대 전에 관리자가 작성한 Perl 스크립트에서 실행되고 그것이 어떻게 작동하는지 아무도 모른다고 가정해 보겠습니다. 축적된 기술 부채와 문서 부족으로 인해 필연적으로 무릎뿐만 아니라 다른 팔다리에도 총을 쏘게 될 것입니다. 이는 오히려 시간 문제입니다.

서비스 구성요소에 대한 적절한 설명이 있으면 충돌 통계를 올리십시오. 거의 확실하게 그것들은 완전히 전형적일 것입니다. 예를 들어, 때때로 디스크가 가득 차서 수동으로 정리할 때까지 노드에 오류가 발생하는 경우가 있습니다. 또는 누군가가 인증서 갱신을 다시 잊어버렸지만 Let's Encrypt를 설정할 수 없거나 설정하고 싶지 않아 클라이언트 서비스를 사용할 수 없게 되었습니다.

방해꾼 같은 생각

가장 어려운 부분은 이전에 한 번도 발생하지 않았지만 잠재적으로 서비스가 완전히 중단될 수 있는 사고를 예측하는 것입니다. 여기서 동료들과 저는 주로 악당 역할을 맡습니다. 커피와 맛있는 음식을 많이 마시고 회의실에 가두세요. 동일한 협상에서 대상 서비스를 직접 개발했거나 정기적으로 협력하는 엔지니어를 확보해야 합니다. 그런 다음 칠판이나 종이에 서비스에 발생할 수 있는 모든 공포를 그리기 시작합니다. 특정 청소부까지 자세히 설명하고 케이블을 뽑을 필요는 없으며 '로컬 네트워크 무결성 위반' 시나리오를 고려하면 충분합니다.

일반적으로 가장 일반적인 응급 상황은 다음 유형에 해당됩니다.

• 네트워크 장애
• OS 서비스 실패
• 신청 실패
• 철분 고장
• 가상화 실패

각 보기를 살펴보고 서비스에 적용되는 내용을 확인하세요. 예를 들어, Nginx 데몬이 내려가고 올라가지 않을 수 있습니다. 이는 OS 측의 오류입니다. 웹 애플리케이션을 작동하지 않는 상태로 만드는 드문 상황은 소프트웨어 오류입니다. 이 단계가 진행되는 동안 문제를 진단하는 것이 중요합니다. 예를 들어, 가상화 시 정지된 인터페이스와 Cisco의 타락 및 네트워크 충돌을 구별하는 방법은 무엇입니까? 책임 있는 사람을 신속하게 찾아 사고가 해결될 때까지 꼬리를 당기는 것이 중요합니다.

일반적인 문제를 기록한 후 우리는 더 많은 커피를 따르고 일부 매개변수가 표준을 벗어나기 시작하는 가장 이상한 시나리오를 고려하기 시작합니다. 예를 들어:

• 활성 노드의 시간이 클러스터의 다른 시간에 비해 XNUMX분 뒤로 이동하면 어떻게 되나요?
• 그리고 시간이 앞으로 흐르고 10년이 지나면?
• 동기화 중에 클러스터 노드의 네트워크가 갑자기 끊어지면 어떻게 됩니까?
• 그리고 네트워크를 통해 서로 일시적으로 격리되어 두 노드가 리더십을 공유하지 않으면 어떻게 되나요?

이 단계에서는 역방향 접근 방식이 많은 도움이 됩니다. 병든 상상력을 가진 팀 중 가장 완고한 구성원을 데리고 그에게 가능한 한 짧은 시간 내에 전환을 준비하는 임무를 부여하십시오. 그러면 서비스가 중단될 것입니다. 진단이 어렵다면 더욱 좋습니다. 무언가를 깨뜨리려는 아이디어가 주어졌을 때 엔지니어들이 생각해내는 이상하고 멋진 아이디어를 믿지 못할 것입니다. 그리고 이에 대한 테스트 스탠드를 약속한다면 매우 좋습니다.

당신의 이 DRP는 무엇입니까?!

따라서 위협 모델을 정의했습니다. 그들은 또한 구리를 찾아 광섬유 케이블을 자르는 지역 주민들과 금요일 16시 46분에 엄격하게 무선 중계선을 끊는 군용 레이더를 고려했습니다. 이제 우리는 이 모든 것을 어떻게 해야 할지 알아내야 합니다.

당신의 임무는 비상시에 개봉할 동일한 빨간 봉투를 작성하는 것입니다. (그렇다면!) 모든 것이 망가지면 가장 경험이 부족한 훈련생만이 근처에 있을 것이며, 무슨 일이 일어나고 있는지에 대한 공포에 손이 격렬하게 흔들릴 것이라고 즉시 예상하십시오. 의료실에서 비상 표지판이 어떻게 구현되는지 확인하세요. 예를 들어, 아나필락시성 쇼크를 어떻게 처리해야 할까요? 의료진은 모든 프로토콜을 외우고 있지만 근처에 있는 사람이 죽기 시작하면 모든 사람이 무기력하게 모든 것을 붙잡는 경우가 많습니다. 그러기 위해서는 “이런 포장을 열어라”, “정맥 주사로 너무 많은 양의 약을 주사하라”와 같은 항목으로 명확한 지시 사항이 벽에 걸려 있습니다.

긴급 상황에서는 생각하기 어렵습니다! 척추 분석에 대한 간단한 지침이 있어야 합니다.

좋은 DRP는 몇 가지 간단한 블록으로 구성됩니다.

1. 사고의 시작을 누구에게 알릴 것인가. 이는 제거 프로세스를 최대한 병렬화하기 위해 중요합니다.
2. 올바르게 진단하는 방법 - systemctl status servicename 등을 추적하고 살펴봅니다.
3. 각 단계에서 얼마나 많은 시간을 보낼 수 있습니까? SLA 시간 동안 직접 손으로 고칠 시간이 없으면 어제 백업에서 가상 머신을 종료하고 롤링합니다.
4. 충돌이 끝났는지 확인하는 방법.

DRP는 서비스가 완전히 실패했을 때 시작되며 효율성이 떨어지더라도 복구를 통해 완료된다는 점을 기억하세요. 단순히 예약을 잃어버리면 DRP가 활성화되어서는 안 됩니다. DRP로 차 한잔을 처방할 수도 있습니다. 진지하게. 통계에 따르면, 당황한 직원이 무언가를 고치기 위해 서두르고 동시에 데이터가 있는 유일한 라이브 노드를 죽이거나 마침내 클러스터를 종료한다는 사실로 인해 많은 사고가 불쾌한 것에서 재앙으로 변합니다. 일반적으로 차 한 잔을 마시는 5분은 진정하고 무슨 일이 일어나고 있는지 분석할 수 있는 시간을 제공합니다.

DRP와 시스템 여권을 혼동하지 마십시오! 불필요한 데이터로 과부하를 일으키지 마십시오. 하이퍼링크를 통해 문서의 필수 섹션으로 빠르고 편리하게 이동하고 서비스 아키텍처의 필수 섹션에 대해 확장된 형식으로 읽을 수 있는 기회를 제공하십시오. 그리고 DRP 자체에는 복사-붙여넣기를 위한 특정 명령으로 연결하는 위치와 방법에 대한 직접적인 지침만 있습니다.

올바르게 테스트하는 방법

담당 직원이 모든 항목을 완료할 수 있는지 확인하십시오. 가장 중요한 순간에 엔지니어에게 필요한 시스템에 대한 액세스 권한이 없거나, 필요한 계정에 대한 비밀번호가 없거나, "프록시를 통해 서비스 관리 콘솔에 연결하는 방법"이 무엇인지 전혀 알 수 없다는 사실이 밝혀질 수 있습니다. 본사'를 의미한다. 각 항목은 가능한 한 단순해야 합니다.

틀린 - "가상화로 이동하여 데드 노드를 재부팅합니다"
올바르게 - "웹 인터페이스를 통해 virt.example.com에 연결하고 노드 섹션에서 오류를 일으키는 노드를 다시 로드하세요."

모호함을 피하십시오. 겁에 질린 인턴을 기억하세요.

DRP를 꼭 테스트해보세요. 이는 단지 보여주기 위한 계획이 아닙니다. 이는 귀하와 귀하의 고객이 위기 상황에서 신속하게 벗어날 수 있도록 하는 것입니다. 이 작업을 여러 번 수행하는 것이 가장 좋습니다.

• 전문가 XNUMX명과 인턴 여러 명이 실제 서비스를 최대한 모방한 테스트벤치에서 작업한다. 전문가는 다양한 방법으로 서비스를 중단하고, DRP에 따라 훈련생이 복원할 수 있도록 해준다. 문서의 모든 문제, 모호함 및 오류가 기록됩니다. 훈련생을 훈련시킨 후, 잘 알려지지 않은 부분에서 DRP를 보완하고 단순화합니다.
• 실제 서비스에서 테스트 중입니다. 실제로 실제 서비스의 완벽한 복사본을 만들 수는 없습니다. 따라서 복구 순서를 평가하기 위해 10년에 두 번씩 계획적으로 서버의 일부를 끄고 연결을 끊고 위협 목록에서 기타 사고를 정리해야 합니다. 데이터 손실로 인해 최대 부하에서 몇 ​​시간 동안 갑작스러운 장애가 발생하는 것보다 한밤중에 XNUMX분간 계획된 중단을 갖는 것이 더 좋습니다.
• 실제 문제 해결. 예, 이것도 테스트의 일부입니다. 위협목록에 없는 사고가 발생한 경우에는 조사결과를 바탕으로 DRP를 보완, 확정하는 것이 필요하다.

키 포인트

1. 만약 이런 일이 일어날 수 있다면, 그 일은 일어날 뿐만 아니라 가능한 가장 재앙적인 시나리오에서도 일어날 것입니다.
2. 장애 조치를 위한 리소스가 있는지 확인하세요.
3. 백업이 있는지 확인하세요. 백업은 자동으로 생성되고 정기적으로 일관성을 확인합니다.
4. 일반적인 위협 시나리오를 고려하십시오.
5. 엔지니어에게 서비스 제공을 위한 비표준 옵션을 생각해 낼 수 있는 기회를 제공하십시오.
6. DRP는 간단하고 멍청한 지침이어야 합니다. 고객이 서비스를 복원한 후에만 모든 복잡한 진단이 가능합니다. 대기상태인데도 말이죠.
7. DRP에 주요 전화번호와 연락처를 나열하세요.
8. DRP에 대한 직원의 이해도를 정기적으로 테스트합니다.
9. 제품에 대한 계획된 사고를 준비하십시오. 스탠드가 모든 것을 대신할 수는 없습니다.

출처 : habr.com