Datamigrering krever nøye forberedelser. Versjonsmigrering av databasestrukturen: grunnleggende tilnærminger Lagre versjonshistorikk

Moderne selskaper står ofte overfor behovet for å migrere informasjonssystemene sine. Denne prosedyren må imidlertid innledes med nøye forberedelser, siden det er mange hindringer på veien.

Det kan være svært mange grunner til å starte overgangen til et nytt informasjonssystem (IS), inkludert å redusere risikoen knyttet til driften av utdaterte plattformer, bringe informasjonssystemer til internasjonale standarder og øke effektiviteten av forretningsprosesser. Men uansett hvilken oppgave selskapet står overfor, må overgangen fra en IP til en annen planlegges og forberedes nøye.

Migrasjonsproblemer

Når det gjelder migrering av transaksjonssystemer som ERP, fakturering, prosessering eller kjernebank, er overgangen til et nytt system svært problematisk. Faktum er at IT-fagfolk må sikre nøyaktig migrering av store datamengder, opprettholde parallell drift av gamle og nye systemer for avstemming og analyse av resultatene.

For eksempel hadde jeg prosjekterfaring i en av de største bankene, hvor et transaksjonssystem ble overført fra den ikke lenger støttede Informix-plattformen til Oracle-plattformen. Samtidig var det nødvendig å foreta en grundig analyse av forretningsprosesser, gjentatte ganger overføre data fra det gamle systemet til det nye, og sjekke konsistensen av resultatene til de nye og gamle systemene, tatt i betraktning varigheten av systemet. prosessforskrifter. Derfor var flyttetiden på 14 måneder. Noen ganger kan parallell drift av to systemer fortsette i lengre tid, men selv når den er begrenset til flere måneder, krever å sikre driften av den nye IS tildeling av ekstra datakraft og betydelig tid for bedriftsansatte til å utføre oppgaver i to systemer samtidig. .

Fra avdelingssystem til bedriftsnivå

IP-oppdatering skjer ofte innenfor rammen av globalisering og sentralisering. Dette lar deg redusere kostnadene for å støtte og oppdatere programvaresystemer betydelig. Det er faktisk mye enklere å opprettholde en enkelt plattform som betjener alle ansatte enn å opprettholde separate verktøy for hver avdeling. For eksempel lar vellykket migrering av et lagerregnskapssystem deg overføre flere tusen avdelinger i en stor organisasjon til en enkelt plattform og gi en alvorlig reduksjon i IT-kostnader. Det bør imidlertid huskes at det meste av forberedelsene i dette tilfellet faller på koordinering av data i ulike formater og representasjoner, utvikling av nye forskrifter og konstruksjon av nye modeller for medarbeidersamhandling.

Et annet viktig aspekt er integrasjonsgrensesnitt med andre bedriftsinformasjonssystemer, spesielt selvskrevne og spesifikke. Problemer knyttet til dem er kanskje ikke så merkbare i det første trinnet, men identifiseres ved etablering av samhandling mellom ulike avdelinger og det overordnede systemet. Og hvis for det gamle systemet slike grensesnitt allerede var implementert programmatisk eller organisatorisk, så for det nye systemet må de kanskje utvikles på nytt.

Det skal huskes at tanker om å utvide funksjonaliteten til systemet kan komme allerede under gjennomføringen av prosjektet, akkurat som appetitten kommer under et måltid. Dette betyr at det vil kreves en hel rekke tilleggsarbeid.

Handlingsplan

Erfaringene fra prosjektaktiviteter på systemmigrering viser at ethvert slikt prosjekt krever nøye forberedelse og må ledsages av en individuell plan. Uansett hvilken type systemer som migreres, programvare, databasevolumer osv., ser imidlertid den generelle ordningen nesten identisk ut.

I den første fasen er det nødvendig å gjennomføre en detaljert revisjon, finne ut alle kravene til driftsmåten til det nye systemet, intervjue alle nøkkelbrukere. Det er viktig å forstå hvilke mengder data og hva slags belastning vi snakker om, først da vil spesialister kunne foreslå riktig migrasjonsstrategi.

Selve prosedyrene må også være nøye gjennomtenkt og inkludere så viktige elementer som reglene for brukertilgang til systemer under migrering, prosedyrer for å rulle tilbake til en tidligere tilstand ved feil, og samhandlingen mellom de ulike spesialistene som er involvert i disse prosessene. .

Etter avtale med kunden utarbeides vanligvis en detaljert plan som omfatter flere stadier, nemlig: datakopiering, verifisering, parallelldrift av to systemer og fullstendig overgang til ny plattform. Etter min mening er hovedsaken i en profesjonelt organisert systemmigrering jevnheten i prosessen for brukere som gradvis, uten stress, kan begynne å jobbe i et nytt automatisert system.

Men selv omhyggelig forberedelse sparer deg ikke alltid fra å undervurdere arbeidskostnadene når du overfører brukere til "nye skinner." Denne prosessen inkluderer både opplæring av bedriftens ansatte og deres støtte i perioden med tilpasning til det nye systemet.

Leif Poulsen for InTech

Systemer for automatisering av produksjon og innhenting av informasjon om produksjonsprosesser er relativt kortvarige. De må ofte oppgraderes eller skiftes ut før prosessutstyret når slutten av levetiden. For mange bedrifter er det en reell utfordring å administrere utskifting eller oppgradering av slike automasjonssystemer uten å stoppe produksjonen. Derfor ignoreres det objektive behovet for modernisering eller utskifting inntil noe skjer. Denne artikkelen handler om hvordan du kan lykkes med denne oppgaven gjennom nøye planlegging og organisering.

To hovedfaktorer ligger bak behovet for å modernisere og erstatte industrielle automasjonssystemer og industrielle IT-systemer: den tekniske degraderingen av disse systemene, samt endringer i kravene til forretningsprosessene som disse systemene støtter.

Påliteligheten til tekniske systemer vil reduseres over tid hvis bedrifter ignorerer behovet for å modernisere operativsystemer, databaser og applikasjonsprogramvare. Den operasjonelle risikoen for utstyrssvikt øker tilsvarende.

