Konferencja Time For SharePoint

15-19 listopada 2010

Nasi partnerzy

Wysoka dostępność SharePoint 2010 w kontekście umów SLA

Tobiasz Janusz Koprowski

{get BIO}

• związany z informatyką od połowy lat dziewięćdziesiątych • kilkuletnie doświadczenie w informatyce bankowej *Zorba, AS/400, ICBS, BTeller] • od ponad pięciu lat pracuje w spółce informatycznej • na co dzień interesujący się MOSS, Disaster Recovery, High Availibility, wirtualizacją, bezpieczeństwem, procedurami operacyjnymi (SEC, DR, HA), SLA, ISO, ITIL • konsultant i wdrożeniowiec przy projektach audytów licencyjnych, systemów procedur bezpieczeństwa i operacyjnych, wdrożeniach platformy SharePoint, • uczestnik kilku programów Microsoft: Connect, Community Leadership Programm, ITPro Momentum, VS2010 Terminology Community, Windows 7 Beta, Desktop Deployment Planning Service, New Efficiency Program, Subject Matter Expert • lider wrocławskiej grupy Polish SQL Server User Group • prelegent na spotkaniach społeczności • Microsoft System Center Influencer • Członek GLOBAL Technical Support Team w GITCA • Director-at-Large GITCA EMEA Board • Członek PASS Programm Committee for 2010 • Współtwórca PASS SQL Azure Virtual Chapter • Autor kilku artykułów technicznych i współpracownik wydawnictwa aPress oraz TechNet • właściciel kilku blogów (w tym trzech specjalizowanych) • W lipcu 2010 wyróżniony nagrodą MVP w kategorii SQL Server

Agenda

Czym jest HA (High Availibility)

Dlaczego SLA – co to jest?

Zastosowanie HA w organizacji

Zastosowanie SLA w organizacji

Zależności SLA i HA

Przykłady

Q&A

Czym jest HA ?

Wysoka dostępność (HA) to zapewnienie nieprzerwanej pracy urządzeń i systemów na potrzeby (zazwyczaj) środowiska produkcyjnego w przedsiębiorstwie.

Ma zapobiegać utracie danych w wyniku: błędów oprogramowania,

defektów produkcyjnych,

awarii sprzętowych

naturalnych katastrof

błędów człowieka

innych nieprzewidzianych zdarzeń

Dwa rodzaje niedostępności:

PSO Planned System Outages – Planowana Niedostępność Systemu

zaplanowana minimalna niedostępność systemu, spowodowana koniecznością przeprowadzenia prac modernizacyjnych, instalacji poprawek, wymianą/rozszerzeniem rozwiązań sprzętowych,

uzgodniona z klientem i nie wpływająca na postanowienia HA i SLA, do momentu<

USO Unplaned System Outages – Nieplanowana Niedostępność Systemu

wystąpienie błędu uniemożliwiającego częściową, bądź całkowita pracę środowiska w sposób odczuwalny, mierzalny przez klienta

powodująca wysokie koszty w przypadku konieczności napraw, jak również płatności karnych za niewykonanie SLA

Wskaźniki wydajności (HA)

Każdy z nas słyszał o popularnych dziewiątkach?

Co to naprawdę jest dostępność rzędu 99,99%?

Dostępność 99,99% to NIEDOSTĘPNOŚĆ rzędu 0,01% w zadanym okresie (np. rocznym), czyli<

Ile to jest w przeliczeniu na niedostępność serwera/środowiska/witryny/kolekcji:

Availability = MTBF / MTBF + MTTR

MTBF -> Mean Time Between Failures

MTTR -> Mean Time To Repair

Niedostępności w dniach, godzinach, minutach

Availability % Downtime per year Downtime per month* Downtime per week

90% 36.5 days 72 hours 16.8 hours

95% 18.25 days 36 hours 8.4 hours

98% 7.30 days 14.4 hours 3.36 hours

99% 3.65 days 7.20 hours 1.68 hours

99.5% 1.83 days 3.60 hours 50.4 min

99.8% 17.52 hours 86.23 min 20.16 min

99.9% ("three nines") 8.76 hours 43.2 min 10.1 min

99.95% 4.38 hours 21.56 min 5.04 min

99.99% ("four nines") 52.6 min 4.32 min 1.01 min

99.999% ("five nines") 5.26 min 25.9 s 6.05 s

99.9999% ("six nines") 31.5 s 2.59 s 0.605 s

Czym jest SLA?

SLA – Service Level Agreement.

