생산 준비 체크리스트

이 기사의 번역은 코스의 학생들을 위해 특별히 준비되었습니다. "DevOps 사례 및 도구", 오늘부터 시작됩니다!

새로운 서비스를 프로덕션 환경에 출시한 적이 있나요? 아니면 그러한 서비스 지원에 참여하셨나요? 그렇다면, 무엇이 당신에게 동기를 부여했습니까? 생산에 좋은 점과 나쁜 점은 무엇입니까? 기존 서비스의 릴리스 또는 유지 관리에 대해 새로운 팀 구성원을 어떻게 교육합니까?

대부분의 기업은 산업 운영 관행과 관련하여 "와일드 웨스트(Wild West)" 접근 방식을 채택하게 됩니다. 각 팀은 시행착오를 통해 자체 도구와 모범 사례를 결정합니다. 그러나 이는 프로젝트의 성공뿐만 아니라 엔지니어에게도 영향을 미치는 경우가 많습니다.

시행착오는 비난과 비난이 흔한 환경을 조성합니다. 이러한 행동으로 인해 실수로부터 배우고 다시 반복하지 않는 것이 점점 더 어려워집니다.

성공적인 조직:

• 생산 지침의 필요성을 인식하고,
• 모범 사례를 연구하고,
• 새로운 시스템이나 구성 요소를 개발할 때 생산 준비 문제에 대한 논의를 시작합니다.
• 생산 준비 규칙 준수를 보장합니다.

생산 준비에는 "검토" 프로세스가 포함됩니다. 검토는 체크리스트 또는 일련의 질문 형식일 수 있습니다. 검토는 수동, 자동 또는 둘 다 수행할 수 있습니다. 정적인 요구 사항 목록 대신 특정 요구 사항에 맞게 조정할 수 있는 체크리스트 템플릿을 만들 수 있습니다. 이러한 방식으로 엔지니어는 필요한 경우 지식과 충분한 유연성을 상속받을 수 있는 방법을 제공받을 수 있습니다.

서비스의 생산 준비 상태를 언제 확인해야 합니까?

생산 준비 상태 점검은 출시 직전뿐만 아니라 다른 운영팀이나 신입사원에게 이관할 때에도 유용합니다.

언제 확인하세요:

• 새로운 서비스를 프로덕션에 출시하고 있습니다.
• 프로덕션 서비스 운영을 SRE와 같은 다른 팀으로 이전합니다.
• 생산 서비스 운영을 신규 직원에게 이전합니다.
• 기술 지원을 구성합니다.

생산 준비 체크리스트

제가 얼마전에 예시로 опубликовала 생산 준비 테스트를 위한 체크리스트입니다. 이 목록은 Google Cloud 고객을 위해 작성되었지만 Google Cloud 외부에도 유용하고 적용 가능합니다.

디자인 및 개발

• 외부 서비스에 대한 액세스가 필요하지 않고 외부 시스템의 오류에 의존하지 않는 반복 가능한 빌드 프로세스를 개발합니다.
• 설계 및 개발 기간 동안 서비스에 대한 SLO를 정의하고 설정하세요.
• 귀하가 의존하는 외부 서비스의 가용성에 대한 기대치를 문서화하십시오.
• 단일 글로벌 리소스에 대한 종속성을 제거하여 단일 실패 지점을 방지합니다. 리소스를 복제하거나 리소스를 사용할 수 없는 경우 대체를 사용합니다(예: 하드 코딩된 값).

구성 관리

• 정적, 소규모 및 비밀이 아닌 구성은 명령줄 매개변수를 통해 전달될 수 있습니다. 그 밖의 모든 경우에는 구성 저장소 서비스를 사용하십시오.
• 구성 서비스를 사용할 수 없는 경우 동적 구성에는 대체 설정이 있어야 합니다.
• 개발 환경 구성은 프로덕션 구성과 관련되어서는 안 됩니다. 그렇지 않으면 개발 환경에서 프로덕션 서비스에 액세스하게 되어 개인 정보 보호 문제 및 데이터 유출이 발생할 수 있습니다.
• 동적으로 구성할 수 있는 항목을 문서화하고 구성 전달 시스템을 사용할 수 없는 경우 대체 동작을 설명합니다.

릴리스 관리

• 릴리스 프로세스를 자세히 문서화합니다. 릴리스가 SLO에 어떤 영향을 미치는지 설명합니다(예: 캐시 누락으로 인한 일시적인 지연 시간 증가).
• 카나리아 릴리스를 문서화합니다.
• 카나리아 릴리스 검토 계획을 개발하고 가능하다면 자동 롤백 메커니즘을 개발합니다.
• 롤백이 배포와 동일한 프로세스를 사용할 수 있는지 확인하세요.

관찰 가능성

• SLO에 필요한 측정항목 집합이 수집되었는지 확인하세요.
• 클라이언트 데이터와 서버 데이터를 구별할 수 있는지 확인하세요. 이는 오작동의 원인을 찾는 데 중요합니다.
• 인건비 절감을 위한 알림을 설정하세요. 예를 들어 일상적인 작업으로 인해 발생한 경고를 제거합니다.
• Stackdriver를 사용하는 경우 대시보드에 GCP 플랫폼 측정항목을 포함하세요. GCP 종속성에 대한 알림을 설정하세요.
• 항상 들어오는 추적을 전파하십시오. 추적에 참여하지 않더라도 이를 통해 하위 수준 서비스가 프로덕션 문제를 디버깅할 수 있습니다.

보호 및 안전

• 모든 외부 연결이 암호화되었는지 확인하세요.
• 프로덕션 프로젝트에 올바른 IAM 설정이 있는지 확인하세요.
• 네트워크를 사용하여 가상 머신 인스턴스 그룹을 격리합니다.
• VPN을 사용하여 원격 네트워크에 안전하게 연결하세요.
• 데이터에 대한 사용자 액세스를 문서화하고 모니터링합니다. 데이터에 대한 모든 사용자 액세스가 감사되고 기록되는지 확인하십시오.
• 디버깅 엔드포인트가 ACL에 의해 제한되는지 확인하세요.
• 사용자 입력을 삭제합니다. 사용자 입력에 대한 페이로드 크기 제한을 구성합니다.
• 서비스가 개별 사용자의 수신 트래픽을 선택적으로 차단할 수 있는지 확인하세요. 이렇게 하면 다른 사용자에게 영향을 주지 않고 위반을 차단합니다.
• 많은 내부 작업을 시작하는 외부 엔드포인트를 피하세요.

용량 계획

• 서비스 확장 방법을 문서화하세요. 예: 사용자 수, 수신 페이로드 크기, 수신 메시지 수.
• 서비스에 대한 리소스 요구 사항을 문서화합니다. 예: 전용 가상 머신 인스턴스 수, Spanner 인스턴스 수, GPU 또는 TPU와 같은 특수 하드웨어.
• 문서 리소스 제한: 리소스 유형, 지역 등
• 새 리소스 생성을 위한 문서 할당량 제한 사항입니다. 예를 들어 API를 사용하여 새 인스턴스를 만드는 경우 GCE API 요청 수를 제한합니다.
• 성능 저하를 분석하려면 부하 테스트를 실행하는 것이 좋습니다.

그게 다야. 수업 시간에 보자!

출처 : habr.com