Data Engineer or die: yhden kehittäjän tarina

Joulukuun alussa tein kohtalokkaan virheen ja tein käännekohdan elämässäni kehittäjänä ja siirryin tietotekniikan (DE) tiimiin yrityksen sisällä. Tässä artikkelissa jaan joitain havaintoja, joita tein kahden kuukauden aikana työskennellessäni DE-tiimissä.

Data Engineer or die: yhden kehittäjän tarina

Miksi tietotekniikka?

Matkani DE:hen alkoi kesällä 2019, jolloin me Xneg mennään Hajautetun laskennan koulu, ja siellä saavutin valaistumisen. Aloin kiinnostua aiheesta, opiskella algoritmeja ja jopa niitä kirjoittaa, ja mietin sitten sovellusaluetta ja huomasin nopeasti, että käytännön sovellus yrityksessämme ovat hajautetut tietokannat.

Mitä tiimimme tarkalleen tekee? Me, kuten kaikki muodikkaat pojat ja tytöt, haluamme tulla tietovetoiseksi yritykseksi. Ja jotta tämä olisi mahdollista, meidän on rakennettava ainakin luotettava varasto, josta voidaan rakentaa kaikki yrityksen tarvitsemat raportit. Mutta tärkeintä on, että tämän tallennustilan tietoihin tulee luottaa. Lisäksi näiden tietojen avulla sinun on kyettävä palauttamaan järjestelmän tila hetkellä t. Kaikkea tätä monimutkaistaa se, että elämme uudessa uljaassa mikropalvelujen maailmassa, ja tämä ideologia tarkoittaa, että jokainen palvelu toteuttaa oman pienen toiminnallisuutensa, sen tietokanta on oma asia ja se voi poistaa sen ainakin joka päivä, mutta klo. samalla meidän on kyettävä vastaanottamaan ja prosessoimaan palvelun tila.

Jos haluat olla tietoihin perustuva, ryhdy ensin tapahtumalähtöiseksi

Ei niin yksinkertaista. Tapahtumat ovat erilaisia, ja kehittäjä ja tietoteknikko katsovat niitä eri tavalla. Tapahtumista puhuminen on erillisen artikkelin aihe, joten en mene siihen tässä. Lisäksi tällainen artikkeli on jo olemassa kirjoitin tietty Martin Fowler, en ota pois hänen laakereitaan, anna hänen tulla myös kuuluisaksi.

Yleisesti ottaen on paljon ajateltavaa, ja siksi tämä alue on houkutteleva. Sattuu vain niin, että yrityksessämme tietoinsinööri on paljon laajempi vastuualue kuin pelkkä ETL/ELT-putkien kirjoittaja (jos et tiedä mitä nämä lyhenteet tarkoittavat, tule tavata. Kontekstikohtaisena mainontana).

Käsittelemme tallennusarkkitehtuuria, tiedon mallintamista, tietoturvaan liittyviä asioita ja tietysti itse putkistot. Meidän on myös varmistettava, että toisaalta läsnäolomme ei ole kovin rasittavaa tuotekehittäjille ja että heidän huomionsa tulee mahdollisimman vähän häiritä vaatimuksistamme, kun leikataan uusia ominaisuuksia järjestelmään, ja toisaalta täytyy tarjota ne kätevästi analyytikoille ja BI-tiimille tallennettuihin tietoihin. Näin me elämme.

Vaikeuksia siirtyessä kehityksestä

Ensimmäisenä työpäivänäni kohtasin useita vaikeuksia, jotka haluan jakaa kanssasi.

1. Ensimmäinen asia, jonka näin, oli tulingin ja joidenkin käytäntöjen puuttuminen. Otetaan esimerkiksi koodin peitto testeillä. Meillä on kehitteillä satoja testauskehyksiä. Tietojen kanssa työskennellessä kaikki on monimutkaisempaa. Kyllä, voimme testata ETL-putkia testitiedoilla, mutta meidän on tehtävä kaikki manuaalisesti ja etsittävä ratkaisuja jokaiseen tapaukseen. Tämän seurauksena testin kattavuus on paljon huonompi. Onneksi on olemassa toinenkin palautekerros, joka on seurannan ja lokien muodossa, mutta tämä edellyttää jo ennemmin reaktiivista kuin ennakoivaa reagointia, mikä on raivostuttavaa ja ahdistavaa.

2. Maailma DE:n näkökulmasta ei ole ollenkaan sitä miltä näyttää tavalliselle tuotekehittäjälle (no, lukija ei tietenkään ole sellainen, ja hän tietää jo kaiken, mutta minä en tiennyt ja nyt olen sotkeen sitä). Kehittäjänä luon oman mikropalvelun, laitan tiedot [valintasi tietokantaan], tallennan osavaltioni sinne, hankin jotain tunnuksella ja se on hyvä. Palvelu on hidasta, tilaukset ovat hämmentäviä, siinä kaikki. He pyytävät minua etsimään tilaani toisesta palvelusta, joten heitän tapahtuman johonkin RabbitMQ: hen ja siinä kaikki. Ja tässä palasimme jälleen edellä kuvattuun tapaukseen.

