Budapesti Műszaki és Gazdaságtudományi EgyetemMéréstechnika és Információs Rendszerek Tanszék

Szolgáltatási szintek menedzsmentje

Kocsis Imreikocsis@mit.bme.hu

Intelligens rendszerfelügyelet

Motiváció

MotivációÚj high score…

Shiny…Total Cost of Ownership…(≠Total Cost of Acquisition)

Return On Investment(final value, initial value)

Azt írják, hogy az outsourcing csodaszer lehet:- Központi kompetenciákra fókuszálás- Erőforrás-hatékonyság (pénz, humán)

- Kockázat-megosztás

Motiváció

Mi facsavart gyártunk. Miért kell nekünk web,

levelező- és csoportmunka-szerver?

Szervezzük ki!Ha tényleg azt mutatják a számok, hogy ez kell…

Motiváció

?!@!!!Nem megy a levelezés! Nem tudok dolgozni!

Beperelem a szolgáltatót!

Én nem tehetek semmit (khm).Főnök, SLA ugye volt a szerződésben?

?

Motiváció

SLA: Service Level Agreement.

+ Az utóbbi nyolc hónap hat nagy kiesésével is bőven > 99%. Azaz:

ennyiért ezt kapjuk.

Azt írja, hogy:99.9% rendelkezésreállás/hónap;

99.9%-99%: 3 nap visszatérítés<99%: 15 nap visszatérítés

De amikor évente 50$/user...

Motiváció

Tanulság: kritikus szolgáltatásokra legyen formális megállapodás az elvárt minőségről, ami egyezik az

üzleti célokkal.

Mellesleg: ez az IT/IS/… részlegre, mint belső szolgáltatóra is

vonatkozik.

Szolgáltatás-kategóriák és minőségi metrikáik

Bevezető Egy szolgáltatást nyújtó rendszer egymás számára

szolgáltatást nyújtó komponensekből épül fel

Funkcionális és {nem|extra}funkcionális jellemzőko Értelmezés: általában szolgáltatáson, rendszeren vagy

adaton

Főbb nemfunkcionális jellemző-kategóriák:o Szolgáltatásbiztonságo Teljesítményo Adatbiztonság

A szolgáltatásbiztonság attribútumai Rendelkezésre állás (availability)

o Helyes szolgáltatás nyújtására készen állás Megbízhatóság (reliability)

o Helyes szolgáltatás folyamatos nyújtása Biztonságosság (safety)

o Katasztrofális következmények hiánya Integritás (integrity)

o „Nem megfelelő” rendszerváltozások hiánya Karbantarthatóság (maintainability)

oMódosíthatóság és javíthatóság

Ezek nem metrikák (mérőszámok).

1. Metrika (matematikailag): lásd távolságfüggvények

2. Metrika (IT): - mérhető/számolható…- …rendszer/szolgáltatásjellemző,- rendezett értelmezési tartománnyal- + időintervallum/időpont

Szolgáltatásbiztonsági metrikák Rendelkezésre állás: annak a valószínűsége, hogy egy

rendszer szolgáltatás nyújtására készen áll.

