čtvrtek 26. prosince 2013

Odkaz Michaila Kalašnikova softwarovému vývoji

V tomhle článku trochu navážu na armádní speciál, který nezávazně píšeme s Banterem. On se v posledním díle Co se firmy můžou přiučit od armády 2 rozepsal o uniformách. Já bych chtěl využít aktuálního tématu, úmrtí Michaila Kalašnikovat [1.], konstruktéra útočné pušky AK-47 (zkráceně pojmenované kalašnikov), která to dotáhla až na vlajku státu Mozambik. Poprvé tuším paralelu se softwarovým vývojem a návrhem AK-47 zmínil Karel Minařík [2.]. Návrh AK-47 může být inspirací pro návrh spolehlivého software, o kterém mluvím a píšu pod hlavičkou Cynický software.

Z nouze ctnost

M. Kalašnikov vycházel při návrhu ze zkušeností a možností tehdejší sovětské průmyslové výroby, kdy bylo prakticky nemožné vyrobit jednotlivé části zbraně přesně na míru. Kromě hlavně a závorníku, které musely přesně pasovat, mohl mít zbytek součástí zbraně odchylky od předepsaných rozměrů. Jako veterán Druhé světové války, počítal s tím, že v boji bude jediným nástrojem dostupným k opravě pouze kladivo [3.]. Návrh zbraně byl velmi jednoduchý a umožňoval lacinou výrobu, další z nutností reflektující ekonomickou realitu tehdejšího Sovětského svazu. Jednoduchý a tolerantní design umožnil spolehlivost s nulovými nároky na údržbu. Z nouze se stala ctnost. Zbraň, která prošla úspěšně prakticky všechny válečné konflikty po Druhé světové válce, se stala legendární a oblíbená právě díky spolehlivosti. Přestože zbraň nedosahovala takové přesnosti střelby, díky toleranci chyb výroby, jako konkurenční útočná puška M16, její jednoduchost a spolehlivost tyto atributy přesvědčivě převážily.

Nadřazenost a úspěch jejího designu potvrzuje i fakt, že byla licencovaně vyráběná v dalších zemích nejenom Varšavské smlouvy. Vychází z ní například izraelská útočná puška Galilcite> nebo finská Velmetcite> [4.]. Přestože je design zbraně starý přes 60. let, došlo prakticky pouze k drobným úpravám. Za tu dobu se nedošlo v oblasti útočných pušek k lepšímu designu, který by AK-47 výrazně překonal [6.].

Odkaz Michaila Kalašnikova

Co si můžeme odnést z designu AK-47 a pro softwarový vývoj? Je několik oblastí, ve kterých se můžeme inspirovat.

M. Kalašnikov, podobně jako řada dalších vynálezců, nebyl osvícen z nenadání. Prošel si celou řadu designu pušek a samopalů, které se běžně používaly v Druhé světové válce. Zároveň mu pomohla vlastní bojová zkušenost - mimochodem navrhl například počítadlo výstřelů k tankovému kanonu nebo úpravu pistole Tokarev pro střelbu z tanku [3.] - díky které dokázal posoudit, co je kritické pro fungování útočné pušky. Pokud začnete designovat nějaký systém je celkem dobrá šance, že někdo dělal něco podobného před vámi. Je užitečné studovat podobná řešení a hledat v nich inspiraci. M. Kalašnikov sám o sobě nevymyslel nic nového, jenom spojil existující nápady do nového celku a zohlednil technická omezení tehdejšího Sovětského svazu.

Věděl, že jednoduchost návrhu umožní levnou výrobu. Výhody jednoduchého designu jsou zřejmé - jednoduché na pochopení a jednoduché na implementaci. Pokud se něco rozbije, bude jednoduché to opravit. Jeho design byl přímo učebnicovým příkladem KISS principu. Jednoduchý design nabízí menší prostor pro rozbití. Během softwarového vývoje je naopak často příliš akcentovaná funkcionalita na úkor provozních nákladu. Bohužel je to dané tím, že výsledné náklady na spravovatelnost celého řešení jsou skryté. Problém spolehlivosti americké útočné pušky M16 během Vietnamské války byl v tom, že se počítalo s její údržbou. Jenom někdo zapomněl dodat čistící soupravy. Oproti tomu M. Kalašnikov počítal s tím, že údržba zbraně nebude na vysoké úrovni.

Vždycky když designujeme nějaký systém a nastane problém s mazáním zastaralých dat, najde se minimálně jedno řešení navrhující formu nějakého garbage collectoru. V klasické podobě to je většinou nějaký cron job. Tohle řešení bohužel funguje jako ten zapomenutý vytěrák k M16. Pokud ho nezapnete zapnout při každé instalaci, pokud není nějakým způsobem založený na tom, že běží jenom jednou a to i v clusteru, pokud nežere moc paměti, pokud doběhne do dalšího naplánovaného běhu. Je tam celá řada ale. Proto vždy preferuji design, kde je mazání zastaralých dat automatické (například MongoDB podporuje takzvané capped kolekce, kde se data mažou automaticky).

Nepřesná výroba a z toho vycházející design by přibližně odpovídal návrhu, kde jednotlivé vazby systému mají pouze volné vazby [5.]. Volné vazby umožňují, aby jednotlivé části systému nezávisely přímo na implementačních detailech. Umožňuje to jednoduše vyměnit jednu implementaci za druhou, aniž by to mělo vliv na funkci celku. Volná vazba rovněž znamená nebo by měla znamenat, že systém je funkční, přestože se mění podmínky prostředí v němž funguje. Stejně jako chcete, aby vám puška fungovala přestože vám ji právě počůral velbloud, chcete aby systém fungoval přestože jedna z jeho částí může mít problémy. Počítejte s tím, že specifikace bude málokdy kompletní případně jí vždy všichni bezchybně splní. Navrhujte systém, který bude z principu tolerantní k chybám, přesně jako s nimi počítal M. Kalašnikov.


Samozřejmě to můžete takový systém těžko navrhnout, pokud předpokládáte, že systém bude fungovat v absolutně spolehlivém prostředí. M. Kalašnikov, díky vlastním zkušenostem z boje, věděl v jakém prostředí se bude jeho zbraň používat. Věděl, k jakým situacím může dojít, a zohlednil tyto situace při návrhu. Pokud se chcete při návrhu a provedení zlepšit, musíte si projít zkušenostmi z prostředí, kde bude výsledný systém nasazený. V softwarovém vývoji si stačí na pár týdnů zkusit provozovat vlastní systém případně se přepnout do DevOps módu.

Největší odkaz Michaila Kalašnikova je asi v tom, že systém nemusí mít tisíc a jednu funkci, ale musí dělat přesně to k čemu se reálně používá a musí to dělat spolehlivě.


Aktualizace: Doporučuji rovněž článek What designers can learn from the AK-47 od Scotta Berkuna (autor excelentní knihy The Myths of Innovation)

Odkazy

pondělí 23. prosince 2013

CZ Podcast 90 - Psaní low latency aplikací v Jave

Podle mého zaujatého pohledu jeden z nejlepších dílů, které jsme letos vůbec natočili. Pokud patříte do skupiny lidí, která vidí Javu jako pomalejšího bráchu C++, pak vás tento díl přesvědčí, že i v Jave lze psát aplikace obsluhující požadavky do jedné milisekundy. Hostem tohoto dílu byl Karel Rank, který nás provedl světem optimalizací - počínaje Java kódem, přes JIT nebo scheduler operačního systému, až po vlastní instrukční sadu CPU. Letos to byl jisto jistě poslední díl, ale hned na začátku toho dalšího natáčime další.

čtvrtek 19. prosince 2013

pondělí 9. prosince 2013

Využití vnitřní motivace

Existují dva typy motivace - vnitřní a vnější. Pokud chodíte do práce a někdo vám za ní pravidelně platí, pak se jedná o motivaci vnější. Mezi další příklady patří další hmotné odměny, postup na kariérním žebříčku apod. Pokud do práce chodíte, protože vás prostě baví, pak se jedná o motivaci vnitřní. Dalším příkladem vnitřní motivace může být touha učit se novým věcem, může to být pocit hrdosti, že dělám určitou věc dobře. Problém externí motivace je v tom, že škáluje jenom do určité míry, to znamená že není přímá úměra mezi kvalitou/výkonem na výstupu a řekněme penězi na vstupu. Interní motivace funguje naopak - za málo peněz hodně muziky. Vnitřní motivace má jenom dvě nevýhody, za prvé - každý člověk je motivován něčím jiným, a za druhé - je celkem obtížné využít tuhle motivaci efektivně ve prospěch týmu a firmy. V tomhle článků vám zkusím dát pár tipů, jak na ní.


Lidé nedělají věci, protože jim to řeknete, a nebo dělají, ale dělají je špatně. Když přijdete k nám do týmu a budu vám dělat code review na kód, u kterého budou chybět testy, neřeknu vám, že píšeme testy, protože chceme mít pokrytí (externí motivace) takové a makové. Namísto toho se vás zeptám jestli chcete ten kód nasadit rovnou na produkci. Pokud vývojář nepochopí, že testy píše pro pocit vlastního bezpečí (interní motivace), nikdy to nebude dělat správně a v dostatečné kvalitě.


Vždycky, tedy skoro vždycky, když mám nějakou špatnou zkušenost s nějakou vnitrofiremní knihovnou/komponentou/službou, souvisí to s tím, že není jasný vlastník. Trochu ta situace připomíná komunismus. Knihovna je všech a zároveň nikoho a podle toho to i vypadá. Naopak pokud je jasný vlastník, vždycky je situace mnohem lepší, protože funguje obyčejná ješitnost (interní motivace). Málokdo chce svoje jméno spojit v uvozovkách s nějakým hnojem. A pokud už ho spojí, má skoro vždy touhu s tím něco udělat. Zde je potřeba si dát jenom pozor na to, aby o vlastnictví nerozhodl nějaký ouřada od stolu. Pak to bude opravdu vlastnictví podle organizační struktury (externí motivace), ale nikoliv pocit vlastnictví. Ješitnost je vůbec skvělá vlastnost pokud jí dokážete správně využít. Možná bych místo termínu ješitnost, který má negativní konotace, použil termín stavovskou pýcha, který vyzní daleko lépe.


Práce nás vývojářů je hodně kreativní. Každý den stojíme před novými problémy, které lze možná zařadit do stejné škatulky - návrh API, škálovatelnost, efektivita atd. - ale jejich konkrétní řešení se bude vždy lišit a bude vyžadovat kreativní přístup. Kreativita bohužel nelze nalajnovat. Nemůžete si říci tak: teď budu kreativní, za osm hodiny zavřu počítač, a půjdu domu. Kreativita jde ruku v ruce se svobodou a se svobodou přichází pocit odpovědnosti (interní motivace). Nenařizujte lidem, jak mají daný problém vyřešit, naopak podpořte jejich touhu (interní motivace) problém vyřešit, tím že jím dáte svobodou volby prostředků a způsobu řešení. Ještě lepší situace nastane, když nemusíte lidem říkat kdo a co je za problém, ale oni si to sami uvědomují a mají svobodu nejenom v řešení, ale i ve volbě priority.


Svobodu můžete dát lidem například tím, že budou moci věnovat určitý čas na vlastní projekty. Kromě toho, že projevíte lidem důvěru, velmi elegantně získáte zpětnou vazbu o tom, co je baví a co by chtěli dělat. Velmi se nám v tomhle směru osvědčily hackathony. Je to win-win strategie, vývojáři pracují na něčem užitečném pro firmu a zároveň dělají na něčem co zajímá. Prakticky z každého hackathonu se vyloupne něco užitečného, co by se tam organickou cestou přes projektový backlog případně jinou formu plánování nedostalo. Určitý čas na vlastní projekty umožňuje, že různé nápady nezůstanou v šuplíku (vnitřní motivace), ale člověk má možnost se k nim alespoň jednou za čas dostat.