Se, mitä palvelu tarvitsee operatiiviseen työhön, ei sovi meille historiatietoihin, joten alkaa kysymys palvelusopimusten uudelleenkäsittelystä ja tiiviistä yhteistyöstä kehitystiimien kanssa. Et voi edes kuvitella, kuinka monta tuntia kesti sovittuamme: millainen Tapahtumavetoinen hän on yrityksessämme.

3. Sinun täytyy ajatella omalla päällään. Ei, en tarkoita sitä, että kehittäjät eivät ajattele (vaikka kuka minä olen puhuakseni kaikkien puolesta), kyse on vain siitä, että tuotekehityksessä on usein jo jonkinlainen arkkitehtuuri ja leikkaat erilaisia ​​sekoitusta ruuhkasta. Tietysti tämä vaatii suunnittelua ja ajattelua, mutta tämä on stream-työtä, jossa suurin ongelma on yksinkertaisesti tehdä se hyvin ja tehokkaasti.

Meille se ei ole niin yksinkertaista, koska erilaisten järjestelmäkomponenttien siirtäminen lämpimästä ja viihtyisästä monoliitista villin mikropalveluviidakon maailmaan ei ole niin yksinkertaista. Kun palvelu alkaa ruiskuttaa tapahtumia, sinun on harkittava uudelleen tallennustilan täyttämisen logiikkaa, koska tiedot näyttävät nyt erilaiselta. Tässä sinun täytyy ajatella paljon ja perusteellisesti, ei enää kehittäjänä, vaan tietoinsinöörinä. Se on tavallinen tarina, kun vietät päiviä vihkon ja kynän kanssa tai tussilla taululla. Se on erittäin vaikeaa, en halua ajatella, rakastan myös tuotantoa.

4. Ehkä tärkein asia on tieto. Mitä teemme, kun meillä ei ole tietoa? Kuka sanoi stackoverflow? Vie tämä henkilö ulos huoneesta. Käymme lukemassa asiakirjoja, aiheeseen liittyviä kirjoja, ja siellä on myös yhteisö, joka järjestää foorumeita, tapaamisia ja konferensseja. Dokumentaatio on hienoa, mutta valitettavasti se voi olla epätäydellinen. Käytämme Cosmos DB:tä useissa projekteissa. Onnea tämän tuotteen asiakirjojen lukemiseen. Kirjat ovat ainoa pelastus, onneksi niitä on olemassa ja niitä löytyy, ne sisältävät paljon perustietoa ja niitä pitää lukea paljon ja jatkuvasti. Mutta ongelma on yhteisössä.

Nyt alueeltamme on vaikea löytää edes yhtä sopivaa konferenssia tai tapaamista. Ei, tietenkään on paljon tapaamisia sanalla Data, mutta tämän sanan vieressä on yleensä outoja lyhenteitä, kuten ML tai AI. Tämä ei siis ole meitä varten, puhumme varastotilojen rakentamisesta, emme siitä, kuinka me tahraamme itseämme neuroneilla. Nämä hipsterit ovat vallanneet kaiken. Tämän seurauksena olemme ilman yhteisöä. Muuten, jos olet tietoteknikko ja tunnet hyviä yhteisöjä, kirjoita kommentteihin.

Päätelmät ja tapaamisen ilmoitus

Mihin päädymme? Ensimmäiset kokemukseni kertovat minulle, että tietoinsinöörin oloista on hyötyä jokaiselle kehittäjälle. Sen avulla voimme vain katsoa asioita eri tavalla, emmekä ylläty, kun silmämme saavat verta, kun näemme, kuinka kehittäjät käsittelevät tietojaan. Joten jos yrityksessäsi on DE, keskustele vain näiden kaverien kanssa, opit paljon uusia asioita (itsestäsi).

Ja lopuksi ilmoitus. Koska on vaikea löytää tapaamisia aiheestamme päivän aikana, päätimme tehdä omat tapaamiset. Miksi olemme huonompia? Onneksi meillä on upea Schvepsss ja ystävämme Uusien ammattien laboratorio, jotka, kuten mekin, kokevat, että tietosuunnittelijat jäävät epäoikeudenmukaisesti huomiotta.

Käytän tätä tilaisuutta hyväkseni, kutsun kaikki asiasta kiinnostuneet tulemaan ensimmäiseen yhteisötapaamiseen lupaavalla otsikolla "DE or DIE", joka järjestetään 27.02.2020 Dodo Pizzan toimistossa. Yksityiskohdat osoitteessa TimePad.

Jos jotain tapahtuu, olen paikalla, voit kertoa minulle henkilökohtaisesti päin naamaa, kuinka väärässä olen kehittäjien suhteen.

Lähde: will.com

Lisää kommentti