SLA가 당신을 구할 것이라고 생각하지 마십시오. 안심시키고 잘못된 보안감을 조성하는 것이 필요합니다.

"서비스 수준 계약"이라고도 알려진 SLA는 고객이 서비스 측면에서 무엇을 받게 될지에 대한 고객과 서비스 제공업체 간의 보증 계약입니다. 또한 공급업체의 귀책사유 등으로 다운타임이 발생한 경우 보상을 규정하고 있습니다. 본질적으로 SLA는 데이터 센터 또는 호스팅 제공업체가 잠재 고객에게 가능한 모든 방법으로 친절하게 대우받을 것이라고 확신시키는 데 도움이 되는 자격 증명입니다. 문제는 SLA에 원하는 것은 무엇이든 작성할 수 있으며, 이 문서에 작성된 이벤트는 너무 자주 발생하지 않는다는 것입니다. SLA는 데이터 센터 선택에 대한 지침과는 거리가 멀기 때문에 이에 의존해서는 안 됩니다.

우리 모두는 특정 의무를 부과하는 일종의 계약에 서명하는 데 익숙합니다. SLA도 예외는 아닙니다. 일반적으로 상상할 수 있는 가장 비현실적인 문서입니다. 아마도 더 쓸모없는 유일한 것은 "영업 비밀"이라는 개념이 실제로 존재하지 않는 관할권에서의 NDA입니다. 그러나 전체 문제는 SLA가 고객이 올바른 공급업체를 선택하는 데 도움이 되지 않고 눈에 먼지만 던진다는 것입니다.

호스팅 업체는 대중에게 공개하는 SLA의 공개 버전에서 가장 자주 무엇을 작성합니까? 글쎄, 첫 번째 줄은 호스팅 업체의 "신뢰성"이라는 용어입니다. 이는 일반적으로 98~99,999%의 숫자입니다. 사실, 이 숫자는 마케터들의 아름다운 발명품일 뿐입니다. 옛날 옛적에 호스팅이 젊고 비용이 많이 들었고 클라우드가 전문가(그리고 모든 사람을 위한 광대역 액세스)의 꿈이었을 때 호스팅 가동 시간 지표는 매우 중요했습니다. 이제 모든 공급업체가 동일한 장비를 사용하고 동일한 백본 네트워크에 위치하며 동일한 서비스 패키지를 제공할 때 가동 시간 표시기는 전혀 눈에 띄지 않습니다.

"올바른" SLA도 있나요?

물론 이상적인 SLA 버전도 있지만 모두 비표준 문서로 고객과 공급업체 간에 수동으로 등록 및 체결됩니다. 더욱이 이러한 유형의 SLA는 서비스보다는 일종의 계약 작업과 관련이 있는 경우가 가장 많습니다.

좋은 SLA에는 무엇이 포함되어야 합니까? 간단히 말해서, 좋은 SLA는 두 엔터티 간의 관계를 규제하는 문서로, 당사자(고객) 중 한 사람에게 프로세스에 대한 최대 통제권을 제공합니다. 즉, 실제 세계에서 작동하는 방식입니다. 글로벌 상호 작용 프로세스를 설명하고 당사자 간의 관계를 규제하는 문서가 있습니다. 이는 경계와 규칙을 설정하고 그 자체로 양측이 최대한 활용할 수 있는 영향력의 지렛대가 됩니다. 따라서 올바른 SLA 덕분에 고객은 계약자에게 합의된 대로 작업하도록 강제할 수 있으며 이는 계약자가 계약에 의해 정당화되지 않는 과도하게 활동적인 고객의 "원하는 것"에 맞서 싸우는 데 도움이 됩니다. 그것은 다음과 같습니다: "우리 SLA가 이렇게 말하고 저기서 나가세요. 우리는 합의한 대로 모든 일을 합니다."

즉, "올바른 SLA" = "서비스 제공을 위한 적절한 계약"이며 상황에 대한 통제권을 제공합니다. 하지만 이는 '동등하게' 일할 때만 가능합니다.

홈페이지에 적힌 내용과 현실에서 기다리는 것은 다른 것입니다.

일반적으로 우리가 더 자세히 논의할 모든 것은 일반적인 마케팅 요령과 주의력 테스트입니다.

인기 있는 국내 호스팅 업체를 선택하면 연중무휴 지원, 25%의 서버 가동 시간, 적어도 러시아에 있는 자체 데이터 센터 등 한 가지 제안이 다른 것보다 낫습니다. 데이터센터에 대한 주의사항을 기억해주세요. 우리는 이 이야기를 조금 나중에 다시 할 것입니다. 그동안 이상적인 내결함성 통계와 서버가 여전히 "0,0000001% 오류"에 속할 때 직면하게 되는 상황에 대해 이야기해 보겠습니다.

