Siirry pääsisältöön
FromNine
Valikko

Ohjelmistot & pilvi

Pilviperusta, joka tekee julkaisuista rutiinia.

Rakennamme pilviperustoja ja sisäisiä kehittäjäalustoja, joissa ympäristöt ovat koodia, julkaisut ovat allekirjoitettuja ja toistettavia ja jokaisella kulueurolla on omistaja.

Organisaatioille, jotka ajavat yhtä pilviperustaa usealle yhtiölle ja tarvitsevat näytön kyberturvallisuuslain ja DORA:n valvojille.

Keskustellaan projektistasiKatso viitearkkitehtuuri
Pilvi- ja alustakehitys: osaamisen kerroksetNeljä kerrosta päällekkäin syvyyssuunnassa. Ylhäältä alas: tuotetiimien työkuormat, sisäinen kehittäjäalusta, allekirjoitetut julkaisuputket sekä pohjalla landing zone -ympäristö identiteetteineen, verkkoineen ja sääntöineen.01Tuotetiimien työkuormat02Sisäinen kehittäjäalusta03Allekirjoitetut julkaisuputket04Landing zone ja säännöt
  1. 01Landing zone -ympäristöt, joissa säännöt ovat koodia ja tietojen sijainti asetetaan työkuormittain
  2. 02Valmiit kehityspolut, jotka vievät uuden palvelun tuotantoon toistettavalla tavalla
  3. 03Palvelutasotavoitteet, testattu palautuminen ja tuotekohtaiset kustannukset päättäjien nähtävillä

01 Ongelmat

Merkkejä siitä, että perusta jarruttaa

  1. 01

    Jokainen ympäristö on erilainen

    Testi- ja tuotantoympäristö eroavat tavoilla, joita kukaan ei ole kirjannut, ja konsolissa käsin tehdyt korjaukset katoavat seuraavassa uudelleenrakennuksessa.

  2. 02

    Julkaisu vaatii kokouksen

    Käyttöönotot ovat harvinaisia, manuaalisia ja ajoitettuja iltoihin. Tiimit keräävät muutoksia isoiksi eriksi, mikä tekee jokaisesta julkaisusta riskialttiimman.

  3. 03

    Pilvilasku yllättää kaikki

    Kustannukset näkyvät tilauksittain, eivät tuotteittain. Tekoälytyön GPU-kapasiteetti menee sille, joka pyysi ensin.

  4. 04

    Kukaan ei tiedä, toimiiko palautus

    Varmuuskopiot ovat olemassa. Palautuksia ei ole testattu, eikä palautumisaika- ja tietojen menetystavoitteista ole sovittu liiketoiminnan kanssa.

02 Toimitukset

