제품명보다 운영 이력을 보는 안정성 점검
서버와 WAS, DBMS 지표를 수집하고 임계치를 넘으면 알람을 받는 모니터링은 공공기관 정보시스템 운영에서 익숙한 방식입니다. 그래서 올해 처음 시행되는 정보시스템 안정성 점검을 앞둔 운영 담당자라면 이런 질문부터 하게 됩니다.
“지금 쓰는 모니터링만으로 충족을 인정받을 수 있는 기준은 어디까지일까?”
이번 점검은 행정안전부가 2026년 4월 13일 시행한 ‘행정기관 및 공공기관 정보시스템 안정성 고시’에 따른 첫 점검입니다. 고시는 행정기관이 법령에 따라 정한 기준을 공식적으로 알리는 행정규칙으로, 안정성 고시에는 정보시스템이 지켜야 할 46개 기준이 담겨 있습니다.
점검은 자체점검과 현장점검으로 나뉩니다. 자체점검은 모든 기관이 스스로 점검해 결과를 정보자원관리시스템(IRM)에 등록하는 방식이고, 현장점검은 민관 합동 점검반이 일부 시스템을 직접 방문하는 방식입니다. 대상은 IRM에 등록된 정보시스템 15,080개(8월 25일 집계)이고, 자체점검 결과는 10월 30일까지 등록해야 합니다.
다만 46개 기준의 충족 근거가 모두 같지는 않습니다. 모니터링 화면과 설정, 경보 발생·확인 이력으로 충족을 보여 줄 수 있는 기준이 있는 반면, 정지·기동 검증이나 다중화 전환 시험처럼 따로 점검하고 결과를 남겨야 하는 기준도 있습니다. 충족 여부도 결과를 등록하는 날이 아니라 8월 31일(점검 기준일) 당시의 운영 현황으로 판단합니다. 그래서 결과를 등록하기 전에 기준일까지 모니터링에 쌓인 기록으로 충족할 수 있는 기준부터 가려내야 합니다.
행정안전부가 8월 19일 배포한 ‘정보시스템 안정성 점검 가이드’를 보면, 모니터링 운영과 직접 관련된 기준은 모니터링 도구 적용, 임계치 관리, 시스템 상태 점검, 서비스 점검 4가지입니다. 이 기준에서는 어떤 제품을 쓰는지가 아니라 상태 수집, 임계치 설정, 경보 발생, 운영자 확인 기능을 실제로 운영한 기록이 충족 근거가 됩니다.
1. 기존 체크리스트를 올해 그대로 쓸 수 없는 이유
지금까지 예방점검의 실무 기준은 2024년 배포된 ‘범정부 정보시스템 예방점검체계’ 매뉴얼이었습니다. 올해부터는 이 점검도 안정성 고시의 46개 기준 안에서 이뤄집니다. 이 기준은 운영관리, 예방점검, 장애관리, 안정성 개선, 서비스 연속성의 5개 분야로 나뉘고, 기준 번호의 앞자리가 이 분야를 나타냅니다. 모니터링과 관련된 기준은 이 가운데 운영관리(1.x)와 예방점검(2.x) 분야에 들어 있습니다.
이와 함께 등급 체계도 1~4등급에서 A1~A4등급으로 바뀌었습니다. 46개 기준 가운데 등급별 필수 기준은 A1이 44개, A2와 A3가 41개, A4가 15개입니다.
이 중 예방점검 분야에는 8개 기준(2.1.1~2.3.1)이 있고, 시스템 상태 점검(2.1.1), 서비스 점검(2.1.2), 유효성 점검(2.1.3) 3개가 일상점검에 해당합니다. 예방점검 매뉴얼도 2026년판으로 개정됩니다. 행정안전부가 9월 운영관리 설명회에서 공개한 주요 변경 사항은 다음과 같습니다.
구분 | 2024년 배포 매뉴얼 | 2026년 개정 기준 |
등급별 적용 범위 | 1등급 8개 항목 필수, 2등급 7개 필수,
3등급과 4등급 권고 | A1~A3등급 8개 항목 필수,
A4등급 일상점검 3개 항목 필수 |
일상점검 세부항목 | 필수와 권고로 구분 | 상, 중, 하로 구분 |
구조진단 주기 | 3년 | 필요 시 |
매뉴얼 마련 | 제품별 점검 방법을 담은 표준 매뉴얼 제공 | 등급 확정 후 3개월 안에 기관별 매뉴얼 마련 |
가장 큰 변화는 필수 범위가 넓어진 것입니다. 2024년 매뉴얼에서는 3·4등급의 예방점검이 권고였지만, 새 기준에서는 A4등급까지 일상점검이 필수입니다. 예전에 권고 대상이라 챙기지 않던 시스템이라면 새 등급의 필수 기준부터 확인해야 합니다.
반면 점검 항목의 구성은 그대로 이어집니다. 앞서 발행한 예방점검체계 대응 전략에서는 2024년판 매뉴얼을 바탕으로 8개 점검 항목과 인프라 영역별 점검 지표를 다뤘는데, 이 8개 항목이 올해도 동일한 기준으로 유지됩니다. 다만 적용 범위와 판단 방법이 달라졌기 때문에 2024년판 기준으로 만든 체크리스트는 새 매뉴얼에 맞게 다시 고쳐야 합니다.
그리고 체크리스트를 고치는 것과 별개로 점검 기준일도 다시 확인해야 합니다. 행정안전부 설명회 자료에 나온 예시처럼 표준운영절차서를 9월에 만들었다면 기준일에는 없던 문서이므로 해당 기준은 미충족으로 등록해야 합니다.
이때 기준이 되는 것은 자료를 만든 날이 아니라 그 자료가 보여 주는 시점입니다. 기준일 이후 새로 마련한 문서나 설정은 올해 충족 근거가 되지 않지만, 기준일 이전부터 쌓인 설정과 이력을 지금 추출해 정리한 자료는 당시 운영 현황을 보여 주는 근거가 됩니다. 지금 새로 만든 문서와 이제부터 쌓이는 이력은 내년 점검의 근거로 남겨 두면 됩니다.
2. 모니터링 운영으로 충족할 수 있는 4가지 기준
기준일까지 운영한 모니터링 기록으로 충족할 수 있는 기준은 4가지입니다. 정보시스템 안정성 점검 가이드에 나온 기준별 점검 주기와 충족 조건은 다음과 같습니다.
안정성 기준 | 점검 주기 | 충족 조건 |
1.2.1 모니터링 도구 적용 | 별도 주기 없음 | 서버, WEB, WAS, DBMS, 스토리지, 네트워크에 상태 수집, 임계치 관리, 경보, 운영자 확인 기능을 갖춘 도구를 운영 |
1.2.2 임계치 관리 | 연 1회 이상 최적화 | 임계치를 2단계 이상으로 설정하고 최근 1년 안에 조정하거나 검토한 이력이 있음 |
2.1.1 시스템 상태 점검 | 일 1회 이상 | 점검 분야마다 자동 알람 기능을 갖춘 모니터링 도구를 운영 |
2.1.2 서비스 점검 | 일 1회 이상 | URL 접속, 응답시간, 가용성 또는 장애 알림 기능을 제공하고 운영자 확인 이력이 있음 |
4가지 기준을 점검할 때는 어떤 제품을 쓰는지보다 어떤 기능을 갖췄는지를 봅니다. 모니터링 도구 적용(1.2.1) 기준의 점검 방법에는 이 원칙이 한 문장으로 나와 있습니다.
제품명은 참고자료로만 기록하며, 제품의 종류 또는 제조사는 평가하지 않고 기능 중심으로 점검한다.
따라서 상용 제품이든 오픈소스든 자체 개발 도구든 충족 근거로 쓸 수 있습니다. 대신 두 가지를 봅니다. 도구에 필요한 기능이 있는지와 그 기능을 실제로 운영했다는 증적자료(점검 결과를 뒷받침하는 기록)가 있는지입니다. 모든 기준에 이런 운영 증적이 필요하고, 그중 임계치 관리(1.2.2)는 조정·검토 이력이, 서비스 점검(2.1.2)은 운영자 확인 이력이 추가로 남아 있어야 합니다.
이런 증적은 제품 소개서가 아니라 운영 중인 시스템에서 가져와야 합니다. 확인 이력이 모니터링 도구가 아니라 ITSM 티켓이나 운영일지, 점검 보고서에 남아 있다면 그 자료도 근거로 함께 정리해 두면 됩니다. 공통으로 필요한 기능과 단계별로 제출할 수 있는 증적은 다음과 같습니다.
그래서 같은 제품을 쓰더라도 점검 결과는 기관마다 다를 수 있습니다. 경보 알림을 메일로 받기만 하고 누가 언제 확인했는지 남기지 않은 기관을 예로 들어 보겠습니다. 이 기관은 도구에 운영자 확인 기능이 있으므로 모니터링 도구 적용(1.2.1)은 충족할 수 있습니다. 하지만 서비스 점검 일지 같은 다른 기록도 없다면 확인 이력이 필요한 서비스 점검(2.1.2)은 미충족이 됩니다. 충족 여부는 제품이 아니라 도구에 남은 운영 이력에 달려 있습니다.
3. 모니터링을 운영해도 미충족이 되는 4가지 경우
모니터링을 운영하고 있어도 설정 범위와 운영 방식, 기록 수준에 따라 미충족이 나올 수 있습니다. 정보시스템 안정성 점검 가이드에는 기준마다 충족으로 볼 수 있는 경우와 볼 수 없는 경우가 함께 나와 있습니다. 이 내용을 기관의 현재 설정과 대조하면 도구는 갖췄지만 설정이나 기록이 부족해 미충족이 되기 쉬운 부분을 미리 찾을 수 있습니다.
모니터링 관련 기준에서 미충족으로 이어지기 쉬운 경우는 다음 4가지입니다.
3-1. 임계치를 한 단계로만 설정한 경우
먼저 임계치 관리(1.2.2) 기준에 따르면 임계치는 제품 특성에 맞게 2단계 이상으로 나눠 설정해야 합니다. CPU 사용률 90% 하나만 설정해 두었다면 충족으로 보기 어렵습니다. 점검 가이드의 증적 예시에도 Down, Critical, Major, Minor, Info처럼 단계를 나눈 임계치 현황이 나옵니다.
그런데 제품이 제공하는 경보 등급과 실제로 설정한 임계치는 구분해야 합니다. 도구에 Critical, Major, Minor 같은 등급이 있어도 점검 대상 지표마다 단계별 임계값을 정해 두지 않았다면 2단계 이상으로 설정했다고 보기 어렵습니다.
설정값을 갖췄다면 결과를 등록하기 전에 실제로 동작하는지도 살펴봐야 합니다. 임계치를 넘었을 때 경보가 발생하는지, 이벤트가 기록되는지, 운영자에게 알림이 가는지는 도구에 직접 접속해 보면 알 수 있습니다.
3-2. 임계치 검토 이력이 없는 경우
임계치는 시스템 부하와 운영 환경이 바뀌면 함께 조정해야 하는 값입니다. 그래서 최근 1년 안에 임계치를 조정하거나 검토한 이력이 있어야 임계치 관리(1.2.2) 기준을 충족할 수 있습니다. ITSM(IT 서비스 관리 시스템)을 운영한다면 조정 요청·승인 티켓이나 변경 이력을, ITSM이 없다면 임계치 조정 보고서나 운영회의 결과, 설정 변경 이력을 증적자료로 내면 됩니다.
물론 값을 꼭 바꿔야 하는 것은 아닙니다. 검토한 결과 조정할 필요가 없었다면 임계치 최종 조정일자와 조정하지 않은 사유를 남겨 점검 예외로 처리할 수 있습니다. 다만 올해 점검에서 인정받으려면 이 기록도 기준일 이전에 남긴 것이어야 합니다. 한편 임계치를 오래 그대로 두면 오탐과 미탐이 늘어날 수 있습니다. 이 문제는 AI 이상탐지 글에서 자세히 다뤘습니다.
3-3. 경보 확인 이력이 없는 경우
임계치를 잘 관리해도 경보를 처리한 기록이 없으면 미충족이 될 수 있습니다. 서비스 점검(2.1.2)은 운영자 확인 이력이 있어야 충족되는 기준이기 때문입니다. 경보가 발생해 메일이나 문자로 알림이 나갔다는 기록만으로는 부족하고, 운영자가 그 경보를 확인했다는 기록이 따로 있어야 합니다. 확인 이력으로 낼 수 있는 기록에는 예를 들어 다음과 같은 것이 있습니다.
✅ 모니터링 도구에서 운영자가 경보를 확인(Ack) 처리한 기록
✅ 경보와 연결된 ITSM 장애 티켓
✅ 담당자와 확인 시각을 적은 점검 일지
지금 진행 중인 현장점검에서도 이 부분을 확인합니다. 9월 21일부터 11월 30일까지 민관 합동 점검반이 A1~A3등급 정보시스템 200여 개를 방문해 증적자료를 확인하고 담당자를 인터뷰합니다. 경보 기록과 함께 누가 확인하고 어떻게 조치했는지 설명할 수 있도록 준비해 두는 것이 좋습니다.
경보 이력 보존 기간
모니터링 도구는 경보와 이벤트 이력을 일정 기간만 보관하고 오래된 기록은 자동으로 지우거나 요약하는 경우가 많습니다. 보존 기간이 60일이라면 8월 31일 무렵의 경보 기록은 10월 말이면 사라집니다. 올해 근거로 쓸 경보·확인 이력은 지금 바로 추출해 두고, 임계치 설정 변경 이력은 1년치가 필요하므로 보존 기간을 함께 확인해 두어야 합니다.
3-4. 일부 영역이 모니터링에서 빠진 경우
경보 기록과 확인 이력을 잘 남겼더라도 점검 대상 일부가 모니터링에서 빠져 있으면 A1~A3등급 시스템은 점수가 낮아집니다(A4등급은 점검만 하고 점수는 계산하지 않습니다). 기준 하나에 여러 점검항목이 있으면 충족한 항목의 비율로 점수를 계산하기 때문입니다. 모니터링 도구 적용(1.2.1) 기준은 서버, WEB, WAS, DBMS, 스토리지, 네트워크 6개 영역이 각각 점검항목입니다. 서버와 WEB, WAS, DBMS만 수집하고 스토리지와 네트워크가 빠져 있다면 6개 중 4개만 충족해 0.67점이 됩니다.
다만 통합 제품 하나로 모두 수집해야 하는 것은 아닙니다. 스토리지와 네트워크 장비는 통합 모니터링 대신 제조사 관리도구로 따로 관리하는 경우도 많습니다. 이런 제조사 도구도 상태 수집, 임계치 관리, 경보, 운영자 확인 기능을 갖추고 실제로 운영하고 있다면 충족 근거가 됩니다.
그런데 제조사 도구는 경보 알림은 보내도 확인 기록을 남기지 못하는 경우가 있어 이 부분을 먼저 확인해야 합니다. 도구가 여러 개라면 영역별로 어느 도구의 어떤 화면을 증적자료로 제출할지와 그 이력을 언제까지 조회할 수 있는지 미리 정리해 두는 것이 좋습니다.
정보시스템 안정성 점검에서 해당없음은 시스템 구조상 점검 대상 자체가 없을 때만 선택할 수 있습니다. 해당없음으로 등록한 항목은 평가에서 빠지지만, 점검 대상이 있는데 도구가 수집하지 못하는 영역은 미충족으로 등록해야 합니다.
4. 모니터링 도구만으로는 충족할 수 없는 기준
앞의 4가지 경우는 모니터링 설정과 운영 기록에서 확인할 사항입니다. 기준일 이전 기록이 남아 있다면 지금 정리해 올해 근거로 내고, 그렇지 않다면 지금부터 보완해 내년 점검에 대비하면 됩니다. 반면 정지와 기동 절차를 직접 검증하거나 다중화 장비의 전환을 시험하는 것처럼 모니터링과 별도로 점검하고 결과를 남겨야 하는 기준도 있습니다. 예방점검 분야에서 이렇게 따로 준비해야 하는 기준은 다음 6가지입니다.
안정성 기준 | 점검 주기 | 충족에 필요한 것 |
2.1.3 유효성 점검 | 월 1회 이상 | 인증서, SW 라이선스, 도메인, NTP 현황을 관리시스템이나 관리대장으로 관리하고 월간 점검 결과를 남김 |
2.2.1 오프라인 점검 | 연 1회 이상 | 정지와 기동 절차를 검증한 점검 결과 |
2.2.2 다중화 점검 | 연 1회 이상 | 다중화 장비의 자동 전환(절체)과 정상 작동을 확인한 결과 |
2.2.3 성능점검 | 연 1회 이상 | WEB/WAS 또는 DBMS의 성능 저하 요인 분석과 개선 내용을 담은 결과서 |
2.2.4 업무집중기간 점검 | 집중기간 전과 기간 중 | 사전 점검과 조치, 기간 중 모니터링 |
2.3.1 구조진단 및 개선 | 필요 시 | 구조진단이 필요한지 판단하는 기준과 절차 |
이 기준들은 모두 따로 준비한 점검 결과나 문서가 필요합니다. 모니터링이 이런 점검을 대신하지는 못하지만, 성능 추이나 장애·이벤트 이력을 점검 결과의 근거 자료로 제공하고 이상 징후를 미리 알려 줄 수 있습니다. 그중 모니터링 데이터를 가장 직접 활용하는 기준은 성능점검과 업무집중기간 점검입니다.
업무집중기간 점검은 기간 중 CPU와 메모리 같은 자원 사용 현황과 응답시간 같은 서비스 상태를 모니터링한 보고서나 운영기록이 증적이 되고, 기간 전에 실시한 사전점검 결과서를 함께 제출하면 됩니다. 업무집중기간이 없는 시스템은 해당없음으로 등록합니다.
4-1. 성능점검: 평소 수집한 데이터로 작성하는 결과서
정보시스템 안정성 점검 가이드에 따르면 성능점검 결과서에 시스템 응답시간과 자원 사용률, 성능 저하 요인 분석, 개선사항을 담으면 충족할 수 있습니다. 이때 부하시험은 필수 요건이 아닙니다. 따라서 별도 시험 없이도 평소 수집한 응답시간과 SQL 성능 추이로 저하 요인을 분석하고 개선 내용을 결과서로 정리할 수 있습니다.
또한 중앙행정기관이라면 성능점검 계획서와 결과서를 행정관리 역량평가의 증적자료로도 쓸 수 있습니다. 역량평가는 2025년 12월부터 2026년 11월까지의 실적을 평가합니다. 지금 실시하는 성능점검도 이 기간에 들어가므로 매년 이어서 쓸 수 있는 양식으로 만들어 두는 것이 좋습니다.
4-2. 구조진단: 판단 기준이 없으면 미충족
구조진단은 3년 주기가 사라지고 필요할 때 실시하는 방식으로 바뀌었습니다. 그 대신 구조진단이 언제 필요한지 판단하는 기준과 절차를 갖춰야 하고, 판단 기준이 없으면 미충족이 됩니다. 가이드에는 판단 기준의 예로 최근 1년 안에 같은 장애가 3회 이상 발생한 경우가 나와 있습니다.
이 조건을 적용하려면 장애 이력이 쌓여 있어야 하므로 구조진단도 모니터링 이력과 이어집니다. 다만 모니터링 이벤트가 곧 장애는 아닙니다. 여러 건의 CPU 경보가 같은 장애 하나에서 나왔을 수도 있고 서로 다른 장애에서 나왔을 수도 있습니다. 장애마다 원인을 분류해 기록해 두어야 '같은 장애'가 몇 번 발생했는지 셀 수 있습니다.
4-3. 함께 챙길 기준: 예방점검 매뉴얼(1.6.2)
표의 6가지 기준 외에 함께 챙겨야 할 기준이 하나 더 있습니다. 운영관리 분야에 속하는 예방점검 매뉴얼(1.6.2)입니다. 행정안전부 표준안을 그대로 보관만 해서는 충족할 수 없고, 기관 환경에 맞는 점검항목과 방법을 반영해야 합니다. 매뉴얼 내용이 실제 운영 환경과 다를 때도 미충족이 됩니다.
그래서 모니터링 도구에 설정한 임계치와 경보 규칙을 매뉴얼의 점검 기준에 반영해 두면 문서와 운영이 어긋나지 않습니다. 임계치는 운영하면서 계속 바뀌므로 조정할 때 매뉴얼도 함께 고치도록 절차를 정해 두면 임계치 검토 이력과 매뉴얼 갱신을 한 번에 챙길 수 있습니다.
5. 정보시스템 안정성 점검 FAQ
결과를 등록하다 보면 점검 기준일이나 운영 주체에 따라 판단하기 애매한 경우가 생깁니다. 그중 자주 묻는 3가지를 행정안전부 점검 가이드와 설명회 자료를 근거로 정리했습니다.
Q1. 8월 31일 이후에 고친 설정이나 새로 만든 문서는 어떻게 등록하나요?
해당 기준은 미충족으로 등록해야 합니다. 충족 여부는 8월 31일 기준 운영 현황으로 판단하므로 9월에 임계치를 2단계로 나눴거나 10월에 경보 확인 절차를 만들었다면 올해는 미충족입니다. 다만 기준일 이전부터 남아 있던 설정과 이력을 지금 추출한 자료는 근거가 됩니다. 기준일 이후 보완한 내용은 내년 점검의 근거가 되므로 보완한 날짜와 내용을 기록해 두면 현장점검 인터뷰에서도 개선 과정을 설명할 수 있습니다.
Q2. 국가정보자원관리원에 입주한 시스템은 어떻게 점검하나요?
인프라 항목 가운데 국가정보자원관리원(국정자원)이 관리하는 부분은 국정자원이 일괄 점검합니다. 기관은 응용프로그램(AP) 항목과 나머지 인프라 항목을 점검하고, 두 결과를 합쳐 평가받습니다. 일괄 점검 내용이 실제와 다르면 기관이 정정할 수 있습니다. 스토리지나 네트워크가 국정자원 일괄 점검 범위에 들어간다면 기관 모니터링에서 빠져 있어도 바로 미충족이 되지는 않습니다.
Q3. 인프라 운영사업자와 AP 운영사업자가 다르면 누구의 결과가 반영되나요?
점검항목마다 반영하는 분야가 정해져 있습니다. 모니터링 관련 기준에서 서버와 스토리지, 네트워크는 인프라 분야 결과만 반영하고, WEB과 WAS, DBMS는 인프라와 AP 가운데 한 분야만 충족하면 됩니다. 예를 들어 인프라 운영사업자가 DBMS를 모니터링하지 않더라도 AP 운영사업자의 도구가 DBMS 경보와 확인 이력을 남기고 있다면 충족할 수 있습니다. 행정안전부도 설명회에서 인프라 담당자와 유지보수 사업자의 협력을 공통 유의사항으로 꼽은 만큼, 두 사업자가 맡을 영역과 낼 증적자료를 미리 나눠 두는 것이 좋습니다.
6. 평소 운영 이력으로 준비하는 자체점검
인프라 담당자와 유지보수 사업자가 함께 준비하는 자체점검은 올해 한 번으로 끝나지 않습니다. 안정성 고시 제9조에 따라 기관은 매년 자체점검을 하고 결과를 IRM에 등록해야 합니다. 제12조는 예방점검에서 수작업으로 인한 누락과 오류를 막기 위해 자동화된 점검 도구나 시스템을 활용하도록 노력해야 한다고 정하고 있습니다. 성능점검처럼 별도 점검이 필요한 기준도 평소 쌓인 모니터링 데이터를 활용하면 수작업을 줄일 수 있습니다. 운영 이력이 자동으로 쌓이게 해 두면 매년 돌아오는 정보시스템 안정성 점검의 부담도 줄어듭니다.
올해 결과를 등록하기 전에 아래 항목을 먼저 확인해 두면 좋습니다. 모든 항목은 지금 상태가 아니라 8월 31일까지 남은 기록과 문서로 확인합니다.
IRM 등록 전 모니터링에서 확인할 것
- 서버, WEB, WAS, DBMS, 스토리지, 네트워크 6개 영역의 수집 여부
- 영역별 임계치의 2단계 이상 설정
- 최근 1년 안의 임계치 조정이나 검토 이력, 또는 미조정 사유
- 경보별 확인 담당자와 확인 시각 기록, 그 이력의 보존 기간
- 성능점검 결과서의 응답시간, 자원 사용률, 저하 요인, 개선 내용
특히 첫 번째 항목은 모니터링이 영역별 도구로 나뉘어 있을수록 확인하기 어렵습니다. 도구마다 다른 화면에서 증적자료를 모으다 보면 특정 영역이나 기간의 기록이 빠졌는지 확인하는 데도 시간이 걸리기 때문입니다.
이럴 때는 여러 영역의 수집 현황과 경보 이력을 함께 보는 통합 모니터링이 도움이 됩니다. exemONE(엑셈원)은 서버와 네트워크 장비, WEB 서버와 WAS, DBMS를 하나의 플랫폼에서 모니터링하고 여러 영역의 경보 발생 이력을 한 화면에서 보여 줍니다. URL 접속 상태 모니터링도 제공해 서비스 점검(2.1.2)의 URL 접속 확인에도 활용할 수 있습니다.
또한 exemONE에서 리포트 형식과 발행 일정을 정해 두면 일간, 월간 점검 결과를 같은 형식으로 남기고 발행 이력도 관리할 수 있습니다. 리포트가 자동으로 발행됐다는 사실이 운영자가 확인하고 조치했다는 사실을 대신하지는 않으므로 확인 기록과 함께 남겨 두어야 합니다. exemONE의 트랜잭션과 SQL 성능, 병목 구간 분석 결과는 성능점검(2.2.3) 결과서의 근거로도 쓸 수 있습니다.
다만 도구 하나로 모든 기준을 충족할 수는 없습니다. 유효성 점검 관리대장, 정지·기동 점검과 다중화 전환 시험 결과, 업무집중기간 점검 계획, 구조진단 판단 기준, 기관별 예방점검 매뉴얼은 기관의 운영 절차로 따로 마련해야 합니다. 모니터링으로 남길 이력과 담당자가 따로 준비할 절차를 나눠 두면 빠진 기준이 없는지 확인하기 쉬워집니다.
올해 자체점검 마감은 10월 30일입니다. 그 전에 경보와 확인 이력이 보존 기간에 걸려 지워지지 않도록 올해 근거로 쓸 기록부터 지금 추출해 두어야 합니다. 내년 점검의 근거가 될 이력은 지금부터 쌓입니다. 지난달 발생한 경보 한 건을 골라 발생부터 확인, 조치까지의 과정을 따라가 보시기 바랍니다. 누가 언제 확인했는지와 조치 결과가 어디에 남았는지 설명할 수 없다면 그 부분이 내년 점검 전에 먼저 보완할 항목입니다.
안정성 점검에 필요한 모니터링 이력, exemONE으로 어떻게 관리할까?
👉🏻 exemONE의 주요 기능을 자세히 확인해보세요
출처
함께 보면 좋은 아티클
