알림 관리
우리 조직에서는 이미 IT 서비스 관리를 위해 Freshservice를 사용하고 있습니다. 그러나 내부 IT 운영 및 서비스 데스크가 함께 작업하는 IT Ops 그룹도 있습니다. 또한, Freshservice를 단일 연락 창구로 더 잘 통합하고자 하는 DevOps 팀도 있습니다. Freshservice가 이와 같은 팀 설정을 수용할 수 있습니까?
답변: 네, 우리는 이러한 설정을 수용할 수 있습니다. 자세히 알아보기.
Freshservice 인벤토리에서 자산을 자동으로 동일한 자산에 대한 수신 알림과 연결하는 방법은 무엇입니까?
답변: 현재 '리소스' 필드는 자산을 사고와 연결하는 주요 키입니다.
Freshservice가 동일한 위치에서 발생하는 여러 알림을 처리하고 모든 장치가 티켓이 닫히기 전에 작동하는지 확인하는 방법은 무엇입니까? 예를 들어 방화벽이 다운되면 모든 액세스 포인트와 스위치가 경고를 생성합니다.
답변: 이 시나리오에서는 다른 장치에서 들어오는 다양한 알림이 동일한 사고와 연결됩니다. 이 연결은 수동으로 수행할 수 있으며, Freddy가 지원하는 자동 그룹핑이 이를 수행할 수 있습니다. 따라서 10개의 장치와 10개의 알림이 있으면 모두 단일 사고로 통합됩니다. IT 팀은 본질적으로 그 하나의 사고에 대해 작업해야 합니다. 10개의 관련 알림이 모두 해결될 때만 사고가 자동으로 해결됩니다.
이와 같은 알림이 주요 사고 관리 프로세스에서도 사용될 수 있습니까?
답변: 네, 주요 사고 관리 프로세스에서 대기 관리 알림을 사용할 수 있습니다.
알림의 태그 수를 늘릴 계획이 있습니까?
답변: 네, 이는 우리의 즉각적인 로드맵의 일부이며, 다가오는 몇 달 내에 이에 대한 소식을 들을 수 있을 것입니다.
당신의 용어로, '문제'와 '주요 사고'의 차이점은 무엇입니까?
답변: 주요 사고 관리 프로세스의 목표는 문제를 가능한 한 빨리 정상으로 복구하는 것이며, 문제 관리의 목표는 문제의 근본 원인을 찾는 것입니다.
주요 사고 관리 프로세스는 문제를 더 빠르게 해결하는 것을 목표로 하며, 문제 관리는 미래에 반복되는 문제를 방지하려고 합니다.
요약하자면, 문제는 단일 또는 여러 사고 또는 주요 사고를 초래할 수 있는 근본적인 문제입니다. 주요 사고는 고객과 비즈니스에 큰 영향을 미치는 사건으로 즉시 해결해야 합니다. 사고/주요 사고는 고객이 직면한 문제이며, 문제는 그 근본 원인입니다.
우리는 제3자 웹 기반(SaaS) 공급업체가 유지보수 창, 서비스 저하 등을 알리기 위해 이메일 모니터링을 사용하고 있습니다. 이메일 알림이 자동 그룹핑에 있어 일관성이 없음을 발견했습니다. 정규 표현식(RegEx) 제어가 이를 개선할 수 있습니까?
답변: 정규 표현식 제어는 알림 그룹핑 기준에 대한 더 큰 제어와 유연성을 제공합니다. 이전에는 동일한 제목의 이메일만 함께 그룹화되었습니다. 정규 표현식 제어를 사용하면 이메일에서 값을 추출하고 그 값을 이메일 통합의 그룹핑 기준으로 사용할 수 있습니다.
10개의 페이로드/장치 중 단 1개만 작동하면 티켓이 닫힙니까?
답변: 각 장치에 별도의 알림이 있는 경우, 즉 10개의 알림이 1개의 사고와 연결된 경우, 10개의 알림이 모두 해결될 때만 사고가 자동으로 해결됩니다.
알림에 대해 티켓을 먼저 생성하지 않고 직접 워크플로우 자동화를 제공할 계획이 있습니까?
답변: 네. 이는 우리의 로드맵에 포함되어 있습니다. 알림에 대한 워크플로우 자동화가 필요한 사용 사례가 있다면, support@freshservice.com으로 이 사용 사례를 설명해 주세요.
서비스 상태 모니터링
"잠재적 서비스"는 어떻게 감지됩니까? 우리는 매우 적은 수의 서비스(현재까지 6개)를 정의했지만, 추천이 없습니다.
답변: 모니터링 도구를 구성하는 동안 잠재적 서비스는 알림 페이로드에서 서비스 이름을 포함하는 페이로드 속성을 선택하여 감지됩니다. 페이로드를 그대로 두거나 정규 표현식을 사용하여 페이로드의 특정 부분을 추출할 수 있습니다. 이렇게 하면 이 페이로드를 가진 모든 알림이 정규 표현식을 통과하게 되어 잠재적 서비스가 감지됩니다.
예: 페이로드 속성: 리소스
알림에서의 페이로드 세부 정보
“리소스” : “예약 데이터베이스”
정규 표현식이 정의되지 않은 경우, 이 경우 잠재적 서비스는 예약 데이터베이스가 됩니다.
서비스의 상태를 수동으로 변경하고 다른 알림이 들어오면 다시 변경됩니까? 알림이 들어오면 변경되는 데 얼마나 걸립니까?
답변: 서비스의 상태를 수동으로 '운영 중'으로 변경한 후, 알림이 들어와 사고를 생성하면 서비스의 상태는 '주의 필요'로 다시 변경됩니다.
하나의 모니터링 도구가 여러 서비스에 매핑될 때 서비스를 어떻게 구성합니까? 서비스가 수동으로 생성되어 모니터링 도구에 매핑될 수 있습니까? 아니면 알림을 처리하고 잠재적 서비스를 통해 서비스를 '발견'해야 합니까?
답변: 하나의 모니터링 도구가 여러 서비스에 매핑될 때, 이러한 서비스를 구성하는 유일한 방법은 알림을 처리하고 잠재적 서비스를 통해 발견하는 것입니다.
다가오는 주요 사고 관리 개선과 통합될 예정입니까? 그렇다면 이 모듈로 서비스를 생성하고 모니터링 도구를 사용할 때 따를 '모범 사례'가 있습니까?
답변: 네, 서비스는 주요 사고 관리와 밀접하게 통합될 것입니다. 주요 사고 관리 모듈에서는 '영향을 받은 서비스'라는 섹션이 있어 주요 사고에 영향을 받은 서비스를 표시할 것입니다. 현재로서는 서비스 상태 모니터링과의 모니터링 도구 통합을 위한 관행이 유효할 것입니다.
이 기능으로 SRE 모델을 어떻게 채택할 수 있습니까?
답변: SRE 팀은 이 모델을 채택할 수 있습니다
인프라 내 서비스 식별 (수동 또는 서비스 상태 모니터링 잠재 서비스 사용 자동화)
서비스 맵 및 종속성을 구성하여 서비스 간 관계 식별
모니터링 도구 통합을 사용하여 서비스를 지속적으로 모니터링하고, 상태를 결정하여 적절히 조치
이 서비스와 알림 통합의 대부분이 클라우드 서비스에 연결된 것 같습니다. 이를 위한 온프레미스 소프트웨어와의 통합 계획이 있습니까?
답변: 특정 온프레미스 소프트웨어를 찾고 계신다면 고려해볼 수 있지만, 주로 클라우드 기반 모니터링 도구 지원으로 방향을 잡고 있습니다.
대기 관리
Microsoft Teams 통합에서 타사에서 Microsoft Teams 번호로 전화를 걸어 대기 알림을 트리거할 수 있습니까?
답변: 대기를 위한 Microsoft Teams 통합은 Servicebot을 통해 대기 상담원에게 직접 메시지로 알림을 보냅니다.