Jag har talat med många analytikerkollegor som är övertygade om att de vill att deras team aldrig ska röra ”produktion”. Även om det finns goda skäl att vara försiktig när du gör ändringar som kan påverka kunderna, anser jag att när programvaran blir mer datadriven är det viktigt att hitta säkra sätt att ge analysteam möjlighet att bygga och distribuera datadrivna applikationer.
Vad är produktion?
För det första en definition av begreppet. ”Produktion” är en miljö. Vanligtvis finns det ett fåtal miljöer där kod kan köras (i progressionsordning):
- Lokal utveckling
- Fjärrutveckling
- Staging / QA
- Produktion
Varje ”applikation” kommer att ha flera miljöer, varav en kommer att vara den miljö som möter användare som inte är utvecklare. Den som står inför användare som inte är utvecklare kallas vanligtvis ”produktion”.
Här är min tes: Det finns naturligtvis undantag från detta och olika typer av applikationer kommer att ha olika ”grader” av datadrivenhet. Historiskt sett har vissa företag tvekat att göra sina tillämpningar mer datadrivna eftersom deras mjukvaruingenjörer inte hade datakunskaper och var rädda för att låta analysteamet påverka tillämpningen. Du bör naturligtvis fatta beslut om att lägga till nya funktioner baserat på hur värdefulla de kommer att vara, inte bara för att någon bloggare sa åt dig att göra det…. Om det inte är möjligt att möjliggöra detta på ett säkert sätt bör du ändra din kundorienterade applikation på ett sådant sätt att det blir möjligt.
Om du tyckte att det sista stycket var chockerande kommer jag att blåsa av dig strumporna: alla dina analytiker distribuerar till produktion varje dag, redan nu. Låt mig gå igenom min favorit2och mest motbjudande. Folk älskar mig på fester. frågeställningar:
- BI-verktyget som du konfigurerar för att tillhandahålla rapportering till användare inom företaget – är det inte produktion?
- R-skriptet som samlar data, rensar dem och tillhandahåller visualiseringar för en PPT som skickas till det verkställande teamet – är det inte produktion?
- Excel-filen (fylld med kod) som används för att fatta ett beslut om lagerhållning på flera miljoner dollar – är det inte produktion?
Håll i minnet: bara för att du inte har en utvecklingsmiljö betyder det inte att din användarvänliga miljö inte är produktion!
För många nystartade företag använder folk ”produktion” som en förkortning för att hänvisa till deras användarvänliga webbapplikation (beroende på företagets stadium kan det vara eller inte vara en rails-monolit). Förutom att säga att man bör sluta använda sådana otydliga termer vill jag förespråka att man ska tänka på varför man kanske vill göra det möjligt för analytiker och datavetare som inte är ingenjörer att distribuera till en kundorienterad applikation. Jag avslutar med några strategier för hur du kan operationalisera detta.
Varför ge analysteamet möjlighet att påverka kunderna?
Byggandet av datadrivna applikationer är en bordsplacering för modern programvaruteknik och produktutveckling. Morgondagens applikationer kommer att ha data integrerade från början till slut och om det finns en mur mellan dina dataexperter och dina applikationsutvecklare kommer du att få det svårt.
Här är några exempel på datadrivna produkter som du kanske vill bygga:
- Implementera Thompson sampling för multi-armed bandit-testning av webbplatsvarianter
- Clustera kunder för riktade marknadsföringsmejl eller varianter av landningssidor
- Förutsäga kunder som troligen kommer att byta och ge endast dessa kunder en kupongkod
- Inför produktrekommendations-/sökrankningsalgoritmer
Om du vill bygga dessa datadrivna produkter vill du att dina dataexperter ska jobba på dem. Här är några skäl att tänka på att sudda ut gränsen mellan ditt Analytics3Som vanligt använder jag i det här inlägget begreppen ”Analytics” och ”analytiker” på ett så brett sätt som möjligt, inklusive datavetare, dataanalytiker och andra dataexperter. team och resten av ditt mjukvaruteknikteam:
- Datavetare är dina algoritm-experter och kontinuerlig integrering är viktigt
- Du vill att din app ska drivas av data!!
- Analytiker känner till data bäst så de är mindre benägna att göra misstag
- Produktion av någon annans arbete är ett skitjobb
- Blockerar du analytikernas iteration med eng prioritering saktar du ner alla och leder till frustration
Det är okontroversiellt att låta produktchefer eller designers distribuera nytt innehåll till webbplatsen via ett CMS. Om det hade stöd för markdown borde det också vara trivialt. Du kan också låta analytiker justera algoritmvikter via ett CMS, så varför inte låta dem distribuera en modell så länge den modellen överensstämmer med det API som appen förväntar sig? Eftersom ditt analysteam kanske inte har alla verktyg eller färdigheter för att arbeta med en komplex webbapplikation vill du naturligtvis se till att de kan göra dessa ändringar på ett sätt som är både säkert och effektivt (dvs. de kan använda de verktyg som de är bekanta med och de andra delarna är abstraherade).
Hur man ger analysteamet möjlighet att påverka kunderna?
När vi nu har diskuterat varför det här kan vara en bra idé kan vi prata om hur man kan få detta att hända på ett säkert och effektivt sätt. Här är några exempel som jag har sett tidigare (och jag vill gärna höra om fler om du känner till några bra mönster):
- Mikrotjänster
- Algoritmen för produktrankning kan leva bakom ett API så att analysteamet kan distribuera ändringar utan att röra resten av appen
- Användarprofiler
- Du kan bevara viktiga användarattribut i en tabell som din webbapp har tillgång till (t.ex.g., via en redis-cache) som hanteras av analysteamet (ETL, ML, vad som helst, så länge API:et inte ändras)
- Väggar/poäng
- Om du har en modell som arbetar med vikter eller attribut för att skapa en ”poäng” (t.ex, en bedrägeririskpoäng) kan du hålla dessa vikter i en tabell som analysteamet kan ha skrivåtkomst till
Jag har skrivit om designmönstret code-as-configuration tidigare, och generellt sett är detta ett utmärkt mönster för att ge icke-ingenjörer möjlighet att säkert distribuera kod till produktionsmiljöer. Bloggvännen Harlan Harris har också skrivit om att använda domänspecifika språk för att underlätta testning, samordning och distribution av modeller för maskininlärning i produktion.