SLO(서비스 수준 목표) 달성 노력, 섹션 1

이론적으로 말하자면, 벌집은 항상 위로 올라간다.우리의 서버는 운행할 때 고장이 발생하지 않으며, 우리의 사용자 인터페이스는 탑재 속도가 빠르고, 응답 속도가 빠르며, 우리의 조회 엔진 속도가 매우 빠르다.사실 항상 그렇지는 않습니다. 본 블로그의 충실한 독자들은 우리가 어떻게 use those experiences to improve the product을 할 수 있는지 알고 있습니다.
이제 우리는 모든 시간을 시스템 안정성에 쏟아부을 수 있다.우리는 전방 코드를 개선하여 저효능을 찾을 수 있다.백엔드에서 더 어려운 테스트 용례를 던지다.(이런 방법을 지지하는 개발자가 몇 명 있다!)그러나 우리는 또한 제품을 더욱 좋게 하기를 희망한다. 그래서 우리는 끊임없이 이렇게 많은 great features을 내놓고 있다.
우리는 언제 안정성을 개선할 것인지, 언제 재미있는 조정을 시작할 것인지를 어떻게 결정합니까?

조직 목표에서 활동으로

만약 우리가 얼마나 나쁜지에 대해 합의를 보았다면.상황이 좋지 않을 때, 작은 오류에 빠지거나, 큰 오류가 서비스 중단을 초래할 때, 우리는 멋진 기능 개발의 속도를 늦추고 안정성 작업을 할 수 있다.반대로 상황이 상당히 안정적이라고 느낄 때 우리는 우리가 상당히 튼튼한 인프라 시설을 가지고 개발하고 수리와 유지 보수 업무를 늦출 수 있다고 믿을 수 있다.
그럼 협의회는 어떻게 되나요?
우선 우리 시스템을 진지하게 살펴볼 수 있다는 뜻이다.벌집은 mature level of observability이 있기 때문에 우리는 우리가 무엇을 하고 있는지, 사용자가 어디에서 도전에 부딪혔는지, 시스템에 어떤 빈틈이 생겼는지 원시적인 도구를 가지고 있다고 자신한다.
둘째, 이것은 완벽한 시스템이 없다는 것을 알아야 한다는 것을 의미한다.만약 우리의 목표가 모든 요청이 언제든지 100%의 정상적인 운행 시간을 유지하는 것이라면, 우리는 어떤 일들은 때때로 실패하기 때문에 실망할 것이다.그러나 우리는 서비스 품질에 관한 성명을 제기할 수 있다.벌집 회사에서 내부 회의를 열었는데 우리는 양적화에 주력했다.

우리는 고객 데이터를 거의 잃어버리고 싶지 않습니다.우리는 고객 데이터를 저장함으로써 생존과 사망을 하기 때문에 모든 고객 원격 측정이 신속하게 적극적인 호응을 얻기를 바란다.만약 우리가 99.95%의 요청을 100밀리초 안에 틀림없이 처리하기를 희망한다면이는 1년 내내 4시간의 다운타임이 있을 수 있음을 의미합니다.)

우리는 누군가가 벌집을 클릭할 때마다 우리의 주요 서비스가 정상적으로 운행되기를 희망한다.io, 우리는 그것이 빨리 불러올 수 있기를 바랍니다.만약 우리가 1초 안에 99.9%의 요청이 잘못된 페이지를 불러오기를 원한다면.

때때로, 검색어를 실행할 때, 검색어가 더 오래 걸릴 때가 있습니다.이를 위해, 우리는 99.5%의 데이터 조회를 10초 안에 되돌려야 하며, 오류를 되돌려주지 않기로 결정했다.

이것들은 모두 완전히 합리적인 목표이다.기묘하게도 이들은 실제로 벌집의 개밥 서버에서 Derived Column expressions으로 표시할 수 있다.
예를 들어 우리는 첫 번째 데이터 섭취에 관한 것인'request.endpoint이 batch단점을 사용하는 사건에 대해 이야기했다. 입력은 POST 요청이다. 그들이 이렇게 할 때 그들은 코드 200duration_ms을 100이하로 되돌려야 한다.
우리는 그것을 사용하여 우리의 서비스 상황을 지시하기 때문에 '서비스 수준 지시기' 라고 부른다.저희 derived column language에서.

IF(
  AND(
   EQUALS($request.endpoint, "batch"),
   EQUALS($request.method, "POST")
  ),
  AND(
   EQUALS($response.status_code, 200),
   LT($duration_ms, 100)
  )
)

파생 열을 "SLI"로 명명하고 계수와 히트맵을 생성합니다.
이것은 보기에 매우 정상적이다. 우리는 더 많은 관점이 정확하다는 것을 보았다. (지표는 좋다. 모든 것이 좋다.)잘못이 아니라 (아, 아니야, 그들은 실패했어!)우리는 모든 가장 느린 점이 가짜 그룹에 있다는 것을 볼 수 있다.
우리가 신뢰할 만한 휴대용 계산기 35K개의'가짜'가 있는 사건을 꺼내자.1억 7100만 원, 정말.이것은 약 0.02%의 실패율이다. 우리의 실패율은 99.98% 로 상승했다.듣자하니 우리 잘했어!

그러나 여전히 약간의 실패가 있다.왜 그런지 알고 싶어요!
Bubble Up 라벨을 클릭하면 누가 이런 느린 경험을 했는지 찾아낼 수 있다.나는 가장 느린 모든 요청을 강조했고, Bubble Up은 모든 차원에 데이터를 집중하는 직사각형을 보여 주었다.다른 모든 열과 가장 다른 열을 찾으면, 나는 이러한 오류가 매우 두드러진 것을 알 수 있다.
... 나는 이것이 특정한 고객, 특정한 단체라는 것을 발견했다.뿐만 아니라 그들은 벌집을 위해 상당히 심상치 않은 API를 사용했다(이것은 네 번째 항목, request.header.user-agent)

이것은 매우 좋고, 게다가 매우 실행할 수 있다.나는 고객에게 연락하여 상황을 이해할 수 있다.나는 우리의 통합팀을 파견하여 특정한 소프트웨어 패키지를 살펴보고 우리가 그것을 잘 사용하기 어려운 일을 하고 있는지 확인할 수 있다.

서비스 품질을 계량화하는 것은 네가 그것을 평가할 수 있다는 것을 의미한다

그래서 우리의 출발점으로 돌아왔다. 우리는 조직의 목표로부터 시작하는 방법을 찾았고 우리의 추상적인 개념을 양적으로 측정하는 방법을 찾았다.'시종일관 신속을 유지한다'는 것은 이제 의미가 있고 측정할 수 있는 것이다.그리고 나서 우리는 그것으로 어디에 문제가 있는지 진단하고 어떻게 속도를 내는지 찾아낼 수 있다.
두 번째 부분, 곧 다가온다. 잠깐만, 내가 왜 내 휴대용 계산기를 꺼내야 돼?우리 컴퓨터 없어요?그리고 이 단어'SLI'는 왠지 익숙한 것 같아...
이 시리즈의 다음 기사를 읽으십시오.
Honeycomb SLO Now Generally Available: Success, Defined.
탁월한 운영의 미래에 대해 흥분하십니까?Honeycomb for free부터 시작합니다.