neděle 24. listopadu 2013

Nechte Conwayův zákon pracovat ve váš prospěch

Nějaký čas zpátky jsme řešili největší technologické problémy (technologický dluh), které nás brzdí v tom, abychom dokázali pružněji a zároveň spolehlivě doručovat nové vlastnosti. Při detailním průzkumu jsme zjistili, že většina technických problémů resp. jejich neřešení je způsobené špatně nastavenou organizační strukturou firmy. Nejenom my v GoodData, ale obecně technologické firmy se snaží, alespoň z mojí zkušenosti, řešit technologické problémy aplikováním jiných technologií, které přináší jiné rodinu problémů, čímž pádem ovšem zakrývají původní příčinu. Tato původní příčina většinou sedí na pozorování, které udělal v 70. letech pan Melvin Conway a je základem zákonu po něm pojmenovaném. V tomto článku si povíme o tom co je to Conwayově zákonu, jaké jsou jeho důsledky, jak může pracovat pro nás i proti nám.


V roce 1968 Melvin Conway popsal následující princip

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure

Historicky jsme měli jednu code base, kde ležely všechny zdrojové kódy, protože jsme měli i jeden a později dva týmy. Postupně se tento stav začal stávat neudržitelný, protože jsme týmů měli několik a každý z nich měl jinou produktivitu. Nedávalo smysl mít jednu verzovací strategii, když jeden tým dodával nové vlastnosti dvakrát do týdne a jiný jednou za měsíc. Začali jsme postupnou demontáží odlupovat jednotlivé komponenty (služby) patřící daným týmům. Šlo to velmi dobře pro komponenty, které vznikly později, a které měly od počátku jasně definovaný tým. Celý proces začal drhnout ve chvíli, kdy jsme narazily na code base, která byla nějakým způsobem rozdělená, ale protože s ní historicky pracoval jeden tým, neexistovalo jasné rozhraní.

Ten tým vždycky seděl v jedné kanceláři, maximálně ve dvou, a proto bylo rozdělení jenom velmi formální - o existenci nějakých rozhraní nemohla být řeč. Proč si taky patlat s formalizováním rozhraní, když jeho uživatel sedí metr a půl od mého stolu. Na všem jsme přece schopni dohodnout se prostým houknutím přes stůl. Jinými slovy propletenec té původní code base odpovídal tomu, že všichni chlapci spolu "navařili" v jedné místnosti. Při rozplétání špaget jsme vytvořili tým, který se pustil do jejich rozplétání. Povedlo se identifikovat komponenty a rozhraní mezi nimi, podle kterého se začalo refaktorovat. Jak už to tak bývá, provedla se jenom první fáze, potom získaly prioritu naléhavější úkoly.

Po nějaké době začal být tento problém opět akutní a my jsme náš plán uvedli znovu do chodu. Oproti původnímu setupu jsme ovšem refaktor distribuovali mezi několik týmů, kterých se rozdělení týkalo. A nestalo se vůbec nic. Abych byl přesnější stalo se to, že jednotlivé týmy vychrlily seznam nutných závislostí na jiné týmy, kterými podmiňovaly začátek vlastní práce.

V druhém případě navržený design přesně kopíroval komunikační strukturu organizace - několik týmů, které vytvořily seznam nutných úkolů. V prvním případě jsme měli jeden tým, který dokázal operovat bez výrazné participace zbytku. Asi není potřeba zdůrazňovat, že druhý přístup - jeden společný cíl s distribucí vzájemně závisejících úkolů mezi více týmu - je mnohem složitější na provedení. Nevím jaká je vaše zkušenost, ale to moje mi říká, že druhý přístup málokdy funguje. Už jenom protože udržet úroveň potřebné komunikace bude složité.

Pokud by existoval jeden ad hoc tým, do kterého by se vybrali zástupci jednotlivých týmů za komponenty, věřím že by vznikly jasně definované komunikační kanály, které by zajistily, že celá práce (design v širším slova smyslu) neskončí ve slepé uličce. Na tomhle případu vynikne Conwayův zákon hned dvakrát. Za prvé, struktura code base přesně kopírovala to, že spolu seděli programátoři v jedné kanceláři - komunikace přes rameno. Za druhé, design řešení problémů, porcování code base, odpovídal struktuře týmů a to jak spolu komunikovaly - výměna úkolů.

Conwayův zákon může pracovat ve váš prospěch. Pokud znáte předpokládaný design systému, na který míříte, můžete vytvořit týmy, které budou tento design kopírovat. To se netýká jenom začátku, ale prakticky jakékoliv fáze vývoje. Představte si, že bude chtít mít striktně oddělený frontend a backend, pak asi nejlépe vytvoříte dva týmy - jeden čistě backendovy a jeden čistě frontendový. Tímhle rozdělením dosáhnete vzniku rozhraní, které bude přesně kopírovat to, že máte dva týmy. To stejné může platit, když budete chtít dělat architekturu orientovanou na služby. Pak vytvoříte týmy, které budou kopírovat jednotlivé služby.

Ways must be found to reward design managers for keeping their organizations lean and flexible. There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity

To byl ještě jednou Melvin Conway a tento výrok se datuje do dob, kdy byl život většiny signatářů Agile manifestu ohraničen kolébkou, dudlíkem, plenkami případně houpacím koněm. Každý systém se mění a tomu by měla odpovídat i změna organizační struktury. V GoodData jsme tuhle zkušenost udělali několikrát ať již při přechodu k architektuře orientované na služby a nebo při přechodu na DevOps. Systém nám přestal škálovat lidsky a technicky. Lidsky neškálovat znamená, že dodání nových programátorů nemá odpovídající dopad na produktivitu. Technicky neškálovat znamená, že s přidáním zdrojů nedošlo k zvýšení výkonu. Postupem času jsme metodou pokusů, omylů a částečných vítězství došli k tomu, že architekturu systému je úspěšně možné změnit jenom pokud jí odpovídá organizace týmů. Nemůžete říkat, že děláte DevOps když máte dvě oddělení - Dev a Ops.

Melvin Conway byl nejenom skvělým pozorovatelem, ale i vizionářem, který přesně popsal vztah mezi organizací a její strukturou a architekturou (designem), který je tato organizace schopna vyprodukovat. Jeho odkaz leží v tom, že systém a jeho změny musí jít ruku v ruce se změnami organizační struktury.

Poznámky

úterý 19. listopadu 2013

CZ Podcast 88 - Behavior-driven development

Další díl jsme zasvětili povídání o Behavior-driven development a světem zkratek BDD, TDD nás provedl Daniel Kolman. Probrali jsme co je to BDD, vztah k TDD. Proč to vzniklo a jaké problémy to má adresovat. K čemu se to hodí/nehodí, jestli to může fungovat v
staticky typovaných jazycích, jak testovat legacy kód, knihovny, tooling a hlavně rozdíl mezi Chicagskou a Londýnskou školou. Vaše ohlasy sdílejte na naší fan stránce.

pondělí 11. listopadu 2013

Logovací vzory - stopování požadavků, logování průběhu, agregované zprávy a výjimku z pravidla

V tomto článku se podíváme na několik vzorů logování, které zvyšují čitelnost logu a umožňují mnohem efektivnější správu systému a vhled do toho co se právě stalo.

Background

GoodData je Business Inteligence platforma provozovaná jako Software As A Service. Koncový uživatel konzumuje GoodData ve formě interaktivních grafů a reportů v prohlížeči. Uživatel si nemusí nic instalovat, všechny služby nutné pro analýzu dat - jako je ETL, ROLAP, model - běží v rámci GoodData platformy někde v cloudu. Rozhraní, přes které se komunikuje s okolním světem i uvnitř platformy, představuje REST (s výjimkou uploadu dat přes WebDAV). Obecně řečeno jakákoliv interakce s GoodData platformou je HTTP požadavek a to platí i pro interakci mezi jednotlivými službami uvnitř. Jednomu HTTP požadavku na vstupu odpovídá několik vnitřních HTTP požadavků a většinou několik SQL příkazů případně volání do NoSQL úložišť jako je Cassandra nebo MongoDB.

Stopování požadavku

Pokud se vám jeden HTTP požadavek rozpadne na X dílčích, navíc distribuovaných přes vícero služeb, je potřeba zajistit jeho dohledatelnost. Pokud navíc dojde k chybě při jeho zpracování, musí mít klient možnost nějakým způsobem ten požadavek identifikovat. Z tohoto důvodu na vstupu zpracování každého HTTP požadavku vygenerujeme unikátní identifikátor, který cestuje s požadavkem po celou dobu jeho zpracování uvnitř GoodData, a nakonec je vrácen i klientovi. Každá ze služeb si tento identifikátor přečte/předává dál v HTTP hlavičce X-GDC-REQUEST. V případě messagingu se předává v rámci zprávy. Bez ohledu na to, jak se tento identifikátor reprezentuje na protokolové úrovni, platí že každá komponenta jej musí nastavit do logovacího kontextu. Tím je zaručeno, že každá hláška v logu bude mít tento unikátní identifikátor.


Identifikátor je možné dále rozdělit na segmenty oddělené dvojtečkou. Každá ze služeb si může libovolně přidat vlastní segment. To umožňuje filtrovat pouze logovací zprávy zprávy týkající se zpracování požadavku v rámci dané služby a všech následujících za ní. Zároveň je možné, aby tento identifikátor vygeneroval přímo klient. Například naše UI aplikace v browseru generuje první segment tohoto identifikátoru ve chvíli zobrazení nového dashboardu. Všechny HTTP požadavky v rámci dashboardu mají stejný první segment. To umožňuje dělat analýzu toho, jak rychle se načítá celý dashboard, kolik HTTP požadavků je na to potřeba atd. Segment tvoří určitý kontext, ke kterému je možné vztahovat další informace z logu.


Pokud stopujete požadavek, existuje několik informací, které se vyplatí logovat - velikost požadavku, user agent, dobu zpracování, unikátní identifikátor viz výše, URI požadavku, uživatele, HTTP status, IP adresu klienta. Většina z těchto hodnot odpovídá standardnímu Apache Access Logu. Kromě toho je dobré logovat čas události, vlákno, kategorii a severitu. Protože používáme k zpracování logů Splunk, více nám vyhovuje strukturovat logovací zprávy na klíč=hodnota.


    
2013-11-10T17:50:49.891+0100 http-bio-8080-exec-194 c.g.c.web.filter.RequestLoggingFilter INFO: action=processing_request status=end uri=/gdc/app/account/bootstrap method=GET time=74 size=8361 httpStatus=200 userAgent='Mozilla/5.0 ...' remote_address=10.250.70.65 forwarded_for='109.80.143.171' component=webapp request_id=uix94085b999276_0:bbnL3uR9mVB3FzUS auth_user=4375 project_id=fc97da87icodqn408r9m4mr25rypatrt 
    

S takto komplexně zalogované zprávy jste schopni vytěžit celkem dost informací - poměr mezi read/write operacemi, časy zpracování požadavků, sledování anomálií indikujících potenciální problém např. poměr mezi HTTP statusy, negativní odchylky z dlouhodobě naměřených dat. Následující dashboard je právě ukázkou měření anomálií. Z dlouhodobě nasbíraných dat známe dobu odpovědí jednotlivých REST resourců. Každý čtvereček zobrazuje měřenou hodinu a barva signalizuje odchylku - zelená ok, žlutá došlo k malému zpomalení, červená - došlo k většímu zpomalení. Bílé kostičky signalizují nedostatek dat případně downtime.