Początki sięgają 1980 roku i umów pomiędzy operatorami telekomunikacyjnymi i klientami końcowymi.

Obustronnie negocjowalna umowa o świadczenie usług (nie tylko IT, choć tych w szczególności)

Powinna być zawarta formalnie, choć prawnie dopuszczalna jest umowa nieformalna

Obejmująca poziom i zakres świadczonej usługi za pomocą mierzalnych wskaźników (poziom dostępności, użyteczności, wydajności)

Umowa powinna mieć sprecyzowany zakres minimum i maksimum dla każdej podlegającej jej usługi

Mierzalność SLA

Nie ma umowy SLA bez określonych wskaźników pomiaru!!!

PRZYKŁAD DLA CALL CENTER / SERVICE DESK:

ABA (Abandonment Rate): Odsetek porzuconych połączeń podczas oczekiwania na odpowiedź.

ASA (Average Speed to Answer): Średnia czasu (zazwyczaj w sekundach) potrzebny do połączenia z help deskiem.

TSF (Time Service Factor): Odsetek odebranych połączeń w precyzyjnych ramach czasowych, np. 80% w 20 sekund.

FCR (First Call Resolution): Procent połączenia, podczas których problem został rozwiązany bez konieczności przełączania do innego eksperta

TAT (Turn Around Time): Czas potrzebny do zakończenia określonych zadań.

Gwarancja SLA w Google

Piotr Waszczuk, IDG News Service

31 października 2008 16:17

Computerworld

Wczoraj (30 października) Google wprowadził gwarancję dostępności komercyjnej wersji pakietu aplikacji biurowych. Umowa SLA ma obejmować m.in. aplikacje: Kalendarz, Dokumenty i Google Sites oraz usługę Google Talk. Wcześniej gwarancja taka dotyczyła tylko usługi Gmail.

Google zobowiązał się do zapewnienia dostępności pakietu Google Apps Premier Edition na poziomie 99,9 proc. w skali miesiąca. W ramach rekompensaty za ewentualne dłuższe przerwy w dostępności koncern zamierza oferować klientom darmowy dostęp do komercyjnych usług. Przykładowo, jeśli dostępność Google Apps spadnie poniżej poziomu 99 proc. w ciągu miesiąca klienci będą mogli za darmo korzystać z aplikacji przez trzy dni. W przypadku dostępności na poziomie niższym niż 95 proc. użytkownicy Google Apps Premier Edition zostaną zwolnieni z opłat na 15 dni.

Uwzględniane będą jednak tylko przestoje trwające dłużej niż 10 minut. Umowa SLA nie uwzględnia również planowanych przerw technicznych, zapowiedzianych z co najmniej pięciodniowym wyprzedzeniem. Jednocześnie Google zobowiązuje się, że przerwy takie nie będą trwały dłużej niż 12 godzin rocznie.

Zapowiedź rozszerzenia gwarancji dostępności jest odpowiedzią na wzrastającą liczbę zarzutów dotyczących spadku jakości oferowanych usług. Tylko w październiku niektórzy użytkownicy Google Apps nie mogli korzystać z aplikacji nawet przez 30 godzin. Według oficjalnych informacji z aplikacji Google Apps korzysta ponad 500 tys. firm z całego świata oraz ponad 10 mln aktywnych użytkowników.

SLA – co to ma wspólnego z administratorem

Godziny Pracy: Godziny w których kolekcja/witryna/strona/lista/dokument/wersja

(środowisko) danych musi być dostępna Może być różny dla różnych części środowiskaych, zależnych np. od

aplikacji Procent czasu działania usługi:

Procent czasu w ciągu (zakresu czasowego) kiedy środowisko jest dostępne

Godziny zastrzeżone dla przestojów: Podane z wyprzedzeniem godziny przestojów (przerwy techniczne)

ułatwiają pracę użytkownikom • Metody pomocy dla użytkowników

• Czas odpowiedzi od HelpDesku • Czas reakcji ADMINISTRATORA na zdarzenie

SLA – co to ma wspólnego z administratorem - cd

Liczba użytkowników w systemie Liczba transakcji obsługiwanych w danej jednostce czasu Dopuszczalne poziomy osiągów dla dostępu do różnych operacji Minimalny czas wymagany do replikacji na różne serwery

Termin na odzyskanie danych z awarii Przypadkowe usunięcie danych Uszkodzenie bazy danych SQL Server Crash OS Server Crash Czas potrzebny na odczytanie danych w internecie (np. odczyt/zapis

tabeli sprzedaży tak by można było kontynuować prowadzenie sprzedaży)

