전체 글142 DNS_PROBE_FINISHED_NXDOMAIN 해결: 도메인·네임서버·DNS 레코드·캐시 점검 그림: 정확한 호스트 이름부터 네임서버·DNS 응답·캐시를 순서대로 확인하는 NXDOMAIN 진단 흐름입니다. 직접 제작한 개념도입니다.브라우저에 DNS_PROBE_FINISHED_NXDOMAIN이 표시되면 HTTP 서버까지 도달하기 전에 이름 해석이 실패했을 수 있습니다. 서버 재시작보다 주소 오타, 도메인 등록 상태, 네임서버 위임과 요청한 호스트의 레코드를 먼저 확인하세요. 루트 도메인과 www는 서로 다른 이름이므로 한쪽이 열려도 다른 쪽이 자동으로 연결되지는 않습니다.1. NXDOMAIN과 다른 DNS 실패를 구분하기DNS 응답의 NXDOMAIN은 조회한 이름이 존재하지 않는다는 의미입니다. 기존 이름에 요청한 형식의 레코드만 없는 응답(NODATA), DNS 서버 처리 실패(SERVFAIL),.. 2026. 9. 27. PostgreSQL too many connections 해결: 연결 수 진단·풀 설정·max_connections 점검 그림: 연결 현황을 관찰하고 앱 전체의 풀 예산을 계산한 뒤 누수를 수정·검증하는 흐름입니다. 직접 제작한 개념도입니다.PostgreSQL에서 too many connections 또는 예약된 연결 슬롯 관련 오류가 나오면 새 접속을 받아 줄 여유가 부족할 가능성이 큽니다. 먼저 접속이 어디서 늘어났는지 확인하고, 앱 인스턴스 전체의 풀 크기를 계산하세요. max_connections를 바로 올리면 원인은 남고 메모리·운영 부담만 커질 수 있습니다.1. 오류 발생 위치와 시점을 확인하기앱 로그의 시간·DB 주소·배포 직후 여부를 기록합니다. DB 서버의 슬롯 부족인지, 중간 프록시나 앱 풀의 대기 시간 초과인지 구분해야 합니다. 운영자가 접속할 수 있다면 아래 읽기 전용 쿼리로 설정과 연결 분포를 확인합.. 2026. 9. 27. 관리형 PostgreSQL 선택: 자체 운영·Amazon RDS·Cloud SQL 비교와 비용 체크리스트 그림: 애플리케이션 연결부터 데이터베이스 운영·가용성·복구 시험까지 평가하는 관리형 PostgreSQL 선택 구조입니다. 직접 제작한 개념도입니다.PostgreSQL을 클라우드로 옮길 때 서버 요금만 비교하면 백업 복구, 장애 대응과 업데이트에 드는 일을 놓치기 쉽습니다. 자체 운영은 통제 범위가 넓고, 관리형 서비스는 일부 운영 작업을 서비스 제공자에게 맡길 수 있습니다. Amazon RDS와 Google Cloud SQL을 선택할 때는 기존 클라우드와의 연결, 필요한 확장 기능, 복구 목표와 전체 비용을 같은 조건으로 비교하세요.1. 자체 운영과 관리형 DB의 책임 범위선택장점주의할 점VM·서버 자체 운영OS·설치·확장 구성의 통제 범위가 넓음패치·백업·장애 전환을 직접 운영Amazon RDS for.. 2026. 9. 27. 기업용 MDM 도입 가이드: Intune·BYOD·업무용 기기 관리 선택 체크리스트 그림: 회사 소유 기기와 개인 기기를 구분한 뒤 정책·파일럿·퇴사 처리를 검증하는 MDM 도입 흐름입니다. 직접 제작한 개념도입니다.직원 노트북과 업무용 스마트폰이 늘어나면 “누가 어떤 기기를 쓰는가”, “분실 때 회사 데이터를 어떻게 보호하는가”가 구매 결정의 핵심이 됩니다. 기업용 MDM은 기기 등록과 설정·정책을 중앙에서 관리하는 도구입니다. 제품 이름보다 기기 소유권, 운영체제, 업무 앱과 퇴사 절차를 먼저 정리해야 도입 후 혼선을 줄일 수 있습니다.1. MDM과 MAM: 관리할 대상을 먼저 정하기MDM은 등록된 기기의 설정과 관리 정책을 다루고, MAM은 지원되는 앱과 그 안의 업무 데이터를 보호하는 데 초점을 둡니다. 예를 들어 Microsoft Intune의 앱 보호 정책은 지원 조건을 충족.. 2026. 9. 27. GitHub Actions 403 해결: GITHUB_TOKEN 권한·포크 PR·OIDC 점검 그림: GitHub Actions 403은 실행 이벤트, 토큰 권한, 외부 클라우드 역할을 차례로 분리해 점검합니다.GitHub Actions에서 Resource not accessible by integration 또는 HTTP 403이 나오면 토큰 문자열을 새로 만드는 것부터 시작하기 쉽습니다. 그러나 대부분은 어떤 이벤트로 실행됐는지, 어떤 권한이 부여됐는지, 어느 API가 거부했는지를 구분해야 해결됩니다. 특히 포크 PR과 OIDC 배포는 일반 push와 권한 조건이 다릅니다.1. 먼저 실패한 API와 실행 이벤트를 찾는다로그에서 실패한 단계와 요청 대상이 GitHub API인지, 패키지 레지스트리인지, AWS 같은 외부 서비스인지 확인하세요. 이어 워크플로의 on: 이벤트, 저장소·조직의 Act.. 2026. 9. 26. Let’s Encrypt 인증서 갱신 실패 해결: Certbot·DNS·포트 80·Nginx 점검 그림: 인증서 만료 확인부터 도메인 검증, 시험 갱신, 웹 서버 재적용까지의 점검 순서입니다.Let’s Encrypt 인증서 갱신에 실패했다면 곧바로 재설치를 반복하지 마세요. 실패 원인은 만료 시각, 도메인 검증 방식, DNS·포트 80 접근, Certbot 설정, Nginx 재적용 중 어디에 있는지 순서대로 확인해야 합니다. 이 글은 운영 서버에서 장애 범위를 좁히는 절차를 다룹니다.1. 만료와 실제 제공 인증서를 구분한다서버에 저장된 인증서 만료일과 사용자에게 보이는 인증서 만료일이 다를 수 있습니다. sudo certbot certificates로 Certbot 관리 인증서를 확인하고, 브라우저 또는 openssl s_client -connect example.com:443 -servername .. 2026. 9. 26. 이전 1 2 3 4 ··· 24 다음