Logování průběhu

Zpracování požadavku prochází většinou různými fázemi - existují minimálně tři - začátek, konec úspěchem, konec neúspěchem.


try {
    log.info("action=started ...");
    doSomething();
    log.info("action=finished_ok ...");
}catch(RuntimeException e) {
    log.info("action=finished_error", e);
}

Tímhle triviálním způsobem jste schopni jednak zjistit poměr mezi úspěšnými/neúspěšnými běhy. Pokud byste jenom vyhazovali výjimku, mnohem hůře by se vám to v logu párovalo. Nemluvě o faktu, kdy má běh několik fází.


Agregace logovacích zpráv

V případě kdy logujeme detaily, např. časy provedení různých částí programu a jsme omezeni velikostí logu z důvodu jeho zpracování, vyplatí se agregovat na zprávy na aplikační úrovni. Obzvláště pokud má každá logovací zpráva velkou režii (logovací kontext).


long start = currentTimeMillis();
foo();
log.info("foo time={}", currentTimeMillis() - start);
start = currentTimeMillis();
hoo();
log.info("hoo time={}", currentTimeMillis() - start);
start = currentTimeMillis();
bar();
log.info("bar time={}", currentTimeMillis() - start);



long start1 = currentTimeMillis();
foo();
long start2 = currentTimeMillis();
hoo();
long start3 = currentTimeMillis();
bar();
log.info("foo time={} hoo time={}  bar time={} ", start2 - start1, start3 - start2, currentTimeMillis() - start3);

My produkujeme řádově stovky gigabajtů logů denně a mohlo by se zdát, že nehraje roli jestli se někde zaloguje o dvě řádky více nebo méně, ale opak je pravdou. Představte si, že tyhle tři nebo jedna řádka se generují s každým HTTP požadavkem. Řekněme, že včetně logovacího kontextu má jedna řádka 500b, na produkci máme 13 milionů HTTP volání za 24 hodin. To dělá při jedné logovací řádce 6GB logů denně a při třech 18GB logů. Další výhodou těchto agregovaných zpráv je lepší čitelnost pro člověka. Pokud do logu přibývá stovky řádek za sekundu, musíte si logovací zprávy nějakým způsobem dohledat. V rámci agregované zprávy máte vše na jednom místě. Daní za přehlednost a menší velikost logu je větší komplexita logovacího kódu.


Výjimka z pravidla

Bez ohledu na to, jaký nástroj budete používat na zpracování logů, vždy budete mít mantinely, mezi kterými se budete muset pohybovat. Právě vybalancování mezi tím, co je potřeba nutně logovat a tím co už je v uvozovkách odpad, nejde moc generalizovat. Je to tedy iterativní proces, kdy bojujete s tím, že vám v logu něco chybí nebo naopak přebývá a vytékají vám data někde jinde. Asi jako nejlepší kompromis mi přijde logovat výjimky z pravidla. Pokud jsou potřeba další detaily, zvednout úroveň logování v runtime pro danou kategorii a nebo udělat přímo změnu kódu.



public boolean verifyCredentials(String userName, String password) {
    log.info("Username '{}' exists", userName);
    ...
    log.info("Password matches", password);
    ...
    log.info("Account is active");
    ...
    return ...
}

Výjimka z pravidla je v tomhle případě neplatnost přihlašovacích údajů. V takovém případě nemusíme logovat, že nějaké podmínka (existence účtu, správné heslo a platnost účtu) byla splněna, ale naopak splněna nebyla.


public boolean verifyCredentials(String userName, String password) {
    log.info("Unknown username={}", userName);
    ...
    return false;
    
    log.info("Password doesn't match", password);
    ...
    return false;
    
    log.info("Account for username={} has not been activated", username);
    ...
    return false;
    
    return ...
}

Tímhle reverzním způsobem máme v 99% nulovou zátěž, protože vše se chová očekávaně. V tom jednom procentu případů. kdy si zákazník stěžuje, na nemožnost přihlášení, mu můžeme z logu jasně říci v čem je problém. Tenhle kód se dá samozřejmě ještě zrefaktorovat.



public boolean verifyCredentials(String userName, String password) {
    boolean verified = false;
    String reason = "Password doesn't match";
    try {
        ...
        reason = "";
        return verified;
    } finally {
        if(!verified) {
          log.info("Supplied credentials for username={} are not valid. reason={}", username, reason);
        }
    }
}

V tomto článku jsem se pokusil sepsat pár postřehů logování. Určitě máte i vy nějaké tipy a postřehy, které jste si vypěstovali, proto budu rád pokud se o ně podělíte.

Starší články k tématu

neděle 10. listopadu 2013

CZ Podcast 87 - Clojure v praxi

Kdo tenhle vlak zastaví? V 87. dílu jsme se věnovali Clojure v praxi. Samozřejmě jsme se museli dotknout i samotného funkcionálního programování, zabrousili jsme k databázi Datomic a nebo nástroji Cascalog. Hostem tohoto dílu jsou pánové Daniel Škarda, Jiří Knesl a Tomáš Svárovský.

neděle 3. listopadu 2013

CZ Podcast 86 - NSA a kauza Snowden

Do tohoto dílu jsme na vaše četná přání pozvali předního českého kryptoanalytika Tomáše Rosu. Jako aktuální téma jsme vybrali fungování organizací jako je NSA ve světle kauzy Snowden. Jaký náskok a v čem mohou mít tyto agentury, veřejné mínění versus realita, se kterou jsme konfrontování v mediích. Vaše ohlasy uvítáme na naší oficiální stránce.

Zmiňované materiály

Tempest

Článek jednoho z autorů DES, který mj. dokládá, že NSA znala tzv. diferenční kryptoanalýzu nejméně 15 let před tím, než k ní dospěla veřejná obec. Na tuto kauzu se v povídání nedostalo, nicméně je to taková čítanková klasika (viz str. 244 článku:"…(NSA) also provided technical advice to IBM…", "…After discussion with NSA, it was decided that…"), takže si zaslouží být zmíněna alespoň takto.


Podivný generátor pseudonáhodných čísel Dual_EC_DRBG je pěkně zpracován zde.


Pro zájemce o kvantové počítače přidáváme k dobru pár odkazů na populární články, které Tomáš s kolegy napsali v roce 2002 pro CHIP u příležitosti onoho slavného rozkladu 15 = 3 * 5.

pondělí 21. října 2013

CZ Podcast 85 - Stavba datového centra

V tomto díle byl hostem Stanislav Višňovský a hutným tématem byla stavba datového centra. Tedy oblast, ke které si běžně aplikační vývojář nečuchne. Cílovou platformou byl Rackspace a přechod z public cloudu AWS, role OpenStack a HW sizing, to co poskytuje private cloud a další zajímavosti.

úterý 15. října 2013

CZ Podcast 84 - Vývoj aplikací v prostředí webového prohlížeče

Právě v prodeji na stáncích 84. díl s podtitulem i my JavaScriptaři budeme mít jednou takový pěkný ekosystém jako máte vy kluci v Jave. Sice se nám bude zdát Java hrozně těžkopádná, ale už teď jsme na ceste k něčemu podobnému. Teď vážně, určitě si to poslechněte, tenhle díl stojí za to!

pondělí 14. října 2013

Team geek postřehy

Nejoblíbenějším rozhraním pro komunikaci programátora s okolním světem je kompilátor, ačkoliv jeho výstup bývá občas lehce nekompatibilní a těžko použitelný pro komunikaci s dalšími lidmi. Většina geeku mylně pokládá technickou stránku software za jediné kritérium úspěchu. Mnohdy ovšem, k velké nelibosti geeku, rozhoduje lidská stránka vývoje - jak si lidé rozumějí a respektují jeden druhého, jak spolu komunikují uvnitř i navenek týmu směrem k managementu a zákazníkovi. Lidskému faktoru a jeho vlivu na vývoj software se věnuje kniha Team Geek s podtitulem A Software Developer's Guide to Working Well with Others. V tomhle článku vám zkusím přiblížit pár postřehů, které mě v knize zaujaly.


Pokora, Respekt a Důvěra

Almost every social conflict can ultimately be traced back to a lack of humility, respect, or trust.

Centrální myšlenkou knihy je aplikování třech pilířů - Humility (Pokora), Respect (Respekt) a Trust (Důvěra).


Pokora
Nejsem středobodem vesmíru a už vůbec nejsem neomylný. Jsem vždy otevřen k učení nových věcí a vlastnímu zdokonalování.
Respekt
Respektuji individuální schopnosti a možností lidí se kterými pracuji.
Důvěra
Věřím že ostatní jsou kompetentní dělat správné věci a rozhodnutí ve správný čas.

Celou knihou se jako červená nit táhne důraz na potlačení vlastního ega. Je to docela pochopitelné, protože jak autoři správně poznamenávají: vývoj software je týmovým sportem. Jednotlivé individuality dávají svoje ego ve prospěch týmu a týmové ego je to jediné, co se posiluje.


Kultura

Budování týmu stojí a padá s kulturou, která definuje formální i neformální pravidla, podle kterých tým funguje. Kultura a lidé, které si vybíráte a najímáte do týmu, jsou spojené nádoby.

A strong culture gives you focus, efficiency, and strength, and these things make for a happier team.

Silná kultura se vyznačuje maximálním zaměřením na doručování kvalitního software. Oproti tomu slabá kultura je zaměřena na jiné aspekty. Pro mě osobně je jedním ze znaků slabé kultury například trollovaní nebo neustále meetingování. Pokud veškerou svou energie vrhnete do plamenného diskutování nad nesmrtelností brouka, získáte ocenění přátel entomologického kroužku, ale doručení kvalitního software to nepomůže ani o milimetr. Zkrátka a jednoduše ztrácíte tah na branku a na to jediné se tu hraje.


If your team’s primary focus is anything other than that (e.g., partying, attending meetings, practicing one- upmanship) your team may bond tightly, but you won’t get very much software written.

Atributy silné kultury

  • Mission statement - pokud chcete, aby všichni táhli za jeden provaz, pokud možno jedním směrem, je potřeba jej definovat. Jeho znalost hraje roli nejenom při strategických rozhodnutích, ale i při běžných rozhodnutích.
  • efektivní meetingy
  • team ego (již bylo zmíněné)
  • komunikace - nastavte vhodné komunikační kanály (diskuzní skupiny, on-line chat, designové dokumenty). To je důležité nejenom pokud máte geograficky distribuovaný tým, ale i pro případ, kdy retrospektivně zkoumáte důvody nějakého rozhodnutí.

Samostatnou kapitolou silné i slabé kultury je způsob, kterým děláte rozhodnutí. Silná kultura se vyznačuje spíše konsensuálním rozhodováním, slabá se spíše vyznačuje rozhodnutím od shora (top down). Konsensuální rozhodování více odpovídá pilířům HRT a je přitažlivá díky svobodě a autonomii. Pokud chcete najmout ty nejlepší inženýry, můžete jenom těžko očekávat, že se budou podřizovat rozhodnutím, která za ně bude dělat někdo jiný. Takoví inženýři půjdou spíš za kulturou, která jim umožní podílet se na rozhodovacím procesu.

Formování kultury je značně ovlivněné výběrem lidí. Pokud najmete lidi, kteří nebudou sedět do vaší kultury, například tím že nebudou chtít potlačit vlastní ego ve prospěch týmu, dojde k jejímu totálnímu rozkladu. Ani sebelepší individualita nestojí za to, abyste měnili kulturu. Nezapomeňte, že vývoj software je týmový sport. Jednou z vlastností každé kultury je schopnost přitahovat lidi smýšlející podobným způsobem. A naopak kultura je určitým způsobem dále formuje.

