데브시스터즈의 장애 대응 원칙과 방법

안녕하세요, 저는 데브시스터즈 기술본부 인프라셀에서 DevOps 엔지니어로 일하고 있는 이창원입니다. 이 글에서는 데브시스터즈에서 전사적으로 적용하고 있는 기술적 관점에서의 장애 대응 원칙과 방법 전문을 공개합니다.

문서에 대한 설명은 데브시스터즈 엔지니어링데이 Infra/SRE 세션에서 소개해드릴 예정입니다. 추후 영상 업로드를 기다려 주세요!

개요

이 문서는 우리가 운영하는 각종 서비스의 장애에 대한 탐지, 대응, 예방을 위해 가져야 할 자세와 방법론에 대해 서술합니다.

원칙

📌 이 원칙들은 구성원들이 상시 장애 상황을 모니터링하라는 의도에서 만들어진 것이 아니며, 꼭 필요한 순간에만 기민한 대응을 할 수 있도록 원칙과 방법을 설정한 것입니다.

📌 모두가 기본적인 응급 조치를 할 수 있는 역량을 확보해야 합니다. 그래야 담당자가 쉬거나 부재 중이더라도 다른 사람이 대응할 수 있고, 서로를 믿고 편하게 쉴 수 있습니다.

[장애 대응의 목표] 장애 대응의 최우선 목표는 서비스가 가능한 정상적으로 동작하게 하는 것입니다.
- 지식이나 경험의 많고 적음에 관계 없이, 서비스 담당자인지 아닌지에 상관 없이 대응이 가능한 사람이라면 그 자리에서 할 수 있는 최선의 노력을 통해 문제 해결에 적극적으로 기여해야 합니다.
- 문제의 원인을 찾아 내려가는 것에만 집중해서는 안됩니다. 개발자라면 문제 발생 시 원인을 파내려가고 싶다는 걸 이해합니다. 그러나 비행 중 문제 발생 시 가장 먼저 할 것은 승객들이 안전하게 대피할 수 있도록 비행기를 잘 착륙시키는 것입니다.
- 스스로 알고 있는 지식으로 문제를 빠르게 해결할 수 있을지 판단해야 하며, 어려울 것 같은 경우 다른 사람에게 부탁해야 합니다.
[에스컬레이션과 상황 전파] 필요할 경우 적극적으로 도움을 요청해야 합니다.
- 장애가 발생한 사실을 뒤늦게 깨닫는 것보다는, 오탐이라도 장애 상황을 의심하고 다시 한 번 점검하는 것이 훨씬 더 좋습니다. 장애 인지를 했는데 이게 장애인지 아닌지, 어떻게 해야 할지 판단이 안 서는 경우에는 시간 장소 관계 없이 즉시 다른 사람들을 부르도록 합시다.
- 호출을 받는 사람은 이런 종류의 호출에 기분 나빠하거나 부담스러워하지 말고, 이런 호출이 있을 수 있다는 사실을 인지하고 문제를 같이 파악합니다.
- 같은 사람을 호출하는 상황이 반복된다면 해당 알람 관련 맥락을 다른 사람에게 잘 전파해주고 있는지를 점검해 보아야 합니다.
[장애 대응을 위한 환경 준비] 장애에 대응할 수 있도록 적절한 장비와 세팅을 최대한 유지합니다.
- 랩탑을 항상 휴대합니다. (사전에 입사자의 멘토가 랩탑 장비 신청 시 휴대성을 고려하여 신청하는 것을 권장합니다)
- 언제든 대응할 수 있도록 랩탑에도 평소 개발/운영 환경(Wireguard, SSH, AWS Console, kubectl, 간단한 스크립트 등)을 셋업하고, OS 버전업/기기 변경 등 다양한 변화에도 항상 잘 동작하게끔 준비하여야 합니다.
- Wi-Fi가 없는 환경에서도 대응할 수 있도록 사용하는 개인 폰에 테더링 환경(요금제 포함)을 구축하거나, 여의치 않은 경우 회사로부터 LTE 모뎀 / LTE 법인폰 등을 지급받아 준비합니다.
[장애 감지의 방법] 장애를 감지할 수 있는 알람 시스템을 구축하고 모두가 받을 수 있도록 항상 준비합니다.
- 장애 슬랙 채널의 알람은 티어에 맞게 Notification 설정을 All new messages 로 설정, 문제를 빠르게 인지할 수 있도록 합니다.
- 장애 문자, 전화 발신자는 Do not Disturb(방해 금지) 예외로 설정해둡니다.
- 적절한 티어링 체계를 갖추면 알람 체계를 잘 유지할 수 있습니다. 문서의 아래 항목에서 그러한 티어링 방안을 제안하고 있으니, 그에 맞춰서 알람 시스템을 정비하길 권장합니다.
[알람 건전성] 모든 알람은 약식으로라도 대응을 하여야 합니다.
- Feed 채널과 알람 채널의 목적은 다릅니다. 확인 결과 대응이 필요하지 않은 알람이었을 경우 알람 조건 수정, 티어 재배치 등을 진행합니다.
- 양치기 소년 이야기의 교훈을 인지해야합니다. 알람을 보고 2차적인 판단을 거쳐 대응하지 않는 케이스가 생기게 되면 이후 심각한 문제 발생 시에도 제대로 대응하지 못하는 경우가 있을 수 있으며, 새로운 사람이 맥락을 따라가기도 어렵게 됩니다.
- 알람에 대응하는 방식에는 여러가지가 있을 수 있습니다. 인지하였음을 스레드로 메시지를 남기거나, 관련한 이슈를 생성하거나, 알람 조건을 조정하고자 하는 논의를 시작하는 등 비교적 낮은 적극성의 액션부터 장애 선언을 하는 높은 적극성의 액션까지가 모두 포함됩니다.
[기록과 커뮤니케이션] 장애 대응 중 실행된 액션들은 객관적으로 공유되어야 합니다.
- 수행하는 조치가 멱등하지 않을 수 있으므로 시스템에 대한 변경 내역은 장애 대응에 참여하고 있는 사람들에게 반드시 공유되어야 하며, 채팅 메세지 혹은 장애 대응 문서에 판단 근거, 조치 시간과 함께 기록을 남아야 합니다.
- 장애 상황에서 조치 내용은 시스템에 대한 이해를 바탕으로 문제 해결을 위한 가설을 세우고, 이를 시험하기 위해 실행한 작업이 실제 안정화에 도움이 되는지 확인하는 과정을 거치기 때문에, 엔지니어로서의 역량을 빠르게 성장시킬 수 있는 기회이기도 합니다. 기록을 잘 남겨둘수록 장애 대응에 참여하지 않았던 다른 구성원들의 역량 강화에도 도움이 되며, 이는 우리가 더 견고한 팀이 되는 가장 효율적인 방법입니다.
- 장애 대응에 반드시 기술 직군만 개입하는 것이 아니므로, 유관 부서에 커뮤니케이션할 때에는 기술적 배경이 적은 사람들도 이해할 수 있도록 작성하는 것을 권장합니다.
[장애 회고의 중요성] 모든 인프라는 다양한 이유로 장애가 날 수 있지만, 같은 이유로 같은 장애를 겪는 것은 우리의 잘못입니다.
- 장애 원인과 조치 내용을 기록으로 남기고 동일한 유형의 장애를 예방할 수 있는 방법을 모색합니다.
- 되짚어볼 필요가 있는 장애라면 업무시간 중 시간을 잡아 포스트모템을 진행합니다. 포스트모템에서의 논의가 건설적일 수 있도록 사전에 논의할 내용은 미리 작성해두도록 합니다.
- 장애 회고 미팅의 참여자들은 비난하지 않는 포스트모템이 될 수 있도록 주의를 기울여야 합니다. 이를 위해서는 장애 대응 과정 중의 모든 조치들이 각자의 상황에서 최선을 다했음을 신뢰하여야 합니다. 만약 결과적으로 잘못된 의사결정 혹은 실수가 있었더라도, 그러한 결과로 이어지게 된 시스템적 원인에 대해 논의할 수 있어야 합니다. 어떠한 실패라도 시스템을 강화할 수 있는 기회로 이어질 수 있습니다.

