Kaksi laatikossa (jos mahdollista) ja kaikki asiakirjoissa (aina).
IT-kontekstissa "kaksi laatikossa" tarkoittaa kahta palvelinta tai komponenttia, jotka on suunniteltu toimimaan yhdessä tuottamaan redundanssia ja lisäämään luotettavuutta. Tällä asennuksella voidaan varmistaa, että jos yksi komponentti epäonnistuu, toinen ottaa sen toiminnan haltuunsa, mikä ylläpitää palvelun jatkuvuutta. "Kaksi laatikossa" tavoitteena on tarjota korkea saatavuus ja katastrofipalautus. Tämä koskee myös ihmisrooleja organisaatiossa; sitä kuitenkin harvoin toteutetaan.
Katsotaanpa asiaankuuluvaa Analytics-esimerkkiä. Tiedämme kaikki todennäköisesti nimellämme yrityksessämme tai organisaatiossamme henkilön, joka on Analyticsin "go-to" -henkilö. He ovat ne, joilla on nimensä raportit tai hallintapaneelit – Miken raportti tai Jane's Dashboard. Toki on muitakin ihmisiä, jotka tuntevat analytiikan, mutta he ovat todellisia mestareita, jotka näyttävät tietävän, miten vaikeimmat asiat saadaan tehtyä ja ylittyvät määräajoissa. Ongelma on siinä, että nämä ihmiset ovat yksin. Monissa tapauksissa paineen alaisena ne eivät toimi kenenkään kanssa, koska se saattaa hidastaa heitä, ja tästä ongelma alkaa. Emme koskaan usko, että menetämme tämän henkilön. Pidättäydyn tyypillisestä "sanotaan, että he joutuvat bussiin" tai käytän esimerkkiä nykyisten työmarkkinoiden mahdollisuuksien hyödyntämisestä ja sanon jotain positiivista, kuten "he voittivat lotossa!", koska meidän kaikkien pitäisi tehdä osamme ollaksemme positiivisia. näinä päivinä.
Tarina
Maanantaiaamu tulee, ja analytiikkaasiantuntijamme ja mestarimme MJ on jättänyt eronsa. MJ voitti lotossa ja on jo lähtenyt maasta ilman huolta maailmassa. Tiimi ja ihmiset, jotka tuntevat MJ:n, ovat innoissaan ja kateellisia, mutta työn täytyy mennä. Nyt on silloin, kun MJ:n tekemisen arvo ja todellisuus ollaan ymmärtämässä. MJ vastasi analytiikan lopullisesta julkaisusta ja validoinnista. He näyttivät aina pystyvän parantamaan tehokkuutta tai tekemään tuon vaikean muutoksen ennen kuin toimittivat analytiikan kaikille. Kukaan ei todellakaan välittänyt siitä, miten se tehtiin, ja hän oli varma siitä, että se vain tapahtui, ja MJ oli Analyticsin henkilökohtainen rocktähti, joten hänelle annettiin tietty autonomia. Nyt kun tiimi alkaa poimia palasia, pyyntöjä, päivittäisiä ongelmia, muutospyyntöjä, he ovat tappiolla ja alkavat sekoittua. Raportit / hallintapaneelit löytyvät tuntemattomista tiloista; joitakin resursseja ei päivitetty viikonlopun aikana, emmekä tiedä miksi; ihmiset kysyvät, mitä tapahtuu ja milloin asiat korjataan, MJ:n mukaan tehdyt muokkaukset eivät näy, eikä meillä ole aavistustakaan miksi. Joukkue näyttää huonolta. Se on katastrofi, ja nyt me kaikki vihaamme MJ:tä.
Oppitunnit
On olemassa joitain helppoja ja ilmeisiä take-away-tuotteita.
- Älä koskaan anna henkilön työskennellä yksin. Kuulostaa hyvältä, mutta pienemmissä ketterissä tiimeissä meillä ei ole aikaa tai ihmisiä toteuttamaan tätä. Ihmisiä tulee ja menee, tehtäviä on monia, joten hajota ja hallitse tuottavuuden nimissä.
- Jokaisen on jaettava tietonsa. Kuulostaa myös hyvältä, mutta jaammeko oikeiden ihmisten kanssa? Muista, että monet lottovoittajat ovat työtovereita. Tiedonjakoistuntojen tekeminen vie myös aikaa tehtävistä ja useimmat ihmiset panostavat taitoihin ja tietoihin vain silloin, kun sitä tarvitaan.
Joten mitkä ovat todellisia ratkaisuja, joita jokainen voi toteuttaa ja joiden takana ovat?
Aloitetaan kokoonpanonhallinnasta. Käytämme tätä kattoterminä useille samankaltaisille aiheille.
- Muutoksen hallinta: Prosessi, jossa suunnitellaan, toteutetaan ja ohjataan muutoksia ohjelmistojärjestelmiin jäsennellysti ja systemaattisesti. Tällä prosessilla pyritään varmistamaan, että muutokset tehdään hallitusti ja tehokkaasti (jolla on mahdollisuus palautua), mahdollisimman vähän häiriötä olemassa olevaan järjestelmään ja mahdollisimman paljon hyötyä organisaatiolle.
- Projektinhallinta: Ohjelmistokehitysprojektien suunnittelu, organisointi ja valvonta sen varmistamiseksi, että ne valmistuvat ajallaan, budjetissa ja haluttujen laatustandardien mukaisesti. Se sisältää resurssien, toimintojen ja tehtävien koordinoinnin koko ohjelmistokehityksen elinkaaren ajan projektin tavoitteiden saavuttamiseksi ja ohjelmistotuotteen toimittamiseksi aikataulussa.
- Jatkuva integrointi ja jatkuva toimitus (CI/CD): Ohjelmistojen rakentamisen, testauksen ja käyttöönoton automatisointiprosessi. Jatkuva integrointi edellyttää koodimuutosten säännöllistä yhdistämistä jaettuun tietovarastoon ja automaattisten testien suorittamista virheiden havaitsemiseksi kehitysprosessin varhaisessa vaiheessa. Jatkuva toimitus/käyttöönotto sisältää testattujen ja validoitujen koodimuutosten automaattisen julkaisun tuotantoon, mikä mahdollistaa uusien ominaisuuksien ja parannusten nopean ja toistuvan julkaisun.
- Version hallinta: Lähdekoodin ja muiden ohjelmistoartefaktien muutosten hallinta ajan myötä käyttämällä erikoistyökaluja. Sen avulla kehittäjät voivat tehdä yhteistyötä koodikannan parissa, ylläpitää täydellistä muutoshistoriaa ja kokeilla uusia ominaisuuksia vaikuttamatta pääkooditietokantaan.
Kaikki edellä mainitut viittaavat hyviin ohjelmistokehityskäytäntöihin. Analyysit, jotka ohjaavat ja johtavat liiketoimintaa, ansaitsevat yhdestäkään vähempää, koska ne ovat kriittisiä päätöksenteon kannalta. Kaikki analytiikkaresurssit (ETL-työt, semanttiset määritelmät, mittausmääritykset, raportit, kojelaudat, tarinat jne.) ovat vain koodinpätkiä visuaalisella käyttöliittymällä suunnittelua varten, ja näennäisesti pienet muutokset voivat haistaa toiminnan tuhoa.
Kokoonpanonhallinnan käyttö kattaa sen, että pystymme jatkamaan toimintaamme hyvässä tilassa. Omaisuudet on versioitu, jotta voimme nähdä, mitä niiden elinkaaren aikana on tapahtunut, tiedämme, kuka työskentelee mitäkin, edistymistä ja aikatauluja, ja tiedämme, että tuotanto jatkuu. Mitä mikään puhdas prosessi ei kata, on tiedon siirtäminen ja ymmärrys siitä, miksi asiat ovat niin kuin ne ovat.
Jokaisella järjestelmällä, tietokannalla ja analytiikkatyökalulla on omat omituisuutensa. Asiat, jotka saavat ne menemään nopeasti tai hitaasti, asiat, jotka saavat ne käyttäytymään tietyllä tavalla tai tuottamaan halutun tuloksen. Nämä voivat olla järjestelmän tai globaalin tason asetuksia tai resurssien suunnittelussa olevia asioita, jotka saavat ne toimimaan juuri niin kuin niiden pitääkin. Ongelmana on, että suurin osa näistä asioista opitaan ajan myötä, eikä niitä aina ole dokumentoimaan. Vaikka siirrymme pilvijärjestelmiin, joissa emme enää hallitse sovelluksen suoritusta, ja luotamme toimittajaan, jotta se tekee sen mahdollisimman nopeasti, määritelmien säätäminen jatkuu omaisuutemme sisällä löytääksemme juuri sen, mitä etsimme. Tämä tieto on se, mitä on otettava talteen ja jaettava tuomalla se muiden saataville. Tätä tietoa on vaadittava osana omaisuuden dokumentointia ja se on tehtävä kiinteäksi osaksi versionhallinta- ja CI/CD-sisäänkirjautumis- ja hyväksymisprosessia ja joissakin tapauksissa jopa osana tarkistuslistaa ennen kuin julkaistaan asioita, joita pitää tehdä ja ei. tehdä.
Analytiikkaprosesseissamme ei ole taikavastauksia tai tekoälyä, joka voisi peittää oikoteitä tai niiden puutetta. Tietojen ja analytiikan virrassa pitävän tiimin koosta riippumatta investoinnit järjestelmään muutosten seurantaan, kaikkien resurssien versioimiseen sekä kehitysprosessin dokumentoimiseen ja tiedon keräämiseen on välttämätöntä. Investoinnit prosesseihin ja aikaan etukäteen säästävät paljon hukattua aikaa asioiden selvittämiseen myöhemmin, jotta voimme ylläpitää analytiikkamme tervettä. Asioita tapahtuu ja on parasta, jos sinulla on vakuutus MJ: lle ja muille lottovoittajille.
