Firemní síť ve víru změn

Efektivní řízení změn začíná u správných politik a nástrojů, pozornost si však získává i automatizace a centra...


Efektivní řízení změn začíná u správných politik a nástrojů, pozornost si však
získává i automatizace a centralizovaná kontrola.
Můžeme to nazvat momentem prozření onu zlomovou sekundu, která následuje po
provedení určitého rozhodujícího kroku, kdy si uvědomíte, že jste se dopustili
fatálního omylu. Pro síťové správce to znamená rozdíl mezi odchodem z práce v
pět hodin odpoledne nebo v pět hodin ráno. Pravdou je, nebereme-li v úvahu
incidenty, kdy nedbalý bagrista způsobí porušení optického kabelu nebo bouřka
shodí elektrické vedení, že chyba síťového administrátora bývá nejčastějším
důvodem, proč dochází k selháním v síti.
"Vždycky existuje nějaký důvod, proč něco nefunguje," říká Richard Willmott,
marketingový manažer společnosti IBM/Tivoli. "A nalezení tohoto důvodu
představuje obtížný úkol." Příliš často jsou správci v úzkých, neboť postrádají
dostatek financí, času nebo laboratoř a nástroje potřebné pro to, aby zjistili
plnou šíři důsledků modifikací, které provedli třeba v konfiguraci interního
směrovacího protokolu, nebo přesně určili dopad změn v rozsáhlém přístupovém
seznamu v ostrém provozu. Ačkoliv neexistuje způsob, jak lidské chyby zcela
eliminovat, jsou k dispozici metody, jak omezit jejich následky.

Spolehlivé procesy
Spolehlivé procesy řízení změn spolu s náležitým proškolením a dostatečnou
úrovní potřebných IT zdrojů však mohou skličující pocity, jež vzbuzují
nesourodé systémy v síti a zastaralé nástroje, obrátit v důvěru, i když možná
zdrženlivou. Pak je zde také ITIL (IT Infrastructure Library), což je soubor
osvědčených praktik pro správu IT. Detailně popisuje kroky nezbytné k osvojení
různých metod, které povedou k redukci problémů a zajištění transparentnosti v
síťové infrastruktuře. A konečně je zde také spousta výrobců, jejichž produkty
jsou zaměřeny na zefektivnění a automatizaci procesu řízení změn. Nic z toho
sice nezaručí úplné zabezpečení proti poruchám, to však není důvodem, proč to
nezkusit.
Softwaroví vývojáři mají, jde--li o testování a implementaci změn, určité
výhody. Je naprosto neslýchané, aby programátoři psali a distribuovali kód bez
jakékoliv formy testování. Jejich testovací platformou může být ovšem i laptop
a plnohodnotná infrastruktura laboratoře pro vývoj softwaru většinou odpovídá
nákladům na několik serverů.
Nicméně v případě zařízení zajišťujících přenos signálu je třeba změny
jakéhokoliv rozsahu provádět typicky bez možnosti předchozího testování. Proč?
Protože je takřka nemožné důkladně testovat každý aspekt zamýšlených změn v
konfiguraci sítě. Ve srovnání s potřebou několika serverů pro testovací
vývojové prostředí vyžaduje síťová laboratoř širokou škálu drahého hardwaru,
který by reálně imitoval produkční prostředí. Příkladem může být simulace TDM
obvodů, frame-relay sítí, ISDN linek či dalších typů propojení používaných v
síti. Jednoduché testy s určitou podmnožinou používaného produkčního vybavení
mohou být sice velmi užitečné, avšak související náklady jsou značné a jistota,
že se předpokládaná změna projeví tak, jak se očekává, je vždy poněkud
diskutabilní.

Dvě možnosti
Pro mnohé firemní infrastruktury existují v podstatě dvě cesty, jak se s
problémem vyrovnat. Jednou z nich je laboratorní prostředí, které umožňuje
simulovat určité části sítě; tou druhou jsou silné politiky pro řízení změn a
software, který zavedení a uplatňování těchto politik podpoří. Jedna věc je
neúmyslně způsobit narušení síťového provozu, ale něco jiného je potom zjistit,
že nemáte žádnou zálohu fungující konfigurace a musíte lovit detailní parametry
ve své paměti nebo ze zastaralých konfigurací.
Pomoc zde mohou nabídnout komerční produkty, které jsou k dispozici. Naštěstí
pro potenciálního zájemce panuje mezi výrobci vysoká míra soutěživosti. Někteří
prodejci nabízejí sady produktů, o nichž tvrdí, že mají pomoci při údržbě
politik v heterogenních sítích a v různorodých síťových zařízeních, při
provádění automatického zálohování konfigurace, vyhledávání i obnově.
Například DeviceAuthority Suite společnosti AlterPoint nabízí kompletní síťové
vývojové prostředí postavené na IDE (Integrated Development Environment)
Eclipse, které poskytuje rozsáhlé automatické skriptovací nástroje pro
tvorbu/vývoj konfiguračních změn a jejich uplatňování na vybraná síťová
zařízení.
Takové nástroje tvoří zpravidla jádro každého řešení pro řízení změn. Bez
náležitých metod pro vývoj, implementaci, údržbu a verifikaci konfiguračních
politik na stovkách zařízení nebude záležet na tom, nakolik promyšlené
procedury využíváte. Někteří poskytovatelé nebo provozovatelé datových center
spoléhají dokonce na integrovaný software pro obsluhu helpdesku a identifikaci
změn, aby byli schopni urychlit proces, při němž hledají souvislosti mezi
problémy a nedávno prováděnými změnami, což napomáhá snazšímu odstraňování
síťových poruch. Jestliže je k dispozici framework pro důsledné řízení změn,
pak taková integrace pomůže správcům vytěžit z využívaných nástrojů maximum.

