IT-alan työpaikat

[Nipa]

Tällainen työpaikkailmoitus tuli vastaan yliopiston sähköpostilistalla:

Projekti: MetaEdit+:n monenkäyttäjän version laajentaminen hajautettuun
ympäristöön

Jos aiempaa kokemusta ei ole, niin tarttuisin ehdottomasti tilaisuuteen. Ensimmäisen työpaikan saaminen on aina haastavaa, ja tuollainen todelliseen yritykseen tehty todelinen projekti näyttää vakuuttavalta CV:ssä, vaikka et samasta firmasta jatkoa saisikaan. Palkkaa ei kannata liikaa tuijotella, vaikka olisikin sitä mieltä että tuosta voisi muutaman satasen enemmän ansaita niin rahaa kerkeät kyllä tienaamaan ja jos tuo aukaisee jo opiskelujen aikana ovia niin kerkeät tienaamaan ne muutamat sataset moninkertaisena takaisin

Itse tein kouluaikoina harjoittelua 1500e/kk -palkalla, minkä jälkeen (ennen valmistumista) ottivat vakkariksi 2500e/kk palkalla. Tämä siis pöndellä, missä ei toki palkat ihan pääkaupunkitasoa ole

 

[Randomizer]

Jos on joku yliopiston oma projekti niin ihan linjassa kyseisen laitoksen kompensaatioiden kanssa. Tossa sentään maksetaan edes jotakin.

 

[hsalonen]

Tällainen työpaikkailmoitus tuli vastaan yliopiston sähköpostilistalla:

Projekti: MetaEdit+:n monenkäyttäjän version laajentaminen hajautettuun
ympäristöön

MetaEdit+ on graafinen ympäristö, jolla voi luoda ja käyttää omia
graafisia määrittelykieliä ja koodingeneraattoreita. Moni käyttäjä voi
mallintaa yhdessä omalla MetaEdit+ Client -ohjelmalla niin, että mallit
ovat paikallisverkon palvelimessa, MetaEdit+ Server -ohjelman takana.
Osa tietoliikenteestä on socket-pohjaista (lähinnä hallintaa) ja osa
tiedostopohjaista (lähinnä mallidataa). Arkkitehtuuri ja protokollat on
tehty pääasiallisesti paikallisverkkoon, jossa on matala latenssi ja
korkea luotettavuus. Jos verkon latenssi on korkea (esim. VPN:n yli),
luotettavuus on heikkoa (VR:n junassa), tai tiedostojärjestelmä antaa
väärää tai vanhentunutta tietoa tiedostoista (Windows SMB tietyissä
oloissa), nopeus ja luotettavuus voi laskea alle hyväksyttävän rajan.
Projektissa parannetaan kaukoyhteyksien nopeutta ja luotettavuutta:

* Muutetaan tietoliikenne puhtaasti socket-pohjaiseksi. Client pyytää
dataa socketilla, Server-ohjelma lukee tiedostosta ja vastaa socketiin.
* Clientin verkkoyhteyden katkaisut ja IP:n muuttumiset kestetään.
Server ja Client ovat valmiit muodostamaan yhteys uudestaan.
* Lisätään mahdollisuus pyytää useita malliolioita kerralla, jolloin
niiden kaikkien dataa voidaan palauttaa yhdessä ja latenssi vältetään.

Tarvittavia taitoja:
* Hyvä kyky ymmärtää laajoja järjestelmiä niiden koodista
* Varmaa olio-ohjelmointitaitoa, joko Smalltalkilla tai usealla kielellä
* Myönteinen asenne uuden oppimiseen ja tapojen muuttamiseen tarpeen
mukaan
* Ymmärrys ja kokemus verkko-ohjelmoinnista (TCP) ja debuggaamisesta
(Wireshark yms.) katsotaan hyödyksi


Ja tästä palkaksi luvattu 1500e/kk, työsuhteen kesto 3kk. Mitä mieltä foorumilaiset? Ainakin näin opiskelijan näkökulmasta tuntuu, että ihan oikea osaaja saa olla, että tuon saa itsenäisesti toteutettua. Siihen nähden aika mielestäni naurettava palkkaus.

Palkka on ok, jos työaika on 15-20h/viikko.

 

[Ascend]

Itsellä ei kyseiselle paikalle ole tarvetta . Kyseessä ihan yksityinen firma. Lähinnä siis mietin, että aika kovat vaatimukset on tuohon palkkaan nähden harjoittelijalta - usein kun harkkapaikoista ilmoitetaan tyyliin "olisi hyvä jos olisit konseptin tasolla perilla aiheesta x."

Toki kaikki työ on arvokasta, itsekin olen ensimmäisiä alan hommia tehnyt n. 1500e liksalla ja ilmaiseksikin erään projektin, joka sitten poiki jatkoa ja on aina vakuuttanut työnantajia. Asiantuntemusta vaadittiin kuitenkin huomattavasti vähemmän. Lähinnä siis tuntuu, että sellainen kaveri, joka tuon osaa itsenäisesti tehdä saa kyllä paremmin palkatun pestin muualtakin.

 

[sirace]

Tällainen työpaikkailmoitus tuli vastaan yliopiston sähköpostilistalla:

Projekti: MetaEdit+:n monenkäyttäjän version laajentaminen hajautettuun
ympäristöön

MetaEdit+ on graafinen ympäristö, jolla voi luoda ja käyttää omia
graafisia määrittelykieliä ja koodingeneraattoreita. Moni käyttäjä voi
mallintaa yhdessä omalla MetaEdit+ Client -ohjelmalla niin, että mallit
ovat paikallisverkon palvelimessa, MetaEdit+ Server -ohjelman takana.
Osa tietoliikenteestä on socket-pohjaista (lähinnä hallintaa) ja osa
tiedostopohjaista (lähinnä mallidataa). Arkkitehtuuri ja protokollat on
tehty pääasiallisesti paikallisverkkoon, jossa on matala latenssi ja
korkea luotettavuus. Jos verkon latenssi on korkea (esim. VPN:n yli),
luotettavuus on heikkoa (VR:n junassa), tai tiedostojärjestelmä antaa
väärää tai vanhentunutta tietoa tiedostoista (Windows SMB tietyissä
oloissa), nopeus ja luotettavuus voi laskea alle hyväksyttävän rajan.
Projektissa parannetaan kaukoyhteyksien nopeutta ja luotettavuutta:

* Muutetaan tietoliikenne puhtaasti socket-pohjaiseksi. Client pyytää
dataa socketilla, Server-ohjelma lukee tiedostosta ja vastaa socketiin.
* Clientin verkkoyhteyden katkaisut ja IP:n muuttumiset kestetään.
Server ja Client ovat valmiit muodostamaan yhteys uudestaan.
* Lisätään mahdollisuus pyytää useita malliolioita kerralla, jolloin
niiden kaikkien dataa voidaan palauttaa yhdessä ja latenssi vältetään.

