MMS-süsteem andmekeskuses: kuidas me automatiseerisime tehnilise teeninduse haldamise

Kujutage ette, et teil on täielik serveritehnika: paar tosinat kliimaseadet, hunnik DGU-sid ja katkematuid toiteallikaid. Selleks, et "raudad" töötaksid korralikult, kontrollite regulaarselt nende toimimist ja ärge unustage ennetustööd: korraldage testkäivitusi, kontrollige õlitaset, vahetage komponente. Isegi ühe serveri jaoks tuleb hoida palju teavet: seadmete registrit, tarvikute loetelu laos, ennetustööde ajakava, samuti garantiidokumente, lepinguid tarnijate ja alltöövõtjatega. 

Nüüd korrutame saalide arvu kümnega. Tekkisid logistika küsimused. Millises laos hoida mida, et mitte joosta iga varuosa järele? Kuidas õigeaegselt varusid täiendama, et ettenägematu remont ei tuleks üllatusena? Kui seadmeid on palju, ei ole kõiki tehnilisi töid peast raske meeles pidada ja paberil on see keeruline. Siin tuleb appi MMS, ehk hooldushaldussüsteem, – seadmete hooldusteadlikkuse juhtimise süsteem. 

MMS-is koostame ennetus- ja remonditööde ajakavasid, hoiame inseneride juhiseid. Kõigil andmekeskustel pole sellist süsteemi, paljud peavad seda liiga kalliks lahenduseks. Kuid oma kogemuste põhjal oleme veendunud, et tööriist ei ole oluline, vaid lähenemine teabele. Esimese süsteemi lõime Excelis ja täiendasime järk-järgult tarkvaratooteks. 

Koos alexddropp otsustasime jagada kogemusi oma MMS-i arendamisest. Mina näitan, kuidas süsteem arenes ja kuidas see aitas rakendada parimaid hooldustavasid. Aleksei räägib, kuidas ta sai MMS-i päranduseks, mis on selle aja jooksul muutunud ja kuidas süsteem parandab inseneride elu täna. 

Kuidas me jõudsime oma MMS-ini

Alguses olid kaustad. 8–10 aastat tagasi hoiti teavet killustatud kujul. Pärast hooldust allkirjastasime tööde vastuvõtuaktid, hoidsime paberkandjal originaale arhiivides ja skannitud koopiad võrgu kaustades. Samuti kogusid kaustadesse, mis olid jagatud seadmete järgi, teavet ZIP-i kohta: varuosi, tööriistu ja tarvikuid. Niimoodi on võimalik elada, kui nendele kaustadele luua struktuur ja ligipääsu tasemed.
Aga siis on teil kolm probleemi: 

• navigeerimine: liigelda erinevate kaustade vahel on aeganõudev. Kui soovid vaadata seadmete remonte mitme aasta jooksul, tuleb teha väga palju klikke.
• statistika: sul seda ei ole, ja ilma selleta on keeruline ennustada, kui kiiresti erinev varustus rikneb või kui palju ZIIP-i järgmiseks aastaks planeerida.  
• reaktsioonide õigeaegsus: keegi ei tuleta meelde, et varuosad saavad otsa ja neid tuleb uuesti tellida. Ja ei ole ilmne, et sama varustus rikneb juba mitte esmakordselt.  

Mõnd aega hoidsime dokumente nii, kuid siis avastasime Exceli 🙂

MMS Excelis. Aja möödudes kolis dokumentatsiooni struktuur Excelisse. Aluseks oli varustuse loetelu, millele sidusime hooldusgraafikud, kontrollnimekirjad ja lingid tehtud tööde aktidele: 

Varustuse loetelus näitasime põhijooned ja asukoha andmed andmekeskuses:

Saime midagi sarnast navigeerijaga, mille kaudu on võimalik kiiresti mõista, mis toimub varustuse ja selle hooldusega. Vajadusel saab hooldusgraafikust vaadata eraldi akte linkide kaudu:

Kui hoolikalt Excelit pidada, siis lahendus sobib arvestatava serveri jaoks. Kuid see on ka ajutine. Isegi kui kasutame ühte konditsioneeri ja teeme hooldust kord kuus, kogume viie aastaga sadu vigu ning meie Excel paisub. Kui lisada veel üks konditsioneer, üks diiselgeneratoor ja üks UPS, tuleb luua mitu lehte ja omavahel siduda. Mida pikem on ajalugu, seda keerulisem on vajalikku teavet kiiresti leida. 