Trochu to zabolí
Pro mnohé administrátory je zavádění řízení změn něco jako návštěva u zubaře je
nezbytné, ale zároveň úděsné. Obecně vzato, změny síťových konfigurací jsou
většinou zdánlivě nepatrné (například doplnění záznamu do rozsáhlého
přístupového seznamu nebo změna v SNMP Community) a vyžadují pro svoji
implementaci řádově několik sekund. Naproti tomu procházení směrnicemi pro
řízení změn, které je někdy trochu obtížné či zdlouhavé, občas může zdánlivě
komplikovat na první pohled přímočaré a snadné úlohy. Dodržování těchto směrnic
se nicméně vyplatí. Jestliže neseberete dostatek odvahy a zubaře nenavštívíte,
vše se tím jenom zhorší a při konfiguraci sítě je situace stejná.
Podniky se mohou na téma správy síťových konfigurací leccos přiučit od
poskytovatelů služeb, jejichž živobytí do značné míry závisí právě na tom,
nakolik plynule, rychle a přesně jsou schopni provádět změny a celý proces
řídit. Téměř všichni velcí poskytovatelé internetových služeb (ISP) mají
zavedeny velmi přesné procedury řízení změn a pro jejich podporu využívají
vyspělé nástroje pro správu konfigurací. Někteří ISP tak důslední nejsou a vše
se tím může zpomalit.
Nedávno jsem asistoval při řešení výpadku v MPLS (Multiprotocol Label
Switching) síti. Ačkoliv jsem nebyl zasvěcen do podrobností o síti operátora,
byl jsem v kontaktu se správcem síťového operačního centra, s nímž jsme
společně problém zkoumali. Kvůli povaze privátních MPLS sítí, které pracují na
vyšší úrovni, mají zařízení třídy carrier mnohem větší vliv na výkon a
spolehlivost služeb. Zatímco tradiční síť založená na technologii frame-relay
pracuje na druhé vrstvě modelu OSI, MPLS sítě využívají 3. vrstvu a zařízení
typu carrier je zodpovědné za údržbu platných cest přes všechny přípojné body
(Points of Presence, POP). Takže když dojde k výpadku sítě a všechny linky jsou
aktivní, problém může spočívat ve směrovacích tabulkách carrier zařízení.
Tak tomu bylo i ve zmiňovaném případě. Problém byl nakonec nalezen ve změně
provedené v konfiguraci routeru tisíce kilometrů od nejvzdálenějšího bodu této
sítě, kde byly chybně vloženy příslušné cesty pro MPLS síť mého klienta do
směrovacích tabulek. Chyba byla způsobena zdánlivě neškodnou změnou ve
směrovací tabulce bez přímého vztahu k síti, kterou bezděčně ovlivnila, a dokud
někdo nekontaktoval technika, který změnu provedl, nikdo netušil, že k ní vůbec
došlo. Trvalo tak tři hodiny, než byl problém identifikován a vyřešen. Kdyby
existovala příslušná politika pro řízení změn, bylo by pravděpodobně možné mu
dokonce i předejít.

