Datu migrācijai nepieciešama rūpīga sagatavošanās. Datu bāzes struktūras versiju migrācija: pamata pieejas Versiju vēstures glabāšana

Mūsdienu uzņēmumi bieži saskaras ar nepieciešamību migrēt savas informācijas sistēmas. Tomēr pirms šīs procedūras ir rūpīgi jāsagatavojas, jo ceļā ir daudz šķēršļu.

Iemeslu pārejas uzsākšanai uz jaunu informācijas sistēmu (IS) var būt ļoti daudz, tostarp ar novecojušu platformu darbību saistīto risku samazināšana, informācijas sistēmu pielāgošana starptautiskiem standartiem un biznesa procesu efektivitātes paaugstināšana. Bet neatkarīgi no tā, ar kādu uzdevumu uzņēmums saskaras, pāreja no viena IP uz otru ir rūpīgi jāplāno un jāsagatavo.

Migrācijas problēmas

Runājot par transakciju sistēmu, piemēram, ERP, norēķinu, apstrādes vai pamata banku pakalpojumu migrēšanu, pāreja uz jaunu sistēmu ir ļoti problemātiska. Fakts ir tāds, ka IT speciālistiem ir jānodrošina precīza lielu datu apjomu migrācija, saglabājot paralēlu veco un jauno sistēmu darbību rezultātu saskaņošanai un analīzei.

Piemēram, man bija projektu pieredze vienā no lielākajām bankām, kur transakciju sistēma no vairs neatbalstītās Informix platformas tika pārcelta uz Oracle platformu. Tajā pašā laikā bija nepieciešams veikt rūpīgu biznesa procesu analīzi, atkārtoti pārsūtīt datus no vecās sistēmas uz jauno un pārbaudīt jauno un veco sistēmu rezultātu konsekvenci, ņemot vērā darbības ilgumu. procesa noteikumi. Tāpēc migrācijas periods bija 14 mēneši. Dažkārt divu sistēmu paralēla darbība var turpināties ilgāku laiku, taču arī tad, kad tas ir ierobežots līdz vairākiem mēnešiem, jaunās IS darbības nodrošināšanai ir nepieciešams piešķirt papildus skaitļošanas jaudu un ievērojamu laiku uzņēmuma darbiniekiem, lai vienlaicīgi veiktu uzdevumus divās sistēmās. .

No departamentu sistēmas līdz uzņēmuma līmenim

IP atjaunināšana bieži notiek globalizācijas un centralizācijas ietvaros. Tas ļauj ievērojami samazināt programmatūras sistēmu atbalsta un atjaunināšanas izmaksas. Patiešām, uzturēt vienu platformu, kas apkalpo visus darbiniekus, ir daudz vienkāršāk nekā uzturēt atsevišķus rīkus katrai nodaļai. Piemēram, veiksmīga krājumu uzskaites sistēmas migrācija ļauj pārcelt vairākus tūkstošus lielas organizācijas nodaļu uz vienu platformu un nodrošināt nopietnu IT izmaksu samazinājumu. Tomēr jāatceras, ka lielākā daļa sagatavošanās šajā gadījumā ir datu saskaņošana dažādos formātos un attēlojumos, jaunu noteikumu izstrāde un jaunu darbinieku mijiedarbības modeļu konstruēšana.

Vēl viens svarīgs aspekts ir integrācijas saskarnes ar citām uzņēmuma informācijas sistēmām, īpaši pašrakstītām un specifiskām. Ar tiem saistītās problēmas var nebūt tik pamanāmas pirmajā posmā, bet tiek identificētas, veidojot mijiedarbību starp dažādām nodaļām un kopējo sistēmu. Un, ja vecajai sistēmai šādas saskarnes jau tika ieviestas programmatiski vai organizatoriski, tad jaunajai sistēmai tās var būt jāizstrādā no jauna.

Jāatceras, ka domas par sistēmas funkcionalitātes paplašināšanu var rasties jau projekta realizācijas laikā, tāpat kā apetīte rodas ēdienreizes laikā. Tas nozīmē, ka būs jāveic vesela virkne papildu darbu.

Darbības plāns

Projekta aktivitāšu pieredze sistēmas migrācijas jomā liecina, ka jebkuram šādam projektam ir nepieciešama rūpīga sagatavošana un tam ir jāpievieno individuāls plāns. Tomēr neatkarīgi no migrējamo sistēmu veida, programmatūras, datu bāzes apjomiem utt., vispārējā shēma izskatās gandrīz identiska.

Pirmajā posmā ir nepieciešams veikt detalizētu auditu, noskaidrojot visas prasības jaunās sistēmas darbības režīmam, intervējot visus galvenos lietotājus. Ir svarīgi saprast, par kādiem datu apjomiem un kādu slodzi ir runa, tikai tad speciālisti varēs piedāvāt pareizo migrācijas stratēģiju.

Arī pašām procedūrām jābūt rūpīgi pārdomātām, un tajās jāietver tādi svarīgi elementi kā noteikumi lietotāju piekļuvei sistēmām migrācijas laikā, procedūras atgriešanai iepriekšējā stāvoklī kļūmju gadījumā un dažādu šajos procesos iesaistīto speciālistu mijiedarbība. .

Pēc vienošanās ar klientu parasti tiek sastādīts detālplānojums, kas ietver vairākus posmus, proti: datu kopēšana, pārbaude, divu sistēmu paralēla darbība un pilnīga pāreja uz jaunu platformu. Manuprāt, profesionāli organizētā sistēmu migrācijā galvenais ir procesa gludums lietotājiem, kuri pamazām, bez stresa var sākt strādāt jaunā automatizētā sistēmā.

Tomēr pat rūpīga sagatavošanās ne vienmēr pasargā jūs no darbaspēka izmaksu nenovērtēšanas, pārceļot lietotājus uz “jaunām sliedēm”. Šis process ietver gan uzņēmuma darbinieku apmācību, gan viņu atbalstu adaptācijas periodā jaunajai sistēmai.

Leifs Poulsens uzņēmumam InTech

Sistēmas ražošanas automatizēšanai un informācijas vākšanai par ražošanas procesiem ir salīdzinoši īslaicīgas. Tie bieži ir jāuzlabo vai jānomaina, pirms procesa iekārtas sasniedz savas kalpošanas laika beigas. Daudziem uzņēmumiem šādu automatizācijas sistēmu nomaiņas vai modernizācijas vadīšana, neapturot ražošanu, ir īsts izaicinājums. Tāpēc objektīvā nepieciešamība pēc modernizācijas vai nomaiņas tiek ignorēta, līdz kaut kas notiek. Šis raksts ir par to, kā jūs varat veiksmīgi veikt šo uzdevumu, rūpīgi plānojot un organizējot.

Rūpnieciskās automatizācijas sistēmu un industriālās IT sistēmu modernizācijas un nomaiņas pamatā ir divi galvenie faktori: šo sistēmu tehniskā degradācija, kā arī šo sistēmu atbalstīto biznesa procesu prasību izmaiņas.

Tehnisko sistēmu uzticamība laika gaitā samazināsies, ja uzņēmumi ignorēs operētājsistēmu, datu bāzu un lietojumprogrammatūras modernizācijas nepieciešamību. Attiecīgi palielinās iekārtu atteices darbības risks.

