DevOps 텍스트 교육
DevOps의 지속적 학습을 어떻게 지원해야 하나요?
소프트웨어 프로젝트에서 체크리스트, 동료 검토, 통제, 감사, 규정 준수 장치가 있어도 문제가 생긴다는 점을 이미 배웠을 것입니다. 피할 수 없는 일입니다. 이제 DevOps 팀과 조직이 스스로 진단하고 학습하고 개선하는 문화를 만들 때입니다. 이런 문화에서는 문제를 받아들이고 팀은 문제가 생길 때 대응할 준비가 되어 있습니다. 문제 해결은 조직의 지속적 학습과 개선에 기여하는 일상 업무여야 합니다. 문제 해결책을 DevOps 조직 전체에 투명하게 공개하고 쉽게 이용하도록 하면 그 효과가 커집니다.
선도적 DevOps 조직인 Netflix는 클라우드 데이터 센터의 치명적 장애를 모의하기 위해 내부 소프트웨어 Chaos Monkey를 만들었습니다. Chaos Monkey는 프로덕션 시스템의 서버를 무작위로 중단시켜 Netflix 팀이 복원력, 안정성 및 중단 없는 서비스 품질을 확보할 운영 능력에 더 큰 확신을 갖도록 돕습니다. 장애마다 교훈을 얻고, 이를 이용해 시스템을 더 안정적이고 복원력 있게 만듭니다.
학습 문화가 중요한 이유 이해하기
인시던트 후 서로 책임을 돌리면 엔지니어에게 두려움의 문화가 생깁니다. 조직은 느리고 관료적이며 내부 정치로 가득한 곳이 됩니다. 오류에서 의식적으로 배우거나 자연스럽게 오류에 강해지고 복구 능력을 기르며 더 주의 깊게 예방하지 못합니다. 모든 사람이 자기 방어에만 관심을 갖습니다. 업무와 문제, 해결책 자체도 완전히 투명하지 않습니다.
Because problems are inevitable in complex systems, instead of finger-pointing, blaming and shaming the ones who cause problems, your organization should value actions to make problems visible in your daily work. It should encourage organizational learnings from errors and inefficiencies, so everyone in your DevOps organization can also learn and profit from these problems, solutions and knowledge.When engineers in your DevOps organization feel safe about giving details about mistakes, they voluntarily go extra mile and spend a lot of energy to make sure that a similar problem will not happen again in their own work center and in other work centers in your organizational value stream. If engineers are punished or even if they feel that they are punished when they do mistakes, then they will be afraid of making mistakes, so
- 실수를 줄이려고 일을 덜 합니다.
- 업무, 문제, 해결책을 투명하게 공개하지 않습니다.
- 해결책을 조직의 학습으로 바꿀 동기가 없습니다.
- 문제와 해결책을 배우고 공유하고 가르치며 가시화하는 데 아무도 시간과 노력을 들이지 않으므로 같거나 매우 비슷한 문제가 다시 발생합니다.
원인에 관한 기억이 흐려지기 전에 인시던트 발생 즉시 사후 검토하기
사후 검토의 목표는 매우 간단합니다.
- 잘한 일을 파악해 비슷한 상황에서 다시 시도할 수 있게 합니다.
- 다르게 했어야 할 일을 기록해 앞으로 기법을 개선할 수 있게 합니다.
- 잘못한 일을 기록하고 다음에 비슷한 문제를 마주할 때 사용할 다른 접근 방식이나 안전 조치를 제안합니다.
- 인시던트의 원인이 된 조치를 취하거나 취하지 않는 것이 당시에는 왜 합리적이었는지 알아봅니다.
자신이 무엇을 잘못했는지 살펴보는 것은 두려운 일이며, 어떤 조직에서는 위험하기도 합니다. 실수를 인정하면 비판이나 징계에 노출되는 경우 실수를 인정하기 어렵습니다. 과거 실수를 이해하지 못하면 미래에 같은 실수를 반복하기 쉬우므로 결국 이런 방식은 역효과를 냅니다. 개선에 진지한 조직은 이 점을 이해하고, 실수를 안전하게 살펴볼 수 있는 프로세스와 문화를 만들려고 노력합니다.
사후 검토를 할 때는 몇 가지 기본 전제를 받아들여야 합니다.
- 모두가 자신이 이해한 범위에서 최선을 다하려고 합니다.
- 스트레스가 많은 상황에서 불완전한 정보로 결정을 내립니다.
- 훈련받지 않은 일을 그때 손에 있는 도구와 자원으로 수행하라는 요청을 자주 받습니다.
- 이런 상황에서 실수는 불가피합니다.
- 이 절차의 목표는 일어난 일을 살펴보고 어떤 교훈을 얻을지 파악하는 것입니다. 개인이나 행동의 잘못을 찾는 것이 아닙니다.
- 이 절차는 개인이나 집단이 아니라 프로세스와 이를 개선하는 방법을 평가하는 결과를 냅니다.
관련된 모든 사람이 다음의 ‘비난하지 않고 배우는 방식’을 온전히 받아들이는 것이 필수입니다. 많은 조직이 이런 안전한 환경을 만들기 위해 큰 노력을 기울입니다. 예를 들어 FAA는 항공 안전 보고 시스템을 운영하여 ‘실수’한 조종사가 해당 인시던트를 보고하면 규제 당국의 징계를 면할 수 있게 합니다.
사후 검토에서는 인시던트의 재발을 막을 실행 가능한 조치를 항상 정해야 합니다. 텔레메트리 지표 및 자동화된 테스트 케이스 추가, 코드 검토가 더 필요한 변경 유형의 식별, 코드 리팩터링, 문제가 잦은 복잡한 시스템 구성 요소의 분리 등이 예방 조치의 예입니다.
사후 검토 기록과 교훈을 조직 전반에 널리 공유하세요. 가치 흐름의 한 작업 단계에서 배운 내용을 조직 전체의 학습으로 바꿀 수 있습니다. 이는 투명성과 개방성, 학습 문화를 키우자는 분명한 메시지가 됩니다.
시스템을 개선하기 위한 장애 모의 훈련일 운영하기
장애 모의 훈련일은 외향적인 사람만 즐기고 내향적인 사람은 시간을 보내려고 휴대전화만 보는 지루한 팀 행사가 아닙니다.
장애 모의 훈련일에는 테스트 시스템에서 치명적 장애를 모의합니다. DevOps 팀은 장애를 수정하고 그로부터 배웁니다.
예를 들어 핵심 서버 하나를 종료해 서비스가 중단되지 않고 장애 조치가 제대로 작동하는지 확인합니다. 이어 백업이나 코드형 인프라(IaC)를 통한 복구 방식이 작동하는지, 어떻게 작동하는지 검증합니다. 이러한 장애 상황에서 문제를 찾아내면 복원력과 내결함성을 갖춘 시스템을 구축하고 교훈을 얻는 데 도움이 됩니다.
문제를 해결하는 과정에서 부담이 없는 조건으로 장애를 연습하며 다른 부서와 관계를 쌓습니다. 더 큰 글로벌 조직 안에서 의사소통과 문제 해결 절차를 시험하고 이를 개선할 기회를 눈으로 확인합니다.
나중에 드러날 더 큰 문제의 약한 신호도 볼 수 있습니다. 장애 상황에서 자주 발생하는 낮은 우선순위 인시던트나 다른 핵심 구성 요소를 거의 중단시킬 뻔한 작은 부작용이 여기에 해당합니다. 시스템을 개선하려면 이러한 신호를 살펴보고 해결해야 합니다.
결론
DevOps 팀에서 신중하게 판단한 위험을 감수하도록 장려하세요. 여러분과 같은 고성과 DevOps 조직은 더 자주 실수합니다. 이는 괜찮을 뿐 아니라 조직이 배우고 더 나은 성과를 내려면 필요한 일입니다.
고성과 조직은 일반 조직보다 프로덕션 시스템의 심각한 장애가 80% 적습니다. 즉, 고객에게 영향을 미치는 인시던트가 5분의 1에 불과합니다. 따라서 엔지니어가 실수를 두려워하지 않고 그로부터 배울 수 있어야 합니다.