Následování ITIL
Stále častěji se lze setkat s tím, že efektivní politiky pro řízení změn
vycházejí z ITIL (IT Infrastructure Library) frameworku. Ve vztahu k řízení
změn představuje ITIL základ postavený na CMDB (Change Management Database,
databáze řízení změn). CMDB může mít takřka jakoukoliv formu od jednoduché
databáze Microsoft Access až po plnohodnotné řešení založené na SQL. CMDB může
rovněž pocházet od dodavatelů specializovaných produktů, jako je Troux CMDB for
ITIL od firmy Troux Technologies. Existuje také několik hostovaných služeb
nabízejících CMDB, které jsou vhodné především pro menší firmy, například
myCMDB.com.
Databáze CMDB obsahuje dokumentaci ohledně veškerého pohybu v rámci
infrastruktury a poskytuje framework pro modifikaci těchto dat, když jsou změny
provedeny.
Proces vytváření a údržby CMDB začíná docela jednoduše: definováním a
zdokumentováním kritických míst ve vaší síti. To nicméně nemusí být jednoduchý
úkol a kdokoliv, kdo investuje do určité aplikace, bude prohlašovat, že je to
kriticky nezbytné, takže je na místě určitá rozvaha. Dobrými příklady kriticky
důležité infrastruktury jsou bezpečnostní systémy, databáze mezd, dodavatelské
a skladové systémy nebo rozhraní pro komunikaci s externími partnery. Tyto
systémy musejí být kompletně od základu zdokumentovány a veškerá data musejí
být vložena v CMDB.
Důležitou stránkou přístupu založeného na CMDB je stanovit vyhovující úroveň
detailnosti, což je důvodem, proč je tak důležité stanovení kritických míst. Je
samozřejmě možné zdokumentovat každý aspekt sítě do nejmenších podrobností, v
jisté situaci to však může být i kontraproduktivní. Omezením rozsahu dat v CMDB
lze předejít riziku, že se utopíte v moři bezvýznamných údajů, budete-li hledat
nezbytné elementy, které mohou mít vliv na vyskytující se problém.
Například nástroje pro správu sítě popsané výše mohou být do CMDB připojeny,
ale při konfiguraci zařízení nemusí být nezbytné, aby bylo vše zaznamenáno do
CMDB. Externí zdroje se mohou o složité detaily na nižší úrovni postarat lépe a
databázi CMDB pak poskytnou pouze podrobnosti o celkové funkci a účelu dané
infrastruktury nebo její části.
Většina výrobců produktů pro správu konfigurací podporuje i koncept řízení
změn. Nicméně mezi oběma přístupy, které spolu vzájemně souvisejí, je rozdíl.
Jedním z aspektů správy konfigurací, který může být jednoznačně užitečný pro
řízení změn, je správa politik a ověření jejich dodržování. Například
TrueControl společnosti Rendition Network dokáže generovat report pro ověření,
že každý přepínač Cisco 2950 v síti má k dispozici stejný přístupový seznam a v
něm je zablokována TCP komunikace pro malé servery. Navíc lze vytvářet politiky
a provádět změny poměrně snadno, čímž se redukuje riziko vzniku lidských chyb,
které by ovlivnily síťové zdroje. Samozřejmé je, že to na druhou stranu přináší
nevýhodu v tom, že se případný omyl rozšíří na všechna zařízení v síti.

První krůčky
Je pochopitelné, že směrnice popisující osvědčené praktiky mohou pomoci pouze
tehdy, když je infrastruktura stabilní. Dobrým způsobem jak takové stability
dosáhnout je nakrátko zmrazit všechny nové projekty. Tato taktika nepochybně
způsobí krátkodobé problémy, avšak dlouhodobá návratnost za to stojí. Jakmile
nebudou zaměstnanci pod tlakem způsobeným nutností rychlé implementace nových
systémů, stabilita vzroste.
Pak je vhodné začít s procesem řízení změn, a to identifikací kritických míst,
realizací potřebné databáze a nalezením nástrojů, s nimiž lze provádět
automatickou aktualizaci databáze. Většina IT firem sleduje různé elementy sítě
spíše minimalistickým nebo i nedostatečným způsobem (třeba v podobě excelovské
tabulky lokalit VLAN atd.). Migrace těchto dat do centrálního archivu je prvním
a zároveň jednoduchým krokem. Stejně, jako je tomu u každé systémové změny,
začít s málem a dosahovat postupných vítězství je začátkem cesty k úspěchu.

Jednotný pohled
Jakmile je CMDB připravena, mohou při její údržbě pomoci vhodné nástroje.
Software helpdesku, který je s CMDB propojen, může poskytnout užitečné
informace a zjednodušit jejich změny, může být však příliš komplexní pro
okamžitou implementaci. Důležitější než rychlé nasazení je ale zajištění
správného zpracování dat z CMDB. Databáze totiž bude užitečná pouze tehdy,
pokud bude obsahovat přesné informace. Díky tomu se vyplatí řídit se při
zavádění jakékoliv formy řízení změn letitou mantrou IT: "Plánovat, plánovat,
plánovat, a pak implementovat." Malé, postupné krůčky přinášejí nejlepší
výsledky.
Důležitým předpokladem pro úspěšnou implementaci příslušného řešení je
sjednocení myšlenek a názorů týkajících konceptu řízení změn. Dokud nebude
každý přesvědčen o výhodách tohoto přístupu, nebude existovat ani dostatečná
stimulace celý systém využívat. Pokud dostane uplatňování politik správný směr
a lidé zodpovědní za provoz sítě uvidí pozitivní výsledky, uchytí se principy
řízení změn velmi rychle.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.