2009/7/21 Anton Turygin :

Ага. Заявки кастомеров типа "дайте мне гарантированый канал до Индии" поражают воображение ;-)

Совершенно нормальные заявки, ничто не мешает такую услугу предоставить. Вообще написание договоров о предоставлении услуг (Интернет-доступ, VPN и пр.) наука не слишком сложная, но требует а) системности и б) навыков. В частности системность - это начать договор с раздела 1 "Предмет договора", а продолжить - разделом 2 "Термины и определения", потом разделом 3 "Обозначения и сокращения". Тем самым установить понятийный аппарат. После чего дальнейшее (права и обязанности сторон, в т.ч. касаемо SLA) писать, чётко и пунктуально опираясь на понятийный аппарат, и тщательно избегая применения в тексте каких-либо понятий, терминов и сокращений, которые не определены чётко ранее. Составление договоров - тоже есть формальная методика, которая позволяет избежать "белых пятен" неопределенности, спорных моментов и логических ловушек (из которых потом растут арбитражные ситуации). В этом и состоит ремесло юристконсульта. Без этого же (многократно наблюдал-с) получается какой-то птичий базар, хлопанье крыльями, говорильня и кудахтанье, в стиле, столь свойственном Herr Mc'Stoolyeff (то есть в практической плоскости - "мутная вода", словесное трёпокружево, и - в конечном итоге - попадалово абонента, или "инвестора"...)

2009/7/21 Anton Turygin

...

Ага. Заявки кастомеров типа "дайте мне гарантированый канал до Индии" поражают воображение ;-)

Совершенно нормальные заявки, ничто не мешает такую услугу предоставить.

С гарантированым RTT и Jiter-ом? ;) На разве что в рамках акции "Распродажа воздуха".

А если кастомер заплатит денег, которых хватит на покупку провайдеров по дороге? ;-) -- Regards, Michael Bochkaryov www.rattler.kiev.ua

Hi, Tue, Jul 21, 2009 at 18:07:22, pa3op wrote about "Re: [uanog] Re: [uanog] Про SLA и дата-центры":

...

...

Ага. Заявки кастомеров типа "дайте мне гарантированый канал до Индии" поражают воображение ;-)

Совершенно нормальные заявки, ничто не мешает такую услугу предоставить.

С гарантированым RTT и Jiter-ом? ;) На разве что в рамках акции "Распродажа воздуха".

Всё проще: надо всего лишь вспомнить методы построения сетей с гарантированной полосой пропускания. То, что в результате всемирного кретинизма они почти везде похерены, и про канал гарантированной ширины сейчас сложно заикаться, а сети с коммутацией каналов идут под нож - не даёт основание поддерживать этот всемирный кретинизм со своей стороны. -netch-

On Tue, Jul 21, 2009 at 11:29:24PM +0300, Valentin Nechayev wrote:

...

...

...

Ага. Заявки кастомеров типа "дайте мне гарантированый канал до Индии" поражают воображение ;-)

Совершенно нормальные заявки, ничто не мешает такую услугу предоставить.

С гарантированым RTT и Jiter-ом? ;) На разве что в рамках акции "Распродажа воздуха".

Всё проще: надо всего лишь вспомнить методы построения сетей с гарантированной полосой пропускания. То, что в результате всемирного кретинизма они почти везде похерены, и про канал гарантированной ширины сейчас сложно заикаться, а сети с коммутацией каналов идут под нож - не даёт основание поддерживать этот всемирный кретинизм со своей стороны.

Сейчас такие сети начинают восстанавливаться, видимо, услуга опять начала пользоваться платежеспособным спросом. man diffserv-aware mpls traffic engineering (или - очень хорошая книжка mpls-enabled applications, второе издание). Ну и плюс, сети с коммутацией каналов на сейчас не только идут под нож, но и активно строятся, вот только называются dwdm и установка канала (пока) делается в основном с помощью ручного прописывания.

On Wed, 22 Jul 2009, Andrey Zarechansky wrote:

...

...

...

Ага. Заявки кастомеров типа "дайте мне гарантированый канал до Индии" поражают воображение ;-)

...

Совершенно нормальные заявки, ничто не мешает такую услугу предоставить.

С гарантированым RTT и Jiter-ом? ;) На разве что в рамках акции "Распродажа воздуха".

