Kujutage ette, et teil on täisserveri infrastruktuur: mitu tosinat kliimaseadet, hulk DGU-sid ja katkestusteta toiteallikaid. Selleks, et "rauad" töötaksid õigesti, kontrollite regulaarselt nende töövõimet ja ei unusta profülaktikat: teete katsekäivitusi, kontrollite õlitaset, vahetate osi. Isegi ühe serveri jaoks tuleb hoida palju teavet: seadmete register, tarvikute loetelu laos, profülaktikakava ning ka garantii dokumendid, lepingud tarnijate ja alltöövõtjatega.
Nüüd korrutame ruumide arvu kümnega. Ilmuvad logistika küsimused. Millises laos hoida mida, et mitte joosta iga varuosa järele? Kuidas õigel ajal varusid täiendada, et ettenägematu remont ei üllataks? Kui seadmeid on palju, ei ole kõiki tehnilisi töid peas hoida võimalik ning paberil – keeruline. Siin tuleb appi MMS, ehk hooldusjuhtimise süsteem (MMS) – tehnilise hoolduse haldamise süsteem.
MMS-is koostatakse ennetavate ja remondi tööde ajakavad ning säilitatakse inseneride juhised. Mitte kõik andmekeskused ei kasuta sellist süsteemi, paljud peavad seda liiga kalliks lahenduseks. Kuid meie kogemuse põhjal oleme veendunud, et tööriist ei ole oluline, vaid lähenemine informatsiooniga töötamisele. Esimese süsteemi lõime Excelis ja arendasime seda järk-järgult tarkvaratooteks.
Koos otsustasime jagada oma kogemust MMS-i arendamisel. Näitan, kuidas süsteem arenes ja aitas parendada parimaid praktikaid. Aleksei räägib, kuidas sai MMS-i päranduseks, mis selle aja jooksul muutunud on ja kuidas süsteem lihtsustab inseneride elu nüüd.
Kuidas me jõudsime oma MMS-ini
Alguses olid kaustad. 8-10 aastat tagasi hoiti teavet hajusalt. Pärast tehnilist hooldust allkirjastasime lõpetamise aktid, säilitades paberilised originaalid arhiivis ja skanneeritud koopiad võrgu kaustades. Samamoodi kogusime kaustades, mis olid jagatud seadmete järgi, ZIPl'e kohta teavet: varuosade, tööriistade ja tarvikute kohta. Nii saab elada, kui selleks kaustadele struktuur ja õiguste tasemed luua.
Kuid sel juhul on teil kolm probleemi:
- navigeerimine: erinevate kaustade vahel liikumiseks kulub palju aega. Kui soovite vaadata konkreetse seadme remontimist mitme aasta jooksul, peate tegema väga palju klikke.
- statistika: teil seda ei ole, aga ilma selleta on raske prognoosida, kui kiiresti erinevad seadmed riknevad või kui palju ZIHen järgmise aasta jaoks planeerida.
- reaction speed: keegi ei tuleta meelde, et varuosad hakkavad otsa saama ja tuleb tellida. Samuti pole ilmne, et sama seadme rikkeid on toimunud juba mitu korda.
Mõnda aega hoidsime dokumente nii, aga seejärel avastasime Exceli 🙂
MMS Excelis. Aja jooksul kanti dokumentatsiooni struktuur Excelisse. Aluseks oli seadmete loetelu, millega seoti hooldusgraafikud, kontroll-loendid ja lingid teostatud tööde aktidele:
Seadmete loetelus on näidatud põhiomadused ja asukoht andmekeskuses:
Tulemus on omamoodi navigeerija, millest saab kiiresti aru, mis seadmetega toimub ja nende hooldusest. Vajadusel saab hooldusgraafikust vaadata eraldi akte linkide kaudu:
Kui Exceli dokumenti hoolikalt peeta, sobib lahendus täiesti väikese serveri jaoks. Kuid see on samuti ajutine. Isegi kui kasutame ühte konditsioneeri ja teeme hooldust iga kuu, koguneb viie aasta jooksul sadu vigu ja meie Exceli fail paisub. Kui lisada teine konditsioneer, üks diiselgeneraatormasin ja üks UPS, tuleb teha mitu lehte ja omavahel siduda. Mida pikem on ajalugu, seda keerulisem on kiiresti vajalikke andmeid leida.
Esimene "täiskasvanud" süsteem. 2014. aastal läbisime esimese Management & Operations auditi Operational Sustainability standardite kohaselt Uptime Institute'ilt. Läbisinud enam-vähem sama Exceliga, kuid aastaga oleme seda oluliselt täiustanud: lisanud lingid tööhendude ja inseneride kontrollnimekirjade jaoks. Auditorid pidasid sellist vormingut täiesti toimivaks. Nad suutsid jälgida kõiki seadmete toiminguid ning veendusid, et teave on ajakohane ja protsessid on korraldatud. Audit läks toona suurepäraselt, teenides 100-st võimalikust 92 punkti.
Tekib küsimus: kuidas edasi elada. Otsustasime, et vajame tõsiselt MMS-i, vaatasime mõningaid tasulisi programme, kuid lõpuks otsustasime tarkvara ise kirjutada. Just seda Excelit kasutasime kui ulatuslikku spetsifikatsiooni. Sellised ülesanded seadsime MMS-ile.
Mida me MMS-ilt soovisime
Enamikul juhtudel on MMS komplekt registritest ja aruannetest. Meie registrite hierarhia näeb välja umbes nii:
Kõige kõrgema taseme register on hoonete loend: tootmishooned, laod, kus seadmed asuvad.
Edasi tuleb inseneritehnika seadmete loend. Kogusime selle süsteemide kaupa:
- Konditsioneerimissüsteem: konditsioneerid, chillereid, pumpasid.
- Elektrivarustussüsteem: UPS, diiselgeneraatorid, jaotuspaneelid.
Iga seadme kohta kogume peamised andmed: tüüp, mudel, seerianumber, tootja andmed, tootmisaasta, kasutusele võtmise kuupäev, garantii aeg.
Kui oleme seadmete loendi täitnud, koostame selle jaoks ettevõtte hooldusprogrammi: kuidas ja kui sageli teha hooldust. Hooldusprogrammis kirjeldame operatsioonide komplekti, näiteks: asendada see aku, seadistada konkreetse osa töö ja nii edasi. Operatsioone kirjeldame eraldi käsiraamatus. Kui operatsioon kordub erinevates programmides, siis ei pea me seda iga kord uuesti kirja panema – võtame lihtsalt käsiraamatust valmis versiooni:
Operatsioonid „Temperatuuri seadistuste muutmine“ ja „Kiirelt eemaldatava kaabliühenduse asendamine“ on ühised chillereid ja ühte tootjat konditsioneerimise süsteemide jaoks.
Nüüd saame iga seadme jaoks luua teenindusgraafiku. Seostame teenindusprogrammi konkreetse seadmega, ning süsteem vaatab ise, kui sageli on vaja teenindust teha, ja arvutab tööde aja alates kasutusele võtmise kuupäevast:
Sellise graafiku koostamise saab automatiseerida isegi Exceli valemite abil.
See ei ole päris ilmne: peame pidama eraldi registrit edasilükatud tööde kohta. Ajakava on ajakava, kuid oleme kõik inimesed ja mõistame, et võib juhtuda igasuguseid olukordi. Näiteks, kui tarvikud ei jõua õigeks ajaks kohale ja hooldust tuleb nädal aega edasi lükata. See on normaalne olukord, kui seda jälgitakse. Me peame statistikat edasi lükatud ja täitmata tööde üle ning püüame, et hooldusettevõtte tühistamised läheksid nulli.
Iga seadme kohta peame samuti statistikat õnnetuste ja erakorraliste remonditööde kohta. Kasutame statistikat ostude planeerimiseks ja nõrkade kohtade otsimiseks infrastruktuuris. Näiteks, kui samas kohas põleb kolmel korral järjest kokku kompressor, on see signaal otsida rikke põhjuseid.
Selline hooldus- ja remontiajalugu on nelja aasta jooksul kogunenud konkreetse kliimaseadmestiku kohta.
Järgmine register – ZИП. Selles arvestame, milliseid tarvikuid on seadmetele vaja, kus ja kui palju neid hoitakse. Siin hoiame ka teavet tarneajad kohta, et paremini planeerida laojuhte.
ZIP arvu tugineb iga seadme remontide aastastatistikale. Kõikidele ZIP-idele määrame miinimumkoguse: kui palju varuosi on igas kohas vajalik. Kui ZIP-ide hulk lõppeb, on selle number ringkonnaks esile tõstetud:
Miinimumvaru kõrge rõhu sensoreid peab olema vähemalt kaks, kuid jäi järele vaid üks. Kiiresti on aeg tellida.
Kuna ZIP-partii saabub, täidame registris andmed saatelehtedest ja märgime ladustamiskoha. Näeme kohe, milline on hetkevaru sellistest ZIP-idest laos:
Peame eraldi registrit kontaktide jaoks. Sinna salvestame tarnijate ja alltöövõtjate andmed, kes hooldustöid teevad:
Iga alltöövõtja-inseneri kaardile on seotud sertifikaadid ja elektriohutusgrupid. Graafiku koostamisel saame vaadata, millistel spetsialistidel on vajalik luba.
MMS-i tegevuse jooksul on saidile sisenemise protsess muutunud. Näiteks on lisandunud dokumente, mis sisaldavad juhiseid hoolduse tegemiseks. Kui varem mahtusid kõik toimingud väikesele kontrollnimekirjale, siis detailsetes juhistes on arvesse võetud kõik: kuidas valmistuda, millised tingimused on vajalikud ja nii edasi.
Kuidas kogu protsess nüüd käib, selgitab näite kaudu .
Kuidas hooldus MMS-is toimub
Kunagi dokumenteerisime teostatud tööd pärast nende lõpetamist. Me lihtsalt viisime hooldust läbi ja allkirjastasime pärast seda tehtud tööde akti. Nii teevad 99% serveri teenusepakkujatest, kuid kogemuse järgi on see ebapiisav. Et midagi ei ununeks, koostame esmalt tööde teostamise loa. See on dokument, mis sisaldab tööde ja nende täitmise tingimuste kirjeldust. Iga hooldus ja remont meie süsteemis algab sellest. Kuidas see toimub:
- Uurime lähimaid planeeritud töid hooldusgraafikus:
- Loome uue tööde teostamise loa. Valime hooldustööde jaoks täitja, kes juhib protsessi meie poolt ja kooskõlastab tööd meiega. Märkime ära, kus ja millal tööd toimuvad, valime seadme tüübi ja programmi, mille alusel edasi läheme:
- Pärast kaardi salvestamist liigume detailide juurde. Määrame täitja ja kontrollime, kas tal on vajalikud load tööde tegemiseks. Kui load puuduvad, on väli punaseks ülevalt ja dokumendi väljastamine ei ole võimalik:
- Määrame konkreetse seadme. Tööde tüübi põhjal on hooldusprogrammis kirjas esialgsed tegevused, näiteks: tellida kütust platsile, planeerida inseneride sisekoolitus ja teavitada kolleege. Tegevuste loetelu ilmub automaatselt, kuid saame lisada ka omi punkte, kõik on piisavalt paindlik:
- Salvestame dokumendi, saadame kooskõlastajale e-kirja ja ootame tema vastust:
- Enne inseneri saabumist prindime dokumendi otse süsteemist.
- Dokumendis on hooldusprogrammi jaoks operatsioonide kontrollnimekiri. Tööülesande juhendaja andmeserveris kontrollib hooldust ja lisab märgised.
Mõnda aega piisas lühikesest kontrollnimekirjast. Seejärel rakendasime metoodilisi juhiseid, või MOP (meetodiprotseduur). Sellise dokumendi abil saab iga sertifitseeritud insener teostada mistahes seadme kontrolli.
Kõik on kirjas maksimaalselt põhjalikult, sealhulgas teavituskirjade mallid ja ilmastikuolud:
Prinditud dokument näeb välja selline:
Uptime Institute'i standardite kohaselt peab selline MOP olema olemas kõigi tööde jaoks. Dokumentatsioon on üsna mahukas. Kogemuse põhjal soovitame neid järk-järgult arendada, näiteks ühe MOP-i kuus.
- Tööde lõpetamisel koostab insener akti. Skenime selle ja lisame kaardile koos teiste dokumentide, nagu pääsupileti ja MOP, skaneeritud koopiatega.
- Pääsupiletis märgime ära tehtud tööd:
- Seadmete kaardil on säilinud hoolduse ajalugu:
Oleme näidanud, kuidas meie süsteem hetkel töötab. Kuid MMS-i arendamine ei lõpe siinkohal: mitmed täiustused on juba plaanis. Näiteks säilitame praegu palju teavet skaneeritud dokumentides. Tulevikus plaanime viia hooldusprotsessi paberivabaks, kasutades mobiilirakendust, kus insener saab märkmed teha ja infot otse kaardile salvestada.
Loomulikult on turul palju valmis tooteid, millel on sarnased funktsioonid. Kuid tahtsime näidata, et isegi väikest Exceli tabelit on võimalik arendada täieõiguslikuks tooteks. Seda saab teha iseseisvalt või kaasata töötajaid, peamine on õige lähenemine. Ja kunagi ei ole liiga hilja alustada.
Allikas: habr.com