Esimene "täiskasvanud" süsteem. 2014. aastal läbisime esimese juhtimise ja tegevuse auditi Uptime Institute'i operational sustainability standardite järgi. Läbisime peaaegu sama Exceliga, kuid aasta jooksul olime selle palju täiendanud: lisasime lingid juhenditele ja inseneride kontrollnimekirjadele. Auditorid pidasid sellist formaati piisavalt töökindlaks. Nad suutsid jälgida kõiki operatsioone varustusega ja veendusid, et teave on ajakohane ja protsessid on üles ehitatud. Audit läks siis "suurepäraselt" läbi, saades 92 punkti 100 võimalikust.

Tekkis küsimus: kuidas edasi elada. Otsustasime, et vajame "tõsist" MMS-i, vaatasime läbi mitu tasulist programmi, kuid lõpuks otsustasime, et kirjutame tarkvara ise. Just Excelit kasutasime arendatud tehnilise ülesandena. Siin on ülesanded, mille seadsime MMS-ile. 

Mida soovisime MMS-ilt

Enamikul juhtudel on MMS tõendite ja aruanne kogum. Meie viidete hierarhia näeb välja enam-vähem selline:

Kõige ülemine viidete loend on hoonete nimekiri: masinaalad, laod, kus on seadmed.

Järgmine on inseneriseadmete nimekiri. Selle koostasime süsteemide kaupa:

• Konditsioneerimise süsteem: konditsioneerid, chillereid, pumbad.
• Elektritoite süsteem: UPS, diiselgeneratsioon, jaotuspaneelid.

Iga seadme kohta kogume põhiandmed: tüüp, mudel, seerianumber, tootja andmed, tootmisaasta, kasutusele võtmise kuupäev, garantii tähtaeg.

Kui oleme seadmete nimekirja täitnud, koostame selle jaoks tehnilise teeninduse programmi: kuidas ja kui tihti teha teenindust. Teenindusprogrammis kirjeldame operatsioonide kogumit, näiteks: asendada see aku, seadistada konkreetse komponendi töö jne. Operatsioonid kirjeldame eraldi viidetes. Kui operatsioon kordub erinevates programmides, ei pea seda iga kord uuesti kirjeldama – lihtsalt võtame valmis viitest:

Operatsioonid "Temperatuuristandardite muutmine" ja "Kaabli kiirühenduste asendamine" on ühised chillereid ja sama tootja konditsioneerimissüsteemide jaoks.

Nüüd saame iga seadme jaoks luua teenindusgraafiku. Seostame teenindusprogrammi konkreetse seadmega ja süsteem vaatab ise programmist, kui sageli teenindust teha, ja arvutab tööd alates kasutusele võtmise kuupäevast:
Selle graafiku koostamise saab automatiseerida isegi Exceli valemite abil.

See pole sugugi ilmne: peame eraldi viite lahendamata tööde kohta. Graafik on graafik, kuid kõik oleme elavad inimesed ja mõistame, et võib juhtuda kõike. Näiteks, kui tarvikud ei tulnud õigeaegselt ja teenindus tuleb nädalaks edasi lükata. See on normaalne olukord, kui selle pärast hoolitseda. Lahendamata ja täitmata tööde kohta koostame statistikat ja püüame, et teeninduse tühistamine oleks minimaalne.  

Samuti kogutakse iga seadme kohta statistikat õnnetustest ja erakorralistest remonditest.Statistikat kasutatakse ostude planeerimiseks, nõrkade kohtade leidmiseks infrastruktuuris. Näiteks, kui samas kohas põleb kompressor kolm korda järjest, on see signaal, et tuleks otsida rikke põhjuseid.   

Selline tehnilise teeninduse ja remontide ajalugu on kogunenud nelja aasta jooksul konkreetse kliimaseadme kohta.

Järgmine juhend – ZIP. Selles arvestame, millised tarvikud on seadmete jaoks vajalikud, kus ja kui suures koguses neid hoitakse. Siin salvestame ka teabe tarnetähtaegade kohta, et paremini planeerida laos asetleidvate tarvikute saabumist. 

ZIP-i kogus arvutatakse igala aastal keskmiste remondistatistika põhjal ühe seadme kohta. Kõikidele ZIP-idele märgime minimaalse jäägi: kui palju varuosi on igas objektis vaja. Kui ZIP-läheb lõppema, siis selle kogus juhendis tõstetakse esile:

Minimaalne jääk kõrge rõhu andureid peab olema vähemalt kaks, aga alles on vaid üks. On aeg kiirelt tellida. 

Kuna pakett ZIP-i saabub, täiendame juhendit kaubaarve andmetega ja märgime hoiustamiskoha. Näeme kohe laos oleva ZIP-i praegust jääki: 