Gjennom nøye planlegging kan operasjonell risiko holdes på et akseptabelt nivå, samtidig som man beskytter investeringer og minimerer livssykluskostnader. For et typisk automasjons- eller IT-system går kun 20-40 % av investeringen til innkjøp av systemet. De resterende 60-80 % går til å opprettholde den høye tilgjengeligheten og tilpasse seg periodisk endrede krav.

I tillegg til å vurdere aktivitetene som kreves for å forhindre teknisk degradering, er det nødvendig å vurdere nye utfordringer samt potensielle forretningsmuligheter. Forretningsmiljøet er i stadig endring, og alle muligheter for å forbedre eksisterende eller introdusere nye teknologier må alltid vurderes. Typiske forretningsmuligheter som kan drive migreringen av høer hastighet til markedet, konkurranseevne, vekst, kvalitet og overholdelse av regelverk.

Langsiktig migrasjonsplan

Å utvikle en langsiktig systemmigreringsplan gjør at bedrifter kan opprettholde systemiske operasjonelle risikoer på et akseptabelt nivå. I tillegg sikrer det risikostyring og rettidig støtte til forretningsmål. Migrasjonsplanen må ta hensyn til restriksjoner som "beste produksjonspraksis", teknologifunksjonalitet og uunngåelig produksjonsstans.

Generelt er tilnærmingen til langsiktig planlegging avbildet i fig. 1. En migreringsplan er utviklet for å bestemme hvor selskapet ønsker å være om fem år, hvilke tiltak som må tas for å komme dit, og om ressursene som kreves for å komme dit er tilgjengelige. Denne tilnærmingen er basert på de arkitektoniske designprinsippene skissert i TOGAF-standarden, som er mye brukt i utviklingen av systemarkitektur for industribedrifter.

Figur 1. Generell tilnærming til å lage en langsiktig migrasjonsplan.

Det er nødvendig å skille mellom den eksisterende arkitekturen og målet, ønsket. Forskjellen mellom dem gjenspeiler forskjellen mellom selskapets nåværende posisjon og posisjonen den ønsker å innta i fremtiden. Migrasjonsplanen kartlegger veien fra eksisterende arkitektur til målarkitektur – eventuelt gjennom flere overgangsfaser.

Hver arkitektur kan beskrives som en serie med "lag" som bygger bro mellom virksomhet og teknologi - som vist i figur 1. 1. Vær oppmerksom på følgende "lag":

  • Forretningsmål det er en del av den overordnede strategiplanleggingen. De lar deg velge riktig retning av prosessen.
  • Forretningsmodell gir kontekst der produksjon og forretningsprosesser blir forstått. Vanligvis inkluderer den en beskrivelse på høyt nivå av materialstrømmer og prosesser.
  • Beskrivelse produksjon og forretningsprosesser er viktig for vellykket anvendelse av teknologier og riktig vurdering av deres verdi fra et forretningsmessig synspunkt.
  • Informasjon, data og dokumenter viktig for å koble sammen prosesser og applikasjoner. Interoperabilitet og styring av informasjonsflyt mellom applikasjoner er spesielt viktig.
  • Beskrivelser applikasjoner lar deg formulere krav på høyt nivå og definere grensesnitt.
  • Definisjon infrastruktur, databehandling og nettverk krav (maskinvare, feiltoleranse, ytelse).
  • sørget for tjenester definere krav for å sikre effektiv operativ ledelse og beslutningsstøtte.

Utvikle en migrasjonsplan

Å utvikle en migreringsplan for en hel organisasjon, eller til og med et enkelt produksjonssted, kan være en virkelig kompleks oppgave som involverer mange mennesker. Det anbefales å dele utviklingsprosessen inn i flere stadier, beskrevet nedenfor.

Del II

Trinn 1: Mobilisering

Grunnleggende mål:

  • oppnå en felles forståelse av oppgaver og mål
  • mobilisere organisasjonen der prosjektet er planlagt
  • detaljer planen ved å beskrive milepælene og resultatene av prosjektfasene
  • samle inn all nødvendig/tilgjengelig informasjon
  • gi en god forståelse av konsepter, praksis og teori
  • planlagte møter
  • workshop dedikert til starten av prosjektet

Resultater:

  • detaljert høringsplan
  • felles mål
  • prosessoversikt

Trinn 2: Analyse

Målene for analysefasen er:

  • analyse av forretnings- og produksjonsprosesser for å:

Vurdere beredskapen til personell som betjener IT- og automasjonssystemer

Forstå data- og funksjonalitetsbehovet for fremtidens arkitektur

Identifiser viktige fordeler med fremtidens arkitektur for å sette mål og implementere forretningscasen

  • analyse av eksisterende arkitektur

Bestemmelse av eksisterende produksjonsprosesser i forbindelse med automasjonssystemer, datainnsamling, produksjonsstyringssystemer

Identifisering av eksisterende forretningsprosesser og deres sammenhenger meder

Identifiser eksisterende applikasjoner, data, logisk og fysisk infrastruktur og tekniske støttetjenester

I løpet av denne fasen utføres følgende aktiviteter:

  • seminarer og diskusjoner om ulike prosesser
  • nettstedsbesøk for å få kontekstuell informasjon
  • seminarer og diskusjoner om eksisterende systemer
  • vurdering av tjenester for å bestemme deres modenhetsnivå og samsvar med regulatoriske krav

Resultater:

  • identifikasjon av eksisterende infrastruktur
  • analysedokumentasjon
  • liste over ideer om utfordringene og mulighetene til den nye arkitekturen liste over ideer om utfordringene og mulighetene til den nye arkitekturen

Etappe 3: Mål

Hensikten med denne fasen er å identifisere og beskrive behovene som er formulert under analysefasen.

Løsningen, eller målarkitekturen, vil beskrive:

  • fremtidige forretningsprosesser og funksjonalitet
  • målapplikasjonstyper, med deres funksjonalitet, brukere, informasjon og grensesnitt
  • infrastrukturbehov og reviderte støttestandarder

I løpet av denne fasen utføres følgende aktiviteter:

  • seminarer og diskusjoner om prosessforbedring
  • workshops og diskusjoner om forbedring av arkitektur

Resultater:

  • fremtidig arkitektur (presentasjon)
  • Kort beskrivelse av applikasjonstyper

Trinn 4: Begrunnelse

Hensikten med begrunnelsesfasen er å gi en innledende forretningscase basert på grove estimater av kostnadene og fordelene ved prosjektet.