Tarvittavia taitoja:
* Hyvä kyky ymmärtää laajoja järjestelmiä niiden koodista
* Varmaa olio-ohjelmointitaitoa, joko Smalltalkilla tai usealla kielellä
* Myönteinen asenne uuden oppimiseen ja tapojen muuttamiseen tarpeen
mukaan
* Ymmärrys ja kokemus verkko-ohjelmoinnista (TCP) ja debuggaamisesta
(Wireshark yms.) katsotaan hyödyksi


Ja tästä palkaksi luvattu 1500e/kk, työsuhteen kesto 3kk. Mitä mieltä foorumilaiset? Ainakin näin opiskelijan näkökulmasta tuntuu, että ihan oikea osaaja saa olla, että tuon saa itsenäisesti toteutettua. Siihen nähden aika mielestäni naurettava palkkaus.

Ilmoitus oli kaupallisen yrityksen ilmoitus? Ei yliopiston tai toisen yo-laitoksen? Kyllähän noilla vaatimuksella ja sillä että kyseessä on vain 3kk jakso niin palkka pitäisi about tuplata.

 

[machia]

Ja tästä palkaksi luvattu 1500e/kk, työsuhteen kesto 3kk. Mitä mieltä foorumilaiset? Ainakin näin opiskelijan näkökulmasta tuntuu, että ihan oikea osaaja saa olla, että tuon saa itsenäisesti toteutettua. Siihen nähden aika mielestäni naurettava palkkaus.

Epäilen että hakemukseen on listattu kaikki maan ja taivaan välillä (kuten yleensä tapana on). En ihan näiltä näppiksiltä usko että tuo on mikään 40h/vko pesti, joten tuo liksa voi olla ihan passeli ekaksi duuniksi opiskelijalle. Saapahan rahaa ja kokemusta.

Hauskaa että MetaEdit on vielä olemassa. Luulin että tuo UI-kikkareesta generoitava koodi on jo päivänsä elänyt. Muistelen joskus 10v sitten koulussa tuon kanssa leikkineen.

 

[juhei]

Haiskahtaa vähän siltä että firma on sanonut hakevansa harjoittelijaa (palkka ja kesto viittaa tuohon) ja yliopistolla joku on vaan välittänyt ilmoituksen sellaisenaan miettimättä onko vaatimuksiltaan harjoitteluksi sopiva.

 

[username]

1500e ei ole edes ns. oikeata rahaa, mutta jos ei ole muutakaan tekemistä, niin ehdottomasti sorvin äärellle. Varmasti antoisampaa kuin kotona hanskan hakkaaminen.

 

[Tech_ananas]

En löytänyt parempaa ketjua joten pannaan tänne. Itseäni kiinnostaisi kovasti 80% työaika ja IT-alasta kyse. Onko kellään techläisellä kokemusta 80% työajasta? Mitä kannattaisi ottaa huomioon kun asiasta neuvottelee? Onko hyviä puolia jota voisi tuoda työnantajalle jotta puoltaisi tätä helpommin?

Kaverillani on 80% työaika ja on kehunut kovasti että miellyttävä järjestely. Paljon enemmän vapaa-aikaa omille projekteille, tämä kai se suurin motivaattori olisi. Toisaalta kun on kohtuullinen palkka niin 80% brutto ei tiputa nettoa 80% vaan lienee jotain 85% jolloin käteen jäisi edelleen ihan mukavasti ( =olisin siihenkin tyytyväinen). Tuossa siis omat perusteet miksi tämä kiinnostaisi. Työnantajan suuntaan positiiviset perusteet jota keksin on oman jaksamisen ja työtehon parantuminen ja toisaalta jos sopimuksessa on 80% tunnit niin olisin helposti satunnaisesti käytettävissä 100-120% tunneilla jolloin piikkien tasaaminen olisi helpompaa. +tietysti bruttopalkan vähennyksen verran vähemmän kuluja

En oikein usko että työnantaja lämpenee ajatukselle kun itsellä ja työkavereilla on koko ajan 110% työkuorma... Oulussa olen duunissa ja täällä vaihtuvuutta alalla on (omassakin firmassa viime aikoina), eli resursseja voidaan kyllä muuttaa kun aikaa on. Tämä varmaankin hyvä asia koska jos 80% tuntimäärän ottaa oikeasti tavoitteeksi niin Oulussa +15v kokemuksella sellaista duunia saada ja ehkä työnantajakin tuon tiedostaa. Mikään korvaamaton resurssi en todellakaan ole, pitkä kokemus alalta mutta vasta viimeiset 3-4v puhtaasti näissä sw hommissa ja nykyiset hommat luistaa omasta mielestäni kyllä hyvin.

 

[edup]

En oikein usko että työnantaja lämpenee ajatukselle kun itsellä ja työkavereilla on koko ajan 110% työkuorma...

Ei tuo välttämättä ole ongelma. Tietämättä mitään tilanteesta tarkemmin, saattaahan se olla että 110% työkuorma johtuu siitä ettei kannata palkata uutta tyyppiä jos sille ei sitten ihan löydy riittävästi hommia. Nyt jos joku haluaisikin tiputtaa oman työaikansa lyhyemmäksi, saattaisi sille uudelle kaverille olla sen verran tekemistä että palkkaaminen kannattaa ja koko tiimi kiittää.

Itse teen konsulttihommia ja noita työaikaräätälöintejä on firmassa aikamoinen kirjo. Osaltaan helpottaa tietenkin kun aina ei asiakkaallekaan saada myytyä 100% työajalle tyyppejä vaan soppari on jotain muuta. Mutta nää on sen verran tapauskohtaisia että asia ei todennäköisesti selviä muutoin kuin keskustelemalla oman esihenkilön kanssa.

 

[dropadrop]

Mä sovin joskus, että teen määräaikaisesti 80% työaikaa jotta voin opiskella sivussa. Tämä sopi työpaikalle ihan hyvin, varmaan koska kehitin itseäni omalla kustannuksella.

Etuna määräaikaisessa (avoimessa) muutoksessa on, että voit palata kenties vanhaan halutessasi? Jos muuten vaan haluaa lyhyempää työviikkoa niin yksi perustelu voisi olla tutkimukset joissa ihmiset saavat lähes yhtä paljon aikaiseksi lyhyemmälläkintyöajalla?

 

[FireFly Renaissance]

Haiskahtaa vähän siltä että firma on sanonut hakevansa harjoittelijaa (palkka ja kesto viittaa tuohon) ja yliopistolla joku on vaan välittänyt ilmoituksen sellaisenaan miettimättä onko vaatimuksiltaan harjoitteluksi sopiva.

Näin ihan mutuna sanoisin, että ei toi nyt miltään kovin vaativalta projektilta teknisesti kuulostanut. Ja jos palkkaa harjoittelijan niin työaikaa saa varmaan käyttää siihen, että ottaa selvää mikä se socketti on ja miten sitä käytetään. Varsinaisena vaatimuksenahan oli, että ymmärtää olioita mikä on yhtä kuin toisen tai kolmannen vuoden tietotekniikan opiskelija.

 