Rūpīgi plānojot, darbības risku var uzturēt pieņemamā līmenī, vienlaikus aizsargājot ieguldījumus un samazinot dzīves cikla izmaksas. Tipiskai automatizācijas vai IT sistēmai tikai 20-40% no investīcijām tiek novirzīti sistēmas iegādei. Atlikušie 60-80% tiek novirzīti tā augstās pieejamības uzturēšanai un pielāgošanai periodiski mainīgajām prasībām.

Papildus tehnisko degradācijas novēršanai nepieciešamo darbību novērtēšanai ir jāapsver jauni izaicinājumi, kā arī iespējamās uzņēmējdarbības iespējas. Uzņēmējdarbības vide pastāvīgi mainās, un vienmēr ir jāapsver visas iespējas uzlabot esošās vai ieviest jaunas tehnoloģijas. Tipiskas uzņēmējdarbības iespējas, kas var veicināt dārgu automatizācijas sistēmu migrāciju, ir ātrums uz tirgu, konkurētspēja, izaugsme, kvalitāte un atbilstība normatīvajiem aktiem.

Ilgtermiņa migrācijas plāns

Ilgtermiņa sistēmas migrācijas plāna izstrāde ļauj uzņēmumiem uzturēt sistēmiskos darbības riskus pieņemamā līmenī. Turklāt tas nodrošina risku pārvaldību un savlaicīgu biznesa mērķu atbalstu. Migrācijas plānā ir jāņem vērā tādi ierobežojumi kā “labākā ražošanas prakse”, tehnoloģiju funkcionalitāte un neizbēgama ražošanas dīkstāve.

Kopumā pieeja ilgtermiņa plānošanai ir attēlota 1. att. Tiek izstrādāts migrācijas plāns, lai noteiktu, kur uzņēmums vēlas atrasties pēc pieciem gadiem, kādas darbības jāveic, lai tur nokļūtu, un vai ir pieejami resursi, kas nepieciešami, lai tur nokļūtu. Šī pieeja ir balstīta uz TOGAF standartā iezīmētajiem arhitektūras projektēšanas principiem, kas tiek plaši izmantots rūpniecības uzņēmumu sistēmu arhitektūras izstrādē.

1. attēls. Vispārējā pieeja ilgtermiņa migrācijas plāna izveidei.

Ir jānošķir esošā arhitektūra no mērķa, vēlamās. Atšķirība starp tām atspoguļo atšķirību starp uzņēmuma pašreizējo pozīciju un pozīciju, kuru tas vēlas ieņemt nākotnē. Migrācijas plānā ir norādīts ceļš no esošās arhitektūras uz mērķa arhitektūru — iespējams, izmantojot vairākus pārejas posmus.

Katru arhitektūru var raksturot kā virkni "slāņu", kas mazina plaisu starp biznesu un tehnoloģijām — kā parādīts 1. attēlā. 1. Jāpievērš uzmanība šādiem "slāņiem":

  • Biznesa mērķi tā ir daļa no vispārējās stratēģijas plānošanas centieniem. Tie ļauj izvēlēties pareizo procesa virzienu.
  • Biznesa modelis nodrošina kontekstu, kurā tiek izprasti ražošanas un biznesa procesi. Parasti tas ietver augsta līmeņa materiālu plūsmu un procesu aprakstu.
  • Apraksts ražošanas un biznesa procesiem ir svarīga tehnoloģiju veiksmīgai pielietošanai un to vērtības pareizai novērtēšanai no biznesa viedokļa.
  • Informācija, dati un dokumenti svarīgi, lai savienotu procesus un lietojumprogrammas. Īpaši svarīga ir sadarbspēja un informācijas plūsmu pārvaldība starp lietojumprogrammām.
  • Apraksti lietojumprogrammasļauj formulēt augsta līmeņa prasības un definēt saskarnes.
  • Definīcija infrastruktūra, skaitļošana un tīkls prasības (aparatūra, kļūdu tolerance, veiktspēja).
  • Ar nosacījumu pakalpojumus definēt prasības efektīvas darbības vadības un lēmumu atbalsta nodrošināšanai.

Migrācijas plāna izstrāde

Migrācijas plāna izstrāde visai organizācijai vai pat vienai ražošanas vietai var būt patiesi sarežģīts uzdevums, kurā iesaistīti daudzi cilvēki. Izstrādes procesu ieteicams sadalīt vairākos posmos, kas aprakstīti tālāk.

II daļa

1. posms: mobilizācija

Pamatmērķi:

  • panākt vienotu izpratni par uzdevumiem un mērķiem
  • mobilizēt organizāciju, kurā projekts tiek plānots
  • detalizēti aprakstiet plānu, aprakstot projekta posmu posmus un rezultātus
  • apkopot visu nepieciešamo/pieejamo informāciju
  • nodrošināt pareizu izpratni par jēdzieniem, praksi un teoriju
  • plānotajām sanāksmēm
  • seminārs, kas veltīts projekta uzsākšanai

Rezultāti:

  • detalizēts konsultāciju plāns
  • kopīgus mērķus
  • procesa pārskats

2. posms: analīze

Analīzes posma mērķi ir:

  • biznesa un ražošanas procesu analīze, lai:

Novērtēt IT un automatizācijas sistēmu apkalpojošā personāla gatavību

Izprotiet datu un funkcionalitātes vajadzības nākotnes arhitektūrai

Nosakiet galvenās nākotnes arhitektūras priekšrocības, lai izvirzītu mērķus un īstenotu biznesa piemēru

  • esošās arhitektūras analīze

Esošo ražošanas procesu noteikšana saistībā ar automatizācijas sistēmām, datu vākšanu, ražošanas vadības sistēmām

Esošo biznesa procesu un to saistību ar ražošanas automatizācijas sistēmām identificēšana

Identificējiet esošās lietojumprogrammas, datus, loģisko un fizisko infrastruktūru un tehniskā atbalsta pakalpojumus

Šajā posmā tiek veiktas šādas darbības:

  • semināri un diskusijas par dažādiem procesiem
  • vietnes apmeklējumi, lai iegūtu kontekstuālu informāciju
  • semināri un diskusijas par esošajām sistēmām
  • pakalpojumu novērtēšana, lai noteiktu to briedumu un atbilstību normatīvajām prasībām

Rezultāti:

  • esošās infrastruktūras identificēšana
  • analīzes dokumentācija
  • ideju saraksts par jaunās arhitektūras izaicinājumiem un iespējām ideju saraksts par jaunās arhitektūras izaicinājumiem un iespējām

3. posms: mērķis

Šī posma mērķis ir identificēt un aprakstīt analīzes posmā formulētās vajadzības.

Risinājums jeb mērķa arhitektūra apraksta:

  • nākotnes biznesa procesi un funkcionalitāte
  • mērķa lietojumprogrammu tipi ar to funkcionalitāti, lietotājiem, informāciju un saskarnēm
  • infrastruktūras vajadzības un pārskatīti atbalsta standarti

Šajā posmā tiek veiktas šādas darbības:

  • semināri un diskusijas par procesu pilnveidošanu
  • semināri un diskusijas par arhitektūras uzlabošanu

Rezultāti:

  • nākotnes arhitektūra (prezentācija)
  • Īss lietojuma veidu apraksts

4. posms: pamatojums

