Hodil by se nám další buddy do party

Napsat zajímavej pracovní inzerát v dnešní době je docela složitý, a proto jsme se rozhodli, že ho prostě psát nebudeme. Místo toho popíšeme jak to u nás chodí, protože to je stejně to, co vás zajímá.

Psal se rok 2010, když se Padák rozhodoval jak se bude naše firma jmenovat. Generátor slov mu vyhodil Keboola a nebo Megake. Volba nebyla zase tolik složitá! A tak se začala vyvíjet firma, která, jak popsal jeden z prvních zaměstnanců Halama, byla překydávátko CSVéček. Doba šla dál a nám se podařilo udělat úspěšný ETL nástroj, který pokryl velkou část E-commerce sektoru v Čechách. Od té doby jsme se dost posunuli a dneska provozujeme platformu pro celý datový proces od ETL, přes DataScience a automatizaci. Po Čechách jsme prorazili i na západním pobřeží v Americe. Aktuálně máme pobočku ve Vancouveru, kde máme 4 kolegy z professional services (oddělení starající se o implementace u zákazníků). Mezi zajímavý klienty v Americe patří například síť restaurací Firehouse, což je síť restaurací, která díky datům začala raketově růst (https://www.firehousesubs.com/All-Locations/).

Rok a půl dozadu se nám začal otevírat svět enterprise klientů a my začali upravovat Keboolu tak, aby více vyhovovala i větším zákazníkům. S tím přišlo spousta requestů na novou funkcionalitu. Víme jak ty věci udělat, ale hodilo by se nám, aby nám s nima někdo pomohl.

Jelikož rozumíme datům a víme, jak stavět procesy kolem nich, tak jsme se letos na jaře rozhodli pomoct státu se řešením situace kolem Covid-19 a vytvořili jsme v Keboole technickou část systému, kterému se říká “Chytrá karanténa”. Máme kolem toho spoustu historek, protože práce se státní sférou je doopravdy “jiná”.

To co vlastně Keboola je trochu složitý na vysvětlení, ale máme o tom super video, kde to Odin vysvětluje https://www.youtube.com/watch?v=Oxy0JFbuzX8 . Já bych to popsal, že učíme lidi jak správně pracovat s datama a mít v nich uklizeno.

Celou dobu, co firma existuje, máme černý čísla a nemáme investora. Organicky rosteme okolo 80% za rok. Aktuálně se ale už po investorovi díváme, aby nám pomohl nejem rychleji růst, ale taky otevíral dveře v dalších velkých firmách. Gartner nás delší dobu neuměl zařadit do žádné škatulky až pro nás vymyslel vlastní kategorii a tou je “Data Operating Systems”. Ve firmě máme zavedený ESOP. Pokud nevíš, co ta zkratka znamená, tak ve zkratce to je, že máš právo na firemní akcie pokud u nás budeš delší dobu (a to my chceme).

Celý náš vývojový tým je různě v Čechách až na jednoho kolegu, který bydlí na Slovensku. Full remote máme v DNA a víme jak v něm pracovat. Jeden kolega půl roku cestoval kolem zeměkoule a normálně u toho pracoval. Pokud to ale není tvůj případ, tak klidně můžeš chodit do kanceláře v Praze (naše hlavní) nebo do Brna. Aby sme se ale líp poznali tak jezdíme 4x do roka na offsite, což je akce, kdy si pronajmeme chatu někde v přírodě a 3 dny diskutujeme všechno. Když tě něco trápí nebo bys chtěl něco změnit, tak tohle je to pravý místo, kde reprodukovat svoje nápady.

Jelikož jsme zatím všichni vývojáři z CZ nebo SK, tak mezi sebou mluvíme česky, ale s partnerama probíhá komunikace anglicky. Je teda potřeba, aby si uměl dobře anglicky psát, protože to budeš potřebovat v komunikaci s klientama, když budeš sedět na supportu.

Hodně aktivně spolupracujeme s Microsoftem, protože stavíme Keboolu nad Azure (doteď byla pouze nad AWS). Tam máme přístup ke spoustě profíků, kteří nám pomáhají urychlovat vývoj. Budeme s nimi dlouhodobý strategický partnerství, kdy nás chtějí u svých klientů používat jako datovou platformu.

Tady začínají důležitý fakta. Ve vývoji nás je aktuálně 18 (a ve zbytku firmy cca 50) a jsme rozdělený do 6 týmů

• Connection — řeši jádro produktu a hlavní API na ukládání dat a metadat
• Platform Services — servisní a metadata aplikace, docker orchestrace (máme napsanou vlastní), serverless appky
• UI — frontend
• Components — docker appky na zpracování dat
• SRE — servisní tým pro pomoc s devops
• Produkt — plánování a směřování produktu

Co se týče technologií, tak vše máme v AWS a v Azure (jsme multicloud), všechny appky jsou v Dockeru (i když jsou třeba uvnitř spíš legacy). Na backendu používáme PHP (pro Dockerový appky) a NodeJS (serveless), na frontendu React. Pokud ale přijde jiná technologie nebo jazyk, který se nám bude hodit na řešení našeho problému, tak ho použijeme. Z frameworků používáme někde Zend (tuším, že prehistorická verze 1) a jinde Symfony, ale snažíme se psát appky tak, aby byly na frameworku co nejvíc nezávislé.

Posledních pár let jsme měli “best effort based” vývoj, kde všichni dělali tak nějak všechno, ale to s rostoucím týmem nebylo možný udržet, takže jsme přešli na takový modifikovaný Scrum, kde se snažíme udržet základní principy, ale hlavním cílem je, aby to fungovalo s našem full remote systému. Standupy máme například asynchronní do Slacku. Sprinty trvají 14 dní a mezi každým sprintem jsou 2 dny na vydechnutí a přípravu issues do dalšího sprintu. Všechny tyhle procesy se snažíme stavět tak, že je vyzkoušíme a pokud nám pomáhají tak je dodržujeme. Pokud ne, tak je po měsíci přestáváme používat.

Děláme code reviews a snažíme se dodržovat jednotný code style. Pomáhá nám v tom phpstan, phpunit, integrační testy, CI/CD … Pokud jde něco zautomatizovat tak to uděláme. Kde je to potřeba tak děláme dark launching a feature toggle. Jsme zvyklí releasovat několikrát za den a to malý věci. Drtivou většinu věcí máme otestovanou, ale stane se i že musíme něco rollbacknout.

Jako vývojáři se rotujeme na Level 2 supportu (používáme Zendesk). Znamená to, že jednou za 18 týdnů (je nás 18 aktuálně) někdo sedí týden na podpoře a v pracovní době odpovídá klientům na jejich problémy. Je to Level 2, takže odpovídáme pouze na tickety, který už nevyřešil Level 1. K tomu máme ještě on-call nad platformou 24h, který se rotuje denně a jeden člověk ho má max 2x do měsíce. Na on-call používáme PagerDuty, která nás notifikuje, že je něco špatně společně s runbookem jak to opravit. Nový člověk má k sobě vždycky backup, který mu vždycky poradí pokud něco nebude vědět. Všechny incidenty píšeme na https://status.keboola.com a je tam vidět, že řešíme něco přibližině 1–2krát za měsíc.

Je nám jedno v kolik budeš vstávat nebo chodit spát. Pokud budeš chtít dovolenou, tak to napíšeš do kanálu #dovolená na Slacku a tím je to vyřešený. V rámci týmu si musíš akorát dát pozor, aby tam někdo zbyl. Snažíme se řešit zastupitelnosti a proto každou věc musí umět alespoň 2 lidi. Pokud se v půlce dne rozhodneš, že chceš jet na kolo, tak si jeď na kolo. Nenárokujeme si 100% tvýho života v době 8:55–17:35. Já třeba v úterý a ve čtvrtek chodím dopoledne cvičit.

Fluktuace lidí je u nás minimální a za posledních 5 let jsme se rozloučili s 3 kolegama. Důvod byl vždycky stejnej a to, že jsme si vzájemně nesedli. Nehledáme lidi na konkrétní pozice, ale lidi, který baví pracovat mezi náma a budovat Keboolu. Není důležitý na 103% umět všechny jazyky a frameworky, ale spíš nám jde o to, abychom si sedli. Nehledáme člověka, který si sedne a bude čekat na přesný rozkazy co má dělat, ale spíš ti dáme problém a budeme o tebe čekat s nápady jak to vyřešit. Jsme extrémně otevřená firma a prakticky všechno se řeší public. Pokud máš s něčím problém nebo potřebuješ pomoct, tak napíšeš do Slacku, kde ti vždycky někdo pomůže.

Obecně se dá říct, že máme dobrej produkt i klienty, kteří nás mají rádi. Je normální, že když pro klienta něco uděláš, tak ti poděkuje.

Příklady z Kebooly

Na posledním offsite jsme řešili například:

• Měli by se lidi v týmech rotovat? — máme víc týmů, kteří se starají o různé části systémů a otázka byla jestli chce někdo do jiného týmu. Odpověď byla ne a že jsou všichni spokojení s tím, co dělají.
• Technologický ownership — máme hromadu technologie, který používáme a občas ta technologie udělá BC break a my to nějak musíme řešit. Musí existovat lidi, kteří se starají o různý technologie a sledují changelogy. Odpověď je, že tohle ještě nemáme pevně vyřešený a postupně ty technologie si nacházejí svoje vlastníky. Teďka jsme například díky tomu podchytili, že Azure updatoval K8S a my jsme měli dost času si odladit jestli to bude fungovat s novou verzí
• Jsme stále API first? — všechno co vyvineme má nejdřív API a pak k tomu teprve děláme UI. Jakmile to má UI, tak to dáváme do na status page(status.keboola.com) jako novinku. Odpověď byla, že se snažíme být pořád API first.

S Microsoftem jsme řešili například:

• Přepis z AWS ECR na Kubernetes (aby jsme mohli být jednodušeji multicloudový)
• Adopci Azure Blob storage (úložiště — v našem případě náhrada pro AWS S3)
• Adopci Azure Synapse (databáze — v našem případě alternativa pro Snowflake)
• Networking v K8S (dokážeme provozovat celou platformu i v private networkingu, kdy není přístup do internetu)

Aktuálně máme ve sprintech user stories například na:

• Vytvoření DEV/PROD režimu — chceme mít v Keboole produkční a vývojové prostředí, které bude oddělené a uživatelé si budou moci “hrát” na svém písečku. V Jiře, kterou používáme na plánování, to pak vypadá asi takhle:

• Pay-as-you-go — Chceme aby Keboola šla platit klasicky kreditkou.
• Youtube deprekuje API a potřebujeme ověřit, že náš extraktor bude dál fungovat
• Vylepšení monitoringu v DataDogu pro Azure stacky, abychom měli detailní monitoring pro K8S

Na Zendesku řešíme například v Level 2 ticketech:

• MSSQL writer při chybě serveru nepoužívá správně retry mechanismus — založila se issue v Jiře pro komponentní tým a ten to v následujicím sprintu opravil a napsal klientovi, že je oprava nasazená
• CSV obsahující JSON soubory timeoutuje při parsování — zjistili jsme, že se všechno dělá správně, ale databáze nestihne rozparsovat velké JSON soubory, takže jsme zvedli timeout v databázi
• Reset MFA u uživatele — uživatel ztratil telefon a potřebujeme vypnout MFA na svém účtu. Ověřili jsme přes třetí osobu na straně klienta, že se nejedná o social hacking a vypnuli jsme MFA (https://keboolamanagementapi.docs.apiary.io/#reference/users/manage-user/disable-mfa-for-user), aby se uživatel mohl přihlásit

Onboarding nových kolegů:

• Přečteš si security standards a “how we roll”
• Vytvoříme ti kanál na slacku #hello_your_name, kde se budeš ptát
• Vytvoříš si svojí první komponentu podle https://developers.keboola.com/extend/component/tutorial/
• Budeš s náma společně alespoň týden v kanceláři v Praze nebo Brně, kde ti pomůžeme všechno nastavit a pochopit. Budeš mít k ruce jednoho vyvojáře, který ti se vším pomůže.
• Upravíš existující komponentu a publikuješ ji
• Dostaneš větší feature, která bude vyžadovat analýzu tvojí strany
• Vybereš si v jakým týmu chceš dělat
• Pracuješ v Keboole až do důchodu

Samozřejmě, že každýmu nemusí sednout styl práce, kterým u nás fungujeme. Pokud se ti to ale líbí, tak klidně napiš na vojta@keboola.com a já se postarám o to, aby sme se sešli. Pokud nejsi programátor(ka) a zaujalo tě, jak u nás fungujeme, tak nám stejně napiš, protože hledáme lidi na všechny pozice (sales, customer success, marketing …).

Díky, Vojta z Kebooly.