[Sandaali_]

Onkohan tähän joku luonnonlaki. Heti päivän jälkeen kun saa haastattelussa sovittua aloituksesta, tulee kutsua toiselta firmalta johon alunperin halusin. Sekin olisi vasta viikon päästä joten ei edes varmuutta pääsystä. Parempi varmaan pelata varman päälle.

 

[Ihime]

Onkohan tähän joku luonnonlaki. Heti päivän jälkeen kun saa haastattelussa sovittua aloituksesta, tulee kutsua toiselta firmalta johon alunperin halusin. Sekin olisi vasta viikon päästä joten ei edes varmuutta pääsystä. Parempi varmaan pelata varman päälle.

Eikait mikään estä menemästä silti haastatteluun toiseen paikkaan ja jos sieltäkin tarjotaan sitten paikkaa niin vaihtaa sinne jos edelleen tuntuu että se olisi mieluisampi paikka työskennellä?

 

[Tach]

Jännitystä ilmassa, hain ensimmäistä IT-alan työpaikkaa ja sain vastauksena pyynnön tehdä muutaman koodaustehtävän. Aika koulutason juttuja siis, pitänee tehdä hieman parempi kuin "Ok" -suoritus

 

[kjns]

Jännitystä ilmassa, hain ensimmäistä IT-alan työpaikkaa ja sain vastauksena pyynnön tehdä muutaman koodaustehtävän. Aika koulutason juttuja siis, pitänee tehdä hieman parempi kuin "Ok" -suoritus

Kannattaa ainakin kiinnittää vahvasti huomiota siihen koodin loogiseen puoleen, siisteyteen ja kommentointiin. Älä lähde turhaan keulimaan tarpeettomilla koukeroilla vaan pidä homma ytimekkäänä. Mitä vähemmällä koodilla saat asian ratkaistua niin sen parempi, mutta tee sen näköistä koodia että haluat myydä itsesi sillä työnäytteellä töihin sinne taloon. Kommentointi sille tasolle, että kuka sitä koodia ikinä lukeekaan tajuaa sieltä mitä teet ja miksi

 

[Paapaa]

Joo, tyylisäännöt kuntoon, järkevät nimet kaikelle nimettävälle, yhdenmukainen ulkoasu (jos Web-juttuja, Prettier käyttöön?). Looginen helposti seurattava koodi on kultaa. Ei kannata mikro-optimoida. Kommenttejakaan ei kannata liikaa viljellä (tässä ehkä kielikohtaisia kulttuurieroja). Selkeä koodi voi korvata kommentin.

 

[Tach]

Joo, tyylisäännöt kuntoon, järkevät nimet kaikelle nimettävälle, yhdenmukainen ulkoasu (jos Web-juttuja, Prettier käyttöön?). Looginen helposti seurattava koodi on kultaa. Ei kannata mikro-optimoida. Kommenttejakaan ei kannata liikaa viljellä (tässä ehkä kielikohtaisia kulttuurieroja). Selkeä koodi voi korvata kommentin.

Tehtävä on aika vapaamuotoinen, eli siinä saa tuoda esiin fronttiosaamista, bäkkiosaamista, molempia tai sitten jotain muuta. Tehtävän voisi kyhätä kasaan 15 minuutissa javascriptillä jos haluaisi, mutta teen silti hieman teknisemmän toteutuksen toisella ohjelmointikielellä. Pyrin pitämään koodin selkeänä ja kommentoimaan avainasioita.

Hakusessa siis junnudevaajan paikka, ja hakemuksessa painotin halua ennenkaikkea päästä oppimaan tekemään asioita oikeasti. Minulla ei ole mitään käsitystä koodaamisesta tuotannollisesti, vaikka kokemusta IT alalta löytyy vuosikaudet järjestelmämäärittelyjen osalta. Tekee vaan mieli vaihtaa koodauspuolelle kun nykyinen työnantaja ei halua maksaa parempaa palkkaa

 

[Leo Rain]

Hakusessa siis junnudevaajan paikka, ja hakemuksessa painotin halua ennenkaikkea päästä oppimaan tekemään asioita oikeasti. Minulla ei ole mitään käsitystä koodaamisesta tuotannollisesti, vaikka kokemusta IT alalta löytyy vuosikaudet järjestelmämäärittelyjen osalta. Tekee vaan mieli vaihtaa koodauspuolelle kun nykyinen työnantaja ei halua maksaa parempaa palkkaa

Täällä vähän samanlaiset ajatukset, ops-puolelta olisi hinkua hypätä enemmän sen paljon puhutun Devopsin puolelle. Tällä hetkellä työn alla Helsingin Yliopistolta Devops with Docker sekä Full stack open, ennen viime joulua myös muutama osio Data analysis with Pythonia - siitä tosin loppui aika kesken, täytynee jatkaa ensi syksyn kurssilla. Näiden lisäksi sitten omia projekteja lähinnä Pythonilla AWSn päällä, joskopa näillä meriiteillä vielä joskus muutakin kuin raakaa Linux-ylläpitoa pääsisi vääntämään.

 

[Tach]

Täällä vähän samanlaiset ajatukset, ops-puolelta olisi hinkua hypätä enemmän sen paljon puhutun Devopsin puolelle. Tällä hetkellä työn alla Helsingin Yliopistolta Devops with Docker sekä Full stack open, ennen viime joulua myös muutama osio Data analysis with Pythonia - siitä tosin loppui aika kesken, täytynee jatkaa ensi syksyn kurssilla. Näiden lisäksi sitten omia projekteja lähinnä Pythonilla AWSn päällä, joskopa näillä meriiteillä vielä joskus muutakin kuin raakaa Linux-ylläpitoa pääsisi vääntämään.

Python osaaminen tuntuu olevan aika monessa paikkaa hakusessa, ja sen takia keskityn itsekin lähinnä siihen. Toki se osui omaksi valinnaksi kun nykyisessä työssä tulee pythonilla kirjoitettua funktioita, mutta hinku olisi oppia tekemään sillä oikeasti jotain hyödyllistä.

 

[Randomizer]

Täällä vähän samanlaiset ajatukset, ops-puolelta olisi hinkua hypätä enemmän sen paljon puhutun Devopsin puolelle. Tällä hetkellä työn alla Helsingin Yliopistolta Devops with Docker sekä Full stack open, ennen viime joulua myös muutama osio Data analysis with Pythonia - siitä tosin loppui aika kesken, täytynee jatkaa ensi syksyn kurssilla. Näiden lisäksi sitten omia projekteja lähinnä Pythonilla AWSn päällä, joskopa näillä meriiteillä vielä joskus muutakin kuin raakaa Linux-ylläpitoa pääsisi vääntämään.

Jenkins pipelinet tohon päälle vielä.

 

[Paapaa]