알람 티어링 권장 체계

알람을 분류할 때 최초 대응 시간(FRT, First Response Time: 문제 상황을 인지하고 파악하는 시작 시점) 을 기준으로 삼을 것을 권장합니다. 대응의 완료를 포함하는 시간이 아닌, 최초 인지 및 파악을 시작하기까지의 시간을 말합니다.

알람을 설정할 때 가급적 알람이 울린 채널만 보고 바로 대응 조치가 필요한지를 직관적으로 알 수 있도록 설정하는 것이 좋습니다.

아래 장애 유형에 부합하지 않는 알람이 있다면, 팀에서 FRT 기준에 맞게 자율적으로 판단하여 적절한 티어에 추가할 수 있습니다.

[Tier 0] 언제든지 대응해야 하는 최우선순위 알람 (<~ FRT 15min)

티어 정의
- 고객이 체감 가능한 문제가 발생하거나, 또는 서비스와 연관된 내부 컴포넌트의 안정성에 위험이 발생하는 경우입니다. 진행 중인 대부분의 일상 업무보다 높은 우선순위를 가지고 최대한 빠르게 대응합니다.
장애 인지
- 시스템을 통한 문제별 주요 담당자에게 전화, 문자
- Tier 0 알람 채널으로의 메시지 수신
  만일 Tier 0수준의 장애에 대하여 위와 같은 시스템을 통한 선제적 인지를 하지 못하고 사람에 의한 인지나 우연에 기반한 파악을 하였다면, 모니터링 체계의 정비가 필요함을 의미합니다.