Gapet mellom den eksisterende og den ønskede situasjonen fører vanligvis til fremveksten av en rekke ideer. Begrunnelse av ideer vil tillate deg å skille "nødvendig" fra "ønskelig", og etter det presentere og utvikle ideer til toppledelsen.

I løpet av denne fasen utføres følgende aktiviteter:

  • grovt anslag på kostnader og fordeler
  • første versjon av presentasjonen

Resultater:

  • felles mål
  • prioritering av forretningsideer
  • vurdering av nødvendige ressurser

Trinn 5: Planlegg

Hensikten med denne fasen er å planlegge prosjektet basert på prioriteringer, ressurser og avhengigheter:

  • planlegge sekvensen for implementering av stadiene i et konsolidert prosjekt
  • gi ressursene og kompetansen som trengs for de neste trinnene
  • igangsetting av prosjektledelsesaktiviteter
  • gjennomføring av rådgivning og overføring av resultater av alle ledd til kunden

I løpet av denne fasen utføres følgende aktiviteter:

  • utvikling av en gjennomføringsplan
  • utvikling av en investeringsplan
  • risikovurdering

Resultater:

  • implementeringsplan
  • vurdering av arbeidsmengden til personell involvert i prosjektet
  • prosjektrisikovurdering
  • investeringsplan (som en første tilnærming)
  • endelig versjon av prosjektpresentasjonen

Kasusstudie

Følgende eksempel illustrerer anvendelsen av den beskrevne tilnærmingen under reelle forhold. For å overholde konfidensialitetsvilkår opprettholdes anonymiteten i beskrivelsen. Vi snakker om en ganske stor bedrift som produserer aktive ingredienser til farmasøytiske produkter. Produksjonsanleggene ble tatt i bruk for mer enn 20 år siden, og selv om det har blitt utført en del modernisering siden den gang, krever en rekke utdaterte systemer utskifting. Bygningsautomasjonssystemer og DCS er i første rekke, da de er basert på utdaterte teknologier som er vanskelige å vedlikeholde. I tillegg må produksjonen tilpasse seg nye forretningskrav, inkludert avvikling av noen produkter og lansering av andre. Generelt er det behov for å jobbe med en migrasjonsplan som dekker både tekniske og forretningsmessige krav.

Først må du lage en hovedliste over utstyr som for øyeblikket brukes i hele bedriften. Denne informasjonen er ofte "gjemt" i ulike dokumenter (og ansattes minner). Det må trekkes ut og visualiseres slik at det blir grunnlag for migrasjonsplanlegging. For dette formålet lager vi vanligvis et prosessmoduldiagram som viser de viktigste utstyrs- og råvarebevegelsene i hver produksjonsenhet. Som separate lag "på toppen" av maskinvaren viser vi hvilke systemer som støtter hvilken maskinvare.

Et eksempel er vist i fig. 2. Data om installerte systemer finnes også i systemlageret (eller ganske enkelt i Excel-filer), og kan brukes til videre analyse og planlegging.

Figur 2. Automatiserings "lag" lar deg evaluere eksisterende systemer

Før man diskuterer en migrasjonsplan, er det nødvendig å identifisere de viktigste forretningsårsakene til endringer i produksjonen. I dette tilfellet identifiserte ledelsen følgende motiver:

1. Konsekvent og feilfri overholdelse av forskriftskrav

2. Minimum tid som kreves for å komme inn på markedet, fleksibilitet

3. Suksess, konkurranseevne, operasjonell fortreffelighet

4. Kompromissløs kvalitet

5. Vekst i produksjonsvolumer

Disse målene må oversettes til mer spesifikke oppgaver, hvor implementeringen kan kvantifiseres.

Deretter må vi finne ut hvor godt eksisterende systemer støtter nåværende og fremtidige forretningsprosesser. For å gjøre dette bruker vi en standard referansemodell (basert på ANSI/ISA-95-serien med standarder). Den inkluderer 19 forretningsprosesser på høyt nivå, detaljert i den grad den lar deg se svakheter i deres praktiske implementering og behovet for endring av hensyn til effektiv virksomhet.

I tillegg må vi også evaluere de tekniske egenskapene til eksisterende systemer for å støtte forretningsprosesser i fremtiden. Dette gjøres systematisk ved å bruke informasjonen beskrevet ovenfor fra systemlageret. For hvert system som det er informasjon om i depotet (i vårt tilfelle, ca. 70 systemer), må følgende aspekter vurderes:

  • Utstyrets tilstand (feilhistorikk, gjennomsnittlig tid mellom feil, utstyrets alder, reservedeler tilgjengelig)
  • Status for programvaren (leverandørstøtte, tilgjengelighet av dokumentasjon, personell med nødvendig kompetanse)
  • Systemgjenopprettingsevner (redundans, gjennomsnittlig levetid før reparasjon)
  • Virksomhetsvurdering (informasjonslevering, datafeil, utilgjengelighet)
  • Indikative indikatorer (systempålitelighet, systemets kritiske betydning, etc.)

Den tekniske vurderingen identifiserte behovet for å modernisere og erstatte en rekke systemer:

  • Prosesskontrollsystemer er basert på en konvensjonell, utdatert DCS og mange forskjellige PLS-er, hvorav noen allerede er "modne" for utskifting.
  • Byggautomatiseringssystemet er basert på en nyere plattform, men krever også oppgradering for å møte nye krav.
  • En rekke sekundære systemer krever også modernisering, eller til og med utskifting.
  • Infrastrukturen som betjener alle systemer krever bedre segmentering og beskyttelse for å møte dagens sikkerhetskrav.

Del III

Etter å ha analysert forretningsmålene for fremtiden, ble det åpenbart at ingen av de eksisterende systemene fullt ut tilfredsstiller fremtidige behov. Denne forståelsen ga opphav til en rekke ideer angående introduksjon av nye teknologier, samt produksjonsutførelsessystemet. Som et resultat av analysen ble 16 ulike prosjekter foreslått som, hvis de implementeres konsekvent, vil hjelpe selskapet med å møte fremtidige tekniske og kommersielle krav.

Innholdet i teknisk arbeid og kostnadene for hvert prosjekt vurderes; For hvert prosjekt utarbeides en kort en-sides oppsummering som ledelsen kan diskutere. (Se figur 3).