Pamatojuma fāzes mērķis ir nodrošināt sākotnējo biznesa piemēru, pamatojoties uz aptuvenām projekta izmaksu un ieguvumu aplēsēm.

Plaisa starp esošo un vēlamo situāciju parasti noved pie vairāku ideju rašanās. Ideju pamatojums ļaus atšķirt “vajadzīgo” no “vēlamo” un pēc tam prezentēt un attīstīt idejas augstākajai vadībai.

Šajā posmā tiek veiktas šādas darbības:

  • aptuvens izmaksu un ieguvumu aprēķins
  • prezentācijas pirmā versija

Rezultāti:

  • kopīgus mērķus
  • biznesa ideju prioritāšu noteikšana
  • nepieciešamo resursu novērtējums

5. posms: plāns

Šī posma mērķis ir plānot projektu, pamatojoties uz prioritātēm, resursiem un atkarībām:

  • konsolidētā projekta posmu īstenošanas secības plānošana
  • nodrošinot resursus un kompetences, kas nepieciešamas nākamajiem soļiem
  • projekta vadības aktivitāšu uzsākšana
  • konsultāciju pabeigšana un visu posmu rezultātu nodošana pasūtītājam

Šajā posmā tiek veiktas šādas darbības:

  • īstenošanas plāna izstrāde
  • investīciju plāna izstrāde
  • riska novērtēšana

Rezultāti:

  • īstenošanas plānu
  • projektā iesaistītā personāla noslodzes novērtējums
  • projekta risku novērtējums
  • investīciju plāns (kā pirmais aptuvens)
  • projekta prezentācijas galīgā versija

Gadījuma izpēte

Sekojošais piemērs ilustrē aprakstītās pieejas pielietojumu reālos apstākļos. Lai ievērotu konfidencialitātes nosacījumus, aprakstā tiek saglabāta anonimitāte. Mēs runājam par diezgan lielu uzņēmumu, kas ražo aktīvās sastāvdaļas farmaceitiskajiem produktiem. Ražotnes tika nodotas ekspluatācijā vairāk nekā pirms 20 gadiem, un, lai gan kopš tā laika ir veikta zināma modernizācija, vairākas novecojušas sistēmas ir jānomaina. Ēku automatizācijas sistēmas un DCS ir pirmajā vietā, jo to pamatā ir novecojušas tehnoloģijas, kuras ir grūti uzturēt. Turklāt ražošanai ir jāpielāgojas jaunām biznesa prasībām, tostarp dažu produktu pārtraukšanai un citu produktu laišanai tirgū. Kopumā ir jāstrādā pie migrācijas plāna, kas aptver gan tehniskās, gan biznesa prasības.

Pirmkārt, jums ir jāizveido galvenais saraksts ar aprīkojumu, kas pašlaik tiek izmantots visā uzņēmumā. Šī informācija bieži tiek “paslēpta” dažādos dokumentos (un darbinieku atmiņās). Tas ir jāizvelk un jāvizualizē, lai tas kļūtu par pamatu migrācijas plānošanai. Šim nolūkam mēs parasti izveidojam procesa moduļa diagrammu, kurā parādītas galvenās iekārtas un izejvielu kustības katrā ražošanas vienībā. Kā atsevišķus slāņus aparatūras "virspusē" mēs parādām, kuras sistēmas atbalsta kādu aparatūru.

Piemērs ir parādīts attēlā. 2. Dati par instalētajām sistēmām ir iekļauti arī sistēmas krātuvē (vai vienkārši Excel failos), un tos var izmantot tālākai analīzei un plānošanai.

2. attēls. Automatizācijas “slānis” ļauj novērtēt esošās sistēmas

Pirms migrācijas plāna apspriešanas ir jāidentificē galvenie ražošanas izmaiņu biznesa iemesli. Šajā gadījumā vadība identificēja šādus motīvus:

1. Konsekventa un bez kļūdām normatīvo prasību ievērošana

2. Minimālais laiks, kas nepieciešams ienākšanai tirgū, elastība

3. Panākumi, konkurētspēja, darbības izcilība

4. Bezkompromisa kvalitāte

5. Ražošanas apjomu pieaugums

Šie mērķi ir jāpārvērš konkrētākos uzdevumos, kuru izpildi var kvantitatīvi noteikt.

Tālāk mums ir jānoskaidro, cik labi esošās sistēmas atbalsta pašreizējos un nākotnes biznesa procesus. Lai to izdarītu, mēs izmantojam standarta atsauces modeli (pamatojoties uz ANSI/ISA-95 standartu sēriju). Tas ietver 19 augsta līmeņa biznesa procesus, kas ir detalizēti tiktāl, ciktāl tas ļauj saskatīt nepilnības to praktiskajā ieviešanā un nepieciešamību pēc izmaiņām efektīvas uzņēmējdarbības labad.

Turklāt mums ir arī jāizvērtē esošo sistēmu tehniskās iespējas, lai nākotnē atbalstītu biznesa procesus. Tas tiek darīts sistemātiski, izmantojot iepriekš aprakstīto informāciju no sistēmas krātuves. Katrai sistēmai, par kuru repozitorijā atrodas informācija (mūsu gadījumā aptuveni 70 sistēmām), ir jāizvērtē šādi aspekti:

  • Iekārtas stāvoklis (atteices vēsture, vidējais laiks starp atteicēm, aprīkojuma vecums, rezerves daļu pieejamība)
  • Programmatūras statuss (pārdevēja atbalsts, dokumentācijas pieejamība, personāls ar nepieciešamajām kompetencēm)
  • Sistēmas atkopšanas iespējas (redundance, vidējais kalpošanas laiks pirms remonta)
  • Uzņēmējdarbības ietekmes novērtējums (informācijas sniegšana, datu kļūdas, nepieejamība)
  • Indikatīvie rādītāji (sistēmas uzticamība, sistēmas kritiskā nozīme utt.)

Tehniskajā novērtējumā tika konstatēta nepieciešamība modernizēt un nomainīt vairākas sistēmas:

  • Procesu vadības sistēmas ir balstītas uz tradicionālo, novecojušo DCS un daudziem dažādiem PLC, no kuriem daži jau ir “nobrieduši” nomaiņai.
  • Ēku automatizācijas sistēma ir balstīta uz jaunāku platformu, taču tā ir arī jāmodernizē, lai tā atbilstu jaunām prasībām.
  • Vairākām sekundārajām sistēmām arī nepieciešama modernizācija vai pat nomaiņa.
  • Infrastruktūrai, kas apkalpo visas sistēmas, ir nepieciešama labāka segmentācija un aizsardzība, lai tā atbilstu mūsdienu drošības prasībām.

III daļa

Izanalizējot biznesa mērķus nākotnē, kļuva skaidrs, ka neviena no esošajām sistēmām pilnībā neatbilst nākotnes vajadzībām. Šī izpratne radīja vairākas idejas par jaunu tehnoloģiju ieviešanu, kā arī ražošanas izpildes sistēmu. Analīzes rezultātā tika piedāvāti 16 dažādi projekti, kas, konsekventi īstenojot, palīdzēs uzņēmumam izpildīt turpmākās tehniskās un komerciālās prasības.