지표가 98% 이상인 경우 모든 하락은 통계 오류 직전의 이벤트입니다. 작업 장비와 연결이 있거나 없거나 둘 중 하나입니다. 자체 SLA에 따라 50%의 "신뢰성" 등급을 가진 호스터를 몇 년 동안 아무런 문제 없이 사용할 수도 있고, 99,99%를 주장하는 사람들과 함께 며칠 동안 한 달에 한 번 "실패"할 수도 있습니다.

추락하는 순간이 오면(그리고 모든 사람이 언젠가는 추락한다는 사실을 상기시켜 드립니다) 클라이언트는 "지원"이라는 내부 회사 시스템에 직면하게 되고 서비스 계약과 SLA가 밝혀지게 됩니다. 무슨 뜻이에요:

• 일부 호스팅 업체는 충돌 순간부터 관세(보상 지불)를 다시 계산하기 시작하지만 처음 XNUMX시간의 가동 중지 시간 동안은 아무것도 표시할 수 없습니다.
• 장기간 서버를 사용할 수 없는 경우 요금 재계산 요청을 제출할 수 있습니다.
• 그리고 이는 공급자의 잘못으로 인해 문제가 발생한 경우에 제공됩니다.
• 제XNUMX자(고속도로에서) 때문에 문제가 발생한 경우에는 “아무도 탓할 수 없는” 것처럼 보이며 문제가 해결되는지는 본인의 운에 달려 있습니다.

그러나 엔지니어링 팀에 접근할 수 없다는 점을 이해하는 것이 중요합니다. 실제 엔지니어가 상황을 해결하려고 시도하는 동안 귀하와 연락을 주고받는 첫 번째 지원 라인에 의해 중단되는 경우가 가장 많습니다. 익숙한 것 같나요?

여기에서는 많은 사람들이 SLA에 의존하는데, 이는 이러한 상황으로부터 사용자를 보호해 주는 것 같습니다. 그러나 실제로 기업은 자체 문서의 경계를 벗어나거나 자체 비용을 최소화하는 방식으로 상황을 전환할 수 있는 경우가 거의 없습니다. SLA의 주요 임무는 경계심을 늦추고 예상치 못한 상황이 발생하더라도 "모든 것이 괜찮을 것"이라고 확신시키는 것입니다. SLA의 두 번째 목적은 주요 중요 사항을 전달하고 서비스 제공업체에 조치를 취할 수 있는 여지를 제공하는 것입니다. 즉, 실패를 공급업체가 "책임을 지지 않는" 문제로 돌릴 수 있는 능력을 제공하는 것입니다.

동시에 대규모 클라이언트는 실제로 SLA 내 보상에 전혀 신경 쓰지 않습니다. "SLA 보상"은 장비 가동 중단 시간에 비례하여 요금 범위 내에서 금액을 환불하는 것으로, 잠재적인 금전적 및 명예 손실의 1%도 보상할 수 없습니다. 이 경우 일종의 "관세 재계산"보다 가능한 한 빨리 문제를 해결하는 것이 고객에게 훨씬 더 중요합니다.

“세계 곳곳에 데이터센터 많다” 우려

위에서 설명한 명백한 통신 문제 외에도 명확하지 않은 문제도 발생하기 때문에 서비스 제공업체에 다수의 데이터 센터가 있는 상황을 별도의 범주에 배치했습니다. 예를 들어, 귀하의 서비스 제공업체는 "그들의" 데이터 센터에 액세스할 수 없습니다.

지난 기사에서 우리는 제휴 프로그램의 유형에 대해 글을 썼고 "화이트 라벨" 모델에 대해 언급했습니다., 그 본질은 다른 사람의 능력을 자신의 모습으로 재판매하는 것입니다. 많은 지역에 "자체 데이터 센터"가 있다고 주장하는 현대 호스팅 업체의 대다수는 화이트 라벨 모델을 사용하는 리셀러입니다. 즉, 스위스, 독일, 네덜란드의 조건부 데이터 센터와 물리적으로 아무런 관련이 없습니다.

여기서 매우 흥미로운 충돌이 발생합니다. 서비스 제공업체와의 SLA는 여전히 작동하고 유효하지만, 공급업체는 사고 발생 시 상황에 근본적으로 영향을 미칠 수 없습니다. 그 자신은 재판매를 위해 전원 랙을 구매한 데이터 센터인 자신의 공급업체에 의존적인 위치에 있습니다.

따라서 신뢰성과 서비스에 대한 계약서 및 SLA의 아름다운 문구뿐만 아니라 문제를 신속하게 해결하는 서비스 제공업체의 능력도 중요하게 생각한다면 시설 소유자와 직접 협력해야 합니다. 실제로 여기에는 데이터 센터와의 직접적인 상호 작용이 포함됩니다.