Mitä toimitamme

  1. 01 Landing zone -ympäristöt ja suvereniteettivaihtoehdot

    Tili- ja tilausrakenne, identiteetti, verkko ja suojakaiteet suurten pilvipalveluntarjoajien ja EU:n suvereenien pilvipalvelujen päällä. Säännöt ovat koodia, ja tietojen sijainti määritetään työkuormittain.

    Mitä teemme

    • Organisaatio-, hallintaryhmä- ja tilirakenteen suunnittelu
    • Keskitetty verkko, ulosmenevän liikenteen hallinta ja yksityiset yhteydet
    • Säännöt koodina tietojen sijainnille, salaukselle ja tunnisteille
    • Vastaavuus ostajiesi edellyttämiin tietoturvavaatimuksiin ja todennuksiin

    Mitä saat

    • Kokonaan koodina määritelty landing zone -ympäristö
    • Sääntökirjasto ja poikkeusmenettely
    • Suvereniteettivaihtoehtojen selvitys työkuormaluokittain

  2. 02 Infrastruktuuri koodina ja sisäiset kehittäjäalustat

    Terraform tai OpenTofu ja Bicep infrastruktuurille, GitOps käyttöönotoille, Kubernetes tai hallinnoidut ajoympäristöt siellä, missä ne sopivat, ja valmiit kehityspolut, joiden avulla tiimi voi käynnistää vaatimukset täyttävän palvelun ilman tukipyyntöjä.

    Mitä teemme

    • Moduulikirjasto infrastruktuurille koodina
    • GitOps ja ympäristöjen välinen eteneminen
    • Kubernetes-alusta tai hallinnoidut vaihtoehdot
    • Palvelupohjat ja kehittäjäportaali

    Mitä saat

    • Sisäinen kehittäjäalusta valmiine kehityspolkuineen
    • Itsepalveluympäristöt
    • Alustatiimin omistama alustan tiekartta

  3. 03 Julkaisuputket ja toimitusketjun tietoturva

    Julkaisuputket, jotka kääntävät kerran, allekirjoittavat artefaktit, kirjaavat alkuperän SLSA:n mukaisesti, hallitsevat salaisuudet asianmukaisesti ja siirtävät saman artefaktin testistä tuotantoon.

    Mitä teemme

    • Julkaisuputkien pohjat laatu- ja tietoturvaportteineen
    • Artefaktien allekirjoitus ja alkuperän todentaminen
    • Salaisuuksien hallinta ja avainten kierrätys
    • Siirtosäännöt ja muutoskirjaukset

    Mitä saat

    • Uudelleenkäytettävät julkaisuputkien pohjat
    • Allekirjoitetut artefaktit todennettavalla alkuperällä
    • Julkaisunäyttö muutostenhallintaa varten

  4. 04 Havainnoitavuus ja SRE

    Liiketoiminnan kanssa sovitut palvelutasotavoitteet, virhebudjetit, jotka ohjaavat julkaisutahtia, OpenTelemetry koko pinossa ja häiriöprosessi, joka palvelee myös kyberturvallisuuslain ja DORA:n raportointivelvoitteita, kun ne koskevat sinua.

    Mitä teemme

    • Palvelutasotavoitteiden määrittely palvelujen omistajien kanssa
    • OpenTelemetry-instrumentointi ja näkymät
    • Hälytykset oireista, ei syistä
    • Häiriöiden hallinta ja häiriöiden jälkeiset katselmoinnit

    Mitä saat

    • Palvelutasotavoitteiden luettelo
    • Havainnoitavuuspino ja näkymät
    • Häiriö- ja raportointiohjeet

  5. 05 FinOps ja tekoälyn kapasiteetti

    Kustannusten kohdistus tuotteille ja tiimeille, yksikkötalous kuten tapahtumakohtainen kustannus sekä tekoälytyökuormien GPU-kapasiteetin suunnittelu ja kustannusten hallinta.

    Mitä teemme

    • Tunnistekäytäntö ja kohdistusmalli
    • Yksikkökustannusten mittarit tuotteittain
    • Sitoumusten ja varausten suunnittelu
    • GPU-ajoitus, kiintiöt ja oikea mitoitus

    Mitä saat

    • Kustannusnäkymät tuoteomistajittain
    • Säästötoimien työjono omistajineen
    • Tekoälyn kapasiteettisuunnitelma

  6. 06 Palautuminen ja irtautuminen

    Varmuuskopiointi ja jatkuvuus, joissa palautumisaika- ja palautumispistetavoitteet on sovittu ja testataan aikataulun mukaan, sekä irtautumisstrategia, joka hyödyntää EU:n datasäädöksen mukaisia vaihto-oikeuksia.

    Mitä teemme

    • RTO ja RPO sovitaan palveluittain
    • Palautus- ja vikasietotestit
    • Kriittisten palvelujen riippuvuuksien kartoitus
    • Irtautumissuunnitelma ja tietojen siirrettävyyden tarkistukset

    Mitä saat

    • Testatut palautusmenettelyt
    • Palautustestien raportit
    • Dokumentoitu irtautumisstrategia

03 Arkkitehtuuri

Havainnollistava viitearkkitehtuuri

Koodi tulee sisään vasemmalta ja toimivat työkuormat ulos oikealta. Välissä julkaisuputki allekirjoittaa kääntämänsä, rekisteri tallentaa vain allekirjoitettuja artefakteja, ja GitOps-ohjain siirtää ne ympäristöstä toiseen sääntöjen mukaisesti.

Pohjalla on landing zone -ympäristö: organisaatiorakenne, identiteetti, verkko, avaimet, palautuminen ja kustannusten hallinta, määriteltyinä kerran koodina ja kaikkien tuotetiimien yhteisinä.

Piirroksen kerrokset

