Situacija
Vilniaus logistikos įmonė su 80 darbuotojų valdo du sandėlius ir savo transporto parką. Visa veikla sukasi apie sandėlio valdymo sistemą: priėmimas, komplektavimas, išsiuntimas, dokumentai vairuotojams. Kai sistema stoja, sandėlyje sustoja krautuvai, o prie rampos laukia vilkikai.
Sistema veikė dviejuose fiziniuose serveriuose biuro patalpoje – serverinėje, kuri iš tikrųjų buvo buvusi sandėliuko dalis su kondicionieriumi. Serveriai buvo septynerių metų, garantija seniai pasibaigusi, o vienas iš jų per pastaruosius metus du kartus išsijungė dėl perkaitimo. Kiekviena tokia prastova sandėliui kainavo kelias valandas rankinio darbo ir vėluojančius išsiuntimus.
Prie to prisidėjo saugumo klausimas. Vairuotojai ir sandėlio darbuotojai jungėsi prie sistemos iš telefonų ir planšečių per atvirą nuotolinio darbalaukio prievadą. Operacijų vadovas, pamatęs klientų užduodamus klausimus apie tiekėjų kibernetinį saugumą, suprato, kad taip tęstis negali.
Ko reikėjo
Su operacijų vadovu ir finansų vadovu sutarėme tikslus:
- Panaikinti priklausomybę nuo fizinės įrangos biure: nebepirkti serverių, nebeprižiūrėti serverinės.
- Sandėlio sistema turi veikti abiem pamainoms, todėl perkėlimas – be ilgesnės nei kelių valandų pertraukos, savaitgalį.
- Saugus prisijungimas iš sandėlių, kelio ir namų, be atvirų prievadų internete.
- Kopijos ne vienoje vietoje ir rašytinis atkūrimo laikas, kurį galima parodyti klientams.
- Atnaujinimai ir priežiūra – ne įmonės rūpestis.
- Terminas: iki didžiausio sezono pradžios, tai yra apie penkios savaitės.
Ką padarėme
1 savaitė: auditas ir planas
Išmatavome, ką iš tikrųjų naudoja sistema: procesoriaus apkrovą, atmintį, disko operacijas piko valandomis. Tai svarbu, nes sandėlio sistemos tiekėjas rekomendavo gerokai didesnius išteklius, nei reikėjo realiai. Suderinome su tiekėju duomenų bazės perkėlimo procedūrą ir testavimo scenarijų. Sudarėme perkėlimo planą su grįžimo atgal variantu, jei kas nors nepavyktų.
2 savaitė: aplinka debesijoje
Mūsų duomenų centre Lietuvoje paruošėme tris valdomus CLOUD serverius: sandėlio sistemos programinei daliai, duomenų bazei ir apskaitos sistemai, kuri iki tol dalijosi serveriu su sandėlio sistema. Visuose serveriuose įdiegtas Bitdefender GravityZone, stebėjimas ir automatinis atnaujinimų valdymas.
Lygiagrečiai sukūrėme VPN tinklą tarp dviejų sandėlių, biuro ir debesijos. Mobiliesiems įrenginiams – VPN klientas su dviejų veiksnių autentifikacija. Atviras nuotolinio darbalaukio prievadas uždarytas.
3 savaitė: bandomasis perkėlimas
Perkėlėme sistemos kopiją į debesiją ir dvi dienas leidome sandėlio vadovams dirbti testinėje aplinkoje: priimti prekes, komplektuoti, spausdinti dokumentus. Čia išlindo sudėtingiausia dalis – etikečių spausdintuvai sandėliuose buvo sukonfigūruoti pagal senojo serverio IP adresą, o dalis jų neturėjo jokios dokumentacijos. Per dvi dienas peržiūrėjome visus 14 spausdintuvų ir sutvarkėme konfigūraciją per VPN.
4 savaitė: perkėlimas
Perkėlimą atlikome šeštadienio naktį. Sustabdėme senąją sistemą, perkėlėme galutinę duomenų bazės būseną, perjungėme darbo vietas ir įrenginius. Sandėlio vadovas patikrino pagrindinius scenarijus sekmadienio rytą. Realus sistemos nepasiekiamumas – apie keturias valandas, visos ne darbo metu. Senieji serveriai liko įjungti dar dvi savaites kaip atsarginis variantas, vėliau išjungti.
5 savaitė: kopijos ir priežiūros režimas
Įjungėme serverių rezervines kopijas su Veeam: kasdienės kopijos lieka Lietuvoje, antra kopija keliauja į Amazon duomenų centrą Vokietijoje. Atkūrimą išbandėme ir išmatavome: visa sandėlio sistema iš kopijos atkuriama per mažiau nei tris valandas, todėl sutartyje įrašėme keturių valandų RTO su atsarga. Atnaujinimų langas suderintas: naktį iš antradienio į trečiadienį, kai sandėlyje tyliausia.
Rezultatas
Per pirmus šešis mėnesius po perkėlimo sandėlio sistema neturėjo nė vienos neplanuotos prastovos. Tai matuojame stebėjimo sistema, kuri registruoja kiekvieną nepasiekiamumo minutę, o klientas kas mėnesį gauna ataskaitą. Planuoti atnaujinimai vyksta naktį ir darbuotojai jų nepastebi.
Sutartas atkūrimo laikas – 4 valandos, patvirtintas realiu testu, ne skaičiavimu. Kopijos saugomos dviejose vietose: Lietuvoje ir Vokietijoje. Tai leido operacijų vadovui atsakyti į klientų saugumo klausimynus konkrečiais faktais, o ne pažadais.
Serverinė biure išardyta, kondicionierius išjungtas. Finansų vadovas serverių atnaujinimo biudžeto eilutę pakeitė mėnesiniu paslaugos mokesčiu, kuris yra žinomas iš anksto.
Anksčiau pirmadienio rytais tikrindavau, ar serveriai gyvi. Dabar tikrinu tik ataskaitą.
Ką patartume panašioje situacijoje
- Prieš perkeldami serverius išmatuokite realią apkrovą. Programų tiekėjų rekomendacijos dažnai yra su didele atsarga, o už išteklius mokėsite kas mėnesį.
- Darykite bandomąjį perkėlimą ir leiskite tikriems darbuotojams dirbti testinėje aplinkoje. Spausdintuvai, skeneriai ir integracijos su tiekėjais išlenda tik taip.
- Atkūrimo laiką įsirašykite į sutartį tik po realaus testo. Keturios valandos popieriuje ir keturios valandos praktikoje – ne tas pats.
- Uždarykite atvirus nuotolinio darbalaukio prievadus iš karto, dar prieš bet kokį perkėlimą. Tai dažniausias kelias, kuriuo į logistikos įmones patenka išpirkos reikalaujančios programos.
