프로덕션에서 문제 해결 속도를 높이는 7가지 디버깅 기술

애플리케이션에 프로덕션 지원을 제공하는 것은 소프트웨어 개발에서 가장 어려운 측면 중 하나입니다. 개발자는 유지 관리 팀에 할당되어 애플리케이션의 버그 패치 작업을 수행합니다. 그러나 생산 중단이 발생하는 경우에도 대기 중으로 사용할 수 있으며, 이 경우 가능한 한 빨리 애플리케이션을 정상 상태로 되돌리기 위해 노력합니다.

이 문서는 프로덕션에서 버그를 방지하고 훨씬 더 빠르게 문제를 찾을 수 있도록 선별된 권장 사항 세트를 제공하는 것을 목표로 합니다. 프로덕션 환경에서 이러한 애플리케이션을 처리하는 것은 복잡한 작업입니다. 사용할 수 있는 문서가 없거나 애플리케이션이 레거시 기술 스택으로 작성되었거나 둘 다인 경우가 많습니다. 교육 세션이 거의 없으며 거의 ​​알지 못하는 응용 프로그램에 대한 지원을 제공하기 위해 전화를 받는 것이 일반적입니다.

많은 개발자가 프로덕션 환경에서 애플리케이션을 처리한 경험이 없습니다. 버그와 가동 중단을 유발하는 프로덕션 환경에서 발생하는 일련의 문제가 있으며 일반적으로 회사에 수천, 때로는 수백만 달러의 수익 손실이 발생합니다. 게다가 대부분의 개발자는 환경에 노출되지 않기 때문에 몇 가지 실수를 계속해서 문제를 일으킬 수 있습니다. 이 팁 목록은 생산 경험을 가르침으로써 작업을 덜 고통스럽게 만들 것입니다.

팁 #1: 애플리케이션을 실행하는 데 필요한 모든 구성을 제거하거나 자동화하십시오.

새 서버에 소프트웨어를 설치하려면 얼마나 많은 구성이 필요합니까? 과거에는 팀에 새 개발자가 있을 때마다 완료하는 데 3일이 소요되기도 했습니다. 응용 프로그램을 설치하려면 수동으로 수행해야 하는 많은 단계가 필요합니다. 시간이 지남에 따라 소프트웨어는 해당 지침과 호환되지 않는 새 버전으로 발전하고 물론 지침은 일반적으로 업데이트되지 않습니다. 갑자기 응용 프로그램을 시작하고 실행하는 데 필요한 것보다 훨씬 더 많은 시간을 소비하게 됩니다.

컨테이너화의 도래로 인해 구성이 필요 없고 Docker 이미지가 자체 포함되므로 훨씬 더 낮은 다른 버전의 운영 체제, 언어 및 사용된 프레임워크에서 문제가 발생할 위험이 있습니다.

마찬가지로 개발자 설정을 단순화하여 IDE 설정을 포함하여 시작하고 실행하는 데 많은 시간이 걸리지 않습니다. 개발자는 30분 이내에 0에서 영웅이 될 수 있어야 합니다.

생산 문제가 발생하면 때로는 최고의 전문가가 없을 수 있으며(예: 휴가 또는 질병) 문제를 제기하는 사람이 문제를 신속하게 해결할 수 있기를 원합니다.

팁 #2: 기술 스택 수프 함정에 빠지지 마십시오.

사용된 기술은 적을수록 좋습니다. 물론 때로는 작업에 적합한 도구를 사용해야 합니다. 그러나 "올바른 도구"에 과부하가 걸리지 않도록 주의하십시오. 식수조차도 너무 많이 마시면 ​​심각한 건강 문제를 일으킬 수 있습니다. 기술 스택에 추가된 모든 새로운 언어와 프레임워크는 영향을 신중하게 고려하여 명확하게 정의된 의사 결정 프로세스를 거쳐야 합니다.

• StringUtils 클래스가 필요하다는 이유로 새 프레임워크 종속성을 추가하지 마십시오.
• 파일을 이동하기 위해 빠른 스크립트를 작성해야 한다고 해서 완전히 새로운 언어를 추가하지 마십시오.

라이브러리가 호환되지 않거나 프레임워크 자체 또는 전이적 종속성에서 보안 위협이 발견될 때 큰 종속성 더미는 삶을 비참하게 만들 수 있습니다.

또한 스택 복잡성이 추가되어 팀을 위해 새로운 개발자를 찾고 교육하는 것이 어렵다는 점을 기억하십시오. 사람들은 다른 회사에서 새로운 역할로 이동하고 새로운 역할을 찾아야 합니다. 이직률은 엔지니어링 팀에서 매우 높으며, 심지어 훌륭한 특전과 일과 삶의 균형을 제공하는 것으로 알려진 회사에서도 마찬가지입니다. 가능한 한 빨리 새 팀원을 찾고 싶습니다. 기술 스택 위에 추가되는 모든 새로운 기술은 새 후보자를 찾는 데 걸리는 시간을 늘리고 새 직원을 점점 더 비싸게 만들 가능성이 있습니다.

팁 #3: 로깅은 쓸모없는 세부 사항으로 당신을 익사시키지 않고 문제를 찾을 수 있도록 안내해야 합니다.

로깅은 주석과 매우 유사합니다. 모든 중요한 결정과 디버깅 기술에 사용할 모든 정보를 문서화해야 합니다. 간단하지는 않지만 약간의 경험이 있으면 프로덕션 중단의 몇 가지 가능한 시나리오를 매핑한 다음 최소한 그것을 해결하는 데 필요한 로깅을 입력할 수 있습니다. 물론 로깅은 어떤 문제가 나타나는지에 따라 코드베이스와 함께 진화합니다. 일반적으로 말해서, 80%의 로깅이 코드의 가장 중요한 20%, 가장 많이 사용될 부분에 있어야 합니다. 예를 들어 중요한 정보는 메서드에 전달된 인수의 값, 자식 클래스의 런타임 유형, 소프트웨어가 취한 중요한 결정, 즉 기로에 서 왼쪽 또는 오른쪽을 선택하는 시간입니다.

