Ennen kuin allekirjoitat sopimuksen pilvisiirtokumppanin kanssa, kysy, miten se inventoi ajamasi järjestelmät, valitsee siirtostrategian kullekin sovellukselle, suunnittelee ja suojaa kohdeympäristön, varautuu palauttamaan jokaisen tuotantovaihdon, näyttää sinulle kustannukset ja valmistaa tiimisi ylläpitämään lopputulosta. Täsmälliset, kirjalliset vastaukset kertovat edessä olevasta siirrosta enemmän kuin päivähinta.
Kysy, miten kumppani selvittää, mitä oikeasti ajat
Siirtosuunnitelma on vain niin hyvä kuin sen takana oleva inventaario. Kysy kumppanilta, miten se rakennetaan: sovellusten omistajien haastatteluista, infrastruktuuridatasta, kuten palvelinmittareista ja verkkoyhteyksistä, itse koodista vai kaikista kolmesta. Olemassa oleva dokumentaatio on lähtökohta, ei todiste, koska se erkanee ajan mittaan siitä, mitä oikeasti ajetaan.
Kysy, mitä inventaarioon kirjataan ja kuka omistaa sen jälkikäteen. Hyvä vastaus nimeää kentät ja vahvistaa, että inventaario jää sinulle, päätitpä seuraavaksi mitä tahansa.
- Jokainen sovellus, sen liiketoiminnan omistaja ja kriittisyys
- Ajoympäristöt, sovelluskehykset ja käyttöjärjestelmät sekä merkintä kaikesta, minkä tuki on päättynyt
- Tietokannat, tiedostojaot, ajastetut työt ja jonot, joista kukin sovellus riippuu
- Integraatiot molempiin suuntiin, myös ne, joita kukaan ei dokumentoinut
- Laitteistoon tai prosessorimäärään sidotut lisenssit, jotka eivät välttämättä siirry pilveen
- Hyväksyttävä katkoaika ja liiketoiminnan kalenteri: kuunvaihde, sesonkihuiput, viranomaismääräajat
Odota strategiaa sovelluksittain, ei yhtä koko kokonaisuudelle
Sovellukset siirtyvät pilveen eri tavoin. Tavalliset vaihtoehdot ovat siirtää sovellus sellaisenaan (lift and shift), siirtää se pienin muutoksin, esimerkiksi hallinnoituun tietokantaan (replatform), muokata se käyttämään pilvipalveluita (refactor), korvata se SaaS-tuotteella, pitää se toistaiseksi paikallaan tai poistaa se käytöstä. Kumppani, joka ehdottaa yhtä lähestymistapaa kaikkeen, ei ole katsonut tarpeeksi tarkasti.
Pyydä kriteerit, joilla kumppani valitsee, ja pyydä näkemään ne sovellettuna kolmeen tai neljään omaan sovellukseesi ennen allekirjoitusta. Sen päättely todellisista järjestelmistäsi kertoo enemmän kuin menetelmädia. Kysy erityisesti, miten se käsittelee sovelluksia, joiden ajoympäristön tuki on päättynyt, koska niiden siirtäminen muuttamattomina kantaa vanhat riskit uudelle alustalle.
Selvitä, kuka suunnittelee ja suojaa landing zonen
Landing zone on valmisteltu kohdeympäristö: tilirakenne, identiteetti ja käyttöoikeudet, verkot, lokitus, salaus ja suojakaiteet, jotka jokainen sovellus perii. Siinä tehty virhe toistuu jokaisessa sovelluksessa, joka laskeutuu sen päälle. Kysy, kuka sen suunnittelee, määritelläänkö se koodina, esimerkiksi Terraformilla, ja katselmoiko tietoturvatiimisi sen ennen kuin ensimmäinen sovellus siirtyy.
Pilven tietoturva on jaettu vastuu. Palveluntarjoaja suojaa taustalla olevan infrastruktuurin, ja sinä vastaat edelleen siitä, miten konfiguroit ja käytät sitä. Kysy kumppanilta, mitkä kontrollit se ottaa käyttöön, mitkä jäävät tiimillesi ja miten sen omien kehittäjien käyttöoikeudet myönnetään, kirjataan lokiin ja lopuksi poistetaan.
- Erilliset tilit tai projektit kullekin ympäristölle, tuotanto eristettynä
- Kertakirjautuminen (SSO) nimetyillä käyttäjillä ja vähimmäisoikeuksien rooleilla, ei jaettuja ylläpitäjätunnuksia
- Keskitetty lokitus ja auditointijäljet, joita projektin kehittäjät eivät voi kytkeä pois päältä
- Salaus levossa ja siirrossa oletuksena, ja salaisuudet pidetään poissa koodista
- Alueet valittu tietojen sijaintia ja GDPR:ää koskevien velvoitteidesi mukaan
Pyydä kumppania käymään läpi yksi tuotantovaihto ja yksi palautus
Tuotantovaihto (cutover) on hetki, jolloin liikenne ja tiedot vaihtuvat uuteen ympäristöön, ja siinä siirto näkyy liiketoiminnalle eniten. Pyydä kumppania käymään yhden sovelluksesi tuotantovaihto läpi vaihe vaiheelta: miten tiedot synkronoidaan, miten liikenne vaihdetaan, mitkä tarkistukset ajetaan jälkeenpäin ja kuka päättää, että se onnistui.
Kysy sitten, miten se palaisi takaisin. Uskottava suunnitelma nimeää palautuksen laukaisevat ehdot, päätöksen tekevän henkilön ja sen, kuinka kauan vanha ympäristö pysyy saatavilla. Jos käyttäjät ovat vaihdon jälkeen kirjoittaneet tietoja uuteen ympäristöön, kysy, miten nuo tiedot palaavat vanhaan. Heikot suunnitelmat ohittavat tämän kysymyksen.
Artikkelimme satojen vanhojen sovellusten siirrosta AWS:ään näyttää, miten näistä vaiheista tulee ajo-ohjeita suuressa kokonaisuudessa.
Vaadi näkemään kustannukset ennen ensimmäistä laskua
Pilvikustannukset käyttäytyvät eri tavalla kuin konesalissa. Maksat siitä, mikä on käynnissä, myös testiympäristöistä, joita kukaan ei sammuttanut, jatkuvasti kasvavasta tallennustilasta ja palveluntarjoajan verkosta ulos siirretystä datasta. Pyydä kustannusarvio sovelluksittain oletuksineen kirjallisena ja kysy, miten kumppani vertaa sitä todelliseen käyttöön ensimmäisinä kuukausina.
Kustannusten näkyvyys on suunnittelupäätös, ei kuukausiraportti. Pyydä tunnistesäännöt (tagging), jotka liittävät jokaisen resurssin sovellukseen ja omistajaan, budjetit ja hälytykset ensimmäisestä päivästä alkaen sekä instanssikokojen tarkistus, kun sovellukset ovat toimineet todellisella kuormalla. Pilvipalvelinten mitoittaminen vanhan laitteiston mukaan on varma tapa maksaa kapasiteetista, jota kukaan ei käytä.
Varoitusmerkit siitä, että siirtoehdotus ei ole valmis
Jokaiselle näistä voi olla selitys. Useat samassa ehdotuksessa tarkoittavat yleensä, että riski on jätetty sinun löydettäväksesi.
- Kiinteä aikataulu ennen kuin kukaan on nähnyt inventaariotasi
- Yksi siirtostrategia sovellettuna jokaiseen sovellukseen
- Ei kirjallista palautussuunnitelmaa, tai palautus, joka perustuu varmuuskopioiden palauttamiseen paineen alla
- Pilvitilit, infrastruktuurikoodi tai putket kumppanin eivätkä sinun omistuksessasi
- Kustannusarviot ilman oletuksia eikä suunnitelmaa tunnisteille tai budjeteille
- Osaamisen siirto ajoitettu viimeiselle viikolle
Suunnittele osaamisen siirto ensimmäisestä viikosta, ei viimeisestä
Siirto päättyy, alustan ylläpito ei. Kysy, miten tiimisi oppii käyttämään rakennettua: parityöskentelyä oikeissa tehtävissä siirron aikana, ajo-ohjeet toistuviin toimenpiteisiin sekä valvonnan ja hälytysten läpikäynti päivystävien ihmisten kanssa.
Pyydä, että kaikki on alusta asti tileilläsi ja repositorioissasi: infrastruktuurikoodi, putket, ajo-ohjeet ja kaaviot. Sovi sitten, miten luovutus hyväksytään, esimerkiksi niin, että tiimisi ottaa sovelluksen käyttöön ja palauttaa sen ilman kumppanin apua.
Olimme mukana tiimissä, joka siirsi 600+ Crédit Agricolen sisäistä sovellusta vanhoilta virtuaalikoneilta AWS:ään, ja toimitimme itse 50+ näistä siirroista. Jos haluat toisen mielipiteen siirtoehdotuksesta tai tiimin toteuttamaan osan työstä, pilvi-infrastruktuurin kehittäjämme voivat käydä nämä kysymykset läpi kanssasi.
Tärkeimmät havainnot
- Kysy, miten inventaario rakennetaan ja tarkistetaan, koska jokainen arvio ja aaltosuunnitelma riippuu siitä.
- Odota sovelluksittain valittua siirtostrategiaa ja kriteerejä, jotka näet sovellettuna omiin järjestelmiisi.
- Määrittele landing zone koodina, anna tietoturvatiimisi katselmoida se ja pidä se omilla tileilläsi.
- Älä hyväksy tuotantovaihdon suunnitelmaa ilman nimettyä palautuksen laukaisinta ja keinoa palauttaa vaihdon jälkeen kirjoitetut tiedot.
- Sovi tunnisteista, budjeteista ja luovutuksen hyväksymisestä ennen kuin ensimmäinen sovellus siirtyy.
UKK
Pitäisikö kokonaisuutemme arvioivan kumppanin myös siirtää se?
Se voi, ja se säästää usein aikaa, koska inventaarion rakentanut tiimi tuntee erikoistapaukset. Osta arvio erillisenä tuotoksena, jonka omistat, jotta voit viedä sen toiselle kumppanille, jos siirtoehdotus ei vakuuta.
Miten eri siirtokumppanien ehdotuksia verrataan?
Anna jokaiselle kumppanille sama inventaarion ote ja samat kysymykset ja pyydä kutakin soveltamaan kriteerejään samoihin muutamaan sovellukseen. Vertaa päättelyä, palautussuunnitelmia ja arvioiden taustaoletuksia, älä vain kokonaishintaa.
Voiko tiimimme jatkaa ominaisuuksien julkaisemista siirron aikana?
Kyllä, jos suunnitelmassa kerrotaan, miten. Sovi kullekin sovellukselle muutosten jäädytysikkuna, tapa pitää molemmat ympäristöt synkronissa siirron ajan ja se, kuka hyväksyy julkaisut, kun sovellus on kesken siirron.