Ris. 3. En-sides beskrivelse av et potensielt migrasjonsprosjekt

For å velge prioriterte prosjekter vurderes de potensielle resultatene for hvert av dem. Resultatene vurderes med tanke på forretningsmål, samt påliteligheten til prosesskontrollsystemet.

Vanligvis må du evaluere flere implementeringsscenarier for å estimere de samlede ressurs- og finansieringskravene for hver plan (Figur 7). En av hovedbegrensningene å vurdere er vinduene i produksjonsprosessen der systemer kan erstattes eller modifiseres. Som regel oppstår disse "vinduene" i helgene - og dette er en alvorlig flaskehals.

Ris. 7. Konsolidert oversikt over migreringsplanen

Siden det alltid er lite tid til å skifte systemer og sette dem opp, må forberedelsene være svært grundige. Alt må planlegges i detalj. Et viktig aspekt ved planleggingen er å teste de implementerte systemene.

I det tilfellet vi beskriver ble gjennomføringen av den langsiktige migrasjonsplanen gjennomført i seks ulike bekker, se fig. 8.

Ris. 8. Organisering av migrasjonsprosjekter i seks ulike strømmer

En del av forarbeidet er en grundig vurdering og forebygging av prosjektrisiko. I fig. Figur 9 viser typiske risikoer knyttet til migrasjonsprosjekter.

Ris. 9. Vurdere typiske risikoer ved migrasjonsprosjekter

Forretningsstøtteprosesser

Tilnærmingen til livssyklusstyring og langsiktig migrasjonsplanlegging beskrevet i denne artikkelen er drevet av forretningsbehov. Den inkluderer en vurdering av nåværende og fremtidige forretningsmål, samt en grundig analyse av hvordan tekniske systemer vil bli vedlikeholdt eller erstattet for best mulig å støtte disse målene. Tilnærmingen er basert på TOGAF-prinsipper, som sørger for sekvensiell prosjektgjennomføring avhengig av tilgjengeligheten av budsjetter og kvalifisert personell. Vurdering av nåværende og fremtidige systemarkitekturer er et nøkkelelement i å bestemme fremtidige migrasjonsprosjekter. Til slutt er det nødvendig å følge prinsipper for organisatorisk endringsledelse som sikrer rettidig involvering av sentrale prosjektinteressenter, noe som er så viktig for suksessen til migrasjonsprosjekter. Effektiviteten til denne tilnærmingen har blitt demonstrert gjentatte ganger i praksis.

Leif Poulsen) ( ), ledende automasjons- og IT-spesialist i NNE Pharmaplan. Han har en mastergrad i prosessledelse. Hos NNE Pharmaplan er Poulsen ansvarlig for utvikling av teknologier, metoder og kompetanse innen industriell automasjon og IT, og jobber som senior bedriftsrådgiver.

Sist oppdatert: 31.10.2015

Ofte oppstår det en situasjon når modellen endres. For eksempel bestemte vi oss for å introdusere nye eiendommer i den. Men samtidig har vi allerede en eksisterende database som inneholder en del data. Og for å oppdatere databasen uten tap, tilbyr ASP.NET MVC oss en slik mekanisme som migreringer. For eksempel har vi en enkel brukermodell:

Offentlig klasse Bruker ( offentlig int Id ( get; sett; ) offentlig streng Navn ( get; sett; ) )

Følgelig er det en datakontekst som vi arbeider med databasen gjennom:

Brukere(get;sett;))

Og la oss si at vi har all infrastrukturen for å jobbe med denne modellen - visninger, kontrollere, og vi har allerede flere objekter av denne modellen i databasen. Men på et tidspunkt bestemte vi oss for å endre applikasjonsmodellbasen. For eksempel la vi til et annet felt i brukermodellen:

Offentlig klasse Bruker ( offentlig int Id ( get; sett; ) offentlig streng Navn ( get; sett; ) offentlig int Alder ( get; sett; ) )

I tillegg bestemte vi oss for å legge til en modell til, for eksempel:

Offentlig klasse Firma ( offentlig int Id ( get; sett; ) offentlig streng Navn ( get; sett; ) )

Dermed endres datakonteksten vår allerede som følger:

Offentlig klasse UserContext: DbContext ( public UserContext() : base("DefaultConnection") ( ) public DbSet Brukere ( get; set; ) public DbSet Selskaper ( få; sett; ) )

Vi kan legge til et ekstra felt for Age-egenskapen til visningene for brukermodellen, vi kan lage en kontroller og visninger for den nye modellen, men når vi prøver å legge til et nytt objekt i databasen, får vi en feilmelding:

Datakonteksten har endret seg, og nå må vi migrere fra det gamle databaseskjemaet til det nye. Og først av alt, finn Package Manager Console-vinduet nederst i Visual Studio, skriv inn kommandoen i det: enable-migrations og trykk Enter:

Etter å ha kjørt denne Visual Studio-kommandoen, vil en Migrations-mappe bli opprettet i prosjektet, hvor du kan finne filen Configuration.cs. Denne filen inneholder en erklæring om konfigurasjonsklassen med samme navn, som angir konfigurasjonsinnstillingene:

Namespace MigrationApp.Migrations (bruker System; bruker System.Data.Entity; bruker System.Data.Entity.Migrations; bruker System.Linq; intern forseglet klasse Konfigurasjon: DbMigrationsConfiguration ( public Configuration() ( AutomaticMigrationsEnabled = false; ContextKey = "MigrationApp.Models.UserContext"; ) protected override void Seed(MigrationApp.Models.UserContext context) ( ) ) )

I Seed-metoden kan du initialisere databasen med frødata. Nå må vi lage selve migreringen. Der, i Package Manager Console, skriv inn kommandoen:

PM Add-Migration "MigrateDB"

Visual Studio vil da automatisk generere en migreringsklasse:

Navneområde MigrationApp.Migrations (bruker System; bruker System.Data.Entity.Migrations; offentlig delklasse MigrateDB: DbMigration ( public override void Up() ( CreateTable("dbo.Companies", c => new ( Id = c.Int( nullable: false, identitet: true), Name = c.String(), )).PrimaryKey(t => t.Id); : false)); ) public override void Down() ( DropColumn("dbo.Users", "Age"); DropTable("dbo.Companies"); ) ) )