장애 유형
- 유저가 체감할 수 있는 이상 징후가 발생하는 경우
  - e.g., API failure rate N% 증가, Latency XXms 지연 등
- 시스템의 일부가 복구 불가능한 상황을 맞이하여 시스템 자체 안전성에 대한 위험이 예상되는 경우 (당장의 문제가 일어나지 않는 경우를 포함 e.g., HA 구성된 시스템의 일부 장애)

[Tier 1] 최선의 속도로 대응해야 하는 차순위 알람 (FRT 평일 <~ 15m, 밤일 경우 다음날 오전까지인 약 12h)

티어 정의
- Tier 0과 같은 직접적인 영향은 감지하지 않았지만 기술적인 연관성을 통해 Tier 0으로 퍼질 수 있는 경우입니다. 업무 시간 중에는 Tier 0과 같은 수준의 경각심과 우선순위로 빠르게 대응하나, 늦은 밤에 일어날 경우 다음날 오전에 확인하는 것을 목표로 합니다.
장애 인지
- Tier 1 알람 채널으로의 메시지 수신
  Tier 1도 Tier 0과 마찬가지로, 시스템을 통한 선제적 인지를 하지 못하고 사람에 의한 인지나 우연에 기반한 파악을 하였다면 모니터링 체계의 정비가 필요합니다.
장애 유형
- Tier 0 문제로 발전할 가능성이 있는 기술적 문제
  - e.g., CPU Usage X% 이상 사용, DB latency API XXms 지연, 어플리케이션의 재시작 등
  - e.g., Atlantis(인프라 배포 툴), Vault(사용자 인증), 사내 운영툴 장애 등

[Tier 2] 즉각적인 대응이 필요하지는 않지만 개입을 필요로 하는 알람 (FRT 평일 <~ 2~3h, 밤이나 주말일 경우 다음 업무일)

티어 정의
- 작업자의 개입이 필요하지만, 작업의 마감이 여유롭게 설정되었거나 또는 서비스 내외부적으로 직접적인 영향을 미치지 않아 시급성은 낮춰 대응해도 되는 경우입니다. 최대 1업무일 이내에 문제 해결계획을 수립하며, 실제 대응 작업을 더 늦게 진행할 경우 진행상황을 파악할 수 있도록 작업 티켓 등으로 기록을 남겨두는 것을 목표로 합니다.
장애 인지
- Tier 2 알람 채널으로의 메시지 수신
장애 유형
- 충분한 마감기한이 주어지는 작업
  - e.g., 인증서 만료, AWS instance retirement, AWS API deprecation
- 주기적으로 문제를 인지하여 대응이 필요한 작업
  - e.g., 정책적인 위반사항
- 비용에 대한 알람
  - e.g., 데이터독 사용량, cost enforcer

효과적인 장애 대응 방법

💡 이 내용은 모든 것을 반드시 지켜야 한다기보다는 일종의 가이드라인입니다.

실제 장애 발생시 큰 틀 (장애 발생 공유 → 팀 구성 → 해결 → 종료 공유) 을 해치지 않는 선에서 융통성 있게 적용하시되, 포스트 모템을 진행할 때 어떤 것들이 어떤 이유로 가이드라인과 달라졌는지 설명해주세요.