1. Резервированые подключения к услугам транзита ip. 2. Работающий механизм SLA между тобой и провайдерами транзита, включающий такие параметры как RTT и Jiter для каждого класса трафика. 3. Достаточная информация о cети партнеров и их окнах обслуживания. 4. Работающие внутрение механизмы поддержания SLA учитывающие KPI/KPQ. 4.1 Работающие внутрение механизмы оценки рисков и расширения емкости. 6. Грамотный SLA с клиентом в котором, в том числе, озвучена методика измерения RTT и Jiter'а для каждого из классов трафика.

Все. И при чем тут 'распрдажа воздуха' если разговор идет об SLA?

Хотел по пунктам отвечать, но нет смысла ;-) У тебя есть прямой пиринг/аплинк в Индии?

Возьми полный текст договора со своим аплинками и перечитай. Там все расписано.

У меня нету ;-( Сам знаешь, почему. -- RAZ-UANIC RAZ-RIPE

Hello Andrey Zarechansky! Wed, Jul 22, 2009 at 02:08:29AM +0300, zorick wrote about "Re: [uanog] Re: [uanog] Про SLA и дата-центры":

Возьми полный текст договора со своим аплинками и перечитай. Там все расписано.

Есть тут вот один международный оператор с омериканским происхождением, да есть целый раздел SLA с соотв. компенсациями за не соотв. RTT/Packet loss до определенных узлов в их сети, но (!) попытка запросить у них какие же это узлы (их IP) и какая методика подсчета закончилась ответом, что это внутренняя не разглашаемая информация. Т.е. организовать контроль SLA со стороны клиента не возможно - можно только при малейших проблемах жаловаться в саппорт и _может_ быть они потом учтут это при подсчете оплаты. -- //ShaD0w

Hello Andrey Zarechansky! Wed, Jul 22, 2009 at 12:29:49PM +0300, zorick wrote about "Re: [uanog] Re: [uanog] Про SLA и дата-центры":

Почему описание расчета SLA и методики контроля со стороны клиента не было передано еще на этапе тендера? Почему необходимые изменения не были внесены в контракт на этапе подписания? Почему после подобного отказа не была начата процедура закупки аналогичной емкости от другого оператора?

Думаю найдется много причин почему Вам это не [было] нужно.

Угу, скажем так, что причины не технического характера.

Почему 'жалоба в саппорт' воспринимается как что-то унизительное с точки зрения клиента? Ведь это часть механизма работы SLA: есть зафиксированое обращение - начался отсчет времени и денег, нет обращения - никто никому ничего не должен.

Да нет ничего унизительного, просто хотелось автоматизировать эту самую жалобу в саппорт, что бы не пропустить эти самые нарушения SLA со стороны оператора, а они вот скрывают :) -- //ShaD0w

Добрий вечір усім. Хм... Я скажу пару приватних думок, абсолютно без претензії на якусь там глобальну правоту. Все тут кажуть ніби-то й правильно. Ну, кожен гарно описує (і впевнений, що абсолютно чесно та щиросердно!) конкретний окремий випадок в своєму житті ще й помножений на екстраполяцію свого суб'єктивного життєвого досвіду :) Забули зафіксувати лише кілька дрібних деталей: 1. SLA - це якраз і є абсолютно окремий конкретний випадок. От як між собою домовляться дві сторони (а в реалі - це дві людини) - так і буде. 2. Не буває "шаблонів" SLA. А той, хто працює на основі "шаблонів SLA" - або "галімий кідала", або "галімий ламер". Це стосується обох сторін. Хоча ось таки шаблон http://zmejgorynych.blogspot.com/2008/07/sla.html :). 3. Best practice каже, що реально працювати згідно підписаних (sic!) SLA можна лише після того, як: - між провайдером та клієнтом вже є певен досвід співпраці (існує певна довіра), і він в принципі задовольняє обидві сторони - у провайдера є реально діюча система KPI/KQI як мінімум для тих підрозділів, котрі працюють на гарантію параметрів, обіцяних клієнту. Це є лише абсолютно необхідні (але часто не достатні!) умови. Те, що свою інфраструктуру треба знати і гарантувати клієнту availability & accessibility- це одне. Але можна й заробляти гроші на розв'язанні системи лінійних рівнянь :). Аби лише клієнт був з цим згоден. Наприклад, у провайдера-1 є SLA з провайдером-2 про певні QoS-параметри між site-1 та site-2. З передбаченими штрафними санкціями. Ну то кожному з них окремо ніщо не заважає так складати SLA для своїх клієнтів, щоби сума потенційних штрафів провайдера за порушення *цих*QoS-параметрів була меншою за штрафи між провайдерами. Уф.. Велика тема. Ціла наука. Є багато людей та підрозділів, котрі вже десяток років займаються лише цією темою. Regards, /oleh 2009/7/21 Andrew Stesin