Julkaisu
Koodivarastot, julkaisuputket, allekirjoitetut artefaktit ja GitOps-eteneminen.
Alusta
Kehittäjäalusta, säännöt koodina ja ajoympäristö, johon tuotetiimit julkaisevat.
Landing zone
Organisaatio, identiteetti, verkko, avaimet, palautuminen ja FinOps-hallintakeinot.
Ylläpito
Telemetria, palvelutasotavoitteet, virhebudjetit ja häiriöihin reagointi koko kokonaisuudessa.
Havainnollistava esimerkki

  1. Julkaisu

    • Koodi- ja IaC-varastot
    • Käännä, allekirjoita, todenna
    • Allekirjoitettujen artefaktien rekisteri
    • GitOps-eteneminen

  2. Alusta

    • Kehittäjäalusta ja valmiit polut
    • Säännöt koodina
    • Kubernetes ja hallinnoidut palvelut
    • Tuotetiimien työkuormat

  3. Landing zone

    • Hallintorakenne
    • Identiteetti ja käyttöoikeudet
    • Keskitetty verkko ja ulosmeno
    • Avaimet ja salaisuudet
    • Varmuuskopiointi ja palautus
    • Kustannusten kohdistus

  4. Ylläpito

    • OpenTelemetry, palvelutasot ja virhebudjetit, häiriöihin reagointi
Allekirjoitettu julkaisu sääntöjen ohjaamaan landing zone -ympäristöön

Havainnollistava arkkitehtuuri, ei asiakkaan järjestelmä.

Lue kaavio tekstinä

Pääreitti kulkee koodi- ja infrastruktuurivarastoista julkaisuputkiin, jotka kääntävät, allekirjoittavat ja todentavat, sitten artefaktirekisteriin, GitOps-ohjaimeen ja lopulta tuotetiimien työkuormaympäristöihin.

Sisäinen kehittäjäalusta tarjoaa valmiit kehityspolut julkaisuputkiin. Säännöt koodina rajaavat GitOps-ohjainta. Ajoalusta, jossa on Kubernetes ja hallinnoituja palveluja, isännöi työkuormia. Asiakkaan hallinnoimat avaimet syöttävät sääntökerrosta.

Alla olevassa landing zone -ympäristössä ovat hallintorakenne, identiteetti ja käyttöoikeudet, keskitetty verkko, avaimet, varmuuskopiointi ja palautus sekä FinOps-hallintakeinot. Havainnoitavuus palvelutasotavoitteineen ja häiriöihin reagointi kattavat koko alustan.

04 Näkökohdat ja rajat

Tekniset näkökohdat ja rajat

  • Suvereniteetti on asteikko

    Miten hoidamme sen

    Luokittelemme työkuormat arkaluonteisuuden mukaan ja sovitamme kuhunkin luokkaan vaihtoehdon: suuren pilvipalveluntarjoajan EU-alueet, suvereeni pilvipalvelu tai yksityinen infrastruktuuri. Ominaisuuksien, kustannusten ja ylläpidon kompromissit kirjataan.

    Rajat ja riippuvuudet

    Suvereenit palvelut ovat usein jäljessä hallinnoiduissa palveluissa, myös tekoälypalveluissa. Osa työkuormista maksaa niissä enemmän tai tekee vähemmän, ja se on liiketoimintapäätös.

  • Alusta tarvitsee tuoteomistajan

    Miten hoidamme sen

    Käsittelemme sisäistä alustaa tuotteena, jolla on käyttäjät, tiekartta ja palautesilmukat, ja autamme kokoamaan tiimin, joka sitä ylläpitää.

    Rajat ja riippuvuudet

    Alustasta ilman tiimiä tulee pullonkaula. Jos alustalle ei löydy omaa tiimiä, suosittelemme hallinnoituja palveluja ja vähemmän abstraktiotasoja.

  • Sääntely muovaa ylläpitoa

    Miten hoidamme sen

    Häiriöiden luokittelu, raportoinnin aikataulut ja näytön kerääminen rakennetaan häiriöprosessiin, kun kyberturvallisuuslaki tai DORA koskee sinua.

    Rajat ja riippuvuudet

    Sen ratkaiseminen, kuulutko soveltamisalaan ja miten kansallista lakia sovelletaan, jää vaatimusten­mukaisuus- ja lakitiimeillesi.

  • Kustannusten hallinta on yhteistä

    Miten hoidamme sen

    Teemme kustannukset näkyviksi tuotteittain ja lisäämme suojakaiteita, kuten budjetit, kiintiöt ja käyttämättömien ympäristöjen ajastetun sammutuksen.

    Rajat ja riippuvuudet

    Suurimmat säästöt tulevat yleensä arkkitehtuuri- ja käyttöpäätöksistä, joita tuoteomistajat tekevät, eivät pelkästä alustasta.

