Vai onko se mahdollista? SAP-järjestelmien siirto on tietysti monimutkainen ja vaivalloinen prosessi, jonka onnistuminen edellyttää kaikkien osallistujien koordinoitua työtä. Ja jos siirto suoritetaan lyhyessä ajassa, tehtävästä tulee paljon monimutkaisempi. Kaikki eivät päätä tehdä tätä. Syitä voi olla useita. Esimerkiksi itse prosessi on pitkä ja organisatorisesti monimutkainen. Lisäksi on olemassa odottamattomien järjestelmän seisokkien riski. Tai asiakkaat eivät ole varmoja siitä, että he saavat tällaisen toimenpiteen jälkeen etuja, jotka ovat oikeassa suhteessa käytettyihin ponnisteluihin. Poikkeuksia kuitenkin on.
Leikkauksen alla puhumme vaikeuksista, joita asiakkaat kohtaavat siirtäessään ja ylläpitäessään SAP-järjestelmiä, keskustelemme siitä, miksi stereotypiat eivät aina vastaa todellisuutta, ja jaamme tapaustutkimuksen siitä, kuinka onnistuimme siirtämään asiakkaan järjestelmät uutta infrastruktuuria hieman yli kolmessa kuukaudessa.
SAP-järjestelmien isännöinti
Vielä viisi vuotta sitten oli vaikea kuvitella, että asiakkaat alkaisivat massiivisesti käyttää isännöintiresursseja SAP-sovelluksiin. Useimmissa tapauksissa ne toteutettiin paikan päällä. Ulkoistamismallien ja pilvipalvelumarkkinoiden kehittyessä asiakkaiden maailmankuva alkoi kuitenkin muuttua. Mitkä perusteet vaikuttavat SAP:n pilven valintaan?
- Aloittelijoille, jotka ovat juuri suunnitelleet SAP:n käyttöönottoa, pilviinfrastruktuuri on lähes vakiovalinta - resurssien skaalautuvuus järjestelmän tämänhetkisiin tarpeisiin ja haluttomuus ohjata resursseja ei-ydinosaamisalueiden kehittämiseen.
- Yrityksissä, joissa on laaja järjestelmäympäristö, tietohallintojohtajat saavuttavat SAP-järjestelmien isännöinnin avulla laadullisesti erilaisen riskienhallinnan tason, koska Kumppani on vastuussa SLA:sta.
- Kolmanneksi yleisin argumentti on infrastruktuurin rakentamisen korkeat kustannukset korkean käytettävyyden ja DR-skenaarioiden toteuttamiseksi.
- Factor 2027 – toimittaja ilmoitti vanhojen järjestelmien tuen lopettamisesta vuonna 2027. Tämä tarkoittaa tietokannan siirtämistä HANA:lle, mikä aiheuttaa kustannuksia modernisoinnista ja uuden laskentatehon hankinnasta.
SAP-hosting-markkinoita Venäjällä voidaan nyt pitää varsin kypsinä. Ja tämä tarjoaa runsaasti mahdollisuuksia asiakkaille, jotka haluavat vaihtaa isännöintialustojaan. Tällaiset hankkeet voivat kuitenkin oikeutetusti aiheuttaa huolta yrityksissä siirtymäprosessin monimutkaisuuden vuoksi. Tämä pakottaa asiakkaat asettamaan korkeampia vaatimuksia palveluntarjoajille, joilla tulee olla paitsi poikkeuksellista SAP-järjestelmien isännöintiä ja ylläpitoa koskevaa osaamista, myös onnistunutta kokemusta migraatioalalta.
Mitä vaikeuksia SAP-isännöinnin vaihtamisessa on?
Isännöinnit ovat erilaisia. Epäjohdonmukaisuus ilmoitetun palvelutason kanssa, monet "mutta" ja tähdet varauksilla pienessä tekstissä, isännöintipalveluntarjoajan rajalliset resurssit ja kyvyt, joustavuuden puute asioissa viestinnässä asiakkaan kanssa, byrokratia, tekniset rajoitukset, teknisen tuen heikko pätevyys asiantuntijat sekä monet muut vivahteet - nämä ovat Tämä on vain pieni osa sudenkuoppia, joita asiakkaat voivat kohdata käyttäessään liiketoimintajärjestelmiään ulkoistamisinfrastruktuureissa. Usein asiakkaalle tämä kaikki jää varjoon, monisivuisen sopimuksen viidakkoon ja tulee esiin palvelujen käytön yhteydessä.
Jossain vaiheessa asiakkaalle käy selväksi, että hänen saamansa palvelun taso on kaukana hänen odotuksistaan. Tämä on eräänlainen katalysaattori löytää ratkaisuja tilanteen korjaamiseksi ja epäonnistuessa, kun ongelmat kasaantuvat äärirajoille ja siitä tulee erittäin tuskallista, siirrytään aktiivisiin toimiin vaihtoehtoisten vaihtoehtojen kehittämiseksi palveluntarjoajan vaihdon suuntaan. .
Miksi he odottavat viime hetkellä? Syy on yksinkertainen - asiakkaiden järjestelmien siirtoprosessi ei ole aina läpinäkyvä ja ymmärrettävä. Asiakkaan on vaikea arvioida migraatioprosessiin liittyviä todellisia riskejä. Voimme sanoa, että migraatio on asiakkaille eräänlainen musta laatikko: on epäselvää, hinta, järjestelmän seisokit, riskit ja miten niitä voidaan pienentää, ja ylipäätään se on synkkää ja pelottavaa. Se on kuin, jos se ei onnistu, niin päät pyörivät sekä huipulla että esiintyjillä.
SAP on yritystason järjestelmä, monimutkainen ja lievästi sanottuna ei halpa. Niiden toteuttamiseen, muuttamiseen ja ylläpitoon käytetään kunnolliset budjetit, ja yrityksen elinikä riippuu niiden saatavuudesta ja oikeasta toiminnasta. Kuvittele nyt, mitä seurauksia suuren tuotannon pysäyttämisellä on. Nämä ovat taloudellisia tappioita, jotka voidaan laskea lukuisina lukuisina nollia, sekä maine- ja muita yhtä merkittäviä riskejä.
Analysoimme vaikeuksia, joita voi syntyä kussakin vaiheessa, kun SAP-järjestelmiä siirretään asiakkaaltamme.
Valmistelu ja suunnittelu
Muuttoliike on kaava, jossa on monia eri osia. Ja yksi tärkeimmistä on kohteen (uuden) infrastruktuurin suunnittelu- ja valmisteluvaihe.
Meidän piti sukeltaa järjestelmien olemassa olevaan toteutukseen, niiden arkkitehtuuriin. Kohdeinfrastruktuurissa toistimme olemassa olevia ratkaisuja jossain, täydensimme ja paransimme niitä paikoin, uudistimme niitä jossain, harkitsimme ja valitsimme ratkaisut vikasietoisuuden ja käytettävyyden varmistamiseksi sekä yhdistämme kaikki resurssit niin pitkälle kuin mahdollista.
Suunnitteluprosessin aikana tehtiin monia erilaisia harjoituksia, joiden ansiosta oli mahdollista valmistautua mahdollisimman paljon siirtymiseen ja ottaa huomioon kaikenlaiset vivahteet ja sudenkuopat (niistä lisää myöhemmin).
Päädyimme yksilöllisesti suunniteltuun yksityiseen pilviinfrastruktuuriin, joka perustuu datakeskukseemme:
- omistetut fyysiset palvelimet SAP HANA:lle;
- VMware-virtualisointialusta sovelluspalvelimille ja infrastruktuuripalveluille;
- päällekkäiset viestintäkanavat datakeskusten välillä L2 VPN:ää varten;
- kaksi päävarastojärjestelmää tuotteen ja "kaiken muun" erottamiseksi;
- Veritas Netbackupiin perustuva SRC erillisellä palvelimella, levyhyllyllä ja nauhakirjastolla.
Ja tässä on, kuinka toteutimme tämän kaiken teknisestä näkökulmasta.
SAP
- Käyttääksemme tallennustilaa tehokkaasti tuottavaan HANA:han käytimme jaettuja levyjä ilman järjestelmällistä tietokannan replikointia SAP:n avulla. Kaikki tämä oli kääritty sydämentahdistimeen perustuvaan Active-Standby SUSE HAE -klusteriin. Kyllä, palautumisaika on hieman pidempi kuin replikoinnin yhteydessä, mutta säästämme tallennustilaa puoleen ja säästämme sen seurauksena asiakkaan budjettia.
- Esituotantoympäristöissä HANA-klusterit hylättiin, mutta teknisesti tuotantokokoonpano toistettiin.
- Testaus- ja kehitysympäristöt jaettiin useisiin muihin palvelimiin ilman klustereita MCOS-kokoonpanossa.
- Kaikki sovelluspalvelimet virtualisoitiin ja niitä isännöi VMware.
Сети
- Erotimme ohjaus- ja tuotantoverkkojen ääriviivat fyysisesti kytkimien pinoilla ja käänsimme tuottavat asiakkaan konesaleja kohti.
- Asensimme riittävän määrän verkkorajapintoja, jotta suuria liikennevirtoja ei sekoituisi.
- Tietojen siirtämiseksi tallennusjärjestelmistä teimme klassisia FC SAN -tehtaita.
SHD
- SAP:n tuottava ja esituotantokuorma jätettiin all-flash-järjestelmään.
- Kehittäjien testiympäristöt ja infrastruktuuripalvelut sijoitettiin erilliseen hybriditaulukkoon.
IBS
- Valmistettu Veritas Netbackupilla.
- Lisäsimme hieman sisäänrakennettuja komentosarjoja MCOS-kokoonpanojen varmuuskopiointiin.
- Laitamme käyttökopiot levyhyllylle nopeaa palautusta varten ja käytämme nauhoja pitkäaikaiseen säilytykseen.
seuranta
- Kaikki laitteistot, käyttöjärjestelmä ja SAP asennettiin Zabbixin alle.
- Olemme koonneet monia hyödyllisiä kojetauluja Grafanaan.
- Kun hälytys tapahtuu, Zabbix voi luoda pyynnön tapaustenhallintajärjestelmään; olemme toteuttaneet sen Jirassa. Tiedot kopioidaan myös Telegram-kanavalla.
Telegram
HANA:n yleinen terveys
SAP-sovelluspalvelimen tila:
Infrastruktuuripalvelut
- Sisäisten nimiavaruuksien palvelemiseksi nostettiin DNS-palvelinklusteri, joka synkronoidaan asiakkaan palvelimien kanssa.
- Loimme erillisen tiedostopalvelimen tiedonvaihtoa varten.
- Gitlab lisättiin erilaisten asetusten tallentamiseksi.
- Erilaisia arkaluonteisia tietoja varten otimme HashiCorp Vaultin.
Siirtoprosessi
Yleensä siirtoprosessi koostuu seuraavista vaiheista:
- kaiken tarvittavan projektidokumentaation valmistelu;
- neuvottelut nykyisen palveluntarjoajan kanssa - organisatoristen ongelmien ratkaiseminen;
- uusien laitteiden hankinta, toimitus ja asennus projektia varten;
- testaa siirtoa ja prosessien virheenkorjausta;
- järjestelmien siirto, maahanmuuton torjunta.
Lokakuun 2019 lopussa teimme sopimuksen, suunnittelimme arkkitehtuurin ja sovittuamme asiakkaan kanssa tilasimme tarvittavat laitteet.
Se, mihin sinun on ensin kiinnitettävä huomiota, on laitteiden toimitusaika. SAP NAHA:lle sertifioidun laitteiston toimitus, joka täyttää ohjelmistovalmistajan laitteistoalustoille asettamat vaatimukset, kestää keskimäärin 10-12 viikkoa. Ja kun otetaan huomioon kausivaihtelu (projektin toteutus osui täsmälleen uudelle vuodelle), tämä ajanjakso olisi voinut pidentyä toisella kuukaudella. Tästä syystä prosessia oli tarpeen nopeuttaa mahdollisimman paljon: teimme yhteistyötä jakelija-toimittajan kanssa ja sovimme nopeasta toimituksesta lentokoneella (maa- ja merireittien sijaan).
Marras- ja joulukuu vietettiin muuttoon valmistautumiseen ja osan varusteiden vastaanottamiseen. Teimme valmistelun julkisessa pilvessämme olevalla testipenkillä, jossa kävimme läpi kaikki päävaiheet ja havaitsimme mahdolliset vaikeudet ja ongelmat:
- valmisti yksityiskohtaisen suunnitelman projektiryhmän jäsenten välistä vuorovaikutusta varten minuuttikohtaisilla ajoituksilla;
- rakensi testipenkin tietokanta- ja sovelluspalvelimille suunnilleen samalla tavalla kuin kohdeinfrastruktuurissa;
- konfiguroi tarvittavat viestintäkanavat ja infrastruktuuripalvelut integraatioiden toiminnan testaamiseksi;
- työskennellyt leikkausskenaariot;
- Pilvi auttoi meitä myös luomaan esikonfiguroituja virtuaalikoneen malleja, jotka sitten yksinkertaisesti tuotiin ja otettiin käyttöön kohdemaisemassa.
Vähän ennen uudenvuoden lomia saapui meille ensimmäinen erä varusteita. Tämä mahdollisti joidenkin järjestelmien käyttöönoton todellisilla laitteistoilla. Koska kaikkea ei saapunut, liitimme vaihtolaitteet, joiden toimittamisesta onnistuimme sopia myyjän ja jakelijoiden kanssa. Saimme loppuvaiheessa kohdeinfrastruktuurin jäänteet.
Noudattaakseen määräaikaa insinööriemme joutuivat uhraamaan uudenvuoden lomat ja aloittamaan kohdeinfrastruktuurin valmistelutyöt 2. tammikuuta, keskellä lomaa. Kyllä, näin tapahtuu joskus, kun se on tulessa, eikä muita vaihtoehtoja yksinkertaisesti ole. Vaakalaudalla oli niiden järjestelmien suorituskyky, joista yrityksen elinikä riippuu.
Yleinen siirtojärjestys näytti tältä: ensin vähiten kriittiset järjestelmät (kehitysmaisema, testausmaisema), sitten tuottavat järjestelmät. Muuton viimeinen vaihe tapahtui tammikuun lopulla ja helmikuun alussa.
Siirtoprosessi oli suunniteltu minuuttia myöten. Tämä on leikkaussuunnitelma, jossa on luettelo kaikista tehtävistä, valmistumisajasta ja vastuuhenkilöistä. Testimigraatiossa kaikki vaiheet oli jo tehty, joten live-migraatiossa tarvittiin vain seurata suunnitelmaa ja koordinoida prosessia.
Siirto toteutettiin systemaattisesti useassa vaiheessa. Jokaisessa vaiheessa on kaksi järjestelmää.
Kolmen kuukauden sprintin tuloksena syntyi järjestelmä, joka on täysin toimintakuntoinen CROC-palvelinkeskuksessa. Yleisesti ottaen ryhmätyöllä saavutettiin positiivinen tulos, kaikkien osallistujien panos ja omistautuminen prosessiin oli maksimaalinen.
Asiakkaan rooli projektissa
Kommunikointi asiakkaamme lähtevän palveluntarjoajan kanssa ei ollut helppoa. Tämä on ymmärrettävää, he olivat viimeisenä projektin onnistuneesta loppuun saattamisesta kiinnostuneiden listalla. Asiakas otti tehtäväkseen lisätä ja polkea kaikkia viestintäongelmia ja selviytyi tästä 100500%. Erityiskiitos hänelle tästä. Ilman tällaista mahdollista osallistumista prosessiin hankkeen tulos olisi voinut olla täysin erilainen.
Prosessien virallistamisen "entisen" palveluntarjoajan puolelta johtuen infrastruktuurin tuesta vastasivat asiantuntijat, jotka olivat kirjaimellisesti kaukana ongelmista, tuolloin vielä asiakkaansa. Esimerkiksi saman tietokannan vientiprosessi voi kestää tunnista viiteen. Sitten näytti siltä, että tämä oli jonkinlaista taikuutta, salaisuutta, jota meille ei koskaan paljastettu. Varmaan teknisen tuen insinöörit antautuivat meditaatioon sillä välin, unohtaen, että jossain kaukaisessa Venäjällä on aikarajat, insinöörit ilman uudenvuoden salaatteja, asiakas itkee ja kärsii...
Hankkeen tulokset
Siirron viimeinen vaihe oli järjestelmien siirto ylläpitoon.
Nyt tarjoamme yhden ikkunan palvelua asiakkaiden toiveisiin ja katamme koko infrastruktuurikomponenttien ja SAP-pohjan tukitehtävien laajuuden yhdessä kumppanimme - itelligence - kanssa. Asiakas on asunut yksityisessä pilvessä kuusi kuukautta. Tässä tilastot palvelutapauksista tänä aikana:
- 90 tapausta (20 % ratkaistu ilman asiakasta)
- Ratkaistu SLA:ssa – 100 %
- Suunnittelemattomat järjestelmän sammutukset – 0
Jos sinulla on samanlaisia ongelmia kuin asiakkaallamme ja haluat tietää lisää niiden ratkaisemisesta, kirjoita osoitteeseen: [sähköposti suojattu]
Lähde: will.com