2009/7/21 Anton Turygin :

...

Ага. Заявки кастомеров типа "дайте мне гарантированый канал до Индии" поражают воображение ;-)

Совершенно нормальные заявки, ничто не мешает такую услугу предоставить.

Вообще написание договоров о предоставлении услуг (Интернет-доступ, VPN и пр.) наука не слишком сложная, но требует а) системности и б) навыков. В частности системность - это начать договор с раздела 1 "Предмет договора", а продолжить - разделом 2 "Термины и определения", потом разделом 3 "Обозначения и сокращения". Тем самым установить понятийный аппарат.

После чего дальнейшее (права и обязанности сторон, в т.ч. касаемо SLA) писать, чётко и пунктуально опираясь на понятийный аппарат, и тщательно избегая применения в тексте каких-либо понятий, терминов и сокращений, которые не определены чётко ранее.

Составление договоров - тоже есть формальная методика, которая позволяет избежать "белых пятен" неопределенности, спорных моментов и логических ловушек (из которых потом растут арбитражные ситуации). В этом и состоит ремесло юристконсульта.

Без этого же (многократно наблюдал-с) получается какой-то птичий базар, хлопанье крыльями, говорильня и кудахтанье, в стиле, столь свойственном Herr Mc'Stoolyeff (то есть в практической плоскости - "мутная вода", словесное трёпокружево, и - в конечном итоге - попадалово абонента, или "инвестора"...)

2009/7/21 Alexandre Snarskii

On Tue, Jul 21, 2009 at 06:33:07PM +0300, Oleh Hrynchuk wrote:

...

Добрий веч?р ус?м.

Хм... Я скажу пару приватних думок, абсолютно без претенз?? на якусь там глобальну правоту.

Все тут кажуть н?би-то й правильно. Ну, кожен гарно опису? (? впевнений, що абсолютно чесно та щиросердно!) конкретний окремий випадок в сво?му житт? ще й помножений на екстраполяц?ю свого суб'?ктивного житт?вого досв?ду :)

Забули заф?ксувати лише к?лька др?бних деталей: 1. SLA - це якраз ? ? абсолютно окремий конкретний випадок. От як м?ж собою домовляться дв? сторони (а в реал? - це дв? людини) - так ? буде.

2. Не бува? "шаблон?в" SLA. А той, хто працю? на основ? "шаблон?в SLA" - або "гал?мий к?дала", або "гал?мий ламер". Це стосу?ться обох стор?н. Хоча ось таки шаблон :).

Мне вот интересно, а к какой категории ты отнесешь нас, при том, что в любом типовом договоре у нас прописан типовой SLA ? :)

Саш, я by default не говорив про retail-продажі, of course. Лише про корпоративний сектор. Далі все зрозуміло, думаю... Вибачаюсь. Мабуть-таки треба було конкретно це сказати.

On Tue, 21 Jul 2009, Max Tulyev wrote:

Anton Turygin wrote:

...

On Tue, 21 Jul 2009, Max Tulyev wrote:

...

Michael Bochkaryov wrote:

...

Суть SLA сводится к тому, что ты уверен в своей инфраструктуре и готов в том случае, когда она таки не сработает, компенсировать это клиенту. Естественно, за такую страховку клиент платит денег соответственно твоим обязательствам.

Вооот! В _своей_ инфраструктуре! А никак не в паблик Интернете!

Ага. Заявки кастомеров типа "дайте мне гарантированый канал до Индии" поражают воображение ;-)

Так можно ж и дать-то, чего не дать? Но это будет по-другому построенная услуга, а не доступ в Интернет!

Ну если опять кастомер с Индией появится - буду знать, куда отправлять ;-) Услуга ж суть тот же интернет, только сбоку... -- RAZ-UANIC RAZ-RIPE

On Tue, 21 Jul 2009, Dmitry Cherkasov wrote:

2009/7/21 Anton Turygin : On Tue, 21 Jul 2009, Max Tulyev wrote:

...

Michael Bochkaryov wrote:

...

Суть SLA сводится к тому, что ты уверен в своей инфраструктуре и готов в том случае, когда она таки не сработает, компенсировать это клиенту. Естественно, за такую страховку клиент платит денег соответственно твоим обязательствам.

Вооот! В _своей_ инфраструктуре! А никак не в паблик Интернете!