I Opp-metoden, ved å kalle CreateTable-metoden, opprettes tabellen "dbo.Companies" og dens konfigurasjon utføres: opprette kolonner, innstillingsnøkler. Og en ny alderskolonne legges også til den eksisterende tabellen. Ned-metoden fjerner kolonnen og tabellen i tilfelle de eksisterer. Faktisk tilsvarer disse metodene ALTER-uttrykket i SQL, som endrer strukturen til databasen og dens tabeller.

Og til slutt, for å utføre migreringen, vil vi bruke denne klassen ved å skrive kommandoen i samme konsoll:

PM Update-Database

Etter dette, hvis vi ser på sammensetningen av databasen, vil vi se at endringer har blitt brukt på den i samsvar med migreringen som er utført:

Så migreringen er ferdig, og vi kan allerede bruke de oppdaterte modellene og datakonteksten.

I denne artikkelen ønsker vi å systematisere vår erfaring med å gjennomføre datamigrering i store bedriftsprosjekter knyttet til overgangen fra kunder til å jobbe i 1C:Enterprise 8-konfigurasjoner.

Samtidig vil hovedvekten i artikkelen først og fremst legges på den teknologiske komponenten i migrasjonsprosessen. Den organisatoriske komponenten påvirkes også, men i mindre grad.

Begreper og definisjoner

Datamigrering forstås vanligvis som en siste sekvens av arbeid, et prosjekt rettet mot en engangs masseflytting av data fra kildesystemer (historiske systemer) til destinasjonssystemet. Samtidig opphører utnyttelsen av disse dataene i kildesystemene.

Datamigrering må skilles fra dataintegrasjon. Integrasjon er, i motsetning til migrering, en permanent del av IT-arkitekturen og er ansvarlig for flyten av data mellom ulike systemer og datalagre – og er en prosess fremfor en prosjektaktivitet.

Migrasjonsordningen ser generelt slik ut:

Ris. 1

Historiske systemer- databaser for kundens selskap, som er planlagt å bli helt eller delvis erstattet ved implementering av et nytt system.

Mottaker system- målsystem, vilkårlig konfigurasjon "1C:Enterprise 8".

Innledende data- data lastet ned fra historiske systemer til et tilpasset xls-filformat. I dette tilfellet ser xls-formatet ut til å være et av de mest praktiske, siden muligheten til å laste opp til en xls-fil er til stede i mange regnskapssystemer fra "tidligere generasjoner".

Som et moderne alternativ er det mulig å betrakte xml-filformatet som en transport.

Det finnes også muligheter for å bruke en mellomliggende database.

Transformasjon, konvertering- prosessen med å konvertere kildedata til data for lasting. Datatransformasjon skjer i samsvar med lastemaler. Resultatet av transformasjonen er dataene som skal lastes.

Last ned data- data beregnet på å lastes inn i mottakssystemet. Denne artikkelen, så vel som kildedataene, tar hensyn til xls-formatet.

Datamaler for lasting- beskrivelse av datatabeller som skal lastes inn i målsystemet.

Migrasjonsstadier

La oss vurdere prosessen med å forberede og gjennomføre migrering trinn for trinn.

De organisatoriske stadiene av migrasjonen inkluderer følgende punkter:

· Definere en migrasjonsstrategi. På dette stadiet er Leverandøren og Kunden enige om teknologien for å utføre migrasjonsarbeid;

· Fastsettelse av sammensetningen av migrasjonsarbeidsgruppen. Arbeidsgruppen bør omfatte spesialister fra både entreprenøren og kunden som er tilstrekkelig kjent med driften av historiske systemer (på kundens side) og målsystemet (på entreprenørens side);

· Foreløpig migrasjonsplan. Migrasjonsplanen vil bli justert flere ganger etter hvert som prosjektet skrider frem;

· Perioder med datoer for nedlasting av data fra historiske systemer, datamengder. Dataavskjæringsperioder for migreringer, datoer for test og endelige migreringer. Denne informasjonen kan tilskrives migrasjonsplanen;

· Sammensetning av data som skal migreres. Referansedata, klassifikatorer, transaksjonsdata, saldoer, omsetning, etc.;

· Problemer med å kontrollere kvaliteten, riktigheten og integriteten til data under migrasjonsprosessen og på slutten;

· Problemer med å rulle tilbake til en tidligere tilstand i tilfelle feil.

La oss se nærmere på de teknologiske stadiene i migrasjonen.

Ris. 2

1. Forberede maler for lasting av data

Datainnlastingsmalen inneholder tekniske beskrivelser av datatabellene som skal lastes, algoritmer og innlastingsregler for gjeldende mal.

Hver mal målretter vanligvis mot én eller flere relaterte tabeller på målmålsystemet.

Malen sier:

· Beskrivelse av alle feltene i xls-datafilen for nedlasting, inkludert:

o Feltnavn

o Indikator på at feltet må fylles ut

o Eksempel på utfylling av feltet

o Merk

· Beskrivelse av reglene for lasting av målsystemtabellen basert på dataene som skal lastes (kø ved flere relaterte tabeller, søkealgoritmer for nøkkelfelt osv.)

· Beskrivelse av utfylling av feltene i målsystemtabellene direkte hvis noe annet enn å overføre data "en til en" fra en datafil for lasting er gitt. Relevant for referansefelt, for eksempel.

Under arbeidet på dette stadiet skal Entreprenøren også klargjøre en datafillaster for lasting. Når du arbeider med xls-filer, er ikke denne oppgaven spesielt vanskelig.

2.Identifisering av datakilder

Dette trinnet kan begynne sammen med forrige trinn "1. Forbereder maler for datainnlasting."

På dette stadiet bestemmer kundens spesialister fra hvilke systemer og hvilke data som kan lastes ned. Du bør også bestemme hvilke data Kan være kan være nødvendig.

Som regel, i store migrasjonsprosjekter, kan identifisering av en fullstendig uttømmende liste over datakilder ta ganske lang tid og skjer etter hvert som arbeidet fortsetter i påfølgende stadier.

Det er ofte situasjoner der, for ytterligere å sikre integriteten til informasjon, noen data må overføres fra trykte kilder (digitalisert) eller til og med legges inn i tabeller i henhold til ordene til kundens nøkkelmedarbeidere.