Megbízhatóság: annak a valószínűsége, hogy egy rendszer képes elvégezni a feladatát (egy adott időintervallumban, megadott feltételek mellett).

)()()(

DOWNTIMEEUPTIMEEUPTIMEEA

t

dxxftTPtR )()()(

Hibahatás valószínűségi sűrűség függvény

Szolgáltatásbiztonsági metrikák Ezek valószínűségi változók, mi meg mérni

akarunk…o És sokszor csak mintavételezetten tudunk

Availability: „Tapasztalati várható érték” (mintaátlag)

Periodikus mintavételezésből származó hiba!

UP

DOWN 60 s

Rendelkezésre állás Tfh. A szolgáltatásunk web hoszting (~50 szerver) 97%?

o ~11 nap kiesés megengedett egy évbeno „COTS” hardver elég, „next business day” support sem kell

mindenképpo Pipe: nincsenek különösebb igények

99,9%?o ~9 óra kiesés megengedett egy évbeno Erős monitorozás, legalább napi backupo HW hibák ellen: automatizált helyreállítás még működő node-ra

beépített redundancia (vagy jó HW)o SLA a hálózati kapcsolatra

99,999%?

(Szégyentelen) önreklám: http://www.saforum.org/about/companies/

Az adatbiztonság attribútumai Rendelkezésre állás, Integritás, Bizalmasság (confidentiality).

Magas szintű, két szolgáltatás (implementáció) összehasonlítását lehetővé tevő metrikák?o A háttérben nincs tiszta, SAP állapotgépo Bináris szemlélet

• Megtörték/nem törték meg• Megtörhető/nem megtörhető

oMegfigyelhetőség?

Az adatbiztonság metrikái Az elterjedt (könnyen számolható) metrikák sokszor

korlátozottan használhatóako „Ismert, de nem patch-elt sérülékenységek száma”o „Támadási felület”o „Sérülékenységek historikus alakulása”o…

Elméletben a cél a kockázat szembeállítása lenne a megtérülésselo Esemény kockázata = valószínűség * költségo Számítása…?

Teljesítmény – szolgáltatás-típusok Erősen szolgáltatás-típus függő

o Van értelme a válaszidőnek IPTV esetén?

Kérés-válasz jellegű szolgáltatásoko HTTP, DNS, POP3, adatbázisok, …

(Valósidejű) adatfolyam-szolgáltatásoko Streaming audio/video

Erőforrás-nyújtás szolgáltatásoko „utility computing” (Amazon EC2, S3)

Teljesítmény korlátozottan érdekes:• Erőforrás-hozzáférés (resource allowance)

• CPU, tárhely, memória• Esetleg: ütemezés és áteresztőképességek

• Diszk I/O

Teljesítmény – szolgáltatás-típusok Kötegelt feldolgozás

o Nyomtatás Kliensalkalmazások?

Folyamatok teljesítményeo Általánosan is érdekes – lásd pl. backend rendszereko Kiemelendő: támogató folyamatok (ITIL)

Kérés-válasz szolgáltatások teljesítménye Feldolgozási idő (processing time)

Válaszidő (response time)o Felhasználó által érzékelt (user-percieved): hálózati

késleltetések (latency) + feldolgozási időo Lehet tovább részletezni

Throughput („átmenő teljesítmény” / „áteresztőképesség”)o # feldolgozott „feladatok”/időegység (s)

Fontos:- Sokaságokat vizsgálunk legalább MIN/MAX/AVG- Küszöbellenőrzésnél ált. megengedünk kisszámú kieső értéket - a kérések 95%-ának válaszideje < 5 s

Kérés-válasz szolgáltatások teljesítménye Az iparban használt definíciók nem teljesen egységesek Mi „szabványos”?

o Hálózati szinto Amit az egyes tool-ok mérnek o Benchmark-ok egyes metrikái

Teljesítmény-benchmarkoko Cél: tipikus szolgáltatások egyes megvalósításainak

egymással összehasonlíthatóságao Szabványos szolgáltatás-definícióo Szabványos terheléso Szabványos teljesítmény-metrikáko Általában fizetni kell értük

Kérés-válasz szolgáltatások teljesítménye Standard Performance Evaluation Corporation

(SPEC)o SPECjAppServer2004 (J2EE 1.3)o SPECjbb2005 (nagykereskedelmi rendelésfeldolgozás)o SPECweb2005 (HTTP(S); PHP és JSP)o…

Transaction Processing Performance Councilo TPC-App (alkalmazáskiszolgálók, web service-ek)o TPC-C (adatbázisok)o TPC-W (többrétegű, tranzakciókezelő webes szolg.)

Elsődleges metrikák:- „Web Interactions per Second” (WIPS)- „cost per WIPS”

Metrikák kiválasztása és származtatása Amit eddig elhallgattunk: egy metrikával céljaink

szoktak lenni. Pl.:o „Megfelelő” szolgáltatás-minőség definiálása, követéseoMagas szintű szolgáltatás-minőségi metrikák

származtatásao Rendszerfelügyeleti döntések vezérlése

De: már a szolgáltatási szinten is rengeteg metrika értelmezhető. Mi a fontos? Hogyan válasszunk?

Példa: „Goal – Question - Metric” módszer (GQM)

Goal

Question 1 Question 2

Metric 1 Metric 2 Metric 3

Metric 1' Metric 2' Metric 3'

System

GQMdefinitionphase

Modeling & operation phase

check consistency

Cél: „online” érzet biztosítása

Mennyi ideig kell a felhasználónak várnia, míg megjelenik az oldalunk?

Válaszidő Böngésző renderelési idő

Folyamatok minőségjellemzői: néhány ITIL Configuration Management metrika

• Tartsuk nyilván az összes IT eszközt és konfigurációt

• Adjunk pontos információt ezekről más folyamatoknak

• Nyilvántartás verifikálása és javításaCélok

• Pontos modell hatékony nyilvántartásaMetrika cél

(„Question”) • # rossz CMDB adatól származó

meghiúsult RFC-k• # nem megengedett konfigurációk• # rosszul dokumentált CI-k által okozott,

meghiúsult változtatásokból származó incidensek

• # CMDB hibából származó SLA-sértés

Metrika

Folyamatok minőségjellemzői: néhány ITIL Configuration Management metrika

• Tartsuk nyilván az összes IT eszközt és konfigurációt

• Adjunk pontos információt ezekről más folyamatoknak

• Nyilvántartás verifikálása és javításaCélok

• CMDB pontos információt adjon át más folyamatoknak

Metrika cél(„Question”)

• # RFC-k megfelelő CI-frissítés nélkül• Pontatlan CI-k arányaMetrika

Szolgáltatási szint szerződések

Szolgáltatási szint szerződések Service Level Agreement (SLA)

Szolgáltatátó és igénybevevő közötti megállapodáso A szolgáltatás meghatározó minőségi jellemzőirőlo A vonatkozó kötelezettségekről mindkét oldalono Az SLA megsértése esetén való eljárásrendről

Szolgáltató és vevő között általában formális, valódi szerződéso Lehet nem jogi erejű is: belső SLA-k

Ma már gyakorlatilag minden szolgáltatási szektorbano Eredetileg: telco

SLA-k jellemző elemei

A nyújtott szolgáltatás funkcionális leírása

Minőségi jellemzők és korlátaiko Vonatkozó minőségi metrikák definíciójao Célok (SLO-k)/kiértékelés definíciójao Alacsonyabb szintű metrikákból származtatás

megadása (lehet rekurzív)oMérés mikéntjének precíz definíciója

SLA-k jellemző elemei Szolgáltatási szint monitorozás és jelentés

folyamata

Fontos részkérdés: ki mér?o Vevő

• Hozzáférés szintje a szolgáltatói infrastruktúrához?• Pontatlanságot okozó zavaró tényezők?

o Szolgáltató• Meglevő instrumentáció testre szabása?• Megbízható validálás nélkül?

SLA-k jellemző elemei Problémák jelentésének a folyamata

Problémákra reagálás és megoldásuk időkeretei

SLA sértés következményei

Felmentő- és kivétel-cikkelyek („escape clauses”)o Katasztrófáko Nem megfelelő viselkedés a felhasználó részérőlo Karbantartási időszakok, munkaidőo Üzleti hatás nélküli kiesések

Leíró nyelvek A természetes nyelv sokszor elég. Elektronikus SLA-reprezentáció és megegyezés

(negotiation)? Főleg SOA-forgatókönyvek esetén:

o Automatikus (web) service felderítés (discovery)o (Fél)automatikus szolgáltatás-választás

Néhány példa:o Web Service Level Agreements (WSLA) keretrendszer (IBM)o „Akadémiai” nyelvek: SLAng, WSOL (Web Service Offerings

Language), CC-Pi (concurrent constraint pi calculus), …o WS-Agreement (doménspecifikus nyelv beágyazandó!)

ITIL: Service Level Management

Service Level Management (ITUP)

„Service Level Management is the process of negotiating, defining, measuring, managing and improving the quality of IT services at an acceptable cost.”

„Create and Maintain Service Catalog” ITIL fogalom: szolgáltatás-katalógus

o Röviden: egy szervezet által vagy a részlegeinek/alkalmazottainak, vagy a „vevőinek” nyújtott szolgáltatások katalógusa

Összefoghatja pl.:o A szolgáltatás leírásáto A vonatkozó SLA-kato A felhasználókato A vonatkozó költségeketo A vonatkozó Operational Level Agreement-eketo „Underpinning Contracts”o …

Magyarul: a szolgáltatás, mint önálló entitás jelenjen meg (és legyen adminisztratívan kezelve)

„Create and Maintain SLA-s”

„Create and Maintain SLA-s”

Belső/külső szolgáltatók, OLA-k,

UC-k

„Finalizing, Committing to, Executing upon, Publishing, …”

„Monitor and Report SL Achievements”

Szubjektív elégedettség is!

„Monitor and Report SL Achievements”

Referenciák, linkek D.C. Verma: „Service level agreements on IP networks”.

Proceedings of the IEEE, Volume 92, Issue 9, pp 1382 – 1388, 2004.

A. Keller, H.Ludwig: „The WSLA framework: Specifying and monitoring service level agreements for web services”. Journal of Network and Systems Management, Volume 11, Number 1, pp 57-81, Springer, 2003.

M.G. Bruscemi, U. Montanari: „CC-Pi: A Constraint-Based Language for Specifying Service Level Agreements”. In: Programming Languages and Systems, LNCS 4421, pp 18-32, Springer, 2007.

V. Tosic et al: „Management applications of the web service offerings language (WSOL)”. Information Systems, Volume 30, Number 7, pp 564-586, 2005, Elsevier.

Referenciák, linkek Web services agreement specification (WS-Agreement). Global

Grid Forum, 2004.o http://

www.opengridforum.org/Public_Comment_Docs/Documents/Oct-2006/WS-AgreementSpecificationDraftFinal_sp_tn_jpver_v2.pdf

A Avizienis, J.C. Laprie, B. Randell, C. Landwehr, „Basic Concepts and Taxonomy of Dependable and Secure Computing”, IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2004, IEEE Computer Society.

Standard Performance Evaluation Corporationo http://www.spec.org

Transaction Processing Performance Councilo http://www.tpc.org

itSMF: Metrics for IT Service Management. Van Haren Publishing, 2006.