Tiek novērtēts katra projekta tehniskā darba saturs un izmaksas; Katram projektam tiek sagatavots īss vienas lapas kopsavilkums, ko vadība var apspriest. (Skatīt 3. attēlu).

Rīsi. 3. Potenciālā migrācijas projekta apraksts vienas lapas garumā

Lai izvēlētos prioritāros projektus, tiek izvērtēti katra no tiem iespējamie rezultāti. Rezultāti tiek vērtēti, ņemot vērā biznesa mērķus, kā arī procesu kontroles sistēmas uzticamību.

Parasti jums būs jānovērtē vairāki īstenošanas scenāriji, lai novērtētu katra plāna kopējās resursu un finansējuma prasības (7. attēls). Viens no galvenajiem ierobežojumiem, kas jāņem vērā, ir logi ražošanas procesā, kura laikā sistēmas var nomainīt vai modificēt. Parasti šie “logi” notiek nedēļas nogalēs - un tas ir nopietns sašaurinājums.

Rīsi. 7. Migrācijas grafika konsolidēts pārskats

Tā kā sistēmu nomaiņai un uzstādīšanai vienmēr ir maz laika, sagatavošanai jābūt ļoti rūpīgai. Viss ir rūpīgi jāizplāno. Svarīgs plānošanas aspekts ir ieviesto sistēmu testēšana.

Mūsu aprakstītajā gadījumā ilgtermiņa migrācijas plāna īstenošana tika veikta sešās dažādās plūsmās, sk. 8.

Rīsi. 8. Migrācijas projektu organizēšana sešās dažādās plūsmās

Daļa no sagatavošanās ir rūpīga projekta risku novērtēšana un novēršana. Attēlā 9. attēlā parādīti tipiski riski, kas saistīti ar migrācijas projektiem.

Rīsi. 9. Migrācijas projektu tipisko risku izvērtēšana

Biznesa atbalsta procesi

Šajā rakstā aprakstītā dzīves cikla pārvaldības un ilgtermiņa migrācijas plānošanas pieeja ir balstīta uz uzņēmējdarbības vajadzībām. Tas ietver pašreizējo un nākotnes biznesa mērķu novērtējumu, kā arī rūpīgu analīzi par to, kā tehniskās sistēmas tiks uzturētas vai nomainītas, lai vislabāk atbalstītu šos mērķus. Pieeja ir balstīta uz TOGAF principiem, kas paredz secīgu projektu realizāciju atkarībā no budžeta un kvalificēta personāla pieejamības. Pašreizējās un turpmākās sistēmas arhitektūras novērtēšana ir galvenais elements turpmāko migrācijas projektu noteikšanā. Visbeidzot, ir nepieciešams ievērot organizatorisko izmaiņu vadības principus, kas nodrošina savlaicīgu galveno projekta ieinteresēto personu iesaistīšanos, kas ir tik svarīga migrācijas projektu panākumiem. Šīs pieejas efektivitāte ir vairākkārt pierādīta praksē.

Leifs Poulssn) ( ), vadošais automatizācijas un IT speciālists uzņēmumā NNE Pharmaplan. Viņam ir maģistra grāds procesu vadībā. Uzņēmumā NNE Pharmaplan Poulsen ir atbildīgs par tehnoloģiju, metožu un kompetenču izstrādi rūpnieciskās automatizācijas un IT jomā, kā arī strādā par vecāko biznesa konsultantu.

Pēdējo reizi atjaunināts: 31.10.2015

Bieži vien situācija rodas, mainoties modelim. Piemēram, mēs nolēmām tajā ieviest jaunus īpašumus. Bet tajā pašā laikā mums jau ir esoša datu bāze, kurā ir daži dati. Un, lai atjauninātu datubāzi bez zaudējumiem, ASP.NET MVC mums piedāvā tādu mehānismu kā migrācijas. Piemēram, mums ir vienkāršs lietotāja modelis:

Publiskā klase Lietotājs ( publisks int Id ( get; set; ) public string Name ( get; set; ) )

Attiecīgi ir datu konteksts, caur kuru mēs strādājam ar datu bāzi:

Lietotāji (get;set;))

Un pieņemsim, ka mums ir visa infrastruktūra darbam ar šo modeli – skati, kontrolleri, un datu bāzē jau ir vairāki šī modeļa objekti. Bet kādā brīdī mēs nolēmām mainīt lietojumprogrammas modeļa bāzi. Piemēram, lietotāja modelim pievienojām vēl vienu lauku:

Publiskā klase Lietotājs ( public int Id ( get; set; ) public string Name ( get; set; ) public int Vecums ( get; set; ) )

Turklāt mēs nolēmām pievienot vēl vienu modeli, piemēram:

Publiskās klases uzņēmums ( publisks int Id ( get; set; ) public string Name ( get; set; ) )

Tādējādi mūsu datu konteksts jau mainās šādi:

Publiskā klase UserContext: DbContext ( publiskais UserContext() : base("Noklusējuma savienojums") ( ) public DbSet Lietotāji ( get; set; ) publiskais DbSet Uzņēmumi ( iegūt; iestatīt; ) )

Lietotāja modeļa skatiem varam pievienot papildu lauku rekvizītam Vecums, jaunajam modelim varam izveidot kontrolleri un skatus, bet, mēģinot datubāzei pievienot jaunu objektu, saņemsim kļūdu:

Datu konteksts ir mainījies, un tagad mums ir jāmigrē no vecās datu bāzes shēmas uz jauno. Un vispirms Visual Studio apakšā atrodiet Package Manager Console logu, ievadiet tajā komandu: enable-migrations un nospiediet taustiņu Enter:

Pēc šīs Visual Studio komandas palaišanas projektā tiks izveidota mape Migrations, kurā var atrast failu Configuration.cs. Šajā failā ir tāda paša nosaukuma konfigurācijas klases deklarācija, kas nosaka konfigurācijas iestatījumus:

Nosaukumvietas MigrationApp.Migrations (izmantojot System; izmantojot System.Data.Entity; izmantojot System.Data.Entity.Migrations; izmantojot System.Linq; iekšējā slēgtā klases konfigurācija: DbMigrationsConfiguration (publiskā konfigurācija() ( AutomaticMigrationsEnabled = false; ContextKey = "MigrationApp.Models.UserContext"; ) aizsargāta ignorēšana void Seed(MigrationApp.Models.UserContext konteksts) ( ) ) )

Sēklu metodē datu bāzi var inicializēt ar sākuma datiem. Tagad mums ir jāizveido pati migrācija. Tur pakotņu pārvaldnieka konsolē ievadiet komandu:

PM pievienošana-migrācija "MigrateDB"

Pēc tam Visual Studio automātiski ģenerēs migrācijas klasi:

Nosaukumvieta MigrationApp.Migrations ( izmantojot System; izmantojot System.Data.Entity.Migrations; publiska daļēja klase MigrateDB: DbMigration ( publiska ignorēšana void Up() ( CreateTable("dbo.Companies", c => new ( Id = c.Int() nullable: false, identitāte: true), Name = c.String(), )).PrimaryKey(t => t.Id); AddColumn("dbo.Users", "Age", c => c.Int(nullable : false)); ) publiska ignorēšana void Down() ( DropColumn("dbo.Users", "Age"); DropTable("dbo.Companies"); ) ) )