På dette stadiet bør du imidlertid prøve å identifisere så mye nødvendig data som mulig.

3. Laste opp kildedata

Prosessen med å laste ned data fra historiske systemer kan ta ganske mye tid, spesielt hvis det er mange systemer, de er forskjellige og ulike divisjoner av kunden er ansvarlige for dem. Dette punktet må tas i betraktning under test og sluttmigrering.

Det mest praktiske alternativet ser ut til å være opplasting til xls-filer. Mange eldre IT-systemer støtter dette alternativet.

Det kan også være muligheter for opplasting til csv-format, dbf, xml-formater og andre.

Det er verdt å merke seg at av en eller annen grunn (for eksempel sikkerhetsproblemer) kan ikke kunden alltid gi fullstendige datanedlastinger på dette stadiet! Bare en datastruktur og noen få testposisjoner. Dermed kan det oppstå en situasjon at under test- og sluttbelastninger vil data av lav kvalitet bli oppdaget i kildetabellene, noe som vil føre til uplanlagte feil.

For å minimere dette problemet bør volumet av testnedlastinger fra historiske systemer avtales på forhånd.

4.Datakartlegging

Kartlegging (datakartlegging) - generelt, prosessen med å sammenligne data fra historiske systemer og mottakssystemet. Det vil si kildedataene og dataene som skal lastes.

Kartleggingsstadiet er det mest arbeidskrevende stadiet og kan ta mer enn 50 % av alt arbeid med migrasjonsoppgaven.

På dette stadiet er hele arbeidsgruppen for migrasjonsprosjektet fullt ut involvert.

I prosessen med datakartlegging er det nødvendig å skille delfasene av tabellkartlegging og feltkartlegging.

· Kartlegging av tabeller, eller kartlegging av maler - sammenligning av tabeller med kildedata og datamaler for lasting. Kampen kan være enten 1:1 eller N:N. Som et resultat av dette arbeidet blir et tabellkartleggingsregister kompilert og vedlikeholdt. Denne delfasen er nødvendig for neste deltrinn av feltkartlegging og for å overvåke den generelle tilstanden i kartleggingen.

Gruppe av 1C maler

Navnet på 1C-malen

Filnavn-

kilde

Regler for å generere en kildefil

Ansvarlig

Status

Merk

NSI

Prøve_

Nomenklatur

Nomenk

latura.xls

Still inn valg i system N
. Lagre til txt
. Åpne i xls, kolonner er tekst
. Den første linjen er overskriften
. Antall kolonner - 15
. Sjekk antall linjer i txt og xls
. Arknavnet er alltid "Sheet1"

Ivanov I.I.

på jobb

· Felttilordning - kartlegge tabellfelt innenfor en allerede definert tabelltilordning. Resultatet av dette arbeidet er et feltkartleggingsregister.

№pp

Cl. felt

Obligatorisk

1C mal feltnavn "Template_Nomenclature"

Beskrivelse

Feltnavn "Nomenclature.xls"

Fyllingsalgoritme

Kode

Katalogelementkode

Kode

Navn

Navn

Ja

Denne gruppen

Inneholder en av følgende verdier:
. 1 - for grupper
. 0 - for elementer

Hvis kodelengde = 11 tegn og siste 4 tegn<>"0000", så er dette elementet "0", ellers er gruppen "1".

Fullt navn

Katalogelementnavn

Navn

If ThisGroup = 1, Then "", ElseIf ThisGroup = 0, then Name.

Som en del av dette stadiet bør også mulig arbeid med datanormalisering gjennomføres.

5.Utarbeidelse av transformasjonsregler

I motsetning til de tidligere stadiene, er dette stadiet teknisk og involverer arbeidet til entreprenørens utvikler.

Basert på avtalte feltkartleggingsregistre utvikler entreprenørens spesialister regler for datatransformasjon.

For operativt arbeid under de forberedende stadiene av migrering og videre, under test- og sluttmigreringer, er det viktig at det er et praktisk miljø for å utvikle regler (skript) for datatransformasjon og et miljø for å konvertere kildedata til data for lasting.

Kravene til dette miljøet inkluderer:

· Bekvemmelighet og hastighet på utvikling av transformasjonsregler;

· Datakonverteringshastighet. Inn- og utdatafilene kan være hundretusenvis av linjer lange!

· Evne til å jobbe med flere inndatafiler samtidig;

· Evne til å lagre transformasjonsregler i separate filer.

For våre migreringsprosjekter har vi utviklet en spesialisert utviklerarbeidsstasjon som bruker standard 1C Query Console-behandling som grunnlag.

Query Console-behandlingen har blitt forbedret for å tillate direkte spørringer til xls-filer.

Her er et eksempel på å kombinere to kilde xls-filer Ansatte.xls


Ansatt kode

Etternavn

Navn

Etternavn

Fødselsdato

2423

Ivanov

Ivan

Ivanovich

17.11.1992

1523

Petrov

Basilikum

Aleksandrovich

04.02.1991

4363

Sidorov

Kirill

Nikolaevich

01.05.1995

Denisov

Denis

Denisovich

01.01.1990

Og Drift.xls med sider:

Avskrivninger

Ansatt kode

Dato

Sum

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

Og Kvitteringer:

Ansatt kode

Dato

Sum

01.05.2004

02.05.2004

03.05.2004

04.05.2004

2423Fødselsdato

Kvitteringsbeløp

Avskrevet beløp

Ivanov Ivan Ivanovich

2423

17.11.1992

1341234

1010

Petrov Vasily Alexandrovich

1523

04.02.1991

245245

Denisov Denis Denisovich

01.01.1990

380000

320000

Sidorov Kirill Nikolaevich

4363

01.05.1995

613382

26336

TOTAL:

2579861

347842

Merk at eksemplet er kunstig, spesielt valgt for å demonstrere alle mulige stadier av transformasjon av datakilder.

Den teknologiske sekvensen av transformasjonsoperasjoner her er som følger:

Ved å bruke Access SQL-spørringsspråket (som gir betydelige tilleggsmuligheter sammenlignet med 1C-spørringsspråket), opprettes en innledende spørring som trekker ut data fra xls-filen til 1C-miljøet. Samtidig er ulike kontroller og normalisering av data allerede mulig på dette stadiet.