Maksymalna ilość miejsca Maksymalna ilość miejsca na strony, kolekcje, listy, biblioteki,

dokumenty Ilość użytkowników w konkretnych rolach

Czy wiesz dlaczego SLA jest ważne?

Tak naprawdę to coś więcej niż tylko podpisana umowa między klientem a twoim szefem.

Jest to kontrakt który również TY musisz spełniać

Jeśli jest podpisana umowa na zero przestojów i zero utraty danych (abstrakcja?) to musisz mieć pewność, że w przypadku korupcji możesz tę umowę spełnić (zmiana/usunięcie danych celowo przez autoryzowanego użytkownika).

Jeśli nie możesz spełnić SLA, to biznes narażony jest na przestoje i utratę danych

Końcowym efektem jest złożenie swojego CV do agencji pracy<

Czy myślisz że możesz spełnić swoje SLA?

Musisz wiedzieć jakie są warunki/wymagania dla SLA jeżeli masz je spełnić

Jak możesz je spełnić, jeśli nie wiesz że istnieje umowa SLA?

Jak możesz przejrzeć umowę skoro nikt Cię nie zaprosił na spotkanie w sprawie stworzenia umowy SLA?

Końcowym efektem jest złożenie swojego CV do agencji pracy<

Warunki SLA dla Office SharePoint Online (1) Standard terms applicable to all Service Levels outlined herein:

Definitions

“Claim” means a claim submitted by Customer to Microsoft pursuant to this SLA that a Service Level has not been met and that a Service Credit may be due to Customer.

“Customer” refers to the organization that has signed a volume licensing agreement (“Agreement”) under which it has purchased Microsoft SharePoint Online Services from Microsoft.

“Customer Support” means the services by which Microsoft may provide assistance to Customer to resolve issues with the Services.

“Incident” means any set of circumstances resulting in a failure to meet a Service Level.

“Microsoft” means the Microsoft entity that signed your Microsoft Agreement.

“Service” or “Services” refers to the Microsoft SharePoint Online service provided to Customer pursuant to the Agreement.

“Service Credit” is the percentage of the monthly service fees for the Service that is credited to Customer for a validated Claim.

“Service Level” means standards Microsoft agrees to adhere to and by which it measures the level of service it provides as specifically set forth below.

Warunki SLA dla Office SharePoint Online (2) Service Credit Claims

Microsoft provides this SLA subject to the following terms. These terms will be fixed for the duration of the initial term of the subscription. If a subscription is renewed, the version of this SLA that is current at the time the renewal term commences will apply throughout the renewal term. Customer can review the most current version of the SLA and related terms at any time by visiting http://go.microsoft.com/fwlink/?LinkID=127035.

In order to be eligible to submit a Claim with respect to any Incident, the Customer must first have notified Customer Support of the Incident, using the procedures set forth by Microsoft, within five business days following the Incident.

To submit a Claim, Customer must contact Customer Support and provide notice of its intention to submit a Claim. Customer must provide to Customer Support all reasonable details regarding the Claim, including but not limited to, detailed descriptions of the Incident(s), the duration of the Incidents, the number of affected users and the locations of such users and any attempts made by Customer to resolve the Incident.

In order for Microsoft to consider a Claim, Customer must submit the Claim, including sufficient evidence to support the Claim, by the end of the month following the month in which the Incident which is the subject of the Claim occurs.

Microsoft will use all information reasonably available to it to validate Claims and make a good faith judgment on whether the SLA and Service Levels apply to the Claim.

Warunki SLA dla Office SharePoint Online (3) Configuration Requirements and Acceptable Use

Customers must adhere to any required configurations, use supported platforms, and follow any policies for acceptable use found at http://go.microsoft.com/fwlink/?LinkId=128857 in order to make Claims.

SLA Exclusions

This SLA and any applicable Service Levels do not apply to any performance or availability issues:

Due to factors outside Microsoft’s reasonable control;

That resulted from Customer’s or third party hardware or software;

That resulted from actions or inactions of Customer or third parties;

Caused by Customer’s use of the Service after Microsoft advised Customer to modify its use of the Service, if Customer did not modified its use as advised;

During scheduled downtime; or

During beta and trial Services (as determined by Microsoft).

Service Credits

The amount and method of calculation of Service Credits is described below in connection with each Service Level description.

Service Credits are Customer’s sole and exclusive remedy for any violation of this SLA.