Metodē Up, izsaucot metodi CreateTable, tiek izveidota tabula "dbo.Companies" un veikta tās konfigurēšana: kolonnu veidošana, taustiņu iestatīšana. Esošajai tabulai tiek pievienota arī jauna sleja Vecums. Metode uz leju noņem kolonnu un tabulu, ja tādas pastāv. Faktiski šīs metodes ir līdzvērtīgas ALTER izteiksmei SQL, kas maina datu bāzes un tās tabulu struktūru.

Un visbeidzot, lai veiktu migrāciju, mēs izmantosim šo klasi, ierakstot komandu tajā pašā konsolē:

PM Update-Database

Pēc tam, ja aplūkosim datu bāzes sastāvu, redzēsim, ka tajā ir veiktas izmaiņas atbilstoši veiktajai migrācijai:

Tātad, migrācija ir pabeigta, un mēs jau varam izmantot atjauninātos modeļus un datu kontekstu.

Šajā rakstā mēs vēlamies sistematizēt mūsu pieredzi datu migrācijas veikšanā lielos korporatīvajos projektos, kas saistīti ar Klientu pāreju uz darbu 1C:Enterprise 8 konfigurācijās.

Tajā pašā laikā galvenais uzsvars rakstā, pirmkārt, tiks likts uz migrācijas procesa tehnoloģisko komponentu. Tiek ietekmēta arī organizatoriskā sastāvdaļa, bet mazākā mērā.

Termini un definīcijas

Datu migrācija parasti tiek saprasta kā darba beigu secība, projekts, kura mērķis ir vienreizēja masveida datu pārvietošana no avota sistēmām (vēsturiskajām sistēmām) uz galamērķa sistēmu. Tajā pašā laikā šo datu izmantošana avota sistēmās tiek pārtraukta.

Datu migrācija ir jānošķir no datu integrācijas. Integrācija, atšķirībā no migrācijas, ir pastāvīga IT arhitektūras sastāvdaļa un ir atbildīga par datu plūsmu starp dažādām sistēmām un datu krātuvēm, un tā ir process, nevis projekta darbība.

Migrācijas shēma kopumā izskatās šādi:

Rīsi. 1

Vēsturiskās sistēmas- Klienta uzņēmuma datu bāzes, kuras plānots pilnībā vai daļēji nomainīt, ieviešot jaunu sistēmu.

Uztvērēja sistēma- mērķa sistēma, patvaļīga konfigurācija “1C:Enterprise 8”.

Sākotnējie dati- dati, kas lejupielādēti no vēsturiskajām sistēmām pielāgotā xls faila formātā. Šajā gadījumā xls formāts šķiet viens no ērtākajiem, jo ​​iespēja augšupielādēt xls failu ir pieejama daudzās “iepriekšējo paaudžu” grāmatvedības sistēmās.

Kā modernu alternatīvu var uzskatīt xml faila formātu kā transportu.

Ir arī iespējas izmantot starpposma datubāzi.

Pārvēršana, pārvēršana- avota datu pārvēršanas process ielādes datos. Datu transformācija notiek saskaņā ar ielādes veidnēm. Transformācijas rezultāts ir ielādējamie dati.

Lejupielādējamie dati- dati, kas paredzēti ielādei saņemšanas sistēmā. Šajā rakstā, kā arī avota datos ir apskatīts xls formāts.

Datu veidnes ielādei- mērķa sistēmā ielādējamo datu tabulu apraksts.

Migrācijas posmi

Apskatīsim migrācijas sagatavošanas un veikšanas procesu soli pa solim.

Migrācijas organizatoriskie posmi ietver šādus punktus:

· Migrācijas stratēģijas noteikšana. Šajā posmā Izpildītājs un Pasūtītājs vienojas par migrācijas darbu veikšanas tehnoloģiju;

· Migrācijas darba grupas sastāva noteikšana. Darba grupā jāiekļauj speciālisti gan no Izpildītāja, gan Pasūtītāja, kas pietiekami labi pārzina vēsturisko sistēmu darbību (no Pasūtītāja puses) un mērķa sistēmu (no Izpildītāja puses);

· Provizoriskais migrācijas plāns. Projekta gaitā migrācijas plāns tiks vairākkārt koriģēts;

· Datu lejupielādes datumu periodi no vēsturiskajām sistēmām, datu apjomi. Datu pārtraukšanas periodi migrācijai, pārbaudes datumi un galīgā migrācija. Šo informāciju var attiecināt uz migrācijas plānu;

· Migrējamo datu sastāvs. Atsauces dati, klasifikatori, darījumu dati, atlikumi, apgrozījums utt.;

· Datu kvalitātes, pareizības un integritātes pārbaudes jautājumi migrācijas procesa laikā un beigās;

· Problēmas ar atgriešanos iepriekšējā stāvoklī kļūmju gadījumā.

Pakavēsimies sīkāk pie migrācijas tehnoloģiskajiem posmiem.

Rīsi. 2

1.Datu ielādes veidņu sagatavošana

Datu ielādes veidnē ir ielādējamo datu tabulu tehniskie apraksti, pašreizējās veidnes algoritmi un ielādes noteikumi.

Katra veidne parasti ir paredzēta vienai vai vairākām saistītām tabulām mērķa mērķa sistēmā.

Veidnē ir norādīts:

· Visu lejupielādes xls datu faila lauku apraksts, tostarp:

o Lauka nosaukums

o Rādītājs, ka lauks ir jāaizpilda

o Lauka aizpildīšanas piemērs

o Piezīme

· Mērķa sistēmas tabulas ielādes noteikumu apraksts, pamatojoties uz ielādējamajiem datiem (rinda vairāku saistītu tabulu gadījumā, atslēgas lauku meklēšanas algoritmi utt.)

· Mērķa sistēmas tabulu lauku tiešās aizpildīšanas apraksts, ja tiek nodrošināts kaut kas cits, izņemot datu pārsūtīšanu "viens pret vienu" no datu faila ielādei. Attiecas, piemēram, atsauces laukiem.

Veicot darbu šajā posmā, Izpildītājam ir jāsagatavo arī datu failu ielādētājs ielādei. Strādājot ar xls failiem, šis uzdevums nav īpaši grūts.

2.Datu avotu identifikācija

Šis posms var sākties kopā ar iepriekšējo posmu “1. Notiek datu ielādes veidņu sagatavošana."

Šajā posmā Klienta speciālisti nosaka, no kurām sistēmām un kādus datus var lejupielādēt. Jums vajadzētu arī noteikt, kādi dati Var būt var būt nepieciešams.

Parasti lielos migrācijas projektos pilnīga izsmeļoša datu avotu saraksta noteikšana var aizņemt diezgan ilgu laiku un notiek, turpinot darbu nākamajos posmos.

Nereti ir situācijas, kad, lai turpmāk nodrošinātu informācijas integritāti, daži dati pēc Pasūtītāja galveno darbinieku vārdiem ir jāpārnes no drukātiem avotiem (digitalizē) vai pat jāievada tabulās.

Tomēr šajā posmā jums jācenšas identificēt pēc iespējas vairāk nepieciešamo datu.

3.Avota datu augšupielāde

Datu lejupielādes process no vēsturiskajām sistēmām var aizņemt diezgan daudz laika, īpaši, ja sistēmu ir daudz, tās ir dažādas un par tām atbild dažādas Klienta nodaļas. Šis punkts ir jāņem vērā testa un galīgās migrācijas laikā.

