Atlassian이 운영 준비성을 갖추는 방법

티어-0: 중요한 백본 인프라

티어-0 서비스는 티어-1 서비스가 실행되는 데 의존하는 지원 인프라와 공유 서비스 컴포넌트를 제공합니다. 다음 중 하나에 해당하면 컴포넌트가 중요한 것으로 간주됩니다.

• 티어-1 서비스를 실행하거나 사용자가 액세스하는 데 필요
• 고객이 티어-1 서비스에 등록하는 데 필요
• 직원이 티어-1 서비스에서 다음과 같은 주요 운영 기능을 지원하거나 수행하는 데 필요

- 서비스 시작 / 중지 / 재시작
- 배포, 업그레이드, 롤백 또는 핫픽스 수행
- 현재 상태 확인(업그레이드/다운그레이드/디그레이드)

티어-1: 필수 서비스

티어-1 서비스는 중요한 비즈니스, 고객 또는 제품 기능을 제공합니다. 고객 대면 서비스나 업무상 중요한 내부 서비스입니다. 서비스가 저하되거나 사용할 수 없게 되면 회사는 손해를 보거나 중요한 업무 기능을 수행할 수 없게 되거나 고객 관점에서 볼 때 핵심 기능을 상실하게 됩니다. 티어-1 서비스에는 연중무휴 지원 담당자 명단이 필요하고 주요 메트릭에 대해 SLA가 높으며 가동 요구 사항이 엄격합니다.

티어-2: 비핵심 서비스

티어-2 서비스는 핵심 기능에 속하지 않는 고객 대면 서비스를 제공합니다. 티어-2 서비스는 선택 사항이나 "있으면 좋은 것"으로 간주될 수 있는 부가 가치 또는 추가적인 사용자 경험을 제공합니다.

티어-2 서비스에는 공공 기업 웹 사이트와 같이 주로 마케팅 기능을 하는 공공 서비스가 포함됩니다. 팀이 역할을 수행하는 데 사용하는 공동 작업 도구, 업무 추적과 같은 직접적인 비즈니스급 서비스 및 내부 서비스를 고객에게 제공하지 않습니다.

티어-2 서비스에는 연중무휴 지원 담당자 명단이 필요할 수도, 그렇지 않을 수도 있고 SLA가 더 낮으며 가동 요구 사항이 더 적습니다.

티어-3: 내부 전용 또는 중요하지 않은 기능

티어-3 서비스는 회사 내부 기능이나 실험용 베타 서비스를 제공합니다. 이 클래스에는 베타 기간 동안 서비스 품질이 저하될 것으로 예상되는, 현재 얼리어답터를 위한 실험 기능인 서비스도 포함될 수 있습니다. 이 수준은 최선의 노력으로만 지원되는 서비스에 대해 낮은 SLA 버킷을 제공합니다.

데이터 손실(RPO)

이 숫자는 서비스 장애 시 서비스에서 손실되는 데이터의 최대 양입니다. 티어-0 서비스는 서비스 장애 시 1시간 미만의 데이터가 손실됩니다.

서비스 복원(RTO)

이 숫자는 서비스를 다시 가동하기까지 걸리는 최대 시간을 나타냅니다. 티어-0 서비스는 4시간 이내에 완전히 복구됩니다.

백업

서비스가 중단되면 팀이 백업을 사용하여 데이터를 특정 시점으로 복원해야 할 수도 있습니다. 정기적으로 데이터를 백업하고 복원 프로세스를 구현하고 백업 및 복원 프로세스를 정기적으로 테스트하는 것이 중요합니다. 백업 및 복원 프로세스는 신뢰성 있고 효과적이어야 합니다. 여기서 핵심 사항은 문서화 및 테스트입니다.

완료의 정의

• 백업 및 복원 프로세스 구현
• 백업 및 복원 프로세스를 문서화하고 테스트
• 백업 및 복원 프로세스를 정기적으로 테스트
  

작업 수용량 관리

서비스가 소비자에게 제공하는 용량을 명확하게 설명합니다. 특히, 서비스가 소비자에게 부과하는 제한이 있는지 확인해 줍니다. 서비스가 예상되는 제한 내에서 작동하는지 확인하기 위한 성능 테스트를 실시합니다.

테스트하고 소비자에게 제공할 정보의 예시는 다음과 같습니다.