아래의 예시를 따라 장애를 대응하면 보다 문제를 효과적, 효율적으로 대응할 수 있습니다.

이 내용은 가장 심각도가 높은 장애 상황을 가정하여 작성되었으므로 모든 장애 상황을 아래와 같이 대응하진 않아도 되고, 상황에 따라선 일부 항목을 생략할 수 있습니다.
위 티어링 체계 기준으로 Tier 0 및 1의 문제는 아래같이 대응하면 효과적입니다.

장애 최초 전파 및 대응 팀 구성
- 장애를 인지한 모든 인원은 즉시 팀 채널에 장애를 인지하였음을 알려야 합니다.
- 이후 장애 대응 팀을 구성합니다. 장애 대응 팀은 최소 2인 이상으로 구성함을 원칙으로 합니다.
- 장애 대응 팀은 지휘자와 기록가 역할 포함하도록 구성합니다.
- 각 역할은 특정 사람에게 명확하게 할당되어야 합니다.
  - ㅇㅇ님은 장애 기록 해주실 수 있을까요? 장애 문제는 제가 정리할게요
  - ㅁㅁ님은 서버 증설 준비해주세요
각 역할에 따라 해야 할 일은 다음과 같습니다.

A. 공통
- 장애 발생 원인 및 해결 방안을 탐색합니다.
- 의심이 되는 지점을 발견하면 다른 사람들에게 캡쳐나 링크 등의 근거자료와 함께 공유합니다.
- 장애 대응 과정에서 모든 의사 결정은 논의 하에 함께 수행합니다.
- 장애가 종료된 후, 포스트 모템 문서를 정리하여 공유합니다.
B. 지휘자
- 장애 상황을 주도적으로 파악하고, 대응 팀을 구성하여 역할을 분배합니다.
- 보통은 최초 인지자가 지휘자를 담당하는 경우가 많으며, 상황에 따라서 더 적절한 대상자가 있으면 다른 사람에게 지휘자를 인계할 수 있습니다.
- 추가 인원이 필요한 경우 다른 구성원들에게 적극적으로 연락하여 대응을 요청합니다.
  - 특히 문제 해결에 어려움을 겪을 경우, 혼자서 고민하지 말고 최대한 빨리 다른 사람들의 도움을 요청하도록 합시다.
  - 상황에 따라선 주 담당자 외에 외부의 인원이 문제를 함께 보는 것이 도움될 수 있습니다. (e.g., 인프라셀, 제품 팀 엔지니어, 동일 직군 다른 부서의 사람들, 그룹장 등)
- 대부분은 공동작업이 가능하나, 논의가 필요한 사항이 있다면 지휘자가 적극적으로 검토하고 결정합니다.
C. 기록가
- 원인, 고려한 해결 방안, 실제로 실행한 해결 방안 등 모든 것을 그 때 그 때 시간 순서로 기록합니다.
  - 각자가 의심하는 지점 및 장애 조치 내용은 각자가 직접 공유해주는 것이 원칙이며, 기록가는 그 내용들을 정리하고 수합하는 것이 주 목적입니다.
  - 장애 복구에 성공적인 시도만 기록하는 것보다는 실패했던 시도도 기록하는 것이 나중을 위한 자산이 됩니다.
- 장애 시점의 각종 모니터링 지표, 자료, 그래프, 로그 등을 보이는 대로 모두 모아 가능한 실시간으로 기록합니다. 실시간으로 기록이 정리되면 문제가 복잡해져 여러 사람의 개입이 필요한 경우 정보 전달 속도에 이점이 생깁니다.
- 장애 상황의 공유를 주로 담당합니다. 장애가 길어지는 경우에는 (30분 이상 소요되는 경우) 대응 현황, 예상 복구 시간을 공유합니다. 주기적으로 계속 업데이트합니다. 종료된 후에도 공유합니다.
장애 대응 채널 구성
- 지휘자는 Datadog Incident 기능을 사용하여 장애를 선언하고, 별도의 장애 대응 채널을 구성합니다. 장애를 선언하는 방법은 다음과 같습니다.
  - https://app.datadoghq.com/incidents/new 를 통해 UI에서 선언
  - 슬랙의 장애 인지 채널에서 /datadog incident 명령어를 사용하여 선언