Peame eraldi kontaktide juhendit. Sellesse kantakse tarnijate ja alltöövõtjate andmed, kes teostavad tehnilist teenindust: 

Iga alltöövõtja-inseneri kaardile on seotud sertifikaadid ja elektriohutuse grupid. Graafiku koostamisel saame vaadata, kellel spetsialistidest on vajalikud load. 

MMS-i eksisteerimise ajaloos on tööde lubamise süsteem muutunud. Näiteks on lisandunud dokumendid metoodiliste juhistega tehnilise teeninduse tegemiseks. Kui varem mahtus tegevuste kogum väikesesse kontroll-loendisse, siis põhjalikes juhistes on ette nähtud kõik: kuidas valmistuda, millised tingimused on vajalikud jne.   

Kuidas kogu protsess praegu toimib, räägib näide alexddropp. 

Kuidas toimub MMS-i tehniline teenindus

Kaua aega tagasi dokumenteerisime tehtud tööd juba fakti põhjal. Me lihtsalt viimistlesime tehnilist teenindust ja pärast seda allkirjastasime tehtud töö akti. Nii teevad 99% serveriteenuseid, aga kogemuse põhjal on sellest ebapiisav. Et mitte midagi unustada, koostame esmalt tööde lubamise dokumendi. See on dokument tööde ja nende teostamise tingimuste kirjeldamiseks. Iga tehniline teenindus ja remont meie süsteemis algab sellega. Kuidas see toimub: 

1. Vaadata lähimaid planeeritud töid tehnilise teeninduse graafikus:
   
2. Loome uus töökorraldus. Valime hoolduspartneri, kes juhib protsessi meie poolt ja kooskõlastab tööd meiega. Näitame, kus ja millal tööd toimuvad, valime seadme tüübi ja programmi, millega jätkame: 
   
3. P pärast kaardi salvestamist liigume detailide juurde. Näitame täitjat ja kontrollime, kas tal on vajalik luba töödeks. Kui luba puudub, siis väljakutse väli on punasega esile tõstetud ja kutset ei saa välja anda:  
   
4. Näidake konkreetsed seadmed. Olenevalt tööde tüübist on hooldusprogrammis kirjas ettevalmistavad tegevused, näiteks: tellida kütus platsile, planeerida sissejuhatav koolitus inseneridele ja teavitada kolleege. Tegevuste nimekiri ilmub automaatselt, kuid saame lisada ka oma punkte, kõik on piisavalt paindlik:
   
5. Salvestame töökorralduse, saadame kirja kooskõlastajale ja ootame tema vastust:
   
6. Inseneri saabumise ajaks trükime töökorralduse otse süsteemist välja.
   
7. Töökorralduses on hooldusprogrammi tegevuste kontrollnimekiri. Tööde juht andmesaalis kontrollib hooldust ja märgib ruudud.
   

   Mõnda aega piisas lühikesest kontrollnimekirjast. Seejärel rakendasime meetodlike juhiseid, või MOP (meetodiprotseduur). Sellise dokumendi abil saab iga sertifitseeritud insener läbi viia mis tahes seadme kontrolli. 

   Kõik on maksimaalselt detailselt kirjas, sealhulgas teavituskirjade šablonid ja ilmastikutingimused: 

   

   Prinditud dokument näeb välja selline:

   

   Uptime Institute'i standardite kohaselt peaks selline MOP olema kõigi operatsioonide jaoks. See on üsna suur dokumentatsiooni maht. Kogemuse põhjal soovitame neid järk-järgult välja töötada, näiteks ühe MOP kuus.

8. Tööde lõppedes koostab insener tehtud tööde akti. Skaneerime selle ja lisame kaardile koos teiste dokumentide, nagu töökorralduse ja MOP, skannidega. 
   
9. Töökorralduses märgime ära tehtud tööd: 
   
10. Seadmete kaardil on säilinud hoolduse ajalugu:
    

Oleme näidanud, kuidas meie süsteem hetkel töötab. Kuid MMS-i kallal töötamine ei lõpeta: plaanis on mitu täiustust. Näiteks säilitame praegu palju teavet skannides. Tulevikus planeerime teha hoolduse paberi-vabaks: ühendada mobiilirakendus, kus insener saab märkida ruudud ja kohe salvestada teabe kaardile. 

Loomulikult on turul palju valmis tooteid, millel on sarnased funktsioonid. Kuid me soovisime näidata, et isegi väikest Exceli faili saab arendada täieõiguslikuks tooteks. Seda saab teha iseseisvalt või kaasates alltöövõtjaid, peamine on õige lähenemine. Ja kunagi pole liiga hilja alustada.

Allikas: habr.com