많은 DC가 실제로 한 회사에 속할 수 있는데 왜 옵션을 고려하지 않습니까? 글쎄요, 그런 회사는 거의 없습니다. XNUMX개, XNUMX개, XNUMX개의 소규모 데이터 센터 또는 하나의 대규모 데이터 센터가 가능합니다. 그러나 XNUMX개의 DC(그 중 절반은 러시아 연방에 있고 두 번째는 유럽에 있음)는 거의 불가능합니다. 이는 여러분이 상상하는 것보다 더 많은 리셀러 회사가 있다는 것을 의미합니다. 간단한 예는 다음과 같습니다.

Google Cloud 서비스 데이터 센터 수를 추정합니다. 유럽에는 XNUMX개밖에 없습니다. 런던, 암스테르담, 브뤼셀, 헬싱키, 프랑크푸르트, 취리히. 즉, 모든 주요 고속도로 지점에서 발생합니다. 데이터 센터는 비용이 많이 들고 복잡하며 대규모 프로젝트이기 때문입니다. 이제 "러시아와 유럽 전역에 XNUMX개의 데이터 센터"가 있는 모스크바 어딘가의 호스팅 회사를 기억해 보십시오.

물론 화이트 라벨 프로그램에 파트너가 있는 좋은 공급업체는 없으며 충분하며 최고 수준의 서비스를 제공합니다. 동일한 브라우저 창을 통해 EU와 러시아 연방의 용량을 동시에 임대하고 외화가 아닌 루블로 결제하는 등의 작업이 가능합니다. 그러나 SLA에 설명된 사례가 발생하면 그들은 귀하와 똑같은 상황의 인질이 됩니다.

이는 공급업체의 조직 구조와 역량을 이해하지 못하면 SLA가 쓸모없다는 점을 다시 한 번 상기시켜 줍니다.

결과와의

서버 충돌은 항상 불쾌한 사건이며 누구에게나 어디서든 일어날 수 있습니다. 문제는 상황에 대해 얼마나 많은 통제를 원하는가입니다. 이제 시장에는 용량을 직접 공급하는 업체가 그리 많지 않습니다. 대규모 플레이어에 대해 이야기하면 상대적으로 말하면 유럽 전역에 걸쳐 액세스할 수 있는 DC XNUMX개 중 모스크바 어딘가에 단 하나의 DC만 소유하고 있습니다.

여기에서 각 고객은 스스로 결정해야 합니다. 지금 당장 편안함을 선택할 것인지, 아니면 장비를 배치하거나 용량을 구매할 수 있는 러시아나 유럽의 허용 가능한 위치에 있는 데이터 센터를 찾는 데 시간과 노력을 쏟을 것인지. 첫 번째 경우에는 현재 시장에 나와 있는 표준 솔루션이 적합합니다. 두 번째에는 땀을 흘려야 합니다.

우선, 서비스 판매자가 시설/데이터센터의 직접 소유자인지 여부를 판단할 필요가 있습니다. 화이트 라벨 모델을 사용하는 많은 리셀러는 자신의 상태를 위장하기 위해 최선을 다하며, 이 경우 간접적인 징후를 찾아야 합니다. 예를 들어, "그들의 유럽 DC"에 공급업체 이름과 다른 특정 이름과 로고가 있는 경우입니다. 또는 "파트너"라는 단어가 어딘가에 나타나는 경우. 95%의 경우 파트너 = 화이트 라벨입니다.

다음으로 회사 자체의 구조를 숙지하거나 장비를 직접 살펴보는 것이 더 좋습니다. 데이터 센터 중에서 여행을 하는 관행이나 적어도 자체 웹사이트나 블로그에 여행 기사를 올리는 것은 새로운 것이 아닙니다. 시간 и два)에서는 사진과 자세한 설명을 통해 데이터 센터에 대해 이야기합니다.

많은 데이터 센터가 있으므로 사무실을 직접 방문하거나 DC 자체로의 미니 견학을 계획할 수 있습니다. 거기에서 순서의 정도를 평가할 수 있으며 아마도 엔지니어 중 한 명과 대화할 수 있을 것입니다. 월 300 RUB의 서버 한 대가 필요한 경우 아무도 프로덕션 투어를 제공하지 않을 것이 분명하지만 심각한 용량이 필요한 경우 영업 부서가 귀하를 만날 수 있습니다. 예를 들어, 우리는 그러한 여행을 진행합니다.

어떤 경우에도 상식과 비즈니스 요구 사항을 활용해야 합니다. 예를 들어, 분산 인프라가 필요한 경우(서버 중 일부는 러시아 연방에 있고 다른 서버는 EU에 있음) 화이트 라벨을 사용하여 유럽 DC와 파트너십을 맺은 호스팅 업체의 서비스를 사용하는 것이 더 쉽고 수익성이 높습니다. 모델. 전체 인프라가 한 지점, 즉 하나의 데이터 센터에 집중된다면 공급업체를 찾는 데 시간을 투자할 가치가 있습니다.

일반적인 SLA는 도움이 되지 않을 가능성이 높기 때문입니다. 그러나 리셀러가 아닌 시설 소유자와 협력하면 가능한 문제 해결 속도가 크게 빨라집니다.

출처 : habr.com