- Incident를 선언하면 해당 incident 전용 채널이 생성됩니다. 장애 대응에 관여하는 모든 인원은 해당 채널에서 커뮤니케이션합니다.
- 화면공유를 위해 Slack huddle 또는 Google Meet 등을 개설해도 되지만, 주 커뮤니케이션은 슬랙 메세지를 이용해 추후 타임라인 분석이 용이하도록 잘 기록합니다.
장애 발생 공유
- 기록가가 장애 상황에 대해 인지한 즉시 슬랙을 통해 공유합니다. 만일 유관 부서와도 연관되는 내용이라면 메일 등 적절한 수단을 통해 유관부서로도 공유합니다. 공유 시에는 다음 내용이 들어가야 합니다.
  - 서비스 명
  - 발생 시간
  - 장애 규모와 범위
  - 장애 대응 채널
  - 장애 발생 메시지 예시:
    
    장애@ 쿠키런 킹덤 PVP 부분 장애
    
    조금 전 8월 11일 새벽 2시 35분경 부터 쿠키런 킹덤 PVP 서비스에 장애가 관측되고 있습니다. 약 25% 정도의 접속자가 영향을 받은 것으로 추정되고 있습니다. 용감한 쿠키, 명랑한 쿠키 2인이 #incident-XY 채널에서 대응 중이며, 추후 경과는 다시 공유드리겠습니다.
장애 원인 파악 및 해결
- 장애 대응은 기본적으로 원인 파악 → 해결 방안 탐색 → 해결 방안 시행 → 해결 여부 확인의 과정으로 진행됩니다.
- 앞서 명시한 장애 대응 원칙에 따라, 사용자들이 서비스 이용에 영향을 받는 상황이라면 근본 원인을 찾는 것보다 서비스를 가능한 빨리 복구하는 것을 우선시하여 대응해야 합니다.
  
  ⚠️ 어떠한 변경 작업 진행 시에는 반드시 작업 내용을 공유하여 함께 진행합니다.
  
  시스템에 따라 멱등성이 보장되지 않을 수도 있으므로 일관성을 위해 시스템 변경은 1인이 진행해야 합니다. 그러나, 이 1인이 독단적으로 시스템을 변경해서는 안됩니다.
  
  위급한 상황에서 개인이 단독으로 대응하는 것은 구성원 간 맥락의 전파를 저해할 뿐더러 긴급한 순간에서 빠르게 결정된 사항으로 더 나쁜 결과로 이어질 수 있습니다. 따라서 변경 작업 진행 시에는 커뮤니케이션을 통해 작업 내용을 같이 리뷰해나가며 진행하는 것이 우리의 방침입니다.
장애 종료 공유
- 장애 종료 메시지를 공유하는 것도 장애 대응의 일부입니다. 장애 대응이 끝나면 명확한 종료 선언을 하여 혼란을 방지합니다.
  - Root cause 분석이 끝나지 않았더라도, 일단 당장의 문제가 해결되면 장애 상황은 종료된 것입니다.
- 장애 상황이 종료되면 장애 상황 종료에 대해 슬랙을 통해 공유합니다. 공유 내용으로는 다음 항목을 포함하여 작성해야 합니다.
  - 장애 종료 시간
  - 장애 발생 (추정) 원인
  - 조치 내역 혹은 해결 방안
  - 포스트모템 미팅 일시
  - 장애 종료 메시지 예시:
    
    장애@ 쿠키런 킹덤 PVP 부분 장애
    
    2시 55분경 안정화되었습니다. PVP 서버 4대 중 1대에 이상이 생겨 해당 서버에 접속한 유저들에게 장애가 있었던 것으로 추정됩니다.
    
    대응 조치로 해당 서버를 서비스에서 제외하고 새 서버 1대를 추가하였습니다.
    
    서버에 왜 갑자기 이상이 생겼는지는 내일 중으로 추가 조사를 진행할 예정입니다.
    
    장애 포스트모템은 내일 오후 3시에 퓨어바닐라왕국 연회장 회의실에서 진행하겠습니다.
- 후속 액션을 위해 다양한 직군이 관여되어야 할 수 있으므로 장애 종료 공지를 할 때에는 가급적 프로그래머가 아닌 직군들도 이해할 수 있는 표현을 사용하고, 자세한 기술적인 내용이 궁금하면 포스트모템을 참고하도록 안내합니다.
- 장애 종료가 공유되면 지휘자가 Datadog incident status를 조정합니다.
  - 포스트모템 미팅이 예정되어 있을 경우: Active → Stable
  - 포스트모템 미팅이 예정되어 있지 않을 경우: Active → Resolved