• 서비스의 초당 요구 사항이 X개로 제한
• 서비스는 X의 응답 시간을 보장
• 서비스의 X 기능이 리전 간에 복제되거나 복제되지 않음
• 소비자는 X를 하면 안 됨
  - 서비스를 오버로드
  - X보다 큰 파일을 업로드

완료의 정의

• 서비스 제한이 식별되고 문서화됨
• 제한이 적용되는지 여부 확인하기 위한 성능 테스트를 갖춤
  

고객 인식

지원 가능성은 신뢰성, 유용성과 함께 서비스 품질에서 중요한 측면입니다. 서비스나 서비스의 새 기능이 가동되기 전에 팀이 지원 프로세스를 구축해야 합니다. 지원 가능성에는 고객 지원 프로세스, 변경 관리 프로세스, 지원 런북 및 기타 지원 중심 항목이 포함될 수 있습니다.

고객 지원 프로세스

개발자는 고객이 지원 팀에 지원을 요청하면 어떻게 되는지, 그리고 지원 프로세스에 대한 각자의 책임을 이해해야 합니다. 여기에는 대기 교대 근무를 하거나 프로덕션 문제가 발생할 때 해결 요청을 받는 것이 포함될 수 있습니다.

변경 관리 프로세스

모든 변경 사항이 고객에게 같은 방식으로 영향을 미치는 것은 아닙니다. 사소한 버그 수정과 같이 고객이 알아차리지 못하는 변경 사항도 있고 API를 완전히 다시 작성하는 것과 같이 고객이 적응하는 데 많은 노력이 드는 변경 사항도 있습니다. 변경 관리를 통해 변경 사항이 고객에게 미칠 수 있는 영향의 규모를 평가할 수 있습니다.

런북 지원

런북은 서비스 작동 방식에 대한 개략적인 개요와 발생할 수 있는 문제 및 해결 방법에 대한 자세한 설명을 제공합니다. 서비스가 변경될 때 런북을 정기적으로 업데이트하고 문서화된 지원 절차가 정확한지 확인하는 것이 중요합니다.

완료의 정의

• 지원 팀이 이슈를 조사하는 데 필요한 대부분의 질문에 답하는 문서
• 효과적인 변경 관리 프로세스
  
  

재해 복구

재해의 일부는 가용 영역을 잃는 것입니다. 가용 영역 장애 발생 시 서비스가 정상적으로 작동하려면 충분한 복원력이 있어야 합니다. 재해 복구에는 두 가지 요소가 있습니다. 첫 번째는 재해 복구 프로세스를 개발하고 문서화하는 것이고 두 번째는 문서화된 프로세스를 지속적으로 테스트하는 것입니다. 재해 복구는 정기적으로 테스트해야 합니다. 문서화된 재해 복구 계획을 사용하여 가용 영역 장애를 처리하는 능력을 테스트하세요.

완료의 정의

• DR 계획이 문서화됨
• DR 계획이 테스트됨
• DR 계획에 대한 반복 테스트가 예정되어 있음
  

로깅

로그는 이상 징후 탐지, 서비스 중단 중 또는 그 이후의 조사, 고유 식별자로 서비스 간 관련 이벤트를 연결하여 악성 활동을 추적하는 것과 같은 다양한 이유에 유용합니다. 로그에는 여러 종류가 있습니다. 대부분의 서비스에 포함해야 하는 매우 유용한 몇 가지 로그는 다음과 같습니다.

• 액세스 로그
• 오류 로그

완료의 정의

• 적절한 로그가 생성됨
• 로그는 쉽게 찾고 검색할 수 있는 곳에 저장되어 있음
  

논리적 액세스 검사

논리적 액세스 검사는 내부 사용자 액세스, 외부 사용자 액세스, 서비스 간 액세스, 데이터 암호화를 관리하는 방법에 중점을 둡니다. 서비스는 기능과 데이터에 대한 권한이 없는 액세스를 어떻게 방지합니까? 사용자 권한은 어떻게 정의, 확인, 업데이트, 지원 중단됩니까? 제어 기능이 민감한 데이터를 충분히 보호합니까?

내부 사용자