Täällä vähän samanlaiset ajatukset, ops-puolelta olisi hinkua hypätä enemmän sen paljon puhutun Devopsin puolelle. Tällä hetkellä työn alla Helsingin Yliopistolta Devops with Docker sekä Full stack open, ennen viime joulua myös muutama osio Data analysis with Pythonia - siitä tosin loppui aika kesken, täytynee jatkaa ensi syksyn kurssilla. Näiden lisäksi sitten omia projekteja lähinnä Pythonilla AWSn päällä, joskopa näillä meriiteillä vielä joskus muutakin kuin raakaa Linux-ylläpitoa pääsisi vääntämään.

Toi on hyvä Docker-kurssi!

Jos et AWS:ää vielä ns. hallitse, niin tuohon kylkeen kannattaa tutustua vaikka AWS:n sertifikaatteihin ja niihin liittyviin koulutuksiin. Serteistä ei ehkä kannata maksaa, mutta niihin tähtäävät kurssit ovat hyviä. Udemystä saa alkaen kymppi, AWS:n omat ovat osin ilmaisia jne. Linux Academyllä on $49/kk paljon eri kursseja ja boonuksena siellä on AWS-sandbox, jossa voi tehdä harjoituksia ilman että laskua tulee senttiäkään lisää. AWS:n free tier on myös hyvä, mutta se sinulla varmaan on.