Šķiet, ka ērtākā iespēja ir augšupielādēt xls failus. Daudzas vecākas IT sistēmas atbalsta šo iespēju.

Var būt arī iespējas augšupielādēt csv formātā, dbf, xml formātā un citos.

Ir vērts atzīmēt, ka viena vai otra iemesla dēļ (piemēram, drošības jautājumi) Klients šajā posmā ne vienmēr var nodrošināt datu lejupielādi pilnā apjomā! Tikai datu struktūra un dažas testa pozīcijas. Tādējādi var izveidoties situācija, ka testa un galīgās slodzes laikā avota tabulās tiks konstatēti zemas kvalitātes dati, kas radīs neplānotas kļūdas.

Lai mazinātu šo problēmu, iepriekš jāvienojas par testa lejupielāžu apjomiem no vēsturiskajām sistēmām.

4.Datu kartēšana

Kartēšana (datu kartēšana) - kopumā vēsturisko sistēmu un saņemošās sistēmas datu salīdzināšanas process. Tas ir, avota dati un dati, kas jāielādē.

Kartēšanas posms ir darbietilpīgākais posms, un tas var aizņemt vairāk nekā 50% no visa migrācijas uzdevuma darba.

Šajā posmā ir pilnībā iesaistīta visa migrācijas projekta darba grupa.

Datu kartēšanas procesā ir jānošķir tabulas kartēšanas un lauku kartēšanas apakšposmi.

· Tabulu kartēšana jeb veidņu kartēšana - avota datu tabulu un datu veidņu salīdzināšana ielādei. Mačs var būt 1:1 vai N:N. Šī darba rezultātā tiek apkopots un uzturēts tabulu kartēšanas reģistrs. Šis apakšposms ir nepieciešams nākamajam lauka kartēšanas apakšposmam un vispārējā kartēšanas stāvokļa uzraudzībai.

1C veidņu grupa

1C veidnes nosaukums

Faila nosaukums-

avots

Avota faila ģenerēšanas noteikumi

Atbildīgs

Statuss

Piezīme

NSI

paraugs_

Nomenklatūra

Nomenk

latura.xls

Iestatīt atlasi sistēmā N
. Saglabāt txt failā
. Atvērt xls, kolonnas ir teksts
. Pirmā rinda ir galvene
. Kolonnu skaits - 15
. Pārbaudiet rindu skaitu txt un xls
. Lapas nosaukums vienmēr ir "Sheet1"

Ivanovs I.I.

darbā

· Lauku kartēšana - tabulas lauku kartēšana jau noteiktas tabulas kartēšanas ietvaros. Šī darba rezultāts ir lauka kartēšanas reģistrs.

№ lpp

Cl. lauks

Obligāti

1C veidnes lauka nosaukums “Template_Nomenclature”

Apraksts

Lauka nosaukums "Nomenclature.xls"

Aizpildīšanas algoritms

Kods

Direktorija elementa kods

Kods

Vārds

Vārds

Jā

Šī grupa

Satur vienu no šīm vērtībām:
. 1 - grupām
. 0 - elementiem

Ja koda garums = 11 rakstzīmes un pēdējās 4 rakstzīmes<>"0000", tad šis elements ir "0", pretējā gadījumā grupa ir "1".

Pilnais vārds

Direktorija elementa nosaukums

Vārds

Ja ThisGroup = 1, tad "", ElseIf ThisGroup = 0, tad Name.

Šī posma ietvaros būtu jāveic arī iespējamais darbs pie datu normalizēšanas.

5.Transformācijas noteikumu sagatavošana

Atšķirībā no iepriekšējiem posmiem šis posms ir tehnisks un ietver Izpildītāja izstrādātāja darbu.

Pamatojoties uz saskaņotajiem lauku kartēšanas reģistriem, Izpildītāja speciālisti izstrādā noteikumus datu pārveidošanai.

Operatīvā darba veikšanai migrācijas sagatavošanas posmos un turpmāk, testa un galīgās migrācijas laikā, ir svarīgi, lai būtu ērta vide datu transformācijas noteikumu (skriptu) izstrādei un vide avota datu konvertēšanai datos ielādei.

Prasības šai videi ietver:

· Pārveidošanas noteikumu izstrādes ērtība un ātrums;

· Datu konvertēšanas ātrums. Ievades un izvades faili var būt simtiem tūkstošu rindu gari!

· Spēja strādāt ar vairākiem ievades failiem vienlaicīgi;

· Iespēja saglabāt transformācijas noteikumus atsevišķos failos.

Mūsu migrācijas projektiem esam izstrādājuši specializētu izstrādātāja darbstaciju, par pamatu izmantojot standarta 1C Query Console apstrādi.

Vaicājumu konsoles apstrāde ir uzlabota, lai varētu veikt tiešus vaicājumus uz xls failiem.

Šeit ir divu avota xls failu apvienošanas piemērs Darbinieki.xls


Darbinieka kods

Uzvārds

Vārds

Uzvārds

Dzimšanas datums

2423

Ivanovs

Ivans

Ivanovičs

17.11.1992

1523

Petrovs

Baziliks

Aleksandrovičs

04.02.1991

4363

Sidorovs

Kirils

Nikolajevičs

01.05.1995

Deņisovs

Deniss

Deņisovičs

01.01.1990

Un Operācijas.xls ar lapām:

Norakstīšana

Darbinieka kods

datums

Summa

2423

01.02.2014

1523

02.02.2014

4363

03.02.2014

04.02.2014

100000

2423

05.02.2014

1523

06.02.2014

4363

07.02.2014

2356

08.02.2014

140000

2423

09.02.2014

1523

10.02.2014

4363

11.02.2014

23523

12.02.2014

80000

Un Kvītis:

Darbinieka kods

datums

Summa

01.05.2004

02.05.2004

03.05.2004

04.05.2004

2423Dzimšanas datums

Kvīts summa

Norakstītā summa

Ivanovs Ivans Ivanovičs

2423

17.11.1992

1341234

1010

Petrovs Vasilijs Aleksandrovičs

1523

04.02.1991

245245

Denisovs Deniss Denisovičs

01.01.1990

380000

320000

Sidorovs Kirils Nikolajevičs

4363

01.05.1995

613382

26336

KOPĀ:

2579861

347842

Ņemiet vērā, ka piemērs ir mākslīgs, īpaši atlasīts, lai demonstrētu visus iespējamos datu avotu transformācijas posmus.

Pārveidošanas darbību tehnoloģiskā secība šeit ir šāda:

Izmantojot Access SQL vaicājumu valodu (kas nodrošina ievērojamas papildu iespējas salīdzinājumā ar 1C vaicājumu valodu), tiek izveidots sākotnējais vaicājums, kas izvelk datus no xls faila 1C vidē. Tajā pašā laikā jau šajā posmā iespējamas dažādas datu pārbaudes un normalizēšana.

ADO datu piekļuves tehnoloģija nodrošina lielu ātrumu.

Rīsi. 3

2. Vaicājums 1C valodā - galvenais vaicājums, kas realizē lauka kartēšanas algoritmu. Un arī: lejupielādēto datu bagātināšana ar datiem no 1C datu bāzes, pārgrupēšana, apvienošana ar vaicājumu rezultātiem uz citiem avota xls failiem utt.