ADO datatilgangsteknologi gir høy hastighet.

Ris. 3

2. Spørring på 1C-språk - hovedspørringen som implementerer feltkartleggingsalgoritmen. Og også: berikelse av nedlastede data med data fra 1C-databasen, omgruppering, sammenslåing med resultatene av spørringer til andre xls-kildefiler, etc.

3. Etterbehandling av 1C-forespørselsresultatet om nødvendig. Implementert ved hjelp av et skript i 1C-språk.

For eksempel implementerer vi her tillegget av "TOTAL"-linjen i beløpskolonnene.

4.Skriv det endelige datasettet inn i en xls-fil.

Generelt er utdataene endelige filer for lasting i mål 1C-databasen.

Dette verktøyet lar deg også lagre datakonverteringsregler i en egen xml-fil:

I tillegg er det mulig å jobbe V batch-modus, som er spesielt viktig når det er en stor mengde heterogene migrerende data.

I løpet av de foregående stadiene avsluttes vanligvis den forberedende delen av arbeidet - alle datakilder identifiseres, kildedata lastes ned fra kildene, nedlastingsmaler utarbeides i måldatabasen, datakartlegging utarbeides og til slutt utvikles skript for datatransformasjon .

Det skal bemerkes at før den endelige migreringen bør du definitivt utføre flere tester. Under testmigreringer identifiserer entreprenøren, sammen med kundene:

Konverteringsfeil, datainnlastingsfeil

Gjennomfør en foreløpig vurdering av kvaliteten på data som er lastet inn i målsystemet

Basert på resultatene av testmigreringer lager/oppdaterer de en endelig migreringsplan

7. Dataavstemming

Kvaliteten på de nedlastede dataene bør kontrolleres både etter testmigreringer og ved slutten av den endelige migreringen. Under avstemmingen kan følgende indikatorer kontrolleres:

· Sammenfall av totale beløp for saldoer, ifølge dokumenter;

· Kvantitative treff, for eksempel antall OS;

· Riktig fylling av individuelle utvalgte enheter;

Vær oppmerksom på at visse kontroller av migreringsdata og problemer med datanormalisering må løses gjennom alle migreringsprosesser. Du må alltid spørre deg selv hva som må gjøres på det nåværende stadiet for å unngå feil i påfølgende stadier.

For eksempel:

· Se etter duplikater etter nøkkelfelt. Det kan og bør utføres på de originale dataene;

· Tvang av felttyper;

· Referanseintegritet;

· Matematiske inkonsekvenser. For eksempel å se etter tomme numeriske felt som deling er planlagt til under transformasjon;

· Generelt fylles obligatoriske felter ut;

· Erstatning av feil tegn. For eksempel engelske tegn i kyrilliske felt ("o", "a", "e", etc.) Dette gjelder spesielt for nøkkelfelt!

· Sjekke verdiene til strengfelter for samsvar med typene av mottakersystemet (lengdebegrensninger)

Etter at den endelige migreringen er fullført, i henhold til en forhåndsbestemt migrasjonsstrategi og migrasjonsplan, tas det en beslutning om den videre driften av de historiske systemene.

Ofte fullføres operasjonen umiddelbart etter de endelige dataavstemmingene og registrering av suksessen med migreringen - brukere av det nye systemet fører ikke lenger journaler i to systemer parallelt, men bytter fullstendig til det nye systemet. Samtidig opprettholdes tilgangen til det gamle systemet i lesemodus.

I noen tilfeller kan parallelldrift av to systemer forekomme under prøvedriftens varighet (TE) og til og med utover denne perioden. Spørsmålet om parallelt arbeid av brukere i to systemer er nært knyttet til spørsmålet om muligheten for å rulle tilbake til det gamle systemet dersom migreringen (eller generelt driften av det nye systemet!) anses som utilfredsstillende.

Konklusjon

Avslutningsvis vil jeg merke meg at når det kommer til å migrere store transaksjonssystemer, som inkluderer mange 1C:Enterprise-konfigurasjoner, kan overgangen til et nytt system være svært arbeidskrevende.

Derfor bør det huskes at ethvert slikt prosjekt krever nøye forberedelse og må ledsages av en individuell plan. Uansett hvilken type systemer som migreres, databasevolumer osv., ser imidlertid den generelle migreringsordningen nesten identisk ut.

  • overføre eksisterende ressursdomener til organisatoriske enheter av nye domener, noe som vil forenkle administrasjonen av nettverksressurser;
  • «simulere» fremdriften av migreringen, mens ingen reell dataoverføring skjer;
  • angre handlinger i forbindelse med migrasjon;
  • flytte tjenestekontoer;
  • restaurere tillitsfulle forhold mellom kilde- og måldomener;
  • Konverter flere domener til ett eller flere store domener i et allerede opprettet Active Directory-miljø;
  • omstrukturere eksisterende grupper eller slå sammen flere grupper til én i måldomenet;
  • analysere dataoverføringsprosessen ved å logge migreringshendelser.

Migrering av brukere og arbeidsstasjoner til en enkelt Active Directory-struktur utføres samtidig som eksisterende tilgangsrettigheter bevares.

Oppgraderingsalternativer

Det er to hovedalternativer for å oppgradere domeneinfrastrukturen [4]:

  • Domeneoppdatering. Denne metoden er den vanligste og enkleste å implementere ved migrering av domener. Denne metoden lar deg lagre gjeldende domenestruktur, systeminnstillinger, bruker- og gruppestruktur. Domeneoppdatering (in-place update) innebærer å overføre eksisterende domenekontrollere til det nyopprettede domenet.
  • Domenerestrukturering. Denne metoden lar deg endre den eksisterende strukturen til domener, slå sammen domener eller konvertere domener til organisasjonsenheter.

I tillegg til alternativene ovenfor, er det også et blandet alternativ basert på dem - oppdatering av domener med påfølgende restrukturering [13].

Disse alternativene kalles Overgangsbaner for Active Directory-implementering. Overgangsveien valgt fra dem vil være hovedleddet i den overordnede strategien for oppdatering av domeneinfrastrukturen. Denne strategien vil inkludere en beskrivelse av hvilke katalogtjenesteobjekter som må flyttes og i hvilken rekkefølge. Den beste praksisen for enhver applikasjonsflytting under en Active Directory-implementering er å dokumentere hver eneste detalj i et arbeidsdokument kalt en overgangsplan.

