Případové studie.

Případové studie uvádíme ve zkrácené podobě. O konkrétní referenci se rádi pobavíme při osobním jednání.

Služba

Technologie a oblasti

Řazení

Aktivní filtrSlužba: IT architektura a konzultace

Zobrazeno 6 z 10 případových studií pro službu IT architektura a konzultace

Podnikové IT

Audit Windows serverů a cesta ke sjednocené správě zařízení

Střední podnik, serverová infrastruktura a notebooky · Analýza a doporučení

2× shoda

Zadání: Serverová část rostla léta bez revize a nikdo neměl přehled, které systémy se blíží konci podpory. Notebooky se navíc spravovaly ručně, každý jinak.
Řešení: Prošli jsme Windows serverovou infrastrukturu a sestavili přehled životního cyklu jednotlivých systémů. Souběžně jsme porovnali možnosti sjednocené správy zařízení, ochranu stanic, správu mobilních i firemních zařízení a jednotnou správu koncových bodů.
Výsledek: Firma ví, které servery je nutné řešit letos a které počkají, a má porovnané varianty správy zařízení včetně toho, co která znamená pro každodenní práci IT.

Dodavatel bezpečnostních řešení

Návrh platformy pro nasazení u koncového zákazníka · Technický návrh a kapacitní výpočet

2× shoda

Zadání: Dodavatel potřeboval podložit, na jakém hardwaru jeho bezpečnostní platforma poběží, tak, aby návrh obstál před zákazníkem i před nákupem.
Řešení: Zpracovali jsme technický návrh serverové, úložné a síťové vrstvy na enterprise technologiích. K němu patří kapacitní výpočet, který počítá s provozním i budoucím zatížením, ne jen se špičkou v den nasazení.
Výsledek: Vznikl dokument, se kterým se dá jít rovnou do poptávky: každá položka má odůvodnění, proč je právě v tomto rozsahu.

Geodata a chytrá mobilita

Serverová platforma pro provoz služeb · Návrh konfigurace a dodávka

2× shoda

Zadání: Dodavatel mapových služeb potřeboval serverovou platformu, která unese provoz dnes a přitom nebude za rok blokovat rozšíření.
Řešení: Navrhli jsme konfiguraci, spočítali potřebnou kapacitu a hardware dodali, s ohledem na spolehlivost, prostor pro rozšíření a dostupnost servisu v horizontu životnosti.
Výsledek: Platforma má rezervu pro růst, takže rozšíření znamená doplnění komponent místo výměny celého řešení.

Provozně citlivé prostředí

Ověřovací nasazení na části provozu · Návrh a ověřovací nasazení

2× shoda

Zadání: Privilegované účty se sdílely a nešlo zpětně určit, kdo konkrétní zásah provedl. Zákazník potřeboval vědět, jestli zavedení řízených přístupů nezpomalí samotný provoz.
Řešení: Připravili jsme návrh správy privilegovaných přístupů a ověřili ho na omezeném rozsahu: definice rolí, evidence relací a napojení na stávající správu identit, na reálném provozu, ne v laboratoři.
Výsledek: Zákazník má ověřený model, u kterého ví, jak se chová v jeho prostředí, a rozhodnutí o plošném nasazení stojí na vyzkoušené věci místo na prezentaci.

Poskytovatel ICT služeb

Několik oddělených prostředí · Architektonický návrh

2× shoda

Zadání: Administrátorské účty se používaly odděleně v každém prostředí zvlášť. Nebylo jednotně dohledatelné, kdo kdy k čemu přistoupil, a zároveň nešlo připustit výpadek správy ani na chvíli.
Řešení: Navrhli jsme správu privilegovaných přístupů pro serverové platformy, databáze i kontejnerovou orchestraci napříč oddělenými prostředími, včetně napojení na správu identit, vícefaktorového ověření a předávání bezpečnostních událostí do centrálního vyhodnocování.
Výsledek: Návrh počítá s tím, že vysoká dostupnost a dohledatelnost přístupů si neodporují: správa běží dál i při výpadku jedné komponenty a každá relace zůstává zpětně dohledatelná.

Lesnictví a zemědělství

Národní instituce, dvě lokality · Návrh a realizace

2× shoda

Zadání: Aplikace běžely přímo na fyzických serverech a organizace neměla odzkoušený postup, jak obnovit provoz po havárii. Odpověď na otázku „jak dlouho budeme stát a o kolik dat přijdeme“ neexistovala.
Řešení: Postavili jsme virtualizační platformu ve dvou lokalitách a k ní zálohovací vrstvu s deduplikací a sekundárním úložištěm pro dlouhodobou archivaci. Se zákazníkem jsme pojmenovali kritické systémy, stanovili pro ně cíle RPO a RTO a z toho odvodili zálohovací strategii i plán obnovy po havárii.
Výsledek: Obnova se pravidelně zkouší nanečisto, takže organizace zná reálnou dobu návratu do provozu. Postup je popsaný v dokumentu, podle kterého se dá jednat i ve chvíli, kdy hlavní lokalita neběží.