3. Ja nepieciešams, 1C pieprasījuma rezultāta pēcapstrāde. Īstenots, izmantojot skriptu 1C valodā.

Piemēram, šeit mēs ieviešam rindas “TOTAL” pievienošanu summu kolonnās.

4. Ierakstiet galīgo datu kopu xls failā.

Kopumā izvade ir galīgie faili ielādei mērķa 1C datu bāzē.

Šis rīks arī ļauj saglabāt datu konvertēšanas noteikumus atsevišķā xml failā:

Turklāt ir iespēja strādāt V pakešu režīms, kas ir īpaši svarīgi, ja migrē liels daudzums neviendabīgu datu.

Iepriekšējos posmos darba sagatavošanas daļa kopumā beidzas - tiek identificēti visi datu avoti, no avotiem tiek lejupielādēti avota dati, tiek sagatavotas lejupielādes veidnes mērķa datubāzē, tiek sagatavota datu kartēšana un, visbeidzot, tiek izstrādāti datu transformācijas skripti. .

Jāatzīmē, ka pirms galīgās migrācijas noteikti jāveic vairākas pārbaudes. Pārbaudes migrācijas laikā Izpildītājs kopā ar Pasūtītājiem identificē:

Konversijas kļūdas, datu ielādes kļūdas

Veiciet mērķa sistēmā ielādēto datu kvalitātes sākotnējo novērtējumu

Pamatojoties uz testa migrācijas rezultātiem, viņi izveido/atjaunina galīgo migrācijas plānu

7.Datu saskaņošana

Lejupielādēto datu kvalitāte ir jāpārbauda gan pēc testa migrācijas, gan galīgās migrācijas beigās. Saskaņošanas laikā var pārbaudīt šādus rādītājus:

· Kopējo summu sakritība atlikumiem, saskaņā ar dokumentiem;

· Kvantitatīvās atbilstības, piemēram, OS skaits;

· Pareiza atsevišķu atlasīto entītiju aizpildīšana;

Lūdzu, ņemiet vērā, ka noteiktas migrācijas datu pārbaudes un datu normalizēšanas problēmas ir jāatrisina visos migrācijas procesos. Jums vienmēr jājautā sev, kas ir jādara pašreizējā posmā, lai izvairītos no kļūdām turpmākajos posmos.

Piemēram:

· Pārbaudiet, vai nav dublikātu pēc atslēgas laukiem. To var un vajadzētu veikt, pamatojoties uz sākotnējiem datiem;

· Lauku tipu piespiešana;

· Atsauces integritāte;

· Matemātiskas neatbilstības. Piemēram, pārbaudot, vai nav tukšu ciparu lauku, kuros transformācijas laikā plānots sadalīt;

· Kopumā pārbaudot, obligātie lauki ir aizpildīti;

· Nepareizu rakstzīmju aizstāšana. Piemēram, angļu rakstzīmes kirilicas laukos ("o", "a", "e" utt.) Tas jo īpaši attiecas uz galvenajiem laukiem!

· Virkņu lauku vērtību pārbaude, lai pārbaudītu atbilstību uztverošās sistēmas tipiem (garuma ierobežojumi)

Pēc galīgās migrācijas pabeigšanas saskaņā ar iepriekš noteiktu migrācijas stratēģiju un migrācijas plānu tiek pieņemts lēmums par vēsturisko sistēmu turpmāko darbību.

Bieži vien operācija tiek pabeigta uzreiz pēc galīgajām datu saskaņošanas un migrācijas panākumu fiksēšanas – jaunās sistēmas lietotāji vairs neveic uzskaiti divās sistēmās paralēli, bet pilnībā pāriet uz jauno sistēmu. Tajā pašā laikā piekļuve vecajai sistēmai tiek uzturēta lasīšanas režīmā.

Dažos gadījumos divu sistēmu paralēla darbība var notikt izmēģinājuma darbības (TE) laikā un pat pēc šī perioda. Jautājums par lietotāju paralēlu darbu divās sistēmās ir cieši saistīts ar jautājumu par iespēju atgriezties pie vecās sistēmas, ja migrācija (vai kopumā jaunās sistēmas darbība!) tiek uzskatīta par neapmierinošu.

Secinājums

Nobeigumā vēlos atzīmēt, ka, runājot par lielu transakciju sistēmu migrēšanu, kas ietver daudzas 1C:Enterprise konfigurācijas, pāreja uz jaunu sistēmu var būt ļoti darbietilpīga.

Tāpēc jāatceras, ka jebkurš šāds projekts prasa rūpīgu sagatavošanos un tam ir jāpievieno individuāls plāns. Tomēr neatkarīgi no migrējamo sistēmu veida, datu bāzes apjomiem utt., vispārējā migrācijas shēma izskatās gandrīz identiska.

  • esošo resursu domēnu pārnešana uz jaunu domēnu organizatoriskajām vienībām, kas vienkāršos tīkla resursu pārvaldību;
  • “imitēt” migrācijas gaitu, kamēr nenotiek reāla datu pārsūtīšana;
  • atsaukt ar migrāciju saistītās darbības;
  • pārvietot pakalpojumu kontus;
  • atjaunot uzticamas attiecības starp avota un mērķa domēnu;
  • Konvertējiet vairākus domēnus vienā vai vairākos lielos domēnos jau izveidotā Active Directory vidē;
  • pārstrukturēt esošās grupas vai apvienot vairākas grupas vienā mērķa domēnā;
  • analizēt datu pārsūtīšanas procesu, reģistrējot migrācijas notikumus.

Lietotāju un darbstaciju migrācija vienā Active Directory struktūrā tiek veikta, saglabājot esošās piekļuves tiesības.

Jaunināšanas iespējas

Domēna infrastruktūras jaunināšanai ir divas galvenās iespējas [4]:

  • Domēna atjauninājums. Šī metode ir visizplatītākā un visvieglāk īstenojama, migrējot domēnus. Šī metode ļauj saglabāt pašreizējo domēna struktūru, sistēmas iestatījumus, lietotāju un grupas struktūru. Domēna atjaunināšana (in-place update) ietver esošo domēna kontrolleru pārsūtīšanu uz jaunizveidoto domēnu.
  • Domēna pārstrukturēšana. Šī metode ļauj mainīt esošo domēnu struktūru, apvienot domēnus vai pārveidot domēnus par organizācijas vienībām.

Papildus iepriekšminētajām iespējām ir arī jaukta iespēja, kas balstīta uz tiem - domēnu atjaunināšana ar to turpmāko pārstrukturēšanu [13].

Šīs iespējas sauc Pārejas ceļi Active Directory ieviešanai. No tiem izvēlētais pārejas ceļš būs galvenā saite kopējā domēna infrastruktūras atjaunināšanas stratēģijā. Šī stratēģija ietvers aprakstu par to, kuri direktoriju pakalpojumu objekti ir jāpārvieto un kādā secībā. Labākā prakse jebkurai lietojumprogrammu pārvietošanai Active Directory ieviešanas laikā ir dokumentēt katru detaļu darba dokumentā, ko sauc par pārejas plānu.

Pārejas ceļa izvēles kritēriji

