Situācija
Pārtikas ražotājs Marijampolē, Lietuvā, ar aptuveni 250 darbiniekiem strādā divās maiņās un apgādā mazumtirdzniecības tīklus ar stingriem piegādes logiem. IT infrastruktūra ir raksturīga ražošanai: vairāki virtualizēti serveri ar ERP un noliktavas sistēmām, atsevišķi ražošanas līniju vadības serveri ražošanas tīklā, pāris desmiti darbstaciju, tīkla aprīkojums ar VLAN segmentiem starp biroju un ražošanu un Microsoft 365 e-pastam un dokumentiem.
Rezerves kopijas bija, bet tikai serveriem: Veeam veidoja virtuālo mašīnu kopijas uz lokālo glabātuvi tajā pašā serveru telpā. Līniju vadības serveri netika kopēti, jo tos uzturēja aprīkojuma piegādātājs un neviens nebija pārliecināts, vai to drīkst darīt. Tīkla ierīču konfigurācijas netika glabātas nekur, izņemot pašās ierīcēs. Microsoft 365 uzskatīja par „Microsoft rūpi”. Atjaunošana nekad nebija pārbaudīta.
Vērsties pie mums lika divi iemesli. Pirmkārt, mazumtirdzniecības tīkla audits pieprasīja pierādījumus, ka uzņēmums pēc incidenta spēj atsākt darbu, un „mums ir rezerves kopijas” nebija pietiekama atbilde. Otrkārt, kad atteicās viens komutators, ražošanas tīkls stāvēja pusmaiņu, kamēr tā konfigurāciju atjaunoja no atmiņas. Ražošanas direktors uzdeva vienkāršu jautājumu: ja rīt serveru telpas vairs nebūtu, cik ilgi paietu, līdz mēs atkal ražotu?
Kas bija nepieciešams
- Rezerves kopijas visai infrastruktūrai: serveriem, līniju vadības serveriem, darbstacijām, tīkla ierīču konfigurācijām, Microsoft 365.
- Vismaz viena kopija ārpus rūpnīcas, kas nav sasniedzama no uzņēmuma tīkla.
- Saskaņots un pārbaudīts kritisko sistēmu atjaunošanas laiks, uz kura var balstīt ražošanas plānošanu.
- Atjaunošanas vieta gadījumam, ja uzņēmuma paša aprīkojums tiktu zaudēts.
- Dokumentētas mācības ar atskaiti, ko var uzrādīt auditoriem.
Ko mēs izdarījām
1.–2. nedēļa: inventarizācija un kritiskuma saraksts
Uzskaitījām visu, kam ir IP adrese, un kopā ar ražošanas, loģistikas un finanšu vadītājiem katrai sistēmai noteicām, cik ilgi uzņēmums var strādāt bez tās. Trīs izrādījās kritiskas: ERP, noliktavas sistēma un līniju vadības serveri. Tām saskaņojām 4 stundu atjaunošanas mērķi, bet pārējām – līdz nākamajai darba dienai. Šis saraksts vēlāk kļuva par mācību scenāriju.
3.–6. nedēļa: visas infrastruktūras rezerves kopijas
Serveru rezerves kopijas pārstrukturējām pēc 3-2-1 principa: Veeam kopijas uz vietas, otra kopija MDP CLOUD datu centrā Lietuvā un trešā kopija, kas ir nemaināma un tīklā neredzama, un kurai izspiedējvīruss nevarētu piekļūt pat ar administratora tiesībām. Ar līniju vadības aprīkojuma piegādātāju vienojāmies, ka viņu serveri tiek kopēti, nakts pārtraukumā apturot ierakstus datubāzē. Tas aizņēma visilgāk, jo bija nepieciešams piegādātāja rakstisks apstiprinājums.
Sākām katru nakti automātiski vākt tīkla ierīču konfigurācijas tajā pašā rezerves kopiju krātuvē, saglabājot izmaiņu vēsturi. Darbstacijām ar specializētu programmatūru (svari, etiķešu drukāšana) izveidojām attēlu rezerves kopijas. Microsoft 365 e-pastu, OneDrive un SharePoint ievietojām atsevišķās Microsoft 365 rezerves kopijās, jo Microsoft dzēstos datus glabā tikai ierobežotu laiku un neaptver katru scenāriju.
7.–8. nedēļa: PlanB
Kritiskajām sistēmām sagatavojām PlanB: iepriekš konfigurētu vidi MDP CLOUD mākonī, kurā ERP un noliktavas sistēmu var palaist no rezerves kopijām, nepērkot aprīkojumu. Vide gaida izslēgta, līdz tā ir vajadzīga; pēc ieslēgšanas darbinieki pieslēdzas caur VPN no jebkuras vietas.
9.–10. nedēļa: mācības
Pirmās mācības notika nedēļas nogalē: imitējām serveru telpas zaudējumu un PlanB vidē atjaunojām trīs kritiskās sistēmas. Pirmais mēģinājums aizņēma nedaudz vairāk par 4 stundām, jo izrādījās, ka ERP licences fails ir piesaistīts vecajam servera nosaukumam. Procedūru izlabojām un mācības atkārtojām pēc divām nedēļām, un šoreiz mērķi sasniedzām. Atsevišķi vienu komutatora konfigurāciju atjaunojām rezerves ierīcē. Tas aizņēma ap 20 minūtēm, nevis pusmaiņu.
Rezultāts
Kritisko sistēmu atjaunošana ir pārbaudīta 4 stundās, kas vairs nav mērķis, bet fakts, kas fiksēts mācību atskaitē. Mazumtirdzniecības tīkla auditoriem nodevām mācību atskaiti, rezerves kopēšanas politiku un atjaunošanas procedūras, un jautājumu nepalika.
Visas tīkla ierīču konfigurācijas, 100 %, tiek glabātas ar dienas vēsturi. Izmaiņa, ko kāds otrdien veica komutatorā, trešdien ir redzama, un vajadzības gadījumā to var atcelt.
Atjaunošanas mācības notiek divreiz gadā pēc saskaņota grafika, katru reizi ar citu scenāriju: serveru zaudējums, izspiedējvīrusa uzbrukums, Microsoft 365 konta dzēšana. Katru mācību atskaite nonāk pie vadības un tiek glabāta auditiem.
„Pirmo reizi mums ir atbilde uz jautājumu „cik ilgi paietu, līdz mēs atkal ražotu”, un tā nāk no atskaites, nevis no kāda galvas.”
Ko mēs ieteiktu līdzīgā situācijā
- Rezerves kopijas bez pārbaudītas atjaunošanas ir pieņēmums, nevis aizsardzība. Pirmais tests gandrīz vienmēr atklāj ko tādu, ko jūs nezinājāt.
- Inventarizācijā iekļaujiet visu, kam ir konfigurācija, ne tikai serverus: komutatorus, ugunsmūrus, svarus, printerus.
- Ar aprīkojuma piegādātāju par ražošanas aprīkojuma rezerves kopijām vienojieties rakstiski, pirms incidenta.
- Atjaunošanas mērķi nosakiet kopā ar ražošanas un finanšu vadītājiem, nevis IT nodaļā: viņi zina, cik maksā dīkstāves stunda.