Kriterier for valg av overgangsvei

Ved valg av overgangsvei forutsettes det at beslutningen kun gjelder ett domene, det vil si at det er helt rettferdig å bruke ulike overgangsveier for ulike domener innenfor samme organisasjon.

La oss vurdere hovedkriteriene som brukes ved valg av den mest passende overgangsveien [13], gitt i tabellene 12.1, 12.2, 12.3, 12.4, 12.5, 12.6.

  • Kriterium 1. Tilfredshet med den eksisterende modellen for det eksisterende domenet. Tabell 12.1. Velge en overgangsbane basert på kriterium 1
    Overgangsvei Kvalifikasjonskriterier
    Domeneoppdatering Hvis det ikke er noen vesentlige endringer du ønsker å gjøre i domenemodellen, vil oppdatering av domenet være den enkleste veien. Domenenavnet vil forbli det samme, og det samme vil eksistensen av alle bruker- og gruppekontoer
    Domenerestrukturering Hvis den nåværende domenemodellen ikke lenger oppfyller organisasjonens behov eller ikke lenger passer best for organisasjonens avdelinger, kan omstrukturering av domene være det beste valget.
  • Kriterium 2. Graden av risiko ved overgang til ny domenemodell. Tabell 12.2. Velge en overgangsbane basert på kriterium 2
    Overgangsvei Kvalifikasjonskriterier
    Domeneoppdatering Oppgradering av et domene er en metode med lav risiko. Oppgraderingsprosessen for domenekontrolleren er automatisk, så det er lite rom for feil uten brukerinteraksjon. Metodikken for å gjenopprette fra en domeneoppgraderingsfeil er også relativt enkel: hvis oppgraderingen mislykkes, må du slå av den primære domenekontrolleren (PDC), tilordne enhver backup-domenekontroller (BDC) som har ferske data til PDC-rollen, og start prosedyren på nytt
    Domenerestrukturering Domenerestrukturering er en høyere risiko enn domenefornyelse. Det er flere oppgaver å fullføre, og derfor kan mange prosesser gå galt. Som et resultat er det økende frustrasjon blant brukere som ikke klarer å logge på, få tilgang til nødvendige ressurser eller få tilgang til postboksene sine.
  • Kriterium 3. Utførelsestid for overgang 1 Tidspunktet for overgangen er ikke en avgjørende faktor ved valg av overgangsvei, men det kan være en avgjørende faktor for små organisasjoner med begrensede ressurser. .Tabell 12.3. Velge en overgangsbane basert på kriterium 3
    Overgangsvei Kvalifikasjonskriterier
    Domeneoppdatering Domenefornyelse er en lineær prosess: når den er startet, må den fullføres. Det krever færre steg enn en omstrukturering og tar derfor kortere tid å gjennomføre hele overgangen
    Domenerestrukturering Restrukturering av domene tar alltid lengre tid. For eksempel, under en restrukturering, brukes mye tid på å bygge og validere infrastrukturen til måldomenet, og flytte alle kontoer fra kildedomenet til måldomenet. Store organisasjoner er kanskje ikke i stand til å flytte alle objektene på en gang, så ganske ofte gjøres domenerestrukturering i flere stadier
  • Kriterium 4: Katalogtjenestetid som kreves for å fullføre migreringsprosessen. Tabell 12.4. Velge en overgangsbane basert på kriterium 4
    Overgangsvei Kvalifikasjonskriterier
    Domeneoppdatering Kontoobjekter er ikke tilgjengelige under migreringsprosessen fordi de selvoppdateres når domenet oppgraderes
    Domenerestrukturering Et godt valg for organisasjoner der systemarbeidstid er en kritisk verdi. Fordi det innebærer å skape en ubefolket, "ren" skog og lar det opprinnelige miljøet i hovedsak være uendret, bevares funksjonaliteten til katalogtjenesten ettersom brukerne fortsetter å fungere i sitt eksisterende miljø. Du kan migrere store eller små grupper av brukere i løpet av rushtiden og la disse nye kontoene hvile til du er klar til å forlate det gamle systemet
  • Kriterium 5. Tilgjengelighet av ressurser for å fullføre overgangen. Tabell 12.5. Velge en overgangsbane basert på kriterium 5
    Overgangsvei Kvalifikasjonskriterier
    Domeneoppdatering Siden domeneoppdateringen er en automatisert operasjon, vil denne overgangsstien kreve færre menneskelige ressurser
    Domenerestrukturering Domenerestrukturering innebærer flere oppgaver enn domenefornyelse og krever derfor mer ressurser, noe som betyr at det må være tilstrekkelig bemannet for å håndtere den ekstra arbeidsbelastningen knyttet til domeneomstrukturering. Et alternativ er å sette ut deler av eller hele prosjektet: det er mange konsulentgrupper som spesialiserer seg på slike prosjekter, noe som sparer tid og penger for å trene internt personale
  • Kriterium 6. Overgangsprosjektbudsjett. Tabell 12.6. Velge en overgangsbane basert på kriterium 5
    Overgangsvei Kvalifikasjonskriterier
    Domeneoppdatering Faktorer som bidrar til en reduksjon i de nødvendige budsjettmidlene:
    • evne til å bruke eksisterende servermaskinvare;
    • lavere personalkostnader;
    • reduksjon i testkostnader siden færre oppgraderingsoppgaver må testes
    Domenerestrukturering Av mange grunner vil restrukturering av domene kreve et større budsjett enn domenefornyelse. Maskinvarekravene som trengs for å bygge et bart skogmiljø som katalogtjenesteobjekter må migreres til, bør vurderes fra et budsjettperspektiv

Hvis et selskap ikke helt oppfyller betingelsene for å trygt velge domenefornyelse eller restrukturering som fornyelsesvei, eller hvis begge veiene passer for det, så kan den velge en tredje vei – domenefornyelse etterfulgt av restrukturering.

Denne banen til Active Directory vil gi umiddelbare fordeler (delegering av administrasjon, gruppepolicyer, applikasjonspublisering med mer), samt de langsiktige fordelene ved domenerestrukturering (færre domener med økt domenevolum, domenedesign i samsvar med selskapets forretnings- og organisasjonsmål).