The Service Credits awarded in any calendar month shall not, under any circumstance, exceed Customer’s monthly Service fees.

For Services purchased as part of a suite, the Service Credit will be based on the pro-rata portion of the cost of the Service, as determined by Microsoft in its reasonable discretion. In cases where Customer has purchased Services from a reseller, the Service Credit will be based on the estimated retail price for the applicable Service, as determined by Microsoft in its reasonable discretion.

Warunki SLA dla Office SharePoint Online (4)

Monthly Uptime Percentage Service Credit

< 99.9% 25%

< 99% 50%

< 95% 100%

Service Levels

1. Monthly Uptime Service Level

a. Definitions

i. “Downtime” is defined as any period of time when users are unable to read or write any portion of a SharePoint site collection for which they have appropriate permissions. Downtime does not include the period of time when the Service is not available as a result of: (i) Scheduled Downtime or scheduled network, hardware, or Service maintenance or upgrades; or (ii) the acts or omissions of Customer or Customer’s employees, agents, contractors, or vendors, or anyone gaining access to Microsoft’s network by means of Customer’s passwords or equipment.

ii. “Scheduled Downtime” is defined as those times where Microsoft notifies Customer of periods of Downtime at least five days prior to the commencement of such Downtime. Scheduled Downtime of fewer than 10 hours per calendar year is not considered Downtime for purposes of this SLA.

iii. “Monthly Uptime Percentage” for a specific Customer is calculated by taking the total number of minutes in a calendar month multiplied by the total number of licensed users minus the total number of minutes of Downtime experienced by all users in a given calendar month, all divided by the total number of minutes in that calendar month multiplied by the total number of users.

Jak zabrać się do SLA?

SharePoint 2010 Planning Guide zawiera kilka dobrych przykładowych warunków dla SharePoint SLA Opracowanie umów o poziomie usług dla każdego poziomu serwisu. Taka umowa powinna zawierać następujące elementy: Czas i wymagania proceduralne niezbędne dla stworzenia nowej strony (kto taka stronę tworzy? Kto jest zaangażowany w proces) ; Informacje o kosztach usług dla użytkowników lub działów (kto i za co jest obciążany) Ustalenia operacyjne pozwalające jednoznacznie stwierdzić który zespół jest odpowiedzialny za daną działkę i jak często owe prace są wykonywane (Jaki zespół instaluje poprawki? Jaki zespół realizuje zadania backupowe? Jak często owe czynności są wykonywane?) Polityki rozwiązywania problemów przez help desk (gdzie zgłaszacćincydenty? Jak je rejestrować? Jak eskalować?) Negocjowalne warunki przetworzenia dla pierwszego obciążenia środowiska, testów okolicznościowych (lub cyklicznych) i wydajności w odległych lokalizacjach (odtworzenia, rozłożenie ruchu, strategie akcji typu failover) Możliwości dostosowywania wszelkich polityk związanych ze świadczeniem usług. Limit wielkości miejsca dla danych, bibliotek, dokumentów Obsługa wielu języków (Jakie języki muszą być zainstalowane i wspierane)

Podsumowanie

Musisz wiedzieć o istnieniu SLA

Musisz brać udział w tworzeniu umowy SLA (wymagań/możliwości/technologii)

Musisz mieć plany awaryjne – PRZETESTOWANE

Musisz mieć wiedzę o swojej odpowiedzialności

Musisz mieć możliwość techniczną dotrzymania umowy SLA

PYTANIA PO SESJI / KONTAKT:

MAIL: KoprowskiT@windowslive.com | MSG: KoprowskiT@windowslive.com JABBER: KoprowskiT@alfa.incenti.net.pl | SKYPE: tjkoprowski (niezmiernie rzadko)

TWITTER/FACEBOOK/LINKEDIN: KoprowskiT

BLOGI: ITPRO Anorak’s Vision: http://itblogs.pl/notbeautifulanymore/ [PL] Volume Licensing Specialites: http://koprowskit.eu/licensing/ [PL]

My MVP Blog: http://koprowskit.eu/geek [EN/PL]

POLECANE STRONY: Społeczności IT: http://www.ms-groups.pl | CodeGuru: http://www.codeguru.pl

Virtual Study: http://www.virtualstudy.pl | Windows Server System: http://www.wss.pl Global IT Community Association: http://www.gitca.org Polish SQL Server User Group: http://www.plssug.org.pl

Professional Association of SQL Server: http://www.sqlpass.org

DZIĘKUJĘ ZA UWAGĘ