팁 #4: 예기치 않은 상황에 대처하십시오.

코드의 가정이 무엇인지 매우 명확하게 매핑하십시오. 특정 변수가 항상 2, 5 또는 7 값을 포함해야 하는 경우 int가 아닌 enum 유형인지 확인하십시오. 대규모 생산 중단의 가장 큰 원인은 특정 가정이 실패할 때입니다. 모두가 몇 가지를 당연하게 여기기 때문에 엉뚱한 곳에서 문제를 찾고 있습니다.

가정은 명시적으로 문서화되어야 하며 이러한 가정에 대한 모든 실패는 생산 지원 팀이 상황을 신속하게 수정할 수 있도록 충분한 경보를 발생시켜야 합니다. 데이터가 유효하지 않은 상태가 되지 않도록 하거나 최소한 그러한 경우 일종의 경고를 생성하는 것을 방지하는 코드도 있어야 합니다. 특정 정보를 하나의 레코드에 저장해야 하는데 갑자기 두 개의 레코드가 있는 경우 경고가 발생해야 합니다.

팁 #5: 고객에게 발생한 문제를 재현하는 것은 간단해야 합니다.

가장 어려운 단계 중 하나는 항상 고객이 직면한 문제를 복제하는 것입니다. 많은 경우 문제를 복제하는 데 95%의 시간을 할애하고 문제를 복제할 수 있는 순간 패치, 테스트 및 배포하는 데 몇 분 만에 문제가 발생합니다. 따라서 애플리케이션 설계자는 문제를 매우 간단하고 빠르게 복제할 수 있도록 해야 합니다. 고객이 처한 동일한 상황에 도달하기 위해 개발자는 상당한 양의 애플리케이션 구성을 수행해야 하기 때문에 이러한 일이 많이 발생합니다. 고객이 처한 상황을 복잡하게 만드는 많은 기록이 저장되어 있습니다. 문제는 개발자가 고객이 무엇을 했는지 정확히 추측해야 한다는 것입니다. 그리고 때때로 그들은 일련의 단계를 수행했는데 그 중 마지막 단계만 기억합니다.

또한 고객은 비즈니스 용어로 문제를 설명하고 개발자는 이를 기술 용어로 번역해야 합니다. 그리고 개발자가 응용 프로그램에 대한 경험이 적다면 아직 누락된 세부 정보조차 모르기 때문에 누락된 세부 정보를 요청해야 하는지 모릅니다. 전체 프로덕션 데이터베이스를 컴퓨터에 복사하는 것은 불가능합니다. 따라서 상황을 시뮬레이션하는 데 필요한 몇 가지 레코드만 프로덕션 데이터베이스에서 빠르게 가져올 수 있는 도구가 있어야 합니다.

고객에게 주문 화면에 문제가 있다고 가정합니다. 주문, 고객 레코드, 주문 세부 정보 레코드, 주문 구성 레코드 등을 가져와야 할 수도 있습니다. 그런 다음 이를 Docker 인스턴스 내의 데이터베이스로 내보내고 해당 인스턴스를 시작하면 됩니다. 고객이 보고 있는 것과 동일한 것을 보고 있습니다. 물론 이 모든 작업은 개발자가 민감한 데이터에 액세스할 수 없도록 적절한 주의를 기울여 수행해야 합니다.

팁 #6: 애플리케이션에서 중단점을 배치할 위치가 분명해야 합니다.

고객 화면이 있는 경우 해당 화면에서 문제를 디버그하기 위해 중단점을 배치할 수 있는 일부 고객 개체가 있어야 합니다. 때때로 개발자는 추상화 열풍에 빠져 사용자 인터페이스 이벤트를 처리하는 방법에 대한 믿을 수 없을 정도로 똑똑한 개념을 생각해냅니다. 대신, 우리는 항상 KISS 원칙(Keep it Simple, St-er, Silly)에 의존해야 하며 UI 이벤트당 하나의 쉽게 찾을 수 있는 메서드를 가져야 합니다. 마찬가지로 일괄 처리 작업 및 예약된 작업의 경우 해당 코드가 작동하는지 여부를 평가하기 위해 중단점 위치를 쉽게 찾을 수 있는 방법이 있어야 합니다.

팁 #7: 모든 외부 종속성이 명시적으로 문서화되어 있는지 확인하십시오.

이상적으로는 문서가 손실되지 않도록 소스 제어 시스템 내의 README 파일에서 이 작업을 수행하십시오. 응용 프로그램이 제대로 실행되는 데 사용할 수 있어야 하는 외부 시스템, 데이터베이스 또는 리소스를 문서화합니다. 또한 이들 중 어느 것이 선택 사항인지 확인하고 선택 사항이고 사용할 수 없는 경우 처리 방법에 대한 지침을 추가하십시오.

디버깅 기술을 넘어서

새로운 기능을 만들거나 시스템에 유지 관리를 제공하는 동안 이러한 권장 사항을 따르면 프로덕션 지원이 훨씬 쉬워지고 회사는 훨씬 적은 시간(및 비용)을 소비하게 됩니다. 이미 알고 있듯이 프로덕션 버그 및 충돌 문제를 해결하려면 시간이 가장 중요합니다. 절약할 수 있는 1분이라도 수익에 큰 영향을 미칩니다. 즐거운 코딩!