대답해야 할 중요한 몇 가지 질문은 다음과 같습니다. 내부 사용자는 어떻게 인증됩니까? 액세스는 어떻게 허가/프로비저닝됩니까? 어떻게 회수됩니까? 권한 승격은 어떻게 이루어집니까? 정기적인 액세스 검토 및 감사 절차는 어떻게 됩니까?

외부 사용자

고객 인증은 어떻게 처리됩니까? 액세스는 어떻게 허가/프로비저닝됩니까? 어떻게 회수됩니까? 권한 승격은 어떻게 이루어집니까? 정기적인 액세스 검토 및 감사 절차는 어떻게 됩니까?

서비스 대 서비스

내부 사용자 및 외부 사용자와 비슷합니다. 팀은 서비스가 서로에 대해 인증하는 방법을 결정해야 합니다. 예를 들어 OAuth 2.0을 설정하는 것이 있습니다.

암호화

팀은 미사용 시 및 전송 중 데이터를 암호화하고 싶을 것입니다. 서비스가 데이터 암호화를 어떻게 관리하는지 설명하세요. 팀은 키를 어떻게 관리합니까? 키 교체 정책이란 무엇입니까?

완료의 정의

• 내부 사용자, 외부 사용자, 서비스 대 서비스에 대한 논리적 액세스 검사가 문서화, 구현, 테스트됨
• 미사용 시 데이터 암호화
• 전송 중 데이터 암호화
• 암호화가 구현되고 테스트됨
  

릴리즈

새 버전의 서비스를 배포해도 고객 트래픽이 서비스 SLA에 정의된 것 이상으로 중단되어서는 안 됩니다. 모든 변경 사항은 동료 검토를 거쳐 CI/CD 파이프라인을 통해 테스트 및 배포해야 합니다. 배포할 때마다 배포가 성공했고 손상된 기능이 없는지 확인하세요. 배포 후 검증을 자동화하는 것이 좋습니다. 배포를 테스트할 수 있도록 테스트, 스테이징, 사전 프로덕션, 프로덕션과 같은 여러 환경을 가지세요.

완료의 정의

• 서비스에 가동 중지 시간이 없는 배포가 있음
• 프로덕션에 들어가기 전에 서비스를 배포하고 테스트해야 하는 환경이 있음
  

보안 체크리스트

보안 체크리스트는 보안 인프라와 소프트웨어를 개발하고 유지하기 위한 일련의 관행과 표준입니다. 이 표준은 개인 정보 침해와 데이터 침해 가능성을 줄이고 결과적으로 고객 신뢰 강화로 이어집니다. 팀은 구축하고 있는 서비스의 특성을 다루는 보안 체크리스트를 개발해야 합니다. 요구 사항의 몇 가지 예시는 다음과 같습니다.

완료의 정의

• 서비스에 공개적, 치명적이거나 높은 취약점이 존재하지 않음을 증명
• 모든 데이터 저장소에 미사용 시 암호화를 사용
• 서비스가 안전하지 않은 HTTP 연결을 허용하지 않음을 증명
  

서비스 메트릭

서비스 메트릭은 서비스에 대한 필수 상태 및 진단 정보를 제공하며 팀이 인시던트를 모니터링하고 여기에 대응할 수 있게 합니다. 각 서비스에 대해 모니터링되는 메트릭의 집합을 정의하는 것부터 시작하세요. 그런 다음 Datadog 또는 New Relic과 같은 도구에서 메트릭이 포함된 대시보드를 만듭니다. 메트릭이 범위를 벗어나면 알람을 울리고 알람이 발생하면 문제 티켓을 제기하세요.

완료의 정의
측정할 항목의 몇 가지 예시는 다음과 같습니다.

• 지연: 요청을 처리하는 데 걸린 시간
• 트래픽: 외부 사용자가 서비스에 가하는 부하
• 오류: 사용자에게 영향을 미치는 오류 또는 장애의 수
• 포화도: 서비스가 얼마나 바쁘며 얼마나 더 처리할 수 있는지
• 기본 리소스 사용량: CPU, 메모리, 디스크
• 큐, 타이밍, 흐름과 같은 애플리케이션 내부 요소
• 서비스의 사용량 및 핵심 기능: 활성 사용자, 분당 작업 수
  

서비스 복원력

