Please use this identifier to cite or link to this item: https://ric.cps.sp.gov.br/handle/123456789/40347
Full metadata record
DC FieldValueLanguage
dc.contributor.advisorBODÊ, Jonas-
dc.contributor.authorLINS, Jepherson Lucas dos Santos-
dc.contributor.otherFREITAS, Rogério Nunes de-
dc.contributor.otherCUNHA, Cíntia Gimenez da-
dc.date.accessioned2025-12-30T15:14:01Z-
dc.date.available2025-12-30T15:14:01Z-
dc.date.issued2025-12-01-
dc.identifier.citationLINS, Jepherson Lucas dos Santos. Relatório técnico de como resolver problemas comuns de forma eficiente em telecomunicações, 2025. Trabalho de Conclusão de Curso (Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas) - Faculdade de Tecnologia de Americana “Ministro Ralph Biasi”, Americana, 2025.pt_BR
dc.identifier.urihttps://ric.cps.sp.gov.br/handle/123456789/40347-
dc.description.abstractO processo de reconhecimento de incidentes inicia-se com os alertas gerados por plataformas de monitoramento como Zabbix, IBM Netcool, Geolinks e BMC Remedy. Esses sistemas disparam notificações visuais e sonoras em dashboards, além de enviarem emails ou SMS para casos específicos, indicando a gravidade do problema (baixa, média, alta ou crítica). Ao receber o alarme, o analista valida sua ocorrência comparando dados em diferentes ferramentas e realizando testes remotos — como ping, traceroute e consultas SNMP — para descartar falsos positivos. Entre os incidentes mais frequentes estão Dying Gasp (falha de energia), Loss of Signal (ruptura de fibra), variações de atenuação e alarmes de temperatura elevada por superaquecimento. Concluída a validação, o evento é registrado como ticket no Remedy, priorizado conforme o número de clientes afetados, SLA e tempo de alarme, e, se necessário, encaminhado à equipe de campo (NMC) para inspeção e reparo físico.pt_BR
dc.description.abstractThe incident recognition process begins with alerts generated by monitoring platforms such as Zabbix, IBM Netcool, Geolinks and BMC Remedy. These systems trigger visual and audible notifications on dashboards and, in certain cases, send e-mail or SMS alerts, indicating the severity of the issue (low, medium, high or critical). Upon receiving an alarm, the analyst validates its occurrence by cross-checking data across different tools and performing remote tests—such as ping, traceroute and SNMP queries—to rule out false positives. The most common incidents include Dying Gasp (power failure), Loss of Signal (fiber break), attenuation variations (signal levels too high or too low) and overheating alarms due to inadequate equipment ventilation. Once validated, the event is logged as a ticket in Remedy, prioritized according to the number of affected customers, the SLA and the time elapsed since the alarm, and—if necessary—escalated to the field team (NMC) for on-site inspection and physical repair.pt_BR
dc.description.sponsorshipCurso Superior de Tecnologia em Análise e Desenvolvimento de Sistemaspt_BR
dc.language.isopt_BRpt_BR
dc.publisher004pt_BR
dc.subjectTelecomunicaçõespt_BR
dc.subjectInternetpt_BR
dc.subject.otherInformação e Comunicaçãopt_BR
dc.titleRelatório técnico de como resolver problemas comuns de forma eficiente em telecomunicaçõespt_BR
dc.title.alternativeTechnical report on how to efficiently solve common problems in telecommunicationspt_BR
dc.typeRelatório Técnicopt_BR
dcterms.type-pt_BR
Appears in Collections:Trabalhos de Conclusão de Curso

Files in This Item:
File Description SizeFormat 
20252S_Jepherson Lucas dos Santos Lins_OD2763.pdf
  Restricted Access
2.23 MBAdobe PDFView/Open Request a copy
TA - Jepherson Lucas dos Santos Lins.pdf
  Restricted Access
241.31 kBAdobe PDFView/Open Request a copy


Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.