所有文章由New Relic提供 New Relic

  • 경영 현장을 위한 효과적인 경고기능

    "소프트웨어 개발이 더욱 빨라지고 신속하게 진행됨에 따라 최신 DevOps 팀에게는 경고가 필수 관행이 되었습니다. 왜 이렇게 된 것일까요?우선, 여러 차원에서 사이트 성능의 서비스 수준 품질을 고려해야 합니다. 이러한 근본적인 문제로 인해 작업에 주의를 기울이고 경고설정에 필요한 양호하게 설정된 지침을 따라야 합니다. 이 가이드에서는 기술 스택에 대한 효과적인 경고 전략을 만들고 관리하는 방법을 안내합니다. 높은 수준에서 우리는 다음 내용을 다룰 것입니다."

  • 실험 및 확장의 채택

    "많은 조직이 클라우드 접근 방식을 정의하고 최적화하는 과정에 있지만 IT 실무자와 의사결정자간에는, ""클라우드 네이티브""의 의미와 현대 기술과 관행을 활용하는 조직의 궁극적 목표 및 기대치에 대해 여전히 많은 혼란이 있습니다.클라우드 네이티브의 여행을 시작했거나 또는 여정에 있는지 관계없이 이 E-북은 클라우드 네이티브 환경을 최적화하는 데 필수적인 세 가지 규범적 기술 및 문화적 기능을 제시하고 있습니다."

  • 분산 환경에서 DevOps 팀에 가시성이 부족한 이유

    MTTR을 개선하고 다운 타임을 줄이고 최종 사용자 경험의 중단을 방지하기 위해서는, 크래시가 발생했을 때의 두 가지 질문, 즉 고장 지점과 사유를 즉시 해결할 수 있어야 합니다. 가시성과 마찬가지로 인프라를 위한 인프라 또한 존재하지 않습니다. 인프라는 더 넓은 스택의 맥락에서 존재합니다. 스택은 비즈니스를 올바르게 수행하는 데 중요한 고객 경험의 넓은 맥락에서만 존재합니다. 운영팀은 인프라가 애플리케이션에 어떤 영향을 미치는지 정확하게 이해해야 하고 그 반대도 마찬가지입니다.

  • 컨테이너화에 컨텍스트가 왜 필요한가

    컨테이너는 매우 일시적이며 애플리케이션과 인프라 사이의 견고한 선을 흐리게 합니다. 따라서 관리 및 오케스트레이션에 대한 새로운 접근법이 필요합니다.응용 프로그램에 필요한 일관되고 가벼운 환경을 조성함으로써 소프트웨어 개발에 소요되는 속도와 출시시간을 단축하고 모놀리드식 응용 프로그램에 내재된 "내 기계에서 작동" 문제를 근절할 수 있습니다. 컨테이너 기반 애플리케이션을 통해 기업은 빠르고 직관적이며 개인화 된 디지털 경험을 통해 차별화 할 수 있습니다.

  • 인프라 모니터링을 다음 단계로 업그레이드

    현대 인프라 스트럭처 관리에 대해 확실한 유일한 것은 뭔가 변화가 일어날 것이라는 사실입니다. 그리고 이러한 변화는 갈수록 복잡해지는 비즈니스의 표면 전반에 걸쳐 파급 효과를 가져올 것입니다. New Relic은 개방적이고 연결가능하며 프로그래밍 가능한 플랫폼으로 전체 기술 스택에서 엔드 투 엔드 및 상황에 맞는 가시성 등을 제공합니다. 고객이 실제 체험하는 브라우저 및 모바일 디바이스 사용 경험에서 응용 프로그램 및 인프라에 이르기까지 모든 데이터를 통합적으로 볼 수 있습니다.

  • NRDB 들여다 보기

    New Relic은 관찰가능성이 불안감을 더하는 대신 감소시켜야 한다고 믿습니다. 이를 위해 통합 데이터베이스를 갖춘 다음과 같은 특성을 지닌 단일 관찰 플랫폼이 필요합니다: • 모든 원격 측정 데이터를 한 곳에 모아서 시스템의 모든 데이터 포인트를 연결하여 볼 수 있으므로 식별, 이해 및 해결할 수 있습니다. 비즈니스에 영향을 미치는 문제 • 유연한 스키마를 기반으로 하므로 이전에 요구하지 않은 질문에 신속하게 답변 할 수 있습니다. • 비즈니스 성장에 따라 확장되며 비즈니스에 대한 예측 불가한 요구를 지원하기 위해 제한 없이 실행합니다.

  • 올바른 방법으로 MTTR 줄이기

    "현대의 조직은 비즈니스 운영을 갈수록 소프트웨어에 더 의존하고 있어 MTTR 주변의 단절은 단순히 좀 불편한 정도에 멈추지 않습니다. 이들은 소프트웨어 개발 프로세스에 상당한 비용, 위험 및 복잡성을 추가할 뿐 아니라 점점 더 중요한 디지털 고객 경험을 방해함으로써 수익성을 위협합니다.MTTR 또는 평균해결시간은 시스템 안정성 도구 상자에서 가장 널리 사용되는 지표 중 하나입니다. 역설적으로, MTTR은 가장 오해의 여지가 있는 지표 중 하나이기도 합니다. 많은 개발자와 운영 팀은 MTTR의 정의, 사용방법 및 일관되고 지속 가능한 방식으로 개선하는 방법 등에 대하여 명확한 비전이 부족합니다."

  • 가동시간이 전부라 해도 과언이 아닙니다

    무엇이 잘못되었는지 꼭 알 필요는 없습니다. 대신 왜 잘못되었는지, 어떻게 대응해야 하는지를 알아야 합니다. 그렇게 하려면 발생한 모든 이벤트와 다양한 시스템이 어떻게 상호작용 하는지에 대한 완전한 기록이 필요합니다. 이 목표에 어떻게 도달할 수 있을까요?