4. {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
5. 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
6. 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ń
7. 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
8. 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
9. 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
10. 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
11. 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ń.
12. 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.
13. 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
14. 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
15. 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<
16. 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<
17. 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.
18. 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.
19. 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.
20. Warunki SLA dla Office SharePoint Online (4)
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.
Monthly Uptime Percentage Service Credit
< 99.9% 25%
< 99% 50%
< 95% 100%
21. 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)
22. 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
23. 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