Ага. Заявки кастомеров типа "дайте мне гарантированый канал до Индии" поражают воображение ;-)

Вопрос стоимости. Заключаете договор с каким-нибудь Cable & Wireless, у которого есть точки здесь и в Индии, и формируете цену для клиента. В свое время выяснял вопрос для одного клиента, который хотел гарантированный канал в Ю.Корею. Вопрос перепродажи _транспортного_ канала понятен. Но просят же гарантию до определенного _IP_ ;-) (Возможно я изначально неправильно описал, чего просили ;-) -- RAZ-UANIC RAZ-RIPE Technological Systems CJSC Senior Network Engineer

On Tue, 21 Jul 2009, Andrew Stesin wrote:

2009/7/21 Anton Turygin :

       Но просят же гарантию до определенного _IP_ ;-)

и так возможно - всё дело в правильном прописании договора Андрей, в Договоре возможно все. Другой вопрос, как оно соотносится с действительностью. Или предлагаешь продавать так, чтобы профит в любом случае покрывал затраты и штрафы (то есть мы уверенны на 100%, что штрафы мы таки заплатим)? -- RAZ-UANIC RAZ-RIPE

On Tue, 21 Jul 2009, Andrew Stesin wrote:

2009/7/21 Anton Turygin :        Андрей, в Договоре возможно все. Другой вопрос, как оно        соотносится с действительностью.

Хроническая вавка в голове украинского бизнеса - это именно разделять "договор" и "действительность"... небезызвестную тебе Т.П. вспоминаю в этой связи Да не только украинского.

Или предлагаешь продавать так, чтобы профит в любом случае покрывал затраты и штрафы (то есть мы уверенны на 100%, что штрафы мы таки заплатим)?

Нет. Почитай, что написал Олег Гринчук. Это отдельная наука - составить договор так, чтобы он удовлетворил стороны и его можно было реально исполнить. Просто не любая компания до этого понимания доросла, и не только в Украине. Да я-то читаю. Интересно. Только вот практически каждая контора у нас, которая готова технически к предоставлению SLA пытыется наскоком взять все остальные аспекты. Оно и понятно. Опыт практически нулевой. Ткните, плз, в толковую литератру по вопросу SLA. По всем аспектам вопроса ;-) Очень не хочется кучу ненужной лабуды через мозги пропускать в поисках ;-( -- RAZ-UANIC RAZ-RIPE

2009/7/21 Michael Bochkaryov :

...

       Ткните, плз, в толковую литератру по вопросу SLA. По всем аспектам Если не ошибаюсь, то в ITIL эта тема хорошо раскрывается.

И в eTOM тоже. Если быть точным, то eTOM версии 8 это как раз продукт кагбэ "слияния" идей eTOM v.7.5 и ITIL v.3

2009/7/21 Anton Turygin

[dd]

Ткните, плз, в толковую литератру по вопросу SLA. По всем аспектам вопроса ;-) Очень не хочется кучу ненужной лабуды через мозги пропускать в поисках ;-(

Квінтесенція (Bible) операторського SLA - "TMForum's SLA Management Handbook": GB917-1, GB917-2, GB917-3, GB917-4. * Volume 1 - SLA Management Handbook - Executive Overview; * Volume 2 - SLA Management Handbook - Concepts and Principles; * Volume 3 - SLA Management Handbook - Service and Technology Examples; * Volume 4 - SLA Management Handbook - Enterprise Perspective. Volume 1 is written for Chief Executive Officers (CEO) and Board of Directors members. It is a concise introduction to SLA Concepts, Business Case, Benefits, and Consequences for telecommunication service customers, SPs, and hardware and software suppliers. Volume 1 also addresses where SLAs reside within the modern market place. Volume 2 is written for the telecommunication and supplier managers. It provides the detail behind SLA principles such as Service Access Point (SAP), Service Delivery Point (SDP), SLA management process mapping onto eTOM, service parameter framework, and measurement and reporting strategies. Volume 3 is written for Telecommunication and Supplier implementers. It describes how to apply the SLA principles defined in Volume 2 to a representative set of technologies. Volume 3 also includes a checklist of items typically included within telecommunication service SLAs. Volume 4 is written for enterprise managers and implementers. It addresses business application and services as well as internal and external network services. In this context it generically describes enterprise performance requirements for end-to-end services. A number of enterprise business applications of SLAs are described in detail. Ну а URL на "шаблон SLA" на основі цих рекомендацій я вже приводив раніше. -- Regards, /oleh