- Přehledy IS
- APS (25)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (31)
- CRM (52)
- DMS/ECM - správa dokumentů (19)
- EAM (17)
- Ekonomické systémy (68)
- ERP (87)
- HRM (28)
- ITSM (6)
- MES (33)
- Řízení výroby (36)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (40)
- Dodavatelé CRM (37)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (63)
- Informační bezpečnost (43)
- IT řešení pro logistiku (48)
- IT řešení pro stavebnictví (26)
- Řešení pro veřejný a státní sektor (27)
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údržby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tisk
Přihlaste se k odběru zpravodaje SystemNEWS na LinkedIn, který každý týden přináší výběr článků z oblasti podnikové informatiky | ||
Jak stabilní je vaše služba z pohledu zákazníka?
Je vám povědomá následující situace? Uvádíte novou službu, a abyste měli jistotu, že vše funguje, nastavíte monitorování a přidáte posílání alertů. Máte desítky grafů, dashboard jako v NASA. Sledujete každou smysl dávající systémovou metriku a přes sofistikované eskalační procedury alertujete na 24/7 službu. Výsledek?
Probdělé noci a odstraňování problémů, které neměly na výslednou službu zásadní dopad. Spousta zbytečných alertů, demotivovaný, přetížený a unavený support team. Hašení problémů, často bez odstraňování pravých příčin. Na druhou stranu – situace, kdy alerty omezíme a o problému nás informuje až zákazník, je také špatně. Jak z toho ven?
Sledujte takové parametry vaší služby, které mají přímý vliv na zákaznickou zkušenost.
Jak na to? V Revolgy používáme adoptovanou metodologii Google Site Reliability Engineering (SRE). Naprostým základem SRE je definice metrik, jejichž hodnoty ukazují stabilitu a dostupnost služby. Metriky jsou ukryté pod zkratkami SLO (Service Level Objectives), SLI (Service Level Indicators).
- SLI – Číselně vyjádřený stav zvoleného parametru služby, například latence HTTPs request/response, počet chyb na celkovém počtu přístupů. Hodnoty se agregují za krátká časová období v řádu minut a výsledkem bývá percentil, průměr, rate.
- SLO – Procentuálně vyjádřený stav služby v období, které definujeme v SLA, nejčastěji měsíc. Pro výpočet SLO se používají výstupy SLI metrik.
Jak potřebné SLO určit? S tím nejlépe pomůže product owner služby. Ví, které parametry s jakými hodnotami jsou pro zákazníky důležité.
Definovat SLI je úlohou IT. Chcete na základě definovaných SLO připravit monitoring klíčových parametrů služby z pohledu zákazníka. Pro některé systémy je v tomto případě zákazníkem klient, pro další to může být jen jiné oddělení. Měli byste proto vytvořit dashboardy, které jsou jednoduché, čitelné a srozumitelné i netechnickým kolegům.
SLO mají být jednoduché, měřitelné a na začátek maximálně v počtu tři až pět. Při komplexnějších službách definujeme SLO pro jednotlivé části služby a agregujeme do hlavního SLO. Nezapomínejte na integrované třetí strany, například platební brány či SMS rozhraní. SLO by měly být známy celé vaší společnosti. Vše, co se týče vývoje, správy služby, by jim mělo být podřízené. Jsou to základní pravidla vašeho businessu. Pokud parametry plníte, služba je dodávána ve kvalitě, kterou zákazníci očekávají. Všichni zaměstnanci mají spoluodpovědnost za plnění SLO.
Správně definované SLO dá tu pravou informaci o stavu služby z pohledu jejího uživatele.
Vy tak budete sledovat, jestli jste schopni odbavovat zakázky, ale pokud se ve 3 ráno stane, že RAM na třech serverech je na 75 % obsazenosti, váš tým bude muset vstávat, jen pokud to bude představovat problém pro zákazníka (což v mnoha případech být nemusí).
Pro úplnost, tyto informace samozřejmě nadále mají svůj účel. Jsou cenné při odstraňování konkrétních problémů, na které správně nadefinované SLO metriky ukazují.
SLO dávají prostor pro chyby, kterým se nemůžete vyhnout a jsou přirozené
(takzvaný „error budget“). Při „tří devítkovém“ měsíčním SLO je error budget 43 minut a 20 sekund. Problémy řešené v error budgetu jsou méně stresující, protože díky SLO jsou akceptovány celou společností a nastavují očekávání provozu služby.
Co dělat, pokud služba není aktuálně tak stabilní, abyste byli schopni požadovanou kvalitu dodat? Můžeme si SLO nastavit jako aspirační a pracovat na tom, aby práce na službě a infrastruktuře k cíli směřovala.
SLO v čase měníme tak, jak se mění vaše služba a očekávání zákazníků. Pokud máte hodnoty nastaveny vysoko, může to být omezující pro vývoj nebo správu, nebo je to jen příliš drahé, pak hodnoty SLO snížíte, dokud zákazník nepozná rozdíl. Pokud zákazníci se stabilitou nebo kvalitou služby spokojeni nejsou, je čas nastavit aspirační SLO a vývojem k němu směřovat – někdy omezíme vydávání nových vlastností služby, a místo toho pracujeme na stabilitě, kvalitě.
Smyslem implementace SRE je služba s parametry, které váš zákazník zná a pozná podle nich, jestli vše funguje podle jeho potřeb.
Chcete se o SRE dozvědět více? V Revolgy máme zkušenosti s implementací SRE pro zákazníky s potřebou vysoké dostupnosti a škálovatelnosti. Ozvěte se nám, a zjistěte, jak společně můžeme zlepšit zkušenost zákazníků s vaší službou.
Pavel Krejsa
Autor článku je CTO společnosti Revolgy. |
prosinec - 2024 | ||||||
Po | Út | St | Čt | Pá | So | Ne |
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 | 1 | 2 | 3 | 4 | 5 |
23.1. | Odborný webinář Zabezpečení digitální identity zaměstnanců... |
24.1. | CyberEdu NIS2 Academy - druhý běh |
31.3. | HANNOVER MESSE 2025 |
Formulář pro přidání akce
9.4. | Digital Trust |