서비스 복원력 요구 사항은 서비스가 부하의 변화 및/또는 다양한 컴포넌트의 장애를 처리할 수 있는지 여부를 결정합니다. 복원력이 뛰어난 서비스는 자동으로 규모가 조정되고 단일 노드 장애의 영향을 받지 않을 가능성이 높습니다.

자동 규모 조정

서비스에 자동으로 규모를 조정하는 기능이 있으면 자동 규모 조정이 올바르게 구성되고 테스트되었는지 확인하세요. 자동 규모 조정을 트리거하는 메트릭을 결정하고 잘 작동하는지 테스트합니다. 예를 들어 서비스에서 디스크에 데이터를 저장해야 하는 경우 디스크의 여유 공간 백분율을 모니터링하고 사용 가능한 공간이 임계값 아래로 떨어지면 저장 공간을 추가하여 자동으로 규모를 조정할 수 있습니다.

단일 노드 장애 테스트

단일 노드 장애에도 견딜 수 있는 서비스를 갖추는 것이 좋습니다. 단일 서비스 노드가 다운되어도 서비스는 계속 작동해야 하며 이때 용량이 줄어든 상태일 수 있습니다. 서비스에서 하나 이상의 노드를 종료해서 테스트해보고 시스템 동작을 관찰하세요. 서비스에서 단일 노드 장애를 처리할 것으로 예상됩니다. 단일 노드 장애를 시뮬레이션할 환경은 모니터링해야 합니다.

완료의 정의

• 자동 규모 조정이 구현 및 테스트되었다는 것이 증명됨
• 프로덕션 및/또는 스테이징 환경에서 다중 노드를 실행한다는 것이 증명됨
• 서비스가 단일 노드 장애를 견딘다는 것이 증명됨
  

지원

지원은 릴리스 이후 서비스를 지원하는 프로세스입니다. 팀은 구현 전에 런북, 운영 도구, 대기 교대 근무를 갖추고 가동해야 이슈가 발생한 서비스에서 이슈를 해결하는 프로세스를 마련할 수 있습니다.

런북

런북은 대기 중인 대응자에게 신속한 인시던트 대응 및 수정을 위한 노력을 이끄는 데 필요한 컨텍스트와 안내를 제공합니다.

운영 도구

충분한 기준에 맞춰 서비스를 운영한다는 것은 대기 중 담당자 명단이 있고 Opsgenie와 같은 운영 도구가 서비스에 이슈가 있을 때 대기 중 담당자에게 알리도록 설정되어 있다는 뜻입니다.

대기 중 담당자

티어 2 및 티어 3 서비스 - 대기 중 담당자 명단 필요

티어 1 및 티어 0 서비스 - 연중무휴 대기 중 담당자 명단 필요

완료의 정의

• 지원 팀에서 런북을 작성했으며 찾을 수 있음
• 운영 도구가 구성되고 테스트되었음
• 대기 중 교대 담당자가 마련되어 있고 이슈 발생 시 호출됨
  

티어-3에 권장되는 운영 준비성 점검

• 백업
• 로깅
• 릴리즈
• 보안 체크리스트
• 서비스 메트릭
• 지원
  

티어-3 서비스는 가장 기본적인 운영 준비성 요구 사항으로 시작합니다.

티어-2 및 티어-1에 권장되는 운영 준비성 점검

• 백업
• 재해 복구
• 로깅
• 릴리즈
• 보안 체크리스트
• 서비스 메트릭
• 서비스 복원력
• 지원

티어-2 및 티어-1 서비스에는 재해 복구 및 서비스 복원력 운영 준비성 요구 사항이 추가됩니다. 티어-2 서비스와 티어-1 서비스는 운영 준비성 요구 사항이 다를 수 있다는 점에 유의해야 합니다. 티어마다 요구 사항이 다를 필요는 없습니다. 특정 서비스 티어에 다른 운영 준비성 요구 사항이 필요하다고 생각되면 추가하세요. 팀의 필요에 따라 티어-2, 티어-1에 다르게 할 수 있습니다.

티어-0에 권장되는 운영 준비성 점검

• 백업
• 작업 수용량 관리
• 고객 인식
• 재해 복구
• 로깅
• 논리적 액세스 검사
• 릴리즈
• 보안 체크리스트
• 서비스 메트릭
• 서비스 복원력
• 지원

티어-0 서비스에는 작업 수용량 관리, 고객 인식, 논리적 액세스 검사가 추가됩니다.