Situācija
Loģistikas uzņēmums Viļņā, Lietuvā, ar 80 darbiniekiem ekspluatē divas noliktavas un savu transportlīdzekļu parku. Visas darbības griežas ap noliktavas pārvaldības sistēmu: preču pieņemšanu, komplektēšanu, izsūtīšanu, dokumentiem vadītājiem. Kad sistēma apstājas, noliktavā stāv iekrāvēji, bet pie rampas gaida kravas automašīnas.
Sistēma darbojās uz diviem fiziskiem serveriem biroja telpā, serveru telpā, kas patiesībā bija bijusī noliktavas telpa ar gaisa kondicionieri. Serveriem bija septiņi gadi, garantija sen bija beigusies, un viens no tiem pēdējā gada laikā divreiz bija izslēdzies pārkaršanas dēļ. Katra dīkstāve noliktavai nozīmēja vairākas stundas manuāla darba un nokavētas piegādes.
Turklāt bija drošības problēma. Vadītāji un noliktavas darbinieki pie sistēmas savienojās no tālruņiem un planšetdatoriem caur atvērtu attālās darbvirsmas portu. Operāciju vadītājs, redzot klientu jautājumus par piegādātāju kiberdrošību, saprata, ka tā turpināties nevar.
Kas bija nepieciešams
Kopā ar operāciju vadītāju un finanšu vadītāju mēs vienojāmies par mērķiem:
- Atbrīvoties no atkarības no fiziskās aparatūras birojā: vairs nepirkt serverus un neuzturēt serveru telpu.
- Noliktavas sistēmai jādarbojas abās maiņās, tāpēc migrācija bija jāveic ar ne vairāk kā dažu stundu pārtraukumu, nedēļas nogalē.
- Droša piekļuve no noliktavām, no ceļa un no mājām, bez atvērtiem portiem internetā.
- Rezerves kopijas vairākās vietās un rakstiski noteikts atjaunošanas laiks, ko var parādīt klientiem.
- Atjauninājumi un uzturēšana vairs nav uzņēmuma rūpe.
- Termiņš: sezonas kulminācijas sākums, pēc aptuveni piecām nedēļām.
Ko mēs darījām
1. nedēļa: audits un plāns
Mēs izmērījām, ko sistēma patiešām izmanto: procesora slodzi, atmiņu un diska operācijas maksimumstundās. Tas bija svarīgi, jo noliktavas sistēmas piegādātājs bija ieteicis ievērojami vairāk resursu, nekā praksē vajadzēja. Ar piegādātāju mēs saskaņojām datubāzes migrācijas procedūru un testa scenāriju. Mēs sastādījām migrācijas plānu ar atpakaļritināšanas iespēju, ja kaut kas neizdotos.
2. nedēļa: mākoņvide
Mūsu datu centrā Lietuvā mēs sagatavojām trīs pārvaldītus mākoņserverus: noliktavas sistēmas lietojumprogrammu līmenim, datubāzei un grāmatvedības sistēmai, kas līdz tam dalīja serveri ar noliktavas sistēmu. Visos serveros tika uzstādīts Bitdefender GravityZone, monitorings un automatizēta atjauninājumu pārvaldība.
Paralēli mēs izveidojām VPN tīklu, kas savieno abas noliktavas, biroju un mākoni. Mobilajām ierīcēm mēs nodrošinājām VPN klientu ar divfaktoru autentifikāciju. Atvērtais attālās darbvirsmas ports tika aizvērts.
3. nedēļa: izmēģinājuma migrācija
Mēs pārcēlām sistēmas kopiju uz mākoni un divas dienas ļāvām noliktavas vadītājiem strādāt testa vidē: pieņemt preces, komplektēt, drukāt dokumentus. Tieši šeit parādījās vissarežģītākais. Noliktavu etiķešu printeri bija konfigurēti pret vecā servera IP adresi, un daži no tiem nebija dokumentēti vispār. Divu dienu laikā mēs izgājām cauri visiem 14 printeriem un salabojām konfigurāciju caur VPN.
4. nedēļa: migrācija
Migrāciju mēs veicām sestdienas naktī. Mēs apturējām veco sistēmu, pārnesām datubāzes galīgo stāvokli un pārslēdzām darbstacijas un ierīces. Svētdienas rītā noliktavas vadītājs pārbaudīja galvenos scenārijus. Faktiskā nepieejamība bija aptuveni četras stundas, visas ārpus darba laika. Vecie serveri vēl divas nedēļas palika ieslēgti kā rezerves variants un pēc tam tika izslēgti.
5. nedēļa: rezerves kopijas un uzturēšanas režīms
Mēs ieslēdzām serveru rezerves kopijas ar Veeam: ikdienas kopijas paliek Lietuvā, bet otrā kopija tiek nosūtīta uz Amazon datu centru Vācijā. Mēs pārbaudījām un izmērījām atjaunošanu: visa noliktavas sistēma tiek atjaunota no rezerves kopijas mazāk nekā trijās stundās, tāpēc līgumā ar rezervi ierakstījām četru stundu RTO. Atjauninājumu logs tika saskaņots naktij no otrdienas uz trešdienu, kad noliktavā ir vismierīgāk.
Rezultāts
Pirmajos sešos mēnešos pēc migrācijas noliktavas sistēmai nebija ne vienas neplānotas dīkstāves. To mēs mērām ar monitoringa sistēmu, kas fiksē katru nepieejamības minūti, un klients katru mēnesi saņem pārskatu. Plānotie atjauninājumi notiek naktī, un darbinieki tos nemana.
Saskaņotais atjaunošanas laiks ir 4 stundas, un to apstiprina reāls tests, nevis aprēķins. Rezerves kopijas tiek glabātas divās vietās: Lietuvā un Vācijā. Tas ļāva operāciju vadītājam uz klientu drošības anketām atbildēt ar konkrētiem faktiem, nevis solījumiem.
Biroja serveru telpa ir demontēta, un gaisa kondicionieris izslēgts. Finanšu vadītājs budžetā serveru atjaunošanas pozīciju aizstāja ar iepriekš zināmu ikmēneša pakalpojuma maksu.
„Agrāk pirmdienas rītos es pārbaudīju, vai serveri ir dzīvi. Tagad es pārbaudu tikai pārskatu.”
Ko mēs ieteiktu līdzīgā situācijā
- Pirms serveru pārcelšanas izmēriet reālo slodzi. Lietojumprogrammu piegādātāju ieteikumos bieži ir liela rezerve, un jūs par šiem resursiem maksāsiet katru mēnesi.
- Veiciet izmēģinājuma migrāciju un ļaujiet reāliem darbiniekiem strādāt testa vidē. Printeri, skeneri un integrācijas ar piegādātājiem parādās tikai tā.
- Atjaunošanas laiku ierakstiet līgumā tikai pēc reāla testa. Četras stundas uz papīra un četras stundas praksē nav viens un tas pats.
- Aizveriet atvērtos attālās darbvirsmas portus nekavējoties, pirms jebkādas migrācijas. Tas ir biežākais veids, kā izspiedējvīruss iekļūst loģistikas uzņēmumos.
