Mluvil jsem s mnoha kolegy analytiky, kteří jsou přesvědčeni, že chtějí, aby se jejich tým nikdy nedotkl „produkce“. Ačkoli existují dobré důvody, proč být opatrný vždy, když provádíte změny, které by mohly mít dopad na zákazníky, domnívám se, že s tím, jak se software stává stále více založeným na datech, je velmi důležité najít bezpečné způsoby, jak umožnit analytickým týmům vytvářet a nasazovat aplikace založené na datech.
Co je to produkce?
Nejprve několik definic pojmů. „Produkce“ je prostředí. Běžně existuje několik prostředí, ve kterých může být kód spuštěn (v pořadí podle vývoje):
- Lokální vývoj
- Vzdálený vývoj
- Staging / QA
- Produkce
Každá „aplikace“ bude mít více prostředí, z nichž jedno bude to, které bude určeno pro uživatele, kteří nejsou vývojáři. To, které stojí tváří v tvář uživatelům, kteří nejsou vývojáři, se obvykle nazývá „produkční“.
Tady je moje teze: Pro analytické týmy je rozhodující, aby ovlivňovaly aplikace zaměřené na zákazníky1Z toho samozřejmě existují výjimky a různé typy aplikací budou mít různý „stupeň“ datové orientace. V minulosti některé společnosti váhaly s tím, aby jejich aplikace byly více datově orientované, protože jejich softwaroví inženýři neměli datové dovednosti a báli se nechat analytický tým ovlivnit aplikaci. O přidávání nových funkcí byste se samozřejmě měli rozhodovat na základě toho, jak budou hodnotné, a ne jen proto, že vám to poradil nějaký blogger… Pokud to není možné umožnit bezpečným způsobem, pak byste měli upravit aplikaci pro zákazníky tak, aby to bylo možné.“
Pokud vás poslední odstavec šokoval, teď vám vyrazím dech: všichni vaši analytici už nasazují do produkce každý den. Dovolte mi, abych vás provedl svým nejoblíbenějším2a nejprotivnějším. Lidé mě na večírcích milují. linie otázek:
- Nástroj BI, který konfigurujete, aby poskytoval reporty uživatelům ve vaší společnosti – to není produkční?
- Skript R, který shromáždil data, vyčistil je a poskytl vizualizace pro PPT, které se posílají e-mailem výkonnému týmu, to není produkční?
- Ten soubor Excelu (naplněný kódem), který se používá k rozhodnutí o zásobách v hodnotě několika milionů dolarů, to není produkční?
Zapomeňte: to, že nemáte vývojové prostředí, neznamená, že vaše uživatelské prostředí není produkční!
U mnoha startupů lidé používají „produkční“ jako zkratku pro označení své uživatelské webové aplikace (v závislosti na fázi firmy to může, ale nemusí být stále monolit rails). Kromě toho, že byste měli přestat používat takové nejasné termíny, se chci zasadit o to, abyste se zamysleli nad tím, proč byste mohli chtít umožnit analytikům a datovým vědcům, kteří nejsou inženýry, nasazení aplikace zaměřené na zákazníka. Na závěr uvedu několik strategií, jak byste to mohli zprovoznit.
Proč umožnit analytickému týmu působit na zákazníky?“
Vytváření aplikací založených na datech je pro moderní softwarové inženýrství a vývoj produktů sázkou na stůl. Aplikace zítřka budou mít data integrovaná od kmene až po záď, a pokud bude mezi vašimi datovými experty a vývojáři aplikací zeď, budete mít smůlu.
Tady je několik příkladů datově řízených produktů, které možná budete chtít vytvořit:
- Zavedení Thompsonova vzorkování pro víceramenné banditovské testování variant stránek
- Shlukování zákazníků pro cílené marketingové e-maily nebo varianty vstupních stránek
- Předvídání zákazníků, kteří pravděpodobně odejdou, a poskytnutí kupónového kódu pouze těmto zákazníkům
- Zavedení algoritmů pro doporučování produktů / řazení ve vyhledávání
Pokud chcete vytvořit tyto produkty řízené daty, budete chtít, aby na nich pracovali vaši odborníci na data. Zde je několik důvodů, proč přemýšlet o stírání hranic mezi vaším analytickým týmem3Jako obvykle, v tomto příspěvku používám termíny „analytický tým“ a „analytici“ v co nejširším slova smyslu, včetně datových vědců, datových analytiků a dalších datových expertů. a zbytkem vašeho týmu softwarových inženýrů:
- Datoví vědci jsou vaši experti na algoritmy a kontinuální integrace je důležitá
- Chcete, aby vaše aplikace byla poháněna daty!!
- Analytici znají data nejlépe, takže je méně pravděpodobné, že udělají chybu
- Produkce práce někoho jiného je práce na hovno
- Blokování iterace analytiků s eng prioritizací všechny zpomaluje a vede k frustraci
Je nekontroverzní nechat produktové manažery nebo designéry nasazovat nový obsah na web prostřednictvím CMS. Pokud by to podporovalo markdown, mělo by to být také triviální. Mohli byste také nechat analytiky upravovat váhy algoritmů prostřednictvím CMS, tak proč je nenechat nasadit model, pokud tento model odpovídá jakémukoli API, které aplikace očekává? Samozřejmě, protože váš analytický tým nemusí mít všechny nástroje nebo dovednosti pro práci na složité webové aplikaci, chcete se ujistit, že tyto změny mohou provádět způsobem, který je bezpečný a efektivní (tj. mohou používat nástroje, které znají, a ostatní části jsou abstrahovány).
Jak posílit analytický tým, aby mohl ovlivňovat zákazníky?“
Teď, když jsme probrali, proč by to mohl být dobrý nápad, můžeme se bavit o některých způsobech, jak to bezpečně a efektivně provést. Zde je několik příkladů, které jsem v minulosti viděl (a rád bych slyšel o dalších, pokud víte o nějakých dobrých vzorech):
- Mikro služby
- Algoritmus hodnocení produktů může žít za rozhraním API, takže analytický tým může nasadit změny, aniž by se dotkl zbytku aplikace
- Profily uživatelů
- Klíčové atributy uživatelů můžete uchovávat v tabulce, ke které má vaše webová aplikace přístup (např.g., prostřednictvím mezipaměti redis), kterou spravuje analytický tým (ETL, ML, cokoli, pokud se nezmění API)
- Váhy / skóre
- Pokud máte model, který pracuje na základě vah nebo atributů pro vytvoření „skóre“ (např, skóre rizika podvodu), pak můžete tyto váhy uchovávat v tabulce, ke které má analytický tým přístup pro zápis
Již dříve jsem psal o návrhovém vzoru kód jako konfigurace a obecně je to skvělý vzor, který umožňuje neinženýrům úsporně nasazovat kód do produkčních prostředí. Přítel blogu Harlan Harris také psal o používání doménově specifických jazyků pro usnadnění testování, koordinace a nasazení modelů strojového učení v produkčním prostředí.