Organizace

Každá organizace, ve které budete pracovat, má svoje vlastní pravidla a procesy, podle kterých funguje. Pokud dokážete tyhle procesy a pravidla pochopit, můžete je ohnout, aby pracovaly ve váš prospěch. Existuje pár technik, které vám v tom pomohou. Ze svojí zkušenosti a pár let života v korporaci shledávám některé z nich jako velmi efektivní.

Žádejte odpuštění ne povolení
Je jednoduché na někoho svalit odpovědnost, tím že se ho zeptáte, jestli něco můžete udělat. Máte sice krytá záda, ale zase je větší pravděpodobnost, že uslyšíte ne. Zároveň se nikam nikdy neposunete. Někdy se vyplatí to prostě zkusit a pokud to nevyjde, omluvit se a požádat o odpuštění.
Pokud něco nejde prosadit ze shora, prosaďte to ze spodu
Pokud se vám nedaří vaše nadřízené o něčem přesvědčit, například o tom, že je potřeba dělat agilní vývoj, udělejte to od spodu. Najděte dostatečnou podporu mezi svými kolegy, začněte to dělat guerillovým způsobem a pokud se to ujme, nadřízení nebudou mít jinou možnost než to akceptovat.
Šedá ekonomika
Moje oblíbená. V každé firmě funguje spolupráce, která není řízená žádnými procesy. Tým A dělal nějaký nástroj, potřebuji s ním poradit, zajdu za nimi a oni mi pomohou. Až budou něco potřebovat oni od mého týmu, mohou si být skoro jistí, že jim vyjdeme vstříc. Služba, laskavost bez nároku na protislužbu.

Vedení lidí

Bývá pravidlem, že po nějakém čase se z čistě technické pozice, kde odpovídáte jenom sami za sebe, posunete do pozice, kdy budete vést jiné lidi. Existuje celkem dost způsobů, jak to podělat a existuje pár tipů, které vám mohou docela dobře posloužit. Každý vedoucí by si měl uvědomit, že jeho ultimátním cílem je ochraňovat tým a odstraňovat z cesty všechny překážky, na které tým narazí během vývoje. Kromě technické stránky, která nemusí hrát již tak významnou roli, si při vedení lidí budete muset poradit překvapivě především s lidskou stránkou. Správný lídr by se měl opřít o HRT pilíře a pomocí nich nastavit kulturu, o které byla již řeč.

  • Strach z neúspěchu. Lidé kteří mají strach z neúspěchu nepodstupují žádné riziko. Ten kdo nepodstupuje žádné riziko, může dosáhnout jenom omezených výsledků. Podporujte kulturu, ve které není důsledkem neúspěchu jakýkoliv trest, ale ponaučení. Zároveň podporujte rychlé selhání (fail fast). Pokud něco nefunguje, tak ať to víte rychle. Dosáhnete mnohem lepších výsledků, protože lidé se na sebe nebudou bát vzít riziko. Pokud alespoň jednou za rok neselžete, znamená to, že na sebe berete malé riziko.
  • Ignorování lidských obtíží. Každý se občas dostane do situace, kdy není schopen formálně plnit povinnosti dané pravidly firmy. Máte skvělého podřízeného, který ovšem každý den dojíždí do práce dvě hodiny a díky tomu musí každý den odcházet ve čtyři odpoledne ačkoliv je oficiální pravidlo, že nikdo nesmí odejít před pátou. Povolte mu to nebo to pravidlo nějak obejděte, on vám to v budoucnu mnohokrát vrátí.
  • Zacházení s lidmi jako se skupinou školáčků. Nečekejte, že pokud budete brát svoje podřízené jako malé smrady, že se tak nezačnou chovat. Tohle je hlavně mířené na micromanagement. HRT princip, projevte ke svým podřízeným Respekt a Důvěru.
  • Najímání horších lidí. Snaha najmout lidi, kteří nebudou tak schopní jako já. Strach o svoje vlastní místo a najímání lidí, které vždycky dokážu vhodně zmanipulovat. Měl by platit opak najímejte lepší a schopnější lidi než jste vy sám. Kromě toho, že potom nemusíte mít strach odjet na dovolenou, bude vás to nutit se neustále zlepšovat.
  • Ignorování podřízených s horší výkonností (low performers). Pštrosí politika vám v tomhle přinese víc problémů než užitku. Buďto za ty lidi budete muset makat víc vy nebo někdo jiný v týmu. Dlouhodobě neudržitelné. Zkuste si s nimi sednout, nastavit si jasné úkoly a cíle, pravidelně si kontrolujte progress a pokud to nejde, prostě se s nimi rozlučte.
  • Kompromisy při najímání. Máte otevřenou pozici, dostanete deset životopisů, pět si jich pozvete na pohovor a vybere toho nejlepšího z nich přestože to nemusí být člověk, kterého byste za jiných podmínek přijali. Dlouhodobě vede k degeneraci týmu. Je lepší nenajmout než najmout někoho jenom protože zrovna můžete. Zaměřte se na kvalitu.

Motivace

Docela mě zaujala kapitola věnovaná motivaci lidí. Existují vnitřní a vnější motivace. Vnější motivace vychází z okolních stimulu, jako jsou například peníze. Vnitřní motivace z vnitřních stimulů např. pocit spokojenosti, vidění smyslu v tom co děláme atd. Vnitřní motivace má větší dopad na celkovou produktivitu než motivace vnější. Největšími stimuly vnitřní motivace je - autonomie, cíl a mistrovství. Jinak řečeno, pokud chcete lidi efektivně motivovat, dejte jim dost dobrý cíl, ke kterému se upnou, volnost aby na něm mohli pracovat a nechte je to dělat, aby se zlepšili.


Kniha toho obsahuje samozřejmě více, než kolik se vejde do jednoho článku. Určitě bych ji doporučil pročíst, protože není nijak tlustá a dá se zvládnout s trochou snahy za pár dní. K dispozici dávám ještě mind mapu mých poznámek. Jo a ještě jsem našel jednu kratší rezenzi na blogu SW samuraje.

čtvrtek 10. října 2013

Časté chyby při logování - chybějící kontext a hint

Logování (logging) a jeho výstup je mnohdy jediným prostředkem k diagnostikovávání problémů, které vznikají za běhu aplikace. Jednou z chyb, které se často dopouštíme, je chybějící kontext, který umožňuje i bez znalosti zdrojového kódu určit k čemu mohlo dojít. Budu to vysvětlovat na účelově sestrojeném kousku kódu s nákupním košíkem.

public class ShoppingCart {
  private List items;

  public void addItem(Object o) {
    if(o instanceof Item) {
      items.add(o);
    } else {
      LOGGER.warn("Object is not of type Item");
    }
  }
}

Problém té logovací hlášky je v tom, že říká jenom to co se stalo, ale to je informace, která je vám užitečná pouze pokud máte zdrojový kód a chápete důsledky toho k čemu došlo. Pokud dojde k nějakému problému, typicky o několik pater abstrakce výše, těžko se vám bude hledat příčina. Správně by ta logovací hláška měla říkat nejenom to k čemu došlo, ale i jaký to má dopad.


LOGGER.warn("Cannot add item {} to shopping basket because is not of type Item.", o);

Kromě původní informace nám do logovací zprávy přibylo vysvětlení k čemu došlo (není možné přidat položku), ze kterého plyne jasný důsledek (v košíku nebude). Pokud například víme, jak k takové situaci, došlo je dobré to rovněž zalogovat. Může to být hint, který ušetří spoustu práce.


LOGGER.warn("Cannot add item {} to shopping basket because is not of type Item. It may be caused by using an old version of client. Please check the log, version 2.0 or higher is required by add item operation.", o);

Pokud hrozí zanesení logu těmito logovacími zprávami, a vy potřebujete ušetřit místo, lze přidat vysvětlení ve formě odkazu ať již klíčem do slovníku logovacích událostí a nebo na konkrétní stránku, kde lze získat ten samý kontext.


LOGGER.warn("Cannot add item {} to shopping basket because is not of type Item. See WARN-123", o);

LOGGER.warn("Cannot add item {} to shopping basket because is not of type Item. See http://bit.ly/1g3eFoK", o);

S trochou snahy se dá velmi jednoduše vytvořit kontext, pomocí kterého i člověk neznalý zdrojového kódu pochopí k čemu došlo, jaký to má dopad a ideálně jak k tomu mohlo dojít. Nepodceňujte logování ani pokud máte vždy zdrojové kódy k dispozici. V našem modelovém případě nám hint slouží jako permanentní vysvětlení nějakého externí podmínky, kterou bychom si po nějakém čase už těžko vybavili - není přímo zřejmá z kódu vlastní třídy.


Starší články na téma logování: Pár tipů na lepší logy

pondělí 7. října 2013

Znovupoužitelnost vs. agilita

Původně jsem chtěl psát o tom, jak je důležité vizualizovat cokoliv, na čem děláte a jaký efekt měla instalace TV resp. operační dashboard s naší produkcí, ale pak mi běh událostí připomněl téma, které nosím v hlavě delší dobu. Téma souvisí to s naším inženýrsko-programátorským přístupem k znovupoužitelnosti. Tenhle článek nebude o znovupoužitelnosti kódu, lépe řečeno nejenom o něm, ale raději o znovupoužitelnosti a jejím vztahu k agilitě. O tom, že od určité velikosti organizace působí znovupoužitelnost proti agilitě. Příkladem, na kterém to chci ilustrovat je 5 různých frameworků, které používáme k testování REST API.

Zní to strašidelně, když vám řeknu, že máme 5 frameworků, každý v různé fázi užití, které používáme pro testování našeho veřejného a interního REST API. Asi je na místě vysvětlení, jak jsme se do tohoto stavu dostali. Historicky byla velká část code base napsaná v Perlu a tomu odpovídalo, že i testovací framework byl v Perlu. Nevím jestli tehdy neexistoval nějaký open source framework, a dneska je to i jedno, ale s tímhle frameworkem jsme žili od pradávna. Když jsme přibrali další jazyky, Javu a Erlang, začalo tichá revolta proti použití našeho vlastního testovacího frameworku notabene v Perlu. V programátorském světě existuje jenom málo jistot, ale jedna naprosto neotřesitelná je, že nechcete používat jiný programovací jazyk než ten váš. Jinými slovy, Perlista raději obětuje malíček, než aby napsal něco v Jave a naopak. Je to věc náboženství a přes to nejede vlak. Můžete to lidem nařídit, ale jediné čeho dosáhnete, budou v uvozovkách sabotáže a vedení svatých válek. U nás vedla tato neochota k slabému pokrytí testy.

Paradoxně nám v této situaci pomohl růst firmy, kdy se zněkolikanásobil počet vývojářů. Kromě organizačních změn musely být provedené změny v architektuře aplikace směrem k službám. V novém rozložení sil získaly týmy autonomii a bylo plně v jejich kompetenci, jakým způsobem zajistí kvalitu dodávaných služeb. Efektivně přestalo platit omezení, že je tu jedná technologie, kterou musejí všichni používat na testování, ale místo toho začalo platit pragmatické use right tools for right things. Různé týmy začaly pracovat na vlastní strategii pro testování. Tím jsme se dostali do stavu, kdy sice máme několik testovacích frameworků, ale výrazně se zvýšilo pokrytí automatickými testy a dokonce ochota ty testy psát.