05 Työtapa

Miten työskentelemme

Ensin perusta, sitten yksi tiimi valmiille kehityspolulle, sitten kaikki muut.

  1. 01

    Arvioidaan ja luokitellaan

    Työkuormat, tietojen arkaluonteisuus, nykyiset kustannukset ja hallintakeinot, joita tarkastajasi odottavat.

    TuotosTyökuormien luokittelu ja tavoitevaihtoehdot

  2. 02

    Rakennetaan landing zone

    Kaikki koodina, tietoturvan kanssa katselmoituna ja poikkeuksille oma menettely.

    TuotosLanding zone tuotannossa

  3. 03

    Otetaan mukaan ensimmäinen tiimi

    Yksi tuotetiimi siirtyy valmiille kehityspolulle, ja sen kohtaamat esteet muovaavat alustaa.

    TuotosEnsimmäinen palvelu alustalla

  4. 04

    Laajennetaan ja luovutetaan

    Lisää tiimejä tulee mukaan, alustatiimi ottaa omistajuuden, ja palautumista testataan aikataulun mukaan.

    TuotosAlustan tiekartta ja palautustestien raportit

06 Ihmisen ohjaus

Missä ihmiset pitävät ohjat

Automaatio pyörittää alustaa. Ihmiset omistavat päätökset, joihin liittyy riskejä tai kustannuksia.

  • Tuotantomuutokset ovat jäljitettäviä

    Jokainen tuotantomuutos tulee katselmoidusta muutoksesta koodivarastossa, joten se, kuka muutti mitä ja kuka sen hyväksyi, on aina kirjattu.

  • Hätäpääsy on harvinaista ja kirjattua

    Hätäpääsy on aikarajattu, vaatii perustelun ja käydään läpi jälkikäteen.

  • Sääntöpoikkeuksilla on omistaja

    Kun työkuorma tarvitsee poikkeuksen suojakaiteesta, nimetty riskiomistaja hyväksyy sen määräaikaisena.

  • Palvelujen omistajat asettavat tavoitteet

    Palautumistavoitteet ja palvelutasot sovitaan kunkin palvelun liiketoimintaomistajan kanssa, eikä alustatiimi aseta niitä yksin.

07 Teknologiat

Teknologiat, joita käytämme

Pilvi
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • EU:n suvereenit pilvipalvelut
Infrastruktuuri ja julkaisu
  • Terraform ja OpenTofu
  • Bicep
  • Argo CD ja Flux
  • GitHub Actions, GitLab CI ja Azure DevOps
Ajoympäristö
  • Kubernetes ja sen hallinnoidut versiot
  • Serverless- ja konttialustat
  • Service mesh, kun se kannattaa
  • GPU-solmuryhmät tekoälytyökuormille
Ylläpito
  • OpenTelemetry
  • Prometheus ja Grafana
  • Pilvinatiivi valvonta
  • Sääntömoottorit, kuten OPA

Teknologian mainitseminen kuvaa kokemustamme. Se ei tarkoita kumppanuutta toimittajan kanssa eikä toimittajan suositusta.

08 Esimerkki

Havainnollistava esimerkki

Havainnollistava esimerkki

Yhteinen landing zone -ympäristö kaukolämpöyhtiölle kyberturvallisuuslain vaatimuksin

01Tilanne
Kaukolämpö- ja sähkönmyyntiyhtiön kolme liiketoimintaa käyttävät erillisiä pilviympäristöjä eri hallintakeinoin. Toimialan valvoja odottaa näyttöä riskienhallinnasta ja häiriöilmoituksista, eikä kukaan pysty esittämään tietoturvan tilaa yhdestä näkymästä.
02Mitä rakentaisimme
Yksi koodina määritelty landing zone -ympäristö liiketoimintakohtaisine sääntöineen, yhteinen lokitus ja häiriöprosessi, joka luokittelee häiriöt ja kokoaa ilmoituksiin tarvittavat tiedot kyberturvallisuuslain aikataulujen mukaan.
03Missä ihmiset päättävät
Kunkin liiketoiminnan tietoturvavastaava hyväksyy omien työkuormiensa sääntöpoikkeukset. Yhtiön tietoturvajohtaja omistaa yhteisen perustason ja päättää ilmoitusten lähettämisestä.
04Mitä mittaisimme
Aika häiriön havaitsemisesta luokitteluun, sääntöjen piirissä olevien työkuormien osuus ja hyväksytyt palautustestit vuosineljänneksittäin.