포스트모템 준비
- 효율적인 포스트모템을 위해 논의가 필요한 내용, 대응 과정을 미리 갈무리 해둡니다.
  - 지휘자는 포스트모템 준비, root cause 분석, root cause 해결 등의 남은 작업을 특정 사람에게 명확하게 할당합니다.
- 포스트모템 템플릿을 참고하여 정보를 수집합니다.
- 포스트모템 문서 작성의 주 담당은 장애 대응 당시 지휘자였던 사람이 맡습니다.
  - 지휘자가 작성을 온전히 다 하는 것은 아니고, 다른 사람에게도 도움을 받을 수 있습니다.
  - 그러나 작성 진행 상황을 체크하고 잘 작성될 수 있도록 drive하는 것은 지휘자의 역할입니다.
  - 기록가의 기록을 잘 참고하고, 슬랙 히스토리와 대조하여 보충할 내용을 추가합니다.
- 당시 시스템의 상황을 잘 알 수 있도록 대시보드도 캡처해옵니다.
포스트모템 미팅
- 가까운 업무일에 포스트모템 미팅을 진행합니다. 진행 시에는 아래와 같은 항목들을 고민합니다.
  - 장애 대응 팀 뿐 아니라 관련된 구성원이 있다면 모두 소집합니다. 미팅에 초대받지 못하였더라도 관심있는 구성원들이 참여할 수 있도록 미팅 링크를 미팅 시작 시간에 공유합니다.
  - 장애 대응 과정에 대해 리뷰하고 놓친 것은 없는지 공유합니다.
  - 앞으로 같은 장애를 겪지 않도록 액션 아이템을 정리하고 계획을 수립하여 실행합니다. 근본적인 문제 파악에 대해서는 5 Whys 같은 좋은 방법들이 있으니 참고합니다.
- 미팅이 끝나면 포스트모템 문서 형태로 정리하여 공유합니다.
  
  ⚠️ 포스트모텀 미팅은 형식적인 자리여서는 안됩니다. 미팅이 끝나면 아래 질문에 답할 수 있도록 적극적으로 논의되어야 합니다.
  
  오늘 미팅 이후, 같은 문제가 안 생긴다 / 마주했을 때 잘 대처할 수 있다는 자신감이 드나요?

포스트모템 문서 양식

YYYY/MM/DD AAA로 인한 BBB 장애

(장애 대응 원칙과 방법 문서로의 링크)

[장애 대응의 목표] 장애 대응의 최우선 목표는 문제를 정상화하는 것입니다.

Summary

해당 장애를 요약합니다.

Impact

해당 장애로 발생한 영향을 기술합니다.

Root Causes

해당 장애가 발생한 근본적 원인을 기술합니다.

Trigger

해당 장애가 촉발된 직접적 원인을 기술합니다.

Resolution

해당 장애를 어떻게 대응하고 해결 하였는지 기술합니다.

Detection

해당 장애를 어떻게 감지 하였는지 기술합니다.

Timeline

"[시간] 사건에 대한 기술"을 시간 순으로 기록합니다.

Discussion

포스트모템 미팅을 진행하며 서로를 비난해서는 안됩니다.

포스트모템 미팅을 마치면 아래 질문에 답할 수 있어야 합니다.

같은 문제가 생기지 않는다 / 마주했을 때 잘 대처할 수 있다는 자신감이 드나요?

포스트모템 미팅에서 논의할 만한 주제들을 미리 기록해두고, 미팅 내용을 속기합니다.

Lesson Learned

잘 된 일
- 이번 대응에서 잘 된 것을 기술합니다.
잘 안된 일
- 이번 대응에서 잘 되지 않은 것을 기술합니다.
운이 좋았던 일
- 이번 대응에서 운이 좋았던 것을 기술합니다.

Action Items

해당 장애를 위해 앞으로 개선해야 할 것을 구체적으로 기술합니다.

💁 앞으로 같은 문제가 생기지 않는다 / 마주했을 때 잘 대처할 수 있다는 자신감이 드나요?

데브시스터즈는 최고의 인재를 찾고 있습니다.

데브시스터즈에서는 능력있는 SRE/DevOps Engineer를 찾고 있습니다.

자세한 내용은 채용 사이트를 확인해 주세요!

채용 바로가기