Je na místě otázka proč to celé nekoordinovat, proč neudělat jeden testovací framework, který by vyhovoval všem a ten znovupoužít. Kromě dogmatického odmítání cizích jazyků, o kterém jsme už psal, tu jsou i čistě pragmatické důvody. Jak dlouho by trvalo vytvoření takového frameworku a jak vůbec zajistit, aby vyhovoval všem? Odpovím protiotázkou, je lepší mít 5 testovacích frameworků vzájemně si duplikujících část funkcionality s 50% pokrytím testy a nebo strávit půl roku návrhem a implementací univerzálního frameworku s 5% navýšením pokrytí testy? Osobně si myslím, že první možnost není sice optimální, ale daleko lepší než ta druhá.

Podle mých zkušeností nefungují infrastrukturní projekty, které se designují od zeleného stolu. Možná je to tím, že ty týmy neumí spolupracovat agilně a zaměřují se na detailní specifikace, které jsou nekompletní. Každopádně výsledkem bývá frustrace všech zainteresovaných. Na druhou stranu: protože jsem ještě neviděl černou labuť, neznamená to, že neexistuje.

Vývoji software se nejlépe daří v podmínkách kopírujících pravidla volného trhu. Dejte lidem svobodu - nesvazujte je pokud možno regulacemi - a dopřejte jim možnost volby - odpovědnost spojená s možností dělat rozhodnutí. V takových podmínkách vznikají řešení, která si sice mohou vzájemně konkurovat, ale dříve nebo později vyplavou na povrch ty nejlepší. Proto věřím, že těch našich pět frameworků se postupně setřese na dva hlavní, které se stanou mainstreamem pro zbytek firmy. Obrovskou výhodou tohoto přístupu je fakt, že vzniká ze spodu od reálných uživatelů (mimochodem jeden z rysů Agile vývoje) přirozeným výběrem, nikoliv Big Up Front Designem. Agilita, i za cenu určité neefektivity, by měla mít přednost před předčasnou optimalizací v podobě zavádění znovupoužitelných One Size Fits All řešení.

pondělí 30. září 2013

CZ Podcast 82 - Rozhovor s Michalem Illichem

Do 82. dílu zavítal Michal Illich - tvůrce fulltextového vyhledávače Jyxo.cz, majitel automobilu tesla a vůbec úspěšný vývojář a podnikatel. Kromě výše uvedených témat, která se přímo nabízela, jsme zabrousili do machine learningu. Doufáme, že se vám bude tento díl opět líbit. Vaše ohlasy uvítáme na naší fanouškovské stránce.


sobota 21. září 2013

Agilním vývoj není Scrum nebo Kanban


Když jsem byl malej smrad, na Štědrý den mi rodiče kladli na srdce, abych se postil - rozuměj nejedl maso až do štědrovečerní večeře - jinak neuvidím zlaté prasátko. To jsem samozřejmě poctivě dělal až do dovršení věku deseti let. Pak mi došlo, nejenom že žádné prasátko neuvidím, natož zlaté, ale že vlastně ani nevím co si pod tím mám představit. S pojmem Agilní vývoj případně Agile to má většina vývojářů a manažerů podobně. V tom lepším případě si představí Kanban nebo Scrum, případně nějakou konkrétní techniku - párové programování, standup meetings. V tom horším vůbec nic případně to zaškatulkuje pod klíčové slovo bullshit. Většinou je spojuje, že teoreticky zažili všechno, prakticky nic, a od určité doby přestali věřit podobně jako já na to zlaté prasátko. Cynik by mohl dodat, že obojí je to pěkná pohádka.

V tomhle článku se pokusím rozmetat představu, že praktikování Scrumu nebo Kanbanu vede k agilnímu vývoji. Je to asi stejná mentální zkratka, jako od sexu k početí potomka. Můžete mít orální sex, ale jenom těžko můžete očekávat, že z toho někdo otěhotní. Úplně stejně to funguje s agilním vývojem. Praktikujete Kanban a místo agilního vývoje máte produkt doručovaný jednou za půl roku s nulovou přidanou hodnotou zákazníkovi. Zatímco ten orální sex si někdo užije, po zpackaném agilním vývoji zůstane pouze frustrovaný zákazník a zpruzení vývojáři. Když dva dělají totéž nebývá to obvykle totéž.

Položme si jednoduchou otázku. Existoval agilní vývoj, před tím než byly představené metodologie jako Kanban? Samozřejmě, že existoval, jenom se tomu tak neříkalo. Mimochodem techniky, které se postupem času zpopularizovaly, jako například Párové programování nebo Test Driven Development existovaly pravděpodobně ještě před tím, než někoho napadlo přemýšlet o tom, že z nich udělá sadu pravidel. Pokud tedy agilní vývoj existoval před tím, než se ho snažil někdo sešněrovat do řekněme Scrumu, pak ovšem platí, že můžete dělat agilní vývoj, bez toho aniž byste se snažili slepě aplikovat řekněme opět Scrumu. Abych nebyl chycen za slovo, samozřejmě že Scrum nebo Kanban jsou velmi pružné a navržené, aby je bylo možné upravit podle kontextu použití, jak vám jistě řekne nejeden agile expert. Ještě jednou, není důležité jak tomu říkáte, ale jak to funguje.

Vezměte si prosím tužku a papír případně si jinak zaznamenejte, to co si představujete pod agilním vývojem.

Máte je? Výborně! Za chvilku se nám budou hodit.

Další část našeho cvičení pokračuje, kterou z možností (levou nebo pravou) v níže uvedených větách intuitivně preferujete.

  • Jednotlivci a interakce před procesy a nástroji
  • Fungující software před vyčerpávající dokumentací
  • Spolupráce se zákazníkem před vyjednáváním o smlouvě
  • Reagování na změny před dodržováním plánu

Pokud preferujete možnosti nalevo od slova před, pak máte správné mentální nastavení pro odbourání jakýchkoliv stereotypů o agilním vývoji. Pokud preferujete možnost napravo od slova před, pak v uvozovkách stále věříte na zlaté prasátko. V každém případě předchozí věty jsem si nevycucal z prstu, ale pocházejí z Agile manifesto tj. dokumentu absolutně zásadního k pochopení agilního vývoje. V tom samém dokumentu najdete 12 jednoduchých pravidel, kterými je definován agilní vývoj.

  1. Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru.
  2. Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka.
  3. Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody.
  4. Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu.
  5. Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci.
  6. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace.
  7. Hlavním měřítkem pokroku je fungující software.
  8. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale.
  9. Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu.
  10. Jednoduchost--umění maximalizovat množství nevykonané práce--je klíčová.
  11. Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.
  12. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.

Kolik z toho, co jste si představovali pod agilním vývojem, viz papír a tužka, vám sedí proti těmto pravidlům. Těchto 12 pravidel nic neříká o Scrumu, nic neříká o tom, že musíte dělat každý den standup meeting a dokonce to ani nic neříká o tom, jak ta pravidla realizovat. Ještě zajímavější srovnání se nabízí, pokud se snažíte používat Scrum nebo Kanban. Pokud ano, zkuste si položit otázku, jestli podle těch pravidel skutečně fungujete.

V GoodData jsme se pokoušeli dělat agilní vývoj několik let. Bohužel jsme na to šli přes Scrum a později přes Kanban a většinou selhali. Ten důvod nebyla ani jedna z těchto metodologie, ale to že jsme si nikdy neřekli, že to podle čeho chceme skutečně fungovat je těchto 12 pravidel - cíl. Scrum nebo Kanban může (a nemusí) být prostředek - cesta, jak se k němu dostat. Teprve potom, co se snažíme zaměřit na tyto pravidla, začíná agilní vývoj skutečně fungovat. Nedělejte proto stejnou chybu a místo na konkrétní metodologii si zaměřte na to, aby jste se snažili vždy fungovat podle těchto jednoduchých pravidel. Výsledkem bude skutečný agilní vývoj nikoliv jeho předstírání a lhaní si do kapsy.

neděle 15. září 2013

Nenajímejte jednotlivce, budujte tým - proč se nevyplatí klonovat Jaromíra Jágra

Jednou jsem byl na motivační prezentaci o budování úspěšné firmy. Hlavní poselství, alespoň po té době mi to přijde, spočívalo v důrazu na najímání takzvaných A-players - američané občas používají označení Rock Stars. Nikdo asi nemůže rozporovat fakt, že pokud má být firma úspěšná, musí v ní pracovat šikovní a schopní lidé. Na druhou stranu to vůbec nic neříká o tom, že byste potřebovali jenom A-players. V ideálním světě by opravdu k vytvoření skvělé firmy stačilo najmout jenom ty nejlepší (A-players). Drobná potíž je v tom, že mi nežijeme v ideálním světě, ba co hůře najímání A-players dláždí cestu do pekla. V tomto článku zkusím pomocí paralel ze světa sportu vysvětlit proč.

Tým je víc než jednotlivec

Z krátké historie sportu si vybavím jenom jeden tým sestavený z A-players, americký basketbalový Dream team na olympijských hrách v Barceloně, který měl úspěch. Za to si vybavím spoustu nepovedených pokusů sestavit úspěšný tým jenom z A-players - namátkou Real Madrid v éře El Galacticos. Předchozí věta obsahuje, ačkoliv to není na první pohled patrné, nejdůležitější slovo - tým. Když se ještě chvilku podržíme sportovní analogie, v týmovém sportu je tým více než jednotlivec. Proto nejsou ve sportu, případně velmi zřídka, úspěšné týmy složené pouze z A-players - nejlepších jednotlivců - ale týmy a sportovní organizace, které dokáží nejlépe využít vlastností jednotlivých hráčů ve prospěch týmu. Pokud přijmete fakt, že firma je tým a softwarový vývoj je týmový sport, pak se dá najít celkem dost paralel.

Kultura je víc než jednotlivec

Většina úspěšných sportovních organizací má jasně nastavenou filozofii, podle které se řídí ekonomické i sportovní fungování. Vzniká něco co bychom označili za firemní kulturu. Firemní kultura nastavuje vnitřní prostředí, tak aby byla naplněná filozofie firmy a tím pádem i její cíle. Pokud máte skvělého hráče, který nezapadá do vaší firemní kultury, existují jenom dvě možnosti. Změníte firemní kulturu a nebo ten skvělý hráč není ten pravý.


Jágrův malíček aneb team's bus factor

Během hokejového Mistrovství světa ve Vídní 2005 se po jednom ze zápasů základní skupiny, ve kterém byl zraněn Jaromír Jágr - ofenzivní eso české sestavy -, řešily šance týmu na dobrý výsledek. Vyhlídky na úspěch nebo neúspěch se točily kolem stavu Jágrova zlomeného malíčku. Nakonec vše dopadlo dobře a český tým vedený právě Jágrem dosáhl na zlato. Už se nikdy nedozvíme, jak by český tým dopadl bez kladenského barda v sestavě, ale to neznamená, že bychom se z něj nemohli poučit. Faktor štěstí nebo smůly je důležitý v jakékoliv lidské činnosti, fatální je pokud se stane středobodem nebo naopak nejslabším místem vaší strategie. Každý sportovní tým spoléhající na jednotlivce hraje doslova ruskou ruletu. Jednotlivec, byť sebegeniálnější, by měl být v jakémkoliv týmovém uspořádání nahraditelný. V knize Team geek to autoři nazývali team's bus factor: kolik lidí musí ve vašem týmu přejet autobus, aby šel projekt do kopru. Pokud je váš team's bus factor=1 znamená to, že jednoho atd. Schválně si položte otázku jaký je váš team's bus factor...


Týmová hierarchie

