Az ITIL-lel és a változáskezeléssel a Visible Ops keretrendszer új megközelítést ígér a hatékony informatikai működési modell létrehozásához. Sikerének esélye azonban kétségtelen, anélkül, hogy az IT beszerzési, tervezési, konfigurálási, érvényesítési és megvalósítási módját megváltoztatnák.
Szeresd vagy utáld, ITIL és változáskezelés mindig szerves része lesz minden IT-felépítésnek, és olyan szabályozások, mint a Basel III, a FISMA, a Sarbanes-Oxley és a HIPAA folyamatosan a szervezeti vezetők nyakába lélegeznek.
Miután egyszer kaptam egy lila kitűzőt ITIL-gurut viselve egy menedzsernek, lenyűgözött, hogy a keretrendszert minden informatikai problémánk megoldásaként szorgalmazta. Megismételhető és ellenőrizhető informatikai folyamatok meghatározásával foglalkozott, de ez mindig inkább elméleti, mint gyakorlati lett.
Ez a különbségtétel soha nem volt olyan nyilvánvaló, mint a szinte értelmetlen heti változási tanácsadó testületi üléseken. Míg maguk a folyamatok fájdalmasan bürokratikusak voltak, és gyakran eltereltek az operatív munkától, maguk az ülések furcsák voltak.
Alig volt jelen valaki, a testület minden változtatáshoz indoklást kérne, „jóváhagy” válasz mellett. vagy „elutasították”, még akkor is, ha nyilvánvaló volt, hogy alig vagy egyáltalán nem értik a megadott technikai magyarázatot vagy következtetést.
Még mindig megmagyarázhatatlan módon átmentek minden ellenőrzésen, ami viszont legitimálta a radar alatti működési gyakorlatot, amely arra szolgált, hogy égve maradjanak a lámpák.
Aztán ott volt a biztonsági és kockázatmegfelelős fickó, aki bezárkózott a szobájába, a Tripwire műszerfalához ragasztva, és kémkedett minden jóváhagyatlan változtatás után. Képzelje el csodálkozását, amikor bemutattam neki a VMware-t és a vMotiont.
A virtuális gépek fizikai szervereken való áttelepítése anélkül, hogy változást idézett volna elő, és anélkül, hogy a Tripwire-en fel tudta volna venni azt, őrületbe hozta. Szórakoztatva a folyamatos fejrázásán, úgy döntöttem, hogy felfedem, hogy a LUN-okat is zökkenőmentesen migráltam különböző RAID-csoportok között. a HDS sebességtartó automatikájával, hogy több orsót működtessen, majd visszarohant a barlangjába, hogy ellenőrizze, hogy Tripwire választotta-e fel. Tényleg minden vMotion vagy LUN áttelepítésnél változást kellett volna felhoznom?
Néhány évvel később műszaki tanácsadóként nem javult a változási tanácsadó testület hatékonyságáról alkotott benyomásom. Egyik késő este egy ügyfél adatközpontjában felhívtam a figyelmet arra, hogy rossz portokat csatlakoztattak, és ez változtatást igényel.
„Nincs rá szükség” – válaszolta a SAN építésze – „Én az igazgatótanács egyik tagja vagyok”. Ezután széles vigyorral az arcán kihúzta és kicserélte az FC-kábeleket a produkciós műsorvezetőire. Néhány perccel később megcsörrent a telefonja, amire azt válaszolta: "Rendben van, megoldottam. Áramkimaradás volt néhány szerveren." Aztán egy kacsintással felém fordult, és azt mondta: "Tessék. Rendezett. Lubbly nyüzsgő."
Az ITIL gyakorlatiasságával szembeni kezdeti szkepticizmusom a személyes tapasztalataimra összpontosított, de ezt csak megerősítette a számos külső auditorok, akik állítólag ellenőrizték, hogy megfelelő ellenőrzések léteznek-e ebben a sok tűzoltó és cowboy szervezetben eljárások.
Mint a gyerekek osztályterme, akik hallják, amint a tanár feljön a folyosón, és az asztalukhoz rohanva alkot. a fegyelem és a rend benyomása, a megfelelõ nép utolsó pillanatban történt változásai soha nem szűntek megdöbbenteni nekem. Annak ellenére, hogy napi 1-es prioritásúak voltak, megmagyarázhatatlan módon átmentek minden ellenőrzésen, ami viszont legitimálta a lámpák égve tartását szolgáló, álságos radar alatti működési gyakorlatot.
Tehát az ITIL ilyen elmosódott tapasztalata miatt nagy érdeklődéssel kezdtem közelebbről megvizsgálni az ITIL kezdeményezését. Az ITPI látható műveletei. Miközben ötleteit továbbra is az ITIL-terminológiához igazítja, a Visible Ops a szolgáltatási szint növelésére, a költségek csökkentésére, valamint a biztonság és az auditálhatóság növelésére helyezi a terhet. A legegyszerűbb megfogalmazásban a Visible Ops egy gyorsított gyakorlat egy hatékony működési modellhez, amely négy lépésben reprodukálja a jól teljesítő szervezetek kutatott folyamatait:
1. fázis. Stabilizálja a beteget
Tekintettel arra, hogy a kimaradások csaknem 80 százaléka saját maga okozza, az ütemezett karbantartáson kívüli bármilyen változás gyorsan befagy. Ezután a problémakezelők számára kötelezővé válik, hogy minden változással kapcsolatos információ kéznél legyen, hogy mikor hogy a nem tervezett munkák 80 százaléka megkezdődik a kiváltó ok teljes megértése gyorsan alapított.
Ez a fázis azokkal a rendszerekkel és üzleti folyamatokkal kezdődik, amelyek a legnagyobb mennyiségért felelősek tűzoltás, mert ezek megoldása munkaciklusokat szabadítana fel a biztonságosabb és kimért útvonal elindításához változás.
2. fázis. Fogja meg és engedje el, és találjon törékeny műtárgyakat
Ez a fázis magához az infrastruktúrához kapcsolódik, azzal a tudattal, hogy azt nem lehet többszörösen reprodukálni. Az eszközök, konfigurációk és szolgáltatások pontos leltárának megszerzésével a cél az, hogy azonosítsa azokat a műtermékeket, amelyek a legalacsonyabb változtatási sikerarányt, a legmagasabb MTTR-t és a legmagasabb üzletet mutatják leállási költségek.
Mindezen eszközök és kölcsönös függőségeik rögzítésével egy szervezet sokkal biztonságosabb helyzetbe kerül az 1. prioritású tűzoltási munkamenet előtt.
3. fázis. Hozzon létre megismételhető build könyvtárat
Ez a fázis egy hatékony kiadáskezelési folyamat megvalósítására összpontosít. Az előző fázisokat lépcsőfokként használva ez a fázis dokumentálja a legkritikusabb eszközök és szolgáltatások megismételhető összeállításait, így azok újjáépítése költséghatékonyabb, mint a javítás.
Egy olyan folyamatban, amely a szabványos buildek hatékony tömeggyártásához vezet, a vezető IT-műveleti munkatársak reaktívból proaktív kiadáskezelési modelllé alakulhatnak át.
Ez az átalakítás az IT-műveletek életciklusának korai szakaszában valósul meg, következetesen dolgozva a szoftver- és integrációs kiadásokon az éles környezetben történő üzembe helyezés előtt.
Ugyanakkor az egyedi gyártási konfigurációk csökkentését szorgalmazzák, következésképpen növelve a konfigurációt élettartama a csere vagy megváltoztatás előtt, ami viszont a kezelhetőség javulásához és csökkentéséhez vezet bonyolultság.
Végül ezek az ismételhető buildek lehetővé teszik „arany” képek létrehozását, amelyeket a gyártás előtt kipróbáltak, teszteltek, megterveztek és jóváhagytak. Tehát amikor új alkalmazásokat, javításokat és frissítéseket adnak ki integráció céljából, ezeket az aranyos buildeket vagy képeket csupán frissíteni kell.
4. fázis. Folyamatos fejlesztés engedélyezése
Ez eléggé magától értetődő abból a szempontból, hogy egy zárt hurok kialakításával foglalkozik a kiadási, vezérlési és feloldási folyamatok között. Az előző három fázis befejezésével a három kulcsfontosságú folyamatterület – a kiadás, a vezérlők és a felbontás – mérőszámai fókuszba helyezik, különösen azokat, amelyek elősegítik a gyors döntéshozatalt, és pontos mutatószámokat adnak a munkáról és annak sikerességéről működési folyamat.
Az ITIL meghibásodás előtti átlagos idő (MTBF) és a javítás átlagos idejére vonatkozó feloldási folyamat metrikái alapján (MTTR) ez a fázis a kiadást az infrastruktúra hatékony és eredményességének mérésével vizsgálja ellátva. Az ellenőrzéseket azon mérik, hogy a meghozott változtatási döntések milyen hatékonyan tartják fenn a termelési infrastruktúrát elérhető, kiszámítható és biztonságos, míg a megoldást a problémák azonosításának és hatékonyságának mértéke számszerűsíti megoldva.
Tehát bár a Visible Ops jól néz ki papíron, mi különbözteti meg igazán attól, hogy potenciálisan csak egy újabb elméleti folyamat, amelyet a gyakorlati valóságban nem sikerül átfogóan megvalósítani?
Ha az IT beszerzésének, tervezésének, konfigurálásának, érvényesítésének és megvalósításának módja változatlan marad, A Visible Opsnak kevés esélye van, ha egyáltalán nincs olyan sikeres, mint a lila jelvény szerelmesei ITIL.
A Visible Ops végül szenvedni fog, ha a keretrendszer alapját képező informatikai infrastruktúra ugyanazzal a gondolkodásmóddal épül fel, amely a problémákat okozta.
De mi van akkor, ha az IT megközelítése és pontosabban infrastruktúrája megváltozna a hagyományostól vásárold meg a sajátodat, csavard össze és imádkozz, hogy működjön, és ehelyett egy fenntarthatóbb és kiszámítható modell?
Mi van akkor, ha az infrastruktúra megközelítése a zöldmezős megközelítés vagy a zökkenőmentes migráció a előtesztelt, előrevalidált, előre integrált, előre elkészített és előre konfigurált termék – azaz egy igazi konvergált termék infrastruktúra? Milyen hatással lehet ez a Visible Ops és a négy fázis sikerére?
Az 1. fázis azonnal elérhető egy összevont infrastruktúrával, ahol a szervezetnek már nem kell időt töltenie a változás kockázatainak és hatásainak vizsgálatával. A szabványosított termékalapú megközelítéssel több ezer órányi minőségbiztosítási tesztelés és elemzés végezhető el a szállító minden új javítás, firmware-frissítés vagy egy hasonló termékhez tartozó frissítés esetén vevő.
Ezzel a megközelítéssel egy féléves kiadási tanúsítási mátrix előfeltételeként működik, amely frissíti az összes összetevőt a konvergált infrastruktúra átfogó egészének a változási folyamattal jellemzően összefüggő kockázatok Eltüntetett.
Továbbá, mivel a változtatásokat ez az előre tesztelt és előzetesen jóváhagyott folyamat diktálja, és ehhez a mátrixhoz kell ragaszkodniuk támogatáson belül marad, segít a szélhámos alapú változtatások felszámolásában, valamint tájékoztatja a problémakezelőket a szükségesekről változtatások.
Végső soron az 1. fázis stabilizálási célja azonnal elérhető a kockázatcsökkentéssel, amely egy előre megtervezett, előre meghatározott és előre tesztelt frissítési útvonal megvalósításával jár.
A 2. fázis kihívása, amely lényegében egyenértékű az infrastruktúra esetleges teljes leltárával, fájdalmas folyamat. a legjobb időkben, különösen, mivel folyamatosan vásárolnak új készleteket különböző gyártóktól, és a meglévő készlethez rögzítik.
Egyszerűsített vagyonkezelés
A konvergens infrastruktúrára való átállás leegyszerűsíti ezt a kihívást, mivel egyetlen termékről van szó, és így egyetlen cikkszámról van szó a beszerzésnél. A termék alkatrészeit és minden részletét a gyártó ismeri, így biztosítva a pontos leltározást és az egyszerűsített vagyonkezelési folyamatot.
Amikor javításokra, frissítésekre, új alkatrészek és komponensek kiegészítésére van szükség, ezek automatikusan felkerülnek az egyes termék készletlistájára, így biztosítva a naprakész vagyonkezelést.
A 3. fázis kiadáskezelési követelménye olyan kihívást jelent, amely nem csak kockázattal jár, hanem vállalja is jelentős mennyiségű személyzet és vezetői idő annak biztosítására, hogy a technológia és az infrastruktúra megfelelő maradjon dátum.
A konvergens infrastruktúra azonnal megfelel ennek a kihívásnak azáltal, hogy előtesztelt, validált szoftvereket és a végfelhasználó számára elérhető firmware-frissítések, amelyek lehetővé teszik számukra, hogy megtalálják a számára megfelelő kiadásokat rendszer.
Ami az újjáépítést illeti a 3. fázisban a javítási megközelítéssel szemben, mivel az összevont infrastruktúra mindössze 30 nap alatt telepíthető és üzembe helyezhető, hasonló szabványosított infrastruktúrával rendelkezni az új és a közelgő projektekhez sokkal könnyebb folyamat a szokásos építsd magad infrastruktúrához képest modell.
Számlázási és visszaterhelési modell
Részletesebb szinten azáltal, hogy van egy menedzsment és hangszerelési köteg önkiszolgáló portállal, arany Az image virtuális gépek azonnal üzembe helyezhetők számlázási és visszaterhelési modellel, valamint integrációval a CMDB.
Az eredmény a Visible Ops modell 3. fázisának gyors és sikeres elérése egy egységes kiadás és konfigurációkezelési módszertan, amely nagymértékben kiszámítható, és az együttműködési képesség csökkentésével javítja a rendelkezésre állást problémák.
Az olyan mérőszámok, mint például az MTTR és az MTBF, a 4. fázisban részletezett sikerének mérése végső soron az infrastruktúrához bevezetett felügyeleti és támogatási modell sikeréhez kapcsolódik. Az infrastruktúra termékalapú megközelítésével a támogatási modell is jobban fel van szerelve a folyamatos fejlesztés biztosítására.
Egy terméken alapuló eszkalációs válaszfolyamat, függetlenül attól, hogy a probléma megoldásához szükség van-e A több szakértővel vagy alkotócsoporttal folytatott konzultáció végső soron zökkenőmentes és egyetlen kapcsolattartási pontot jelent minden kérdésre.
Teljes körű elszámoltathatóság
Az infrastruktúra támogatásával, karbantartásával és garanciájával kapcsolatos teljes körű elszámoltathatóság a problémamegoldás és a rendelkezésre állás nyomon követését sokkal egyszerűbben mérhető és figyelhető modellré teszi.
Továbbá a nyílt API-kkal, amelyek lehetővé teszik az átfogó felügyeleti és felügyeleti szoftverplatformokkal való integrációt, a konvergált Az infrastruktúra kihasználtsága, teljesítmény- és kapacitásmenedzsmentje, valamint a megjelölhető potenciális problémák nyomon követhetők proaktívan támogatni.
Ahogy az IT-működési hatékonyság egyre inkább elengedhetetlen a vállalkozások számára világszerte, az elméleti a sikertelen gyakorlatokat vagy értékelik, megkérdőjelezik, vagy bizonyos esetekben folytatják.
Amit gyakran figyelmen kívül hagynak, az az, hogy az egyik eredendő probléma az informatikai infrastruktúra kiépítésének és kezelésének hagyományos megközelítése.
Még az olyan radikális és jól kutatott megközelítések és keretrendszerek is, mint a Visible Ops, végül szenvedni fognak, ha az IT Az infrastruktúra, amelyre a keretrendszer épül, ugyanazzal a gondolkodásmóddal épült, amely a problémákat okozta.
Alapvetően attól függ, hogy a Visible Ops modell komoly megfontolást jelent-e a környezet számára vagy sem, a konvergens infrastruktúrával rendelkező keretrendszer átvételével az IT-infrastruktúra stabilizálása, szabványosítása és optimalizálása, és annak szolgáltatásai az üzlet számára sokkal praktikusabbá, következésképpen sokkal kevésbé elméleti.