AWS:n kanssa mielestäni Terraform on ehdoton juttu. Eli sen sijaan, että infra polkaistaan pystyyn klikkailemalla GUI:ssa, se tehdään ohjelmallisesti. Terraform on palveluntarjoajariippumaton eli ei ole rajoittunut AWS:ään (toisin kuin AWS:n oma CloudFormation. Kaikki mahdollinen kuvataan konffikielellä, joka sitten osaa luoda resurssit (esim. EC2-instanssit ja DNS-tietueet) halutunlaisesti suoraan komentoriviltä. Tai kun konffi muuttuu, se osaa tuhota tarvittavat resurssit. Konffi on samalla dokumentaatio infrasta.

Jenkins mainittiin. Hyvä vaihtoehto sille voi olla GitHub Actions. Alkaen ilmainen ja sillä saa todella nätisti CI/CD-pipelinen pystyyn ja integraatio GitHubin kanssa on täydellinen.

 

[voffer]

AWS:n kanssa mielestäni Terraform on ehdoton juttu. Eli sen sijaan, että infra polkaistaan pystyyn klikkailemalla GUI:ssa, se tehdään ohjelmallisesti. Terraform on palveluntarjoajariippumaton eli ei ole rajoittunut AWS:ään (toisin kuin AWS:n oma CloudFormation. Kaikki mahdollinen kuvataan konffikielellä, joka sitten osaa luoda resurssit (esim. EC2-instanssit ja DNS-tietueet) halutunlaisesti suoraan komentoriviltä. Tai kun konffi muuttuu, se osaa tuhota tarvittavat resurssit. Konffi on samalla dokumentaatio infrasta.

Terraform on kyllä hyvä työkalu, mutta tuo palveluntarjoajariippumattomuus ei toki valitettavasti tarkoita sitä, että samaa tai lähes samaa terraform-koodia voisi käyttää ristiin esim. Azuren ja AWS:n välillä.
Eri palveluntarjoajilla on omat providerinsa, joissa komennot tietysti vaihtelevat tarjolla olevien resurssien mukaan.

Eli samalla koodilla ei saa polkaistua pystyyn samanlaista infraa Azureen ja AWS:ään.

 

[zepi]

Terraform on kyllä hyvä työkalu, mutta tuo palveluntarjoajariippumattomuus ei toki valitettavasti tarkoita sitä, että samaa tai lähes samaa terraform-koodia voisi käyttää ristiin esim. Azuren ja AWS:n välillä.
Eri palveluntarjoajilla on omat providerinsa, joissa komennot tietysti vaihtelevat tarjolla olevien resurssien mukaan.

Eli samalla koodilla ei saa polkaistua pystyyn samanlaista infraa Azureen ja AWS:ään.

Olisiko tuohon jotain parempaa työkalua, vai kannattaako luottaa terraformiin jos haluaa mahdollisuuden deployata kumpaan tahansa + rakentaa vain kummallekin palveluntarjoajalle erilliset konffit joita ylläpitää erikseen?

Tietty jos kaipaa esim. S3 storagea, niin miten tuon kanssa kannattaisi toimia?

 

[Paapaa]

Eli samalla koodilla ei saa polkaistua pystyyn samanlaista infraa Azureen ja AWS:ään.

Joo, ei missään nimessä. Hyödyt mielestäni:

• voi yhdistellä eri palveluntarjoajia samaan infraan, eikä tarvitse hirttäytyä yhteen vain siksi, että saisi IaC:n käyttöön (voi esim. siirtää hissukseen sitä infraa uuteen paikkaan)
• voi käyttää IaC:tä
• voi käyttää samaa syntaksia joka paikassa (eri tapa määritellä resurssit, mutta syntaksi sama)

Riippuu sitten palveluntarjoajasta, kuinka hyvä provider on käytettävissä, jos lainkaan. Aika kivasti noita onneksi on tarjolla:

Providers - Configuration Language | Terraform | HashiCorp Developer

An overview of how to install and use providers, Terraform plugins that interact with services, cloud providers, and other APIs.

www.terraform.io

Ja kun periaate on selvillä, niin perusjutut toimivat samalla tavalla eri palvelutarjoajien resursseilla/providerilla.

 

[Paapaa]

Olisiko tuohon jotain parempaa työkalua, vai kannattaako luottaa terraformiin jos haluaa mahdollisuuden deployata kumpaan tahansa + rakentaa vain kummallekin palveluntarjoajalle erilliset konffit joita ylläpitää erikseen?

Tietty jos kaipaa esim. S3 storagea, niin miten tuon kanssa kannattaisi toimia?

Vaatii tietenkin sen, että luo moduulit kummallekin palvelulle. Ja jos niiden moduulien rajapinta on samanlainen, niin sitten provisioiminen kumpaan tahansa menee aika kivuttomasti. Terraform on varmasti hyvä (paras?, ainoa?) ratkaisu tuollaiseen parin pilvipalvelun yhdistämiselle.

Sorry, OT. Kuuluis toiseen ketjuun tämä. Mutta hyvä näitä on opetella alaa silmällä pitäen!

 

[Randomizer]

Toinen hankalampi vaihtoehto on sitten opetella jokaiselle providerille niiden natiivit IaC työkalut, esim. CloudFormation AWS:lle. Terraformissa ei ole myöskään välttämättä kaikkia samoja ominaisuuksia kuin nuissa natiiveissa kielissä. Azureen en ole tutustunu, en tiedä sen konffausmenetelmiä. Itse käytän kyllä Terraformia, lähinnä AWS:ään ja OpenStackiin. Puppetilla sitten serverit.

 

[dropadrop]

Vain ihmiset jotka eivät ole oikeasti infrasta huolehtineet (siis päivystystä SLA’lla) kuvittelevat että IaC tai ylipäätänsä pilvi jotenkin tarkoittaa, ettei infrasta tarvitse huolehtia.

Se mitä IaC käytännössä tekee on, että ne samat tyypit kuin ennen ei välttämättä voi siitä huolehtia, ellei ne ollut apinoita jotka seuraa jonkun muun tekemää runbookkia.

Kyllä softa pilvessäkin kaatuu tai menee jumiin ihan niinkuin muuallakin. Sit vaan kun ympäristö on määritelty koodina niin ylläpitäjät ymmärtävät siitä suunilleen yhtä paljon kuin koodin kirjastoista aikaisemmin.

Meillä toi siirtyminen on tähän mennessä mennyt yllättävän kivuttomasti. Edelleen kyllä vuosienkin jälkeen ne IaC’n alkuperäiset hyödyt on musta toteuttamatta... ”Kato kun tää luo vaan automaattisesti uusia memcached instansseja kun kuorma kasvaa” -> tosin cloudformation määritysten, konffien, jobien ja putkien toteutukseen meni kuukaus kun sen olis tehnyt käsin parissa tunnissa... Eikä kasvua ole odotettavissa niin paljoa että koskaan tarvis skaalautua... Eikä säästöäkään tullut infralle kun ne ”kalliit” serverit on nyt korvattu AWS’llä jonka lasku on miljoonia vuodessa.

 

[Randomizer]

Vain ihmiset jotka eivät ole oikeasti infrasta huolehtineet (siis päivystystä SLA’lla) kuvittelevat että IaC tai ylipäätänsä pilvi jotenkin tarkoittaa, ettei infrasta tarvitse huolehtia.

Se mitä IaC käytännössä tekee on, että ne samat tyypit kuin ennen ei välttämättä voi siitä huolehtia, ellei ne ollut apinoita jotka seuraa jonkun muun tekemää runbookkia.

Kyllä softa pilvessäkin kaatuu tai menee jumiin ihan niinkuin muuallakin. Sit vaan kun ympäristö on määritelty koodina niin ylläpitäjät ymmärtävät siitä suunilleen yhtä paljon kuin koodin kirjastoista aikaisemmin.

Meillä toi siirtyminen on tähän mennessä mennyt yllättävän kivuttomasti. Edelleen kyllä vuosienkin jälkeen ne IaC’n alkuperäiset hyödyt on musta toteuttamatta... ”Kato kun tää luo vaan automaattisesti uusia memcached instansseja kun kuorma kasvaa” -> tosin cloudformation määritysten, konffien, jobien ja putkien toteutukseen meni kuukaus kun sen olis tehnyt käsin parissa tunnissa... Eikä kasvua ole odotettavissa niin paljoa että koskaan tarvis skaalautua... Eikä säästöäkään tullut infralle kun ne ”kalliit” serverit on nyt korvattu AWS’llä jonka lasku on miljoonia vuodessa.

Kyllä suurin hyöty pilveen siirtymisessä on se että sulla ei tuu käytännössä koskaan enää "sori joudutte odottamaan, meidän resurssit on käytetty". Tuota on tullut nähtyä ja jos devaajat joutuvat odottamaan esim. 15 min ylimääräistä koska pull request jonottaa niin se tulee aika saatanan kalliiksi pitemmän päälle. Toisekseen fyysisissä servereissä sulla saattaa tulla paljon helpommin single-point-of-failure pisteitä joka on aina todella huono homma. Puhumattakaan siitä server management säädöstä joka vie helvetisti aikaa. Esimerkiksi pelkkä kernelien päivitys fyysisissä laitteissa vaatii aika tarkan suunnitelman ja käyttökatkovälit. Puhumattakaan tietoturvasäädöistä, palomuurista, laiterikoista, monitoroinnin rakentamisesta, jne. Kaikki em. asiat helpompaa/ei tarvitse huolehtia pilvipalveluissa.

IaC:ista eri mieltä myös. Ensinnäkin, sä tiedät aina mitkä konffit sulla on käytössä. Kun esimerkiksi tulee ongelmatilanteita, tiedät tasan tarkkaan minkälaiset ne sun konffit on siinä koko sun stäkissä, ongelmanratkonta on esimerkiksi huomattavan paljon helpompaa niihin törmätessä. Toisekseen IaC mahdollistaa että infra menee lähemmäksi devaajia, jolloin pienemmissä projekteissa sä et tarvi erikseen ylläpitäjiä, eikä serverituusaajia lainkaan joka on taas aika iso säästö. Infra koodiksi ei myöskään ole mikään valtava urakka jos sun tiimissä on edes hieman asiaa osaavia jannuja hommissa.

 

[edup]

Kyllä suurin hyöty pilveen siirtymisessä on se että sulla ei tuu käytännössä koskaan enää "sori joudutte odottamaan, meidän resurssit on käytetty".

Microsoft tässä taannoin juuri ilmoitti että "sori, Azure on loppu", aiheuttaen juuri kaikenlaista vastaavaa. Ja sitten kun siellä pilvessä ollaan niin kovin herkästi ei enää lähdetä fyysisiä koneita pystyttelemään.

 

[Randomizer]

Microsoft tässä taannoin juuri ilmoitti että "sori, Azure on loppu", aiheuttaen juuri kaikenlaista vastaavaa. Ja sitten kun siellä pilvessä ollaan niin kovin herkästi ei enää lähdetä fyysisiä koneita pystyttelemään.

Sitte sä voit skaalata AWS:ään. Veikkaan että noi pilvikatkokset ovat huomattavan harvinaisia silti vrt. omien servereiden mahdollisiin ongelmiin.

 

[edup]

Sitte sä voit skaalata AWS:ään. Veikkaan että noi pilvikatkokset ovat huomattavan harvinaisia silti vrt. omien servereiden mahdollisiin ongelmiin.

Teknisesti voisikin skaalata. Reaalielämässä ei. Ja kyllä, katkokset on harvinaisempia, ei siitä mihinkään pääse.

 

[Randomizer]

Teknisesti voisikin skaalata. Reaalielämässä ei. Ja kyllä, katkokset on harvinaisempia, ei siitä mihinkään pääse.

Tietysti voit myös rakentaa hybridiratkaisun jossa sulla on sekä on-prem- ,että pilviresursseja. Tällöin molemmat tukevat toisiaan. Ja kustannustehokkaimman ratkaisun saat sillä että aina ensin skaalataan fyysiset resurssit täyteen ja vasta sitten skaalataan pilveen.

 

[edup]

Tietysti voit myös rakentaa hybridiratkaisun jossa sulla on sekä on-prem- ,että pilviresursseja. Tällöin molemmat tukevat toisiaan. Ja kustannustehokkaimman ratkaisun saat sillä että aina ensin skaalataan fyysiset resurssit täyteen ja vasta sitten skaalataan pilveen.

Nää vaihtoehdot on kyllä hyvin tiedossa. Mutta monissa (useimmissa?) paikoissa ei oo realismia se että tehdään multicloudia tai hybridiä. Ei vaan oo kustannustehokasta palkata sitä osaamista että kaikki rullaisi kunnolla, vaan fiksumpaa keskittyä yhteen alustaan. Se sitten toki välillä saattaa aiheuttaa ongelmia, mutta ei se multi/hybrid-cloudikaan mitään pelkkää juhlaa ole. Ja etenkään se että sulla on yksi yksittäinen ongelma nyt, ei ole peruste lähteä pystyttämään multicloudia tai hybridiratkaisuja, kun niidenkin kanssa menee oma aikansa että ne saadaan sellaiseen kuntoon että niistä on apua.

Mutta joo, yleisesti ottaen kannattaa opetella noita pilvialustoja. Jos kontitat sovelluksesi niin hyvin samankaltaisella pilviarkkitehtuurilla ne pyörii ympäristössä kuin ympäristössä.

 

[Paapaa]

Mutta joo, yleisesti ottaen kannattaa opetella noita pilvialustoja. Jos kontitat sovelluksesi niin hyvin samankaltaisella pilviarkkitehtuurilla ne pyörii ympäristössä kuin ympäristössä.

Juuri näin. Noiden osaaminen jollain tasolla on ihan hyvä valttikortti kun hakee uuteen työpaikkaan. Ja onneksi noita voi harjoitella halvalla/ilmaiseksi. AWS:n Free Tier antaa vuodeksi aika kivat eväät treenailuun. Muilla pilvipalveluilla on varmaan vastaavia. Domain maksaa sen 9e/vuosi. Pelkän VPS:nkin (Terraform-tuella) saa parilla eurolla kuussa. Eli onneksi kätensä saa upotettua saveen ilman isoa laskua.

 

[Randomizer]

Nää vaihtoehdot on kyllä hyvin tiedossa. Mutta monissa (useimmissa?) paikoissa ei oo realismia se että tehdään multicloudia tai hybridiä. Ei vaan oo kustannustehokasta palkata sitä osaamista että kaikki rullaisi kunnolla, vaan fiksumpaa keskittyä yhteen alustaan. Se sitten toki välillä saattaa aiheuttaa ongelmia, mutta ei se multi/hybrid-cloudikaan mitään pelkkää juhlaa ole. Ja etenkään se että sulla on yksi yksittäinen ongelma nyt, ei ole peruste lähteä pystyttämään multicloudia tai hybridiratkaisuja, kun niidenkin kanssa menee oma aikansa että ne saadaan sellaiseen kuntoon että niistä on apua.

Mutta joo, yleisesti ottaen kannattaa opetella noita pilvialustoja. Jos kontitat sovelluksesi niin hyvin samankaltaisella pilviarkkitehtuurilla ne pyörii ympäristössä kuin ympäristössä.

Kuten perustelin aikaisemmin syitä:

"Kyllä suurin hyöty pilveen siirtymisessä on se että sulla ei tuu käytännössä koskaan enää "sori joudutte odottamaan, meidän resurssit on käytetty". Tuota on tullut nähtyä ja jos muutama sata devaajaa joutuu odottamaan esim. 15 min ylimääräistä koska pull request jonottaa niin se tulee aika saatanan kalliiksi pitemmän päälle. Toisekseen fyysisissä servereissä sulla saattaa tulla paljon helpommin single-point-of-failure pisteitä joka on aina todella huono homma. Puhumattakaan siitä server management säädöstä joka vie helvetisti aikaa. Esimerkiksi pelkkä kernelien päivitys fyysisissä laitteissa vaatii aika tarkan suunnitelman ja käyttökatkovälit. Puhumattakaan tietoturvasäädöistä, palomuurista, laiterikoista, monitoroinnin rakentamisesta, jne. Kaikki em. asiat helpompaa/ei tarvitse huolehtia pilvipalveluissa."

Lisätään myös vielä se että sun omia fyysisiä servereitä sä et saa koskaan hyödynnettyä 100% koska nekin idlaavat paljon aika ajoin. Silti sä maksat räkkimaksuja, sähkömaksuja ja palvelumaksuja mitä lie niistä servereistä.

Se yks/kaks pilvijamppaa palkattuna/ja/tai koulutettuna nykyiset infrajampat maksaa itsensä hyvin nopeasti takaisin. Toki hybridimallissa sä et pääse serverisäädöstä eroon, ellet paketoi niitä johonkin sisäpilveen(esim. OpenStack) ja annat IT-osaston hoitaa sen fyysisen infran siellä alla.

 

[dropadrop]

Joo, toki yksinkertaistin yllä. Lisäksi, ei kai kukaan ole ajanut fyysisiä servereitä aikoihin vaan vmwarea yms (ainakin jos on tuhansia servereitä).

Se mikä on ollut harvinaisempaa on ehkä ollut vmwaren apien / SDK’n tehokas käyttö, koska vmware on ollut IT’n takana.

Mä leikin joskus vmwaren SDK’n kanssa ja sehän oli tosi hauska ja helppo. En vaan koskaan nähnyt että sitä olis annettu devaajille.

Enkä mä todellakaan ole vastaan AWS’ää. Mulla on mun ”omistamia” tuotteita ajossa siellä ja erityisesti natiivisti suunnitellut palvelut toimivat loistavasti.

 

[Lexy]

Side notena ja ihan jokaiselle infra/pilvikaverille ettei mene liian offtopiciksi (tietoturva kun mainittu):
Pilvessä tietoturva ei saisi olla se mörkö millä siirtymää lykätään. Ne mahdollisuudet mitä eri pilvialustat tarjoaa (AWS, Azure, Google) on lähtökohtaisesti ihan eri tasoa kuin mihin ne Pertti-Saarat niiden fyysisten kanssa pystyy. Nuo firmat lisäksi puskee kyvykkyyksiä sellaista vauhtia, että siinä ei pysy edes mukana.

Mutta...tämä vaatii syvää ymmärrystä mitä kaikkea on mahdollista käyttää. Tietoturva on muutakin kuin palomuureja, konfiguraatioita tai haavoittuvuuksien skannauksia. Aivan helvetin usein näkee kuinka pilviasiantuntija on kyllä palvelut saanut päälle ja nätisti pyörimään mutta ne kyvykkyydet mitä tietoturvanäkökulmasta on kytketty on aivan umpisurkeita verrattuna siihen mitä voisi tai tulisi olla. Isoin syy on osaamattomuus ja ihan se, että niitä tietoturvakilkkeitä tulee jatkuvasti lisää. Osa syyllinen on myös, se että tietoturvakaverit on jääneet pahasti jälkeen.

Dilemma kaksi mitä tulee vastaan aivan liikaa on se, että kuvitellaan että vastuu tietosuojasta/tietoturvasta katoaa koska pilvi. Ei se mihinkään katoa, mutta muoto vaan muuttuu. Ei se MS, AWS tai esim. Google sinulle niitä asetuksia laita vastaamaan teidän riski-/tavoitetasoa. He vastaavat fyysisen ja osittain laite-/verkkotason tietoturvasta mutta tämän on heidän itsensä suojaksi - ei asiakkaan. Palvelun pystyttäjä on vastuussa siitä ympäröivästä tietoturvasta.

Eli kun pilvestä puhutaan niin ottakaa mukaan/palkatkaa/lainatkaa konsulttia joka on pilvitietoturvan asiantuntija (ja ei, ei ole sellaistakaan joka tietää AWS:stä, Azuresta ja GCP:stä kaiken - myös se mihin on fokusoitunut sanelee paljon). Se, että on infratietoturvan syväosaaja ei ole tae, että pilvitietoturvalu onnistuu. Nöyrä pyyntö onkin antaa tietoturva tietoturvasta vastaavien harteille eikä yrittää "säätää vähän sinne päin".

Jos firmassa muutenkin puhutaan ns. tietoturvan yleismiehestä joka hoitaa kaiken sovellustietoturvasta "strategiseen" suunnitteluun niin suosittelen vaihtamaan firmaa nopeasti - nämä tulee jossakin viaheessa epämukavasti vastaan kaikille hommien parissa tekeville koska ei ole sellaista superjumalaa joka hoitaa kaiken mitä kunnolinen tietoturva pitää sisällään.

 

[Paapaa]

Ja nämähän on siis vain siinä varsinaisten hommien lisänä.

Sanoisin, että infran luominen, konffaaminen, ylläpitäminen ja kehittäminen on myös ns. varsinaista hommaa.

Tietenkin joku muu voi tykätä

Kuulostaa lähinnä siltä, että olet ihan väärässä työtehtävässä tekemässä jotain, mistä et lainkaan pidä? Tuossa tilanteessa ehdottomasti kannattaa tuulettaa ja päästä kiinnostavien hommien ääreen.

 

[kaarlos]

Meillä on ainakin tuo devops vs. tuotteiden devaustiimien välinen vastuu jakautunut hyvin määritellyillä järjestelmän laajuisilla ei-toiminnallisilla vaatimuksilla. Niin pitkään kuin kaikkien tuotetiimien kilkkeet toteuttavat kaikki mikropalveluita koskevat NFR:t, on niitä mahdollista laittaa ajoon devops jengin tuottamien deployment-palikoiden kautta.

Tuotteita vääntävien tiimien vastuulle jää siis käytännössä toimivan microservice-infran edellyttävät vaatimukset (health checkit, backpressure, horizontal scalability, service discovery, configurability, ...) sekä jonkinlainen suorituskykytestaus ajoympäristön sizingia varten. Devops porukka kehittää työkaluja sulavaa devausta sekä sovellusten / konfiguraatioiden hallintaa varten.

 

[edup]

Monimutkaisemmassa softassa on ihan tarpeeksi tekemistä, ettei kiinnosta siihen konttiverkkojen, VPC yhdistelmien, DNS:n, security grouppien, serverless palvelujen, cloudwatch monitoroinnin, RDS:n, load balancerien, skaalausparametrien, verkkolevyjen (EBS, EFS), kaikkien näiden yhdistelmien ja konffailujen, Terra/Cloudform skriptien vääntämiseen ja jokaisen parametrin tuunaamiseen lisäksi hukata lopulta rajallista kapasiteettiaan. Ja nämähän on siis vain siinä varsinaisten hommien lisänä.

Kukaan muu kuin softan kehittäjä ei tiedä mitä sen core ja muistivaatimukset on. Se että kehittäjät pystyy sen käytännössä yhtenä konffi-filuna määrittelemään on vain plussaa.

 

[jokumuu]

Kukaan muu kuin softan kehittäjä ei tiedä mitä sen core ja muistivaatimukset on. Se että kehittäjät pystyy sen käytännössä yhtenä konffi-filuna määrittelemään on vain plussaa.

Ei, softan kehittäjällä ei tyypillisesti ole hajuakaan suorituskyky ja muistivaatimuksista. Ne on hallussa teoriassa, mutta käytännön tietää sitten QA osasto - ja siellä suorituskykytestaajat.
Tämä on vain yksi syy siihen, miksi devopsin pitäisi mielestäni olla QA taustaista, ei Dev taustaista, tärkein syy on toki se, että QA taustaisilla ihmisillä on toistettavuus ja järjestelmällisyys hallussa ja Devops on ennenkaikkea tätä. Lisäksi Devopsin ydintä on nimenomaan testaus.

Mutta meitä on toki moneen junaan, ymmärrän kyllä, että monesti softan laatu ei ole top3 kriteereissä, nopeus markkinalle, myytävyys ja hype menevät melkein aina ohi. Tällöin voi laittaa ne devit tekemään opsia ja deploymenttiäkin.

 

[edup]

Ei, softan kehittäjällä ei tyypillisesti ole hajuakaan suorituskyky ja muistivaatimuksista. Ne on hallussa teoriassa, mutta käytännön tietää sitten QA osasto - ja siellä suorituskykytestaajat.
Tämä on vain yksi syy siihen, miksi devopsin pitäisi mielestäni olla QA taustaista, ei Dev taustaista, tärkein syy on toki se, että QA taustaisilla ihmisillä on toistettavuus ja järjestelmällisyys hallussa ja Devops on ennenkaikkea tätä. Lisäksi Devopsin ydintä on nimenomaan testaus.

Mutta meitä on toki moneen junaan, ymmärrän kyllä, että monesti softan laatu ei ole top3 kriteereissä, nopeus markkinalle, myytävyys ja hype menevät melkein aina ohi. Tällöin voi laittaa ne devit tekemään opsia ja deploymenttiäkin.

Kuulostaa aika pahasti päälle liimatulta QA:lta jos sitä ei lasketa softan kehitykseen. Jos sen irrottaa tuolla tavalla täysin irralliseksi kokonaisuudekseen, niin voi olla varma että jatkossakin tulee paskaa.

 

[Paapaa]

Ei, softan kehittäjällä ei tyypillisesti ole hajuakaan suorituskyky ja muistivaatimuksista.

Wut? Softan kehittäjä ei tyypillisesti tiedä, millaisia vaatimuksia softalle on asetettu? Tuo kuulostaa todella oudolta. Miksei devaaja ota tästä selvää? Miksei vaatimuksia kommunikoida devaajille, jos sellaiset on olemassa?

Vai meinasitko, että kehittäjällä ei ole hajua, mitä vaatimuksia softalla on (millaisen ympäristön vaatii toimiakseen kunnolla)? Tämäkin kuulostaa aika oudolta. Toki jos homma on ulkoistettu testaajille, niin noin varmaan voi käydä. Eli ensin tehdään peli, sitten joku alkaa testata ja katsotaan, millaisissa koneissa se oikein pyörii? Vähintään outo tapa toimia. Luulisi, että kehitysvaiheessa on jonkinlainen ajatus siitä, missä sitä softaa tullaan käyttämään, mikä on sen käyttäjäryhmä, ja sen mukaan sitten asetetaan vaatimuksia.

Tai sitten tarkoitit jotain ihan muuta, mitä en tajua, joten avaatko lisää.

 

[Bladekill]

Ei, softan kehittäjällä ei tyypillisesti ole hajuakaan suorituskyky ja muistivaatimuksista.

Olen kyllä itsekin nyt aika hämmentynyt tästä. Oliko tämän tarkoitus olla sarkasmia?

 

[zepi]

Wut? Softan kehittäjä ei tyypillisesti tiedä, millaisia vaatimuksia softalle on asetettu?

Ei kai tässä ollut vaatimuksista puhetta vaan siitä, että (kaikilla) devaajilla ei ole välttämättä kovinkaan hyvää näppituntumaa, että miten erilaiset ratkaisut käyttäytyvät testijärjestelmien ulkopuolella ihan vaan koska heillä ei ole kokemusta ylläpitäämisestä tai ongelmanratkaisusta tuotantojärjestelmissä. Tietty kokeneilla on enemmän kokemusta, kun ovat saaneet uransa aikana mitä erikoisempia bugirapsoja ja tukipyyntöjä.

Usein vaatimukset on asetettu tasolle X, mutta sitten myyjä menee myymään tuotteen käyttöön Y, jossa joku osa-alue voi olla ihan eri tavalla skalautuva.

Esim. itse tullut joskus pähkäiltyä ongelmia kun myytiin jotain venäläisille ja alkuperäiset suunnittelijat eivät olleet keksineet, että synkroniset kirjoitukset Moskovassa olevaan tietokantaan Vladivostokista ovat "hieman" hitaampia kuin testiympäristöissä kahden 100km etäisyydellä toisistaan olevan datacenterin välillä. Tai että joku windows-levyjako johon joku workflow perustuu, toimii hienosti datacenterin sisällä tai kahden lähekkäin olevan datacenterin välillä, mutta tiedonsiirtonopeus romahtaa ihan täysin kun latenssia on tarpeeksi tjsp.

Joo joo, on georedundancy suppport ja tuetaan hajautettua infraa. Ja kohta Elon Musk soittaa, että eihän tää paska toimi kun etäkonttori on Marssissa. Ja huoltomiestäkään ei voi lähettää kahteen vuoteen.

Eikä tämä ole sinänsä kenenkään vika.

 

[jokumuu]

Wut? Softan kehittäjä ei tyypillisesti tiedä, millaisia vaatimuksia softalle on asetettu? Tuo kuulostaa todella oudolta. Miksei devaaja ota tästä selvää? Miksei vaatimuksia kommunikoida devaajille, jos sellaiset on olemassa?

Vai meinasitko, että kehittäjällä ei ole hajua, mitä vaatimuksia softalla on (millaisen ympäristön vaatii toimiakseen kunnolla)? Tämäkin kuulostaa aika oudolta. Toki jos homma on ulkoistettu testaajille, niin noin varmaan voi käydä. Eli ensin tehdään peli, sitten joku alkaa testata ja katsotaan, millaisissa koneissa se oikein pyörii? Vähintään outo tapa toimia. Luulisi, että kehitysvaiheessa on jonkinlainen ajatus siitä, missä sitä softaa tullaan käyttämään, mikä on sen käyttäjäryhmä, ja sen mukaan sitten asetetaan vaatimuksia.

Tai sitten tarkoitit jotain ihan muuta, mitä en tajua, joten avaatko lisää.

Tyypillisesti koodarin näkemys rajoittuu siihen moduuliin tai sen osaseen jota oltiin säätämässä. Tämän osan vaatimukset ovat varmasti hyvin hanskassa, mutta dependenssit sitten muualle ovat hämärän peitossa. Jos puuhaillaan vähänkin monimutkaisemman softan kanssa hiemankaan isommassa organisaatiossa, niin tämä on arkipäivää.
Siksi on QA. QA voi toki olla (ja pitääkin olla) osa kehitystä siten, että osallistuvat koodin tekemiseen, mutta kyllä tuotteen laadun varmistukseen pitää olla vastuullinen organisaatio (vaikka yksi ihminen vaihtuvalla hatulla jos ei muuta).
Monessa paikassa lisäksi kehittäjien testausvastuu tuntuu rajoittuvan yksikkötestaamiseen. Onhan tämä toki tärkeää, mutta ei sillä kokonaisuutta testata. Kun mennään monimutkaisempiin kokonaisuuksiin, aikaa rupeaa palamaan ihan eri tavalla verraten aiempaan, joten monesti on ihan järkevääkin laittaa testaamisen ammattilainen asialle ja käyttää sen kehittäjän ammattitaitoa sitten johonkin, jossa tämä on tuottavimmillaan.

Ja ei QA:n olemassaolo tarkoita mitään vesiputousmallia. Tuotetta voi kyllä testata vaikkei se olisi valmiskaan.

 

[Tach]

Osaako kukaan sanoa onko Kela millainen työnantaja IT-puolella? Nihkeästi löytyy netistä tietoa nimenomaan IT puolesta. Onko millaiset työolot/palkkaus?

 

[burmanm]

Wut? Softan kehittäjä ei tyypillisesti tiedä, millaisia vaatimuksia softalle on asetettu? Tuo kuulostaa todella oudolta. Miksei devaaja ota tästä selvää? Miksei vaatimuksia kommunikoida devaajille, jos sellaiset on olemassa?

Yleensä sellaisia ei ole edes olemassa, jos tehdään usealle asiakkaalle. Tällöin tehdään vain oletuksia "no kai se asiakas nyt käyttää edes läppäritasoista rautaa". Lopputuloksena on jotain aivan muuta, itsekin olen useamman bugiraportin käynyt läpi ettei jokin operaatio koskaan valmistu. Sitten kun katsotaan logia niin siellä on tapauksia kuten SAN-ympäristö tai AWS jossa saadaan diskettiaseman vauhdilla luettua dataa. Ei ihme että tietokantaoperaatioissa kestää.

Aina pitäisi toki olettaa että hakee 80-luvun raudan kaapista ja softan pitää silläkin toimia. Se tosin ei kiinnosta niitä jotka odottavat että softa tulee myyntiin. Jotain yleensä näissäkin asioissa mennään olettamuksilla, jotka jokaisella osapuolella on erilaiset. Eikä kyse ole ikinä pelkästään suorituskyvystä, vaan kaikesta softaan liittyvästä - suurin osa spekseistä sisältää aina oletuksia ja epämääräisyyksiä.

 

[Musashi]

Osaako kukaan sanoa onko Kela millainen työnantaja IT-puolella? Nihkeästi löytyy netistä tietoa nimenomaan IT puolesta. Onko millaiset työolot/palkkaus?

Pari tuttua vaihtanut hektisestä konsulttimaailmasta Kelalle. Jos konsulttielämä on tuttua, niin Kela on sitten päinvastainen: palkka huonompi, kiirettä ei ole, mennään by-the-book, byrokratian määrä on huima, kankea, pitkät lomat...

Eli on hyvää ja on huonoa. Ilmeisen tyypillinen virkamiesmeininki.

Pikaedit: nuo siis tuttujen kommentteja mitä ovat kertoneet. Omakohtaista kokemusta ei ole.