Izvēloties pārejas ceļu, tiek pieņemts, ka lēmums attiecas tikai uz vienu domēnu, kas nozīmē, ka ir pilnīgi godīgi vienā organizācijā izmantot dažādus pārejas ceļus dažādiem domēniem.

Apskatīsim galvenos kritērijus, kas tiek izmantoti, izvēloties piemērotāko pārejas ceļu [13], kas doti 12.1., 12.2., 12.3., 12.4., 12.5., 12.6. tabulās.

  • Kritērijs 1. Apmierinātība ar esošo domēna modeli. 12.1. tabula. Pārejas ceļa izvēle, pamatojoties uz 1. kritēriju
    Pārejas ceļš Atbilstības kritēriji
    Domēna atjauninājums Ja domēna modelī nav būtisku izmaiņu, ko vēlaties veikt, tad domēna atjaunināšana nodrošinās vienkāršāko ceļu. Domēna nosaukums paliks nemainīgs, tāpat kā visu lietotāju un grupu kontu esamība
    Domēna pārstrukturēšana Ja pašreizējais domēna modelis vairs neatbilst organizācijas vajadzībām vai vairs nav vislabāk piemērots organizācijas departamentiem, domēna pārstrukturēšana var būt labākā izvēle.
  • Kritērijs 2. Riska pakāpe, pārejot uz jaunu domēna modeli. 12.2. tabula. Pārejas ceļa izvēle, pamatojoties uz 2. kritēriju
    Pārejas ceļš Atbilstības kritēriji
    Domēna atjauninājums Domēna jaunināšana ir zema riska metode. Domēna kontrollera jaunināšanas process ir automātisks, tāpēc bez lietotāja iejaukšanās ir maz iespēju kļūdīties. Arī atkopšanas metodika pēc domēna jaunināšanas kļūmes ir salīdzinoši vienkārša: ja jaunināšana neizdodas, ir jāizslēdz primārais domēna kontrolleris (PDC), jāpiešķir PDC lomai jebkurš rezerves domēna kontrolleris (BDC), kurā ir svaigi dati, un sāciet procedūru no jauna
    Domēna pārstrukturēšana Domēna pārstrukturēšana ir augstāka riska ceļš nekā domēna atjaunošana. Ir jāveic vairāk uzdevumu, un tāpēc daudzi procesi var noiet greizi. Rezultātā pieaug neapmierinātība starp lietotājiem, kuri nevar pieteikties, piekļūt nepieciešamajiem resursiem vai piekļūt savām pastkastēm.
  • Kritērijs 3. Pārejas 1 izpildes laiks Pārejas laiks nav noteicošais faktors pārejas ceļa izvēlē, taču tas var būt noteicošais faktors mazām organizācijām ar ierobežotiem resursiem. .12.3.tabula. Pārejas ceļa izvēle, pamatojoties uz 3. kritēriju
    Pārejas ceļš Atbilstības kritēriji
    Domēna atjauninājums Domēna atjaunošana ir lineārs process: kad tā ir sākta, tā ir jāpabeidz. Tas prasa mazāk darbību nekā pārstrukturēšana, un tāpēc visas pārejas pabeigšana prasa mazāk laika
    Domēna pārstrukturēšana Domēna pārstrukturēšana vienmēr aizņem ilgāku laiku. Piemēram, pārstrukturēšanas laikā daudz laika tiek pavadīts, veidojot un apstiprinot mērķa domēna infrastruktūru, pārvietojot visus kontus no avota domēna uz mērķa domēnu. Lielas organizācijas var nespēt pārvietot visus objektus vienlaikus, tāpēc diezgan bieži domēna pārstrukturēšana tiek veikta vairākos posmos
  • 4. kritērijs: direktoriju apkalpošanas laiks, kas nepieciešams, lai pabeigtu migrācijas procesu. 12.4. tabula. Pārejas ceļa izvēle, pamatojoties uz 4. kritēriju
    Pārejas ceļš Atbilstības kritēriji
    Domēna atjauninājums Konta objekti migrācijas procesa laikā nav pieejami, jo tie tiek paši atjaunināti, kad tiek jaunināts domēns
    Domēna pārstrukturēšana Laba izvēle organizācijām, kurās sistēmas darba laiks ir kritiska vērtība. Tā kā tas ietver neapdzīvota, "tīra" meža izveidi un atstāj sākotnējo vidi būtībā nemainīgu, direktoriju pakalpojuma funkcionalitāte tiek saglabāta, jo lietotāji turpina darboties savā esošajā vidē. Varat migrēt lielas vai mazas lietotāju grupas ārpus sastrēgumu stundās un atstāt šos jaunos kontus neaktivizētus, līdz esat gatavs pamest veco sistēmu.
  • 5. kritērijs. Resursu pieejamība pārejas pabeigšanai. 12.5. tabula. Pārejas ceļa izvēle, pamatojoties uz 5. kritēriju
    Pārejas ceļš Atbilstības kritēriji
    Domēna atjauninājums Tā kā domēna atjaunināšana ir automatizēta darbība, šim pārejas ceļam būs nepieciešams mazāk cilvēkresursu
    Domēna pārstrukturēšana Domēna pārstrukturēšana ietver vairāk uzdevumu nekā domēna atjaunošana, un tāpēc tai ir nepieciešams vairāk resursu, kas nozīmē, ka tai ir jābūt pietiekami daudz darbiniekiem, lai tiktu galā ar papildu darba slodzi, kas saistīta ar domēna pārstrukturēšanu. Alternatīva ir daļu vai visu projektu izmantot ārpakalpojumu sniedzējiem: ir daudzas konsultāciju grupas, kas specializējas šādos projektos, ietaupot laiku un naudu, kas nepieciešama, lai apmācītu iekšējos darbiniekus.
  • Kritērijs 6. Pārejas projekta budžets. 12.6. tabula. Pārejas ceļa izvēle, pamatojoties uz 5. kritēriju
    Pārejas ceļš Atbilstības kritēriji
    Domēna atjauninājums Faktori, kas veicina nepieciešamo budžeta līdzekļu samazināšanos:
    • spēja izmantot esošo servera aparatūru;
    • zemākas cilvēkresursu izmaksas;
    • samazinātas testēšanas izmaksas, jo būs jātestē mazāk jaunināšanas uzdevumu
    Domēna pārstrukturēšana Daudzu iemeslu dēļ domēna pārstrukturēšanai būs nepieciešams lielāks budžets nekā domēna atjaunošanai. Aparatūras prasības, kas nepieciešamas, lai izveidotu tukša meža vidi, uz kuru jāmigrē direktoriju pakalpojumu objekti, ir jāapsver no budžeta viedokļa.

Ja uzņēmums ne visai atbilst nosacījumiem, lai par atjaunošanas ceļu droši izvēlētos domēna atjaunošanu vai restrukturizāciju, vai tam ir piemēroti abi ceļi, tad tas var izvēlēties trešo ceļu – domēna atjaunošanu, kam seko restrukturizācija.

Šis ceļš uz Active Directory sniegs tūlītējus ieguvumus (administrācijas deleģēšana, grupas politikas, aplikāciju publicēšana un ne tikai), kā arī ilgtermiņa ieguvumi no domēna restrukturizācijas (mazāk domēnu ar palielinātu domēna apjomu, domēna dizains atbilstoši uzņēmuma biznesa un organizācijas mērķiem).