09 Toimialat

Toimialallasi

  • Julkinen sektori

    Suvereniteettivaihtoehdot tietoluokittain, kansalliset tietoturvavaatimukset ja irtautumissuunnitelmat, jotka kestävät seuraavan kilpailutuksen.

  • Rahoitusala

    Digitaalinen häiriönsietokyky DORA:n mukaan: testattu palautuminen, ICT-kolmansien osapuolten valvonta ja häiriöraportointi osana arjen toimintaa.

Suomi

Näyttö kerran, jokaiselle valvojalle

Suomessa NIS2-direktiivi on pantu täytäntöön kyberturvallisuuslailla (124/2025), joka tuli voimaan 8. huhtikuuta 2025. Valvonta on jaettu toimialakohtaisille viranomaisille, ja Traficomin Kyberturvallisuuskeskus toimii keskitettynä yhteyspisteenä. Finanssialan toimijoita koskee lisäksi DORA, jonka vaatimusten noudattamista Finanssivalvonta valvoo valvottavissaan.

Suunnittelemme landing zone -ympäristöt, joissa tietojen sijainti, lokitus ja häiriöiden luokittelu ovat sääntöjä eivätkä projekteja. Näin uusi yhtiö tai maa otetaan mukaan konfiguraatiolla. Irtautumissuunnitelmat nojaavat datasäädöksen mukaisiin vaihto-oikeuksiin, ja ne testataan eikä vain kirjoiteta.

Kysymyksiä pilvi- ja alustakehityksestä

Mitä pilvipalveluntarjoajaa suositellaan?

Sitä, joka sopii työkuormiisi, nykyisiin sopimuksiisi ja suvereniteettivaatimuksiisi. Työskentelemme suurten pilvipalveluntarjoajien ja EU:n suvereenien palvelujen kanssa ja dokumentoimme kompromissit, jotta valinta on perusteltavissa hankinnassa ja sitä voi arvioida myöhemmin uudelleen.

Tarvitsemmeko Kubernetesia?

Ei aina. Kubernetes kannattaa, kun ajat monia palveluja ja sinulla on tiimi alustan ylläpitoon. Muutamalle palvelulle hallinnoidut kontti- tai serverless-alustat ovat usein yksinkertaisempia ja edullisempia ylläpitää.

Miten tietoturva hoidetaan?

Tietoturva on rakennettu landing zone -ympäristöön ja julkaisuputkiin: vähimpien oikeuksien identiteetit, säännöt koodina, allekirjoitetut artefaktit ja salaisuudet, jotka eivät koskaan ole koodissa. FromNine on itse ISO/IEC 27001 -sertifioitu tietoturvallisuuden hallinnan osalta.

Voiko pilvikustannuksia pienentää?

Yleensä kyllä, mutta emme lupaa prosenttilukua ennen kuin olemme nähneet datan. Aloitamme tekemällä kustannukset näkyviksi tuotteittain ja käymme sitten säästötoimet läpi niiden omistajien kanssa, jotka voivat toteuttaa ne.

Miten toimittajalukko vältetään?

Valitsemalla harkiten, missä nojataan palveluntarjoajakohtaisiin palveluihin, pitämällä infrastruktuuri koodina ja ylläpitämällä dokumentoitua ja testattua irtautumissuunnitelmaa. EU:n datasäädös vahvistaa oikeuttasi vaihtaa palveluntarjoajaa, ja irtautumissuunnitelma tekee oikeudesta käyttökelpoisen.

Näytä meille kolme seuraavaa julkaisuasi

Kerromme, mikä tekisi niistä rutiinia ja mitä sellaisen perustan rakentaminen ja ylläpito maksaisi.

Keskustellaan projektistasiArkkitehtuuri & konsultointi