Nahraditelnost jednotlivce ovšem neznamená, že budete tým budovat způsobem všichni jsou si rovni. Jenom absolutní sportovní analfabet by si mohl myslet, že Jaromíra Jágra nahradí hráč čtvrtého útoku Zetoru Brno. Vždycky v jakémkoliv týmovém sportu potřebujete takzvané rozdílové hráče (A-players?). Ti plní rolí lídrů a leží na nich hlavní odpovědnost. Na druhou stranu ani oni se neobejdou bez podpory týmu. Zkuste si představit, jak by vypadal tým, který by byl složený jenom z hráčů, jako je Jaromír Jágr. Ten tým by měl zcela určitě chatrnou defenzivu a s pravděpodobností hraničící s jistotou i mizernou ofenzivu. I božský Jaromír potřebuje, aby mu někdo na ten gól přihrál. Kromě praktických důvodů by se ten tým dříve nebo později rozhádal zevnitř, protože by v autobuse neměli dostatek místa na poskládání ega všech hráčů.

Každý tým musí mít jasně definovanou hierarchii a každý hráč musí přesně znát svojí roli. Nejpatrnější je to asi v NHL, kde pozici v hierarchii týmu odpovídá nejenom platové ohodnocení, ale i patřičný ice time (čas strávený na ledě). Platí v podstatě jednoduchá rovnice: hrál jsi dlouhodobě dobře, dostaneš dobrý kontrakt, máš dobrý kontrakt, dostaneš patřičný čas na ledě, abys mohl svoje kvality prokázat. Ovšem pozor, ani v NHL se nehraje za zásluhy, týmová hierarchie nebývá rigidní co se týká personálního obsazení. Stejně i pracovní týmy, a to i ty softwarové, by měly mít jasnou hierarchii. Každý by měl znát svojí pozici v hierarchii týmu a měl by možnost v rámci ní postoupit. Všichni by si zároveň měli uvědomit, že bez týmové spolupráce se neprosadí nejenom jednotlivec, ale ani tým.


Vychovat, nekupovat

Ve fotbale je výchova a prodej hráčů obchodním modelem mnoha klubů. Pokud se bavíme o těch nejlepších hráčích, A-playerech, pak je jejich nákup velmi drahým špásem. I ty největší a nejznámější fotbalové firmy, jako je Barcelona nebo Manchester United (pozor neplést s městským rivalem City), mají spočteno, že se jim vyplatí A-playery vychovat. Kromě finančního efektu mají vlastní odchovanci ještě jednu výhodu. V klubu jsou dlouhodobě a znají jeho filozofii a kulturu. Funguje to i opačně, klub si mnohdy vychovává hráče od žákovských let a dokonale zná jeho přednosti i nedostatky. S nákupem hráčů, stejně jako s příchodem lidí z venku, je vždy spojená určitá nejistota s tím jak zapadnou a jestli budou opravdovou posilou. Ve sportu a ve fotbale zvlášť nemáte žádnou zkušební lhůtu a pokud někoho uděláte za pořádný balík na pět let, tak mu prostě těch pět let platíte. Proto platí jednoduché pravidlo, že kupovaný hráč musí být výrazně lepší než odchovanec.

Není žádný důvod neaplikovat stejná pravidla pro rozšiřování firemního týmu. Podoba se přímo nabízí. Vychovat si někoho uvnitř je mnohem levnější než ho najmout zvenku a to ještě s rizikem, že nezapadne ani do firemní kultury a ani do týmové hierarchie.


Je nepopiratelné, že jednotlivec označovaný jako A-player hraje důležitou roli v jakémkoliv týmu - softwarovém i sportovním. Vlastní tým, jeho kultura a hierarchie je ovšem důležitější než jednotlivec. Proto se soustřeďte na najímání lidí, kteří budou zapadat do vašeho týmu a ne naopak. Jinými slovy nenajímejte jednotlivce, ale budujte tým.


pondělí 26. srpna 2013

Postřehy Release It!

Kniha Release It! mě nadchla. Přestože byla vydána skoro před sedmi roky (2007) obsahuje plno velmi užitečných rad a postřehů k návrhu a nasazení aplikací do provozu. Mimochodem samotný podtitul by to řekl přesněji Design and Deploy Production-Ready software. V krátkém review na GoodReads jsem napsal, že bych si přál knihu číst před třemi roky, protože by mi ušetřila pár bezesných nocí během hašení požárů na produkci.

Kniha vychází z jednoduché premisy.


Enterprise software must be cynical. Cynical software expect bad things to happen and is never surprised when they do. Cynical software doesn't even trust itself, so it puts up internal barriers to protect itself from failures. It refuses to get too intimate with other systems, because it could get hurt.

Dnešní aplikace, ty webové především, nejsou monolitické ve smyslu závislostí na dalších systémech, ale jedná se o kompozici několika služeb viz. platební systém, mailling systém apod. Pro architekturu aplikací tvořených službami se vžilo označení Service Oriented Architecture (SOA), které se bohužel později dost zprofanovalo. Bez ohledu na to, jestli se jedná o služby interní nebo externí, každá interakce s nimi představuje riziko.

Efekt sněhové koule a pavouk na skle

Představte si, že jedete po silnici a od protijedoucího vozu odlétne kamínek, který naruší vaše přední sklo. Udělá se na něm pavouk. Od jeho středu se šíří praskliny do všech směrů. Když máte štěstí, můžete s tím ještě dojet do servisu. V opačném případě se vám celé sklo vysype a vy můžete auto v nejlepším odstavit a počkat na odtahovou službu.

V životě software máte jenom jednu jistotu: Bugs will happen. They cannot be eliminated, so they must be survived instead. Díky tomu, že architektura aplikací se změnila ve prospěch kompozice služeb, se chyba v jedné ze služeb může velmi rychle rozšířit do služby jiné a vést řetězové reakci v podobě efektu sněhové koule.

The biggest issues stat with something very small. A tiny programming error starts the snowball rolling downhill. As it gains momentum, the scale of the problem keeps getting bigger and bigger.

Šíření chyb jedné služby do jiné v rámci systému se nazývá Failure modes. Platí pravidlo, že selhání v jedné části systému zvyšuje pravděpodobnost selhání jiné části systému. To vše se umocňuje komplexitou systému, která způsobuje že dané selhání se může šířit mnoha směry.

The original trigger and the way the crack spreads to the rest of the system, together with the result of the damage, are collectively called a failure mode.
No matter what, your system will have variety of failure modes. Denying the inevitability of failures robs you of your power to control and contain them.

Once you accept that failures will happen, you have ability to design your system's reaction to specific failures

Stabilita

Stabilita je schopnost systému odolávat selháním/chybám v jeho jednotlivých částech. Selhání vznikají z impulzů a ty vedou k přetížení jednotlivých částí systémů. Představte si, že vaše marketingové oddělení dalo k dispozici slevový kupon na nedostatkové zboží nebo, že jste se dostali na titulní stranu serveru typu Slashdot. Náhlá horda uživatelů, která se na vaší aplikaci nahrne způsobí přetížení části systému, které může vést k jeho selhání. To se potom může šířit libovolnými směry.
V knize jsou popsané antivzory způsobující snížení stability systému a vzory působící naopak na její posílení.



Circuit breaker

Jako příklad vzorů zlepšujícího stabilitu jsem si vybral Circuit breaker (jistič). Podle něj je totiž navržena knihovna Hystrix (doporučuji vaší pozornosti). Místu, kde se aplikace integruje s jinou službou se nazývá integration point. Právě v tomto místě se selhání volané služby akcelerují (cascading failures) a propagují dále nebo se zde zastaví. Circuit breaker je komponenta, která se používá v integračních bodech, aby šíření selhání zabránila.
Circuit breaker je v podstatě proxy, která má tři stavy (polohy) regulující volání dané služby.

  • zavřený - požadavky jdou skrz, v případě chyby se zvýší failure counter a při dosažení určité hranice dojde k přepnutí do stavu otevřeno
  • otevřeno - požadavky se neprovádějí, volající dostává ihned informaci, že volání není možné provést (umožňuje fail fast), po dosažení timeoutu dochází k přepnutí do stavu zkušební provoz
  • zkušební provoz - požadavky se pustí skrz, pokud projdou, zresetuje se failure counter a přejde se do stavu zavřeno. V opačném případě dochází zpět k přechodu do stavu otevřeno.

Aby mohl Circuit breaker správně fungovat, je nutné použít izolovaný thread pool a samozřejmě timeouty, aby nedocházelo k blokujícím vláknům.

Nasazení a transparentnost

Jednou ze základních vlastností, kterou by měl systém splňovat při nasazení do produkce, je transparentnost. Vývojáři často věří, že jejich práce končí ve chvíli, kdy proběhne code review a nebo proběhne formální předání oddělení kvality. Nic není vzdálenější realitě.

The true birth of a system comes not on the day that design and development begins or even when the project is conceived, but on the day it launches into production.

Transparentnost systému je především viditelnost a to na několika úrovních. Globální stav systému by měl umožnit komukoliv získat přehled o aktuální kondici systému. V knize se hovoří o dashboardu s jednoduchým semaforem (červena, oranžová zelená), který jednoduše vyjadřuje aktualní stav. V rámci tohoto stavu se monitorují a vyhodnocují následující atributy.

  • Očekávané události v aplikaci nastaly/nenastaly např. zálohy, garbage collection
  • Nastala/Nenastala nějaká neočekávaná událost např. pád serveru
  • Stav komponent/služeb aplikace např. stav Circuit breaker
  • Všechny sledované parametry jsou/nejsou v normálu

Kromě toho by měl existovat dashboard/nástroj zobrazující detailnější stav tj. přehled na nižší úrovni systému. To je typicky realizované přímým sledováním monitorovacích prostředků např. logů. Na rozdíl od Globálního stavu tento přehled slouží k řešení aktuálních problémů (troubleshooting). My za tímto účelem používáme Splunk.


Without transparency the system will drift into decay functioning a bit worse with each release.

Systems can mature well if and only if they have some degree of transparency.

Anomalies and events can remain forever mysterious or they can be valuable lessons learned. Transparency makes difference between a system that improves over time in production and one that stagnates or decays.

Technologie/Nástroje a monitorování

Existují dva přístupy k monitorování takzvaný white-box a black-box, které se liší tím jestli fungují vně a nebo uvnitř monitorovaného systému.

  • white-box monitoring je nasazen uvnitř sledovaného systému a typicky se jedná o logování.
  • black-box monitoring je nasazeny mimo sledovaný systém. Většinou se jedná o proces, který "olizuje" sledovaný systém.

Možná si pokládáte otázku, proč nestačí logy. Pokud vám sledovaný systém takzvaně zatuhne, pak neprodukuje většinou ani žádné logy. Black-box monitoring může poskytnout alespoň nějaké informace např. vytížení CPU, RAM, IO operace síť, chování garbage collectoru v JVM, které mohou pomoci při průzkumu toho co se děje.


Pro JVM je základním nástrojem pro monitoring JMX. Pokud jste tuto technologie nikdy nepoužily nebo o ní moc nevíte, doporučoval bych vám se na ní podívat. Kromě monitoringu se používá i pro management. Vystavení jednotlivých komponent aplikace přes JMX umožňuje jejich dynamickou správu. My pomocí této technologie za běhu aplikace měníme úrovně logování, provádíme health checky a nebo nastavujeme sizing jednotlivých thread poolu. Mimochodem schopnost restartovat jednotlivé komponenty a služby aplikace namísto restartů celých serverů je jedním z požadavků Recovery-oriented computingu.
Co se týká vlastních atributů, které je dobré monitorovat a tedy vystavit přes JMX a nebo jinou technologii, kterou používáte.

  • Stav/Zdraví integration points (počet chyb)
  • Indikátor provozu (počet požadavků, jejich trvání, velikost dat)
  • Stav resource poolu (počet aktivních/idle vláken, maximální počet vláken, doba čekání na vlákno)
  • Stav databázového connection poolu (počet aktivních/idle spojení, maximální počet spojení, doba čekání na spojení)
  • Stac cache - hit/miss poměr, zaplněné jednotlivých regionů, počet/velikost objektů

Rekapitulace

Samozřejmě se mi do jednoho článku nemůže povést vměstnat všechny moudra, která jsou v knize obsažena. Kniha se dost obšírně věnuje oblasti kapacity a jejího plánování a nebo SLA samostatné aplikace a vlivu externích služeb na SLA. Není ani pochyb o tom, že bych knihu doporučoval k přečtení. Nicméně bych případného čtenáře rád varoval před tím, že její některé části jsou více orientované na svět Javy - tunning a chování GC. Nečekejte, že v knize najdete informace týkající se provozu a nasazení v rámci cloudu. Kniha mi přišla na dobu vídáni pionýrská v tom, že akcentovala některé myšlenky na nichž je postavený celý DevOps.


Don't avoid one-time development expenses at the cost of recurring operational expenses.


You early decisions make the biggest impact on the eventual shape of your system. The earliest decision you make can be the hardest one to reverse later.


K dobru přidávám ještě mind mapu mých poznámek.


čtvrtek 15. srpna 2013

CZ Podcast 81 - Refaktoring, agile a pokec s Roumenem

V pořadí 81. díl jsme strávili pokecem s Romanem Štroblem alias Roumen a tématem byl refaktoring a tool, na kterém Roumen dělal. Bavili jsme se obvykle o novinkách a přidali jsme trochu mudrování na téma agile.

pondělí 29. července 2013

Když je během vývoje intuice špatným rádcem - release a testy

Během vývoje máme občas tendence řídit naše rozhodnutí intuicí, bohužel ne vždy je to dobrý rádce a občas je lepší dělat pravý opak. Vybral jsem několik příkladů kdy je lepší se intuici vyhnout. Většinou se jedná o příklady spojené s releasováním a testy.

Četnost releasů

Problém: release je velmi křehký a bývá sním spojeno plno problémů

Intuice: snížme četnost releasů. Je bezpečnější vystavit se těm problémům jednou za tři měsíce než každý měsíc.

V tomhle případě je docela zřejmé, že nám prodloužení releasovacího okna moc nepomůže. Problémy, které jsou s releasem spojené, nám nikam nezmizí. V horším případě se naopak nakumulují. Pokud releasujete větší celek je složitější dohledat případnou příčinu problému. Dalším poměrně nepříjemný problém představuje rollback. Čím větší je releasovaný celek, tím víc toho musíme odstranit a tím komplikovanější proces to je. Navíc rollbackem přijdeme úplně o všechny změny. Intuice je v tomhle případě špatný rádce, dělejte přesný opak if it hurts do it more ofter. Většina problémů s častým releasem vychází z nedostatečné automatizace celého releas procesu a nebo přílišné závislosti na manuálních testech.

Právě manuální testy resp. jejich doba by měla ze začátku udávat takt releasování. Jestliže potřebujeme manuálně otestovat aplikaci a trvá nám to týden, pak bychom se měli snažit ze začátku o přibližně týdenní releasovací cyklus. Zároveň bychom se měli snažit tyto testy postupně automatizovat. Můžeme si dovolit přístup chytré horákyně a zvýšit frekvenci releasů tím, že ne pro všechny změny jsou manuální testy potřeba a manuálně otestovat jenom část aplikace. To platí v případě, kdy nám chybí jenom část automtických testů a nebo jejich pokrytí není dostatečné.


Build/release procesu

Problém: release/build musí být být přehledný a pochopitelný

Intuice: pojdmě release zdokumentovat, potom ho může každý udělat

Tohle není primárně protiargument intuice, ale jakákoliv dokumentace zastarává od okamžiku kdy je vytvořena. Měli bychom se snažit celý proces automatizovat bez ohledu na to, jestli je to build a nebo release. Dokumentace by měla popisovat high level koncept/design (co), ale nikoliv vlastní provedení (jak). Jak se praví v eposu Píseň Ohně a Ledu (v seriálovém provedení Hra o trůny): slova jsou jenom vítr. Oproti tomu více či méně přehledný kus kódu automatizující cokoliv je právě tím jediným a autentickým zdrojem pravdy. Další nevýhoda dokumentace tkví v kontextu. Dokumentace, kterou bude psát člověk, který zná danou věc dokonale, bude vypadat jinak než dokumentace, kterou budete psát s vědomím toho, že čtenáři bude chybět kontext. Pokud někomu napíšete proveďte restart služby XYZ, předpokládáte že člověk ví, kde se ta služba nachází a jak ji restartovat. To člověk může udělat několika způsoby, počínaje kill -9 přes shell skript až po prostředky operačního systému. Přitom služba resp. pisatel dokumentace očekává, že se použije přesně jeden konkrétní a vůbec ho nenapadne, že by to člověk dělal jinak. Přesně to je kontext, který se zachycuje velmi těžko a je uvozen zkušenostmi toho, kdo dokumentaci píše a používá. Jinými slovy je to na vodě. To je další důvod, proč se vyplatí spoléhat na automatizaci místo dokumentace.


Testování až po implementaci

Problém: testování je drahé

Intuice: testujme až na konci, abychom drahý krok neopakovali

Tenhle argument nepostrádá jistou logiku, pokud by ovšem neplatilo, že čím déle se chyba najde, tím větší náklady jsou na její odstranění. V kombinaci s málo častými releasy je to doslova jako sedět na sudu se střelným prachem s odpáleným doutnákem. Představte si, že najdete závažnou chybu těsně před releasem, který je naplánován jednou za šest měsíců. Tahle intuice je opět důsledkem nedostatečné automatizace testovacího procesu. Platí přímá úměra: čím více automatických testů, tím častější zpětná vazba a odhalení potenciálních problémů. Pokud jsou manuální testy nákladné, je potřeba se zamyslet nad tím, jak jejich penzum snížit a vyvážit je testy automatickými. Samozřejmě není to zadarmo a náklady na udržování automatických testů pro UI mohou být drahé. Obzvláště pokud dochází neustále ke změnám nebo neexistuje dostatečná abstraktní vrstva (testovací DSL), která test odstiňuje od low level implementačních detailů.

Cenu má i testování neúplné implementace. Části systému, které nejsou k dispozici, nahradíme mockem. Sice nemáme systém kompletní z pohledu implementace, ale je kompletní z pohledu funkcionality. Můžeme na něm vyzkoušet určité vzorce chování uživatelů. Pokud s testováním otálíme, můžeme mít na konci sice implementačně kompletní funkcionalitu, která ovšem nebude dávat smysl z pohledu uživatele a nebo bude mít špatnou použitelnost. Pokud nám test po první třetině implementace ukáže, že je celá funkcionalita k ničemu, můžeme jí zahodit a investovat zdroje do něčeho jiného a nebo jí upravit, aby dávala smysl. Testy a teď myslím jakékoliv testy jsou lakmusovým papírkem, který indikuje kvalitu a poskytuje zpětnou vazbu, která je při vývoji kritická.


Nestabilní automatické testy

Problém: testy často padají

Intuice: výsledky testů ignorujeme nebo defektní testy úplně smažeme

Nestabilní testy představují mor. Přestože nám intuice říká: pojďme je ignorovat, nedělejte to. Potíž s testy, o kterých řeknete: "Ano tenhle test občas padá", je v tom, že když začnou padat doopravdy, vy na to nepřijdete. Mimo jiné to znamená, že musíte nějak kontrolovat, že to je očekávané selhání. Další problém spočívá v tom, že to je nepřehledné. Pokud vám dlouhodobě neprochází 5 ze 100 testů ještě to neznamená, že to je jedna a ta samá pětice. Ignorování testů vede k menší ostražitosti, která přechází v letargii. Pokud jsou nějaké testy nestabilní, například protože závisejí na službách třetích stran, je potřeba refaktoring. Často se jedná o ne úplně vhodně napsané testy, kde se místo integrace testuje služba třetí strany. Pokud je test dobře napsán a přesto je nestabilní, lze udělat speciální strategii spouštění toho testu. Tuším, že jsem to viděl v prezentaci Continuos testing v Google, nestabilní testy se několikrát zopakují. Nestabilní testy mají re-try strategii, která naplánuje spuštění testu po určitém intervalu.


V tomto článku jsem vybral několik příkladů, kdy se vyplatí jít proti intuici. Určitě vás napadnou nějaké další a já budu rád, pokud se o ně podělíte v komentářích.


sobota 20. července 2013

Project Phoenix fikce popisující realitu fungování IT a přechod k DevOps

Dočetl jsem skvělou knihu Phoenix Project, která popisuje sice imaginární, nicméně v realitě odrážející se, příběh přechodu k DevOps a Kanbanu. Všechny ty pasti a pastičky, kterými se propletá hlavní hrdina Bill Palmer, zrcadlí svět IT a jeho nefungování v plné nahotě. V tomto článku bych vám chtěl přiblížit komentované postřehy, které považuji za klíčové.

Intro

Kniha začíná poměrně nečekaným uvedením hlavního hrdiny do role VP pro IT operations ve firmě, která vyrábí autodíly. Horší entrée si neumíte ani představit. Firma dlouhodobě neplní stanovené cíle, prodělává, její akcie padají dolu rychleji než popularita Jana Fischera. Konkurence jim dává pořádně na pdel a podle analytiků bude nejspíše firmu potřeba rozdělit a prodat. Aby té smůly nebylo dost, ve firmě krouží banda auditorů se soupisem porušení bezpečnostních a právních pravidel, který by pokryl více papírů než únos Ivety Bartošové. Naděje celé firmy, počínaje vedením, přes marketing a konče u prodejního oddělení, se upínají k projektu Phoenix, který by měl výrazně pomoci dosáhnout cílů společnosti. Projekt se několikrát opozdil a jeho rozpočet se pořádně prodražil, jeho aktuální stav je neurčitý a datum nasazení je nebezpečně blízko. Na hlavního hrdinu padají kostlivci ze skříně zcela neočekávaně, přesně ve chvíli kdy si myslíte, že to nemůže být horší.

Na scéně se postupně objevuje postava mentora Erika, který nechává hlavního hrdinu nahlédnout do výrobního procesů továrny a dospět k zjištění, že správná cesta k řízení práce je Kanban a modus operandi fungování vývojářů a lidí z operations je potřeba vyměnit za DevOps. K dalším výrazným postavám patří Brent, DeusEx machina zasahující prakticky kdykoliv se objeví incident na produkci, případně je potřeba udělat nějakou složitější práci. Klacky pod nohy IT hází šéfka retail oddělení Sarah a drahnou dobu i John odpovědný za bezpečnost.

Zdroje činností v IT a jejich vliv

Jeden z prvních problémů, který musí Bill Palmer vyřešit, je výpadek výplatního systému. Po dlouhém pátrání přijdou na to, že někdo na nasadil šifrování čísel sociálního pojištění (obdoba našeho rodného čísla a zákonu o jeho utajení), které způsobilo nevalidní data v databázi. Postupně se ukazuje, že změna nebyla testována (nebylo testovací prostředí) a někdo tu změnu propašoval bokem mimo jakýkoliv changemanagement.

The only thing more dangerous than a developer is a developer conspiring with security

Information security is always flashing their badges at people and making urgend demands, regardless of the consequences to the rest of the organization

Hlavnímu hrdinovi jde hlava kolem z množství práce, která na IT oddělení padá. Z pohledu zákazníků IT oddělení (business, marketing atd.) to vypadá, že všechny jejich projekty jsou zpožděné a i ty nejjednodušší požadavky trvá vyřídit neúměrně dlouho. Jak se brzo ukáže, tyto požadavky jsou jenom jednou čtvrtinou toho, co IT běžně řeší nebo je po něm požadováno. S tím by se mělo počítat a zohlednit při odhadu výkonu/propustnosti týmu.

  • business projekty - úkoly vycházející z potřeb core businessu např. udělějte feature XYZ
  • interní IT projekty - úkoly, které si stanovuje IT, aby mohlo efektivně fungovat např. vývoj monitorovací infrastruktury, nástroje pro vývoj, sběr a analýza logů
  • změny - nasazení záplat, změna konfigurace, deploy nových mašin a jiné záležitosti související s operačními požadavky na doručované aplikace/skužby
  • neplánovaná práce - urgentní požadavky mimo plán např. řešení incidentů, hotfixy

Tyhle čtyři zdroje činností IT se perou o sdílené zdroje. První věci, kterou náš hlavní hrdina udělá, a vy byste měli rovněž, je rozdělení plánování zdrojů na tyto čtyři oblastí a identifikace omezení, která způsobují, že se tyto čtyři činnosti vzájemně blokují. V případě knihy a jejího děje je omezením DeusEx machina vývojář Brent, na kterém se sbíhají všechny důležité požadavky.

Vybudujte zeď

Processes are supposed to protect people. We need figure out how to protect Brent.


Před Brenta doslova a do písmene postaví zeď v podobě manažera, přes kterého přicházejí všechny požadavky. Bylo totiž zvykem Brentovi přímo volat nebo posílat emaily s tím, že něco je potřeba udělat teď hned a urgentně. Brent potom nedělal nic jiného kromě Neplánovné práce přestože byl potřeba na projektu Phoenix. S Brentem pracují tři vývojáři, aby se předalo jeho know how dál. Postupně se podaří požadavky kategorizovat, zdokumentovat jejich zpracování a nakonec jejich vyřízení kompletně přeberou další vývojáři. Brentovi ruce jsou potom kompletně k dispozici projektu Phoenix.


Unlike other categories of work, unplanned work is recovery work, which almost always takes you away from your goals. That's why it's so important to know where your unplanned work is coming from.


Z tohoto minipříběhu plyne ponaučení, že úkoly by se měly lidem předávat řízenou formou a měl by pro ně existovat jeden zdroj. V knize používají Kanban a co není na Kanbanu, na tom se nedělá. Je velmi přínosné, aby se spolu lidi bavili o tom, co je potřeba udělat. Žádná věc, a to ani v IT, se ovšem nestala jenom protože jste o ní s někým mluvili nebo poslali skupinový mail. Samozřejmě pokud u vás nefunguje bájná skupina japonských inženýrů Onoseto a Samoseto. Bez jednoho autoritativního zdroje práce vám hrozí, že budete pracovat jenom na neplánované práci. Navíc ani nebudete schopni identifikovat její zdroj a způsob jak ji eliminovat.


Unplanned work kills your ability to do planned work, so you must always do whatever it takes to eradicate it.


Work In Process

V metodologii Kanban vývoj funguje podobně jako výrobní linka v továrně. Na vstupu je úkol/zadání, které pluje přes jednotlivé fáze linky. Pro nové features může linka může mít linka fáze - návrh, kódování, testy a deploy. Pro provisioning nových strojů to může být - alokace hardwaru, konfigurace, instalace software a předání. Když je úkol uvnitř výrobní linky má označení Work In Process (zkráceně WIP). Úkol je splněný až ve chvíli kdy opustí výrobní linku. Čím více úkolů máte paralelně ve výrobní licence, tím více WIP úkolů tj. práce která stále nebyla dokončená.


Remember, outcomes what matter - not to the process, not controls, or, for that matter, what work you complete


V našem příběhu se ukáže, že důvodem proč má IT oddělení cokoliv doručit včas je právě vysoký počet WIP úkolů. Díky analýze se přijde na to, že zdrojem WIP je Brent, na kterém se všechno sbíhá a úkoly musí čekat, než je postupně vyřeší. Dalšími faktory ovlivňujícími WIP je technologický dluh firmy. Nakonec hlavní hrdina sáhne k poměrně drastickému opatření a po určitou dobu zakáže přijímání dalších úkolů dokud si nedokončí aktuální WIP úkoly. Znovu otevření je možné jenom pro úkoly resp. výrobní linky, které nezávisí na jejich klíčovém omezení - Brentovi.


Proč je důležité nedělat všechno

Hlavní hrdina si velmi rychle uvědomí, že tempem kterým na IT oddělení padají nové úkoly dojde dříve nebo později k opětovnému zahlcení a růstu WIP. Výsledkem bude, že IT oddělení nebude schopné dostát svým závazkům a vše se bude opožďovat proti plánu. Na scénu vstupuje mentor Erik, který vysvětluje, že nikoliv všechny úkoly, které na IT padají z venku jsou skutečně potřeba. Klíčem je pochopit, které z těch úkolů souvisí s cíli společnosti.


Společně s hlavním hrdinou postupně navštěvujete jednotlivá oddělení (marketing, prodej atd.) s cílem pochopit, jak se cíle společnosti odrážejí v jejich práci. To mu umožňuje identifikovat jejich klíčové potřeby vzhledem k IT a zároveň pochopit, čím by je mohlo IT ohrozit. Jedním ze zdrojů velkého množství úkolů jsou výsledky auditu. Nakonec se ukáže, že díky toku zpracování finančních transakcí je možné velkou část IT systému vyjmout z auditu a snížit počet úkolů.


Remember, it goes beyond reducing WIP. Being able to take nedless work out of the system is more important than being able to put more work into the system. To do that, you need to know waht matters to the achievement of the business objectives, whether it's projects, operations, strategy, compliance with laws and regulations, security, or whatever


Poznámka pod čarou: a z toho plyne ponaučení, že výsledky auditu lze vykládat stejně pružně jako naší ústavu.


Velké projekty nefungují a velké DevOps finále

Hlavní hrdina dochází k závěru, že projekt Phoenix, který se jim v potu tváře nakonec podaří nasadit, vlastně není úplně potřeba vzhledem k cílům společnosti. Jinými slovy, že práce mnoha lidí a miliony investovaných dolarů padnou vniveč a tím pádem i naděje firmy na přežití. Jedním z posledních záchvěvů naděje je sestavení týmu, který by v krátkém čase implementoval projekt umožňující lepší zacílení prodejní kampaň. V týmu jsou obsazeni nejenom lidé z developmentu, ale i z operations a businessu. Co vám mám povídat, je to happyend. Projekt je doručen přesně na čas před Černým pátkem (den kdy američané nejvíce nakupují) a umožňuje firmě dosáhnout nejlepší výsledků za několik let. Firma je zachráněna a nehrozí její prodej na části s outsorcováním IT do Bengalore.

Velké projekty většinou nefungují, protože stojí moc peněz a nikdy se je nepodaří doručit včas. Rozhodujícím faktorem je takzvaný Time to market, tedy jak rychle se vám podaří dostat konkrétní produkt na trh. Není potřeba, aby byl dokonalý, je potřeba aby tam byl. Je to o zkoušení co by se mohlo uchytit, protože dokud to nezkusíte, nemůžete vědět, jak jej zákazníci přijmou a nebo jak zareaguje vaše konkurence. Všechny tyto atributy hrají do karet proti velkým projektům.


Cílem knihy je provést čtenáře změnou organizace a fungování IT, která se nazývá Three Ways.


The First way is all about controlling the flow of work from Development to IT operations.

The Second way is about creating constant feedback loops from IT operations back into Development, designing quality into the product at the earliest stages.

The Third way is about creating a culture that reinforces the value of taking risks and learning from failure and the need for repetition and practice to create mastery


Závěr

Žádný článek popisující knihu nemůže být stejně vyčerpávající jako vlastní kniha, mnoho zajímavých informací a z nich plynoucích konsekvencí jsem musel vynechat - nezůstalo místo na zkrácení dodacího cyklu z devíti měsíců na dny tj. reminiscence continuous delivery, nemohl jsem se ani věnovat tomu, proč je důležité nechat lidem nějaký volný pracovní čas - možná to napravím v některém z dalších článků. Jsem v pokušení napsat, že pokud to s DevOps myslíte vážně, představuje pro vás tato kniha povinné čtení. Nebyla by to ovšem celá pravda, protože tato kniha nabízí podle mých zkušeností zcela reálný popis toho jak funguje IT oddělení valné většiny firem.


When IT fails, the business fails. It stands to reason that if IT is organized so that it can win, the business wins, too.

pátek 12. července 2013

Canary Releasing

Existuje několik způsobů, jakými lze doručovat kód do produkce. V tomto článku vám zkusím přiblížit takzvaný Canary Releasing, který umožňuje velmi bezpečné nasazování změn. Podíváme se na jeho charakteristiku a výhody, které přináší.

Slovo Canary není použito pro srandu papouškům, ale symbolizuje paralelu s metodou používanou v těžařském průmyslu. Kanárci se totiž používali jako indikátor škodlivých plynů v nově vyhloubených štolách ještě před tím, než došlo k rozvoji zařízení pro jejich detekci. Do štoly se nejdříve vypustil kanárek a pokud přežil sfárali i horníci. V případě Canary Releasing nám kanárka nahrazuje uživatel resp. jejich vzorek. Pojďme se podívat, jakým způsobem to funguje. Vybral jsem příklad s HTTP serverem, ale obecně to funguje jednoduše prakticky pro jakoukoliv bezestavovou službu.

Představte si, že máte v produkci server, na který byste rádi nasadili novou funkcionalitu nebo záplatu. Zároveň byste ovšem chtěli dosáhnout toho, že to bude bez ztráty kytičky pro uživatele tohoto serveru. Jinými slovy nechcete mít výpadek serveru po dobu nasazování a nebo v případě, že se něco pokazí. Předpokládejme, že se jedná o standardní HTTP server. Před tento server si nasadíte chytřejší HTTP proxy. Pro novou funkcionalitu nebo záplatu nasadíte zbrusu nový server. Na tento server vám bude HTTP proxy automaticky přeposílat požadavky splňující určitá kritéria např. podle uživatele, typu klienta atd. Zbytek požadavků je směřován stále na původní server. Ve chvíli kdy máte otestováno, že nově nasazený kód nic nerozbil, překonfigurujete HTTP proxy, aby směřovala provoz na nový server a za nějaký čas původní server odstavíte.



Canary Releasing má několik výhod

  • Případná chyba, ke které může vždy dojít, má dopad pouze na zanedbatelné množství uživatelů.
  • Před přepnutím provozu můžete spustit smoke testy, které ověří, že je vše korektně zkonfigurované.
  • Lze tímto způsobem otestovat věci, které se těžko simulují na testovacím prostředí například díky rozdílné topologie nebo charakteru zátěže.
  • Jednoduchý rollback. Při klasickém releasu se v případě problému prodlužuje doba odstávky a rollback na systému, kde byly například provedený konfigurační změny, je prakticky nemožný.
  • Můžete provést A/B testování a zjistit, jak na novou funkcionalitu reagují uživatelé.

Určitou nevýhodu je fakt, že pokud tímhle způsobem releasujete větší cluster, musíte mít k dispozici odpovídající hardwarovou kapacitu. Vedlejším efektem je fakt, že Canary Releasing umožňuje jednoduší automatizaci. Nemusíte řešit aktualizaci prostředí, při které může dojít k interferencím, a místo toho řešíte deploy jedné z vody na čisto. Na začátku jsme naťuknul, že se hodí pro všechny bezestavové služby. V případě služeb, které mají sdílený stav (databáze, cache) je to problém pokud dochází k zpětně nekompatibilním změnám. V takovém případě se Canary Releasing nehodí.