Přejít k navigační liště

Zdroják » Různé » Jaký byl SREcon’16 Europe

Jaký byl SREcon’16 Europe

Články Různé

Letošní SREcon byl v Dublinu. Od 11.7. do 13.7. se zde setkali velcí hráči (Google, Facebook, Microsoft, Amazon) s těmi menšími a vyměňovali si spoustu zkušeností.

Nálepky:

Text původně vyšel na autorově blogu.

Letos jsem se mohl poprvé zúčastnit konference SREcon. Nebyl jsem z ČR sám, zastoupení měli Avast, Seznam nebo Skype či Algolia. Dohromady asi 5 lidí. Konference byla vyprodaná. Byla tu řada lidí z Googlu. Když vás zajímalo, jak se pracuje v Dublinském Googlu nebo Facebooku, mohli jste si o tom s nimi promluvit. Celá konference byla ve 4 sálech. Jeden hlavní sál se po keynote rozdělil na dva, další dva byly hlavně pro workshopy a lighting talky.

Co to SRE je?

SRE je v základu jednoduchá myšlenka o tom, že převedete postupy z vývoje software do provozu systémů.

Podrobně to vysvětluje skvělá kniha Site Reliability Engineering od lidí z Googlu, kde jsou detaily, jak to mají v Google implementované. Je to taková bible SRE a vůbec první kniha zastřešující tento obor.

SRE se dnes používá ve velkých firmách jako je  Facebook, Heroku, LinkedIn, Amazon či Microsoft, ale i v menších jako jsou startupy Intercom, SoundCloud nebo v u nás Apiary.

Nejzajímavější přednášky

Následují mé postřehy k přednáškám. Pokud vás něco zaujme, videa budou za pár týdnů veřejně dostupné na youtube.

Splicing SRE DNA Sequences in the Biggest Software Company on the Planet – Greg Veith, Microsoft

Greg mluvil o transformaci v Microsoftu a jeho práci na zavádění SRE do práce týmů kolem MS Azure. Začali budovat SRE kolem roku 2009 a doteď transformace probíhá nejen v MS Azure, ale v celé firmě. Pro zavedení byly klíčové tři věci. Za prvé vlastní start SRE týmu, zavedení principů. Za druhé aplikaci principů, abyste model otestovali. Za třetí musíte akcelerovat a vylepšovat ho tak, aby zahrnul celou firmu. Gregova přednáška byla také hodně o tom jak je MS velká firma, a tak je to práce pro hodně lidí, přesto hlavní SRE tým je asi jen 5-7 lidí.

Diskuze o tom, kolik SRE lidí má být ve firmě, byla celkem častá. Osobně se mi libí názor z LinkedIN, kde uvádějí 1:10 poměr SRE a Engineeringu. U velkých firem jako je Google je to asi 5 %. Tomu 1:10 odpovídáme i v Apiary a myslím, že je dobré se toho držet.

Doorman: Global Distributed Client-Side Rate Limiting – Jos Visser, Google

Jos mluvil o projektu Doorman, který používají v Youtube limitaci zdrojů v distribuovaném systému pro omezení zátěže MySQL. Doorman je napsaný v Go langu, používá pro komunikaci gRPC. Zajímavé je hlavně to, že nemá žádný diskový prostor pro ukládání stavu a drží informace jen v paměti. Pokud dojde k výpadku, tak se pustí learning mode, od klientů se dozví všechno, co potřebuje, a potom pokračuje ve funkci.

Building and Running SRE Teams – Kurt Andersen, LinkedIn

Kurt mluvil o knize Team of Teams a jak aplikovat vojenské postupy do SRE a systému rozhodování. Jako klíčové viděl hlavně posun důležitých rozhodnutí na lidi, co jsou nejblíže tomu tu akci potom vykonat.

The Production Engineering Lifecycle: How We Build, Run, and Disband Great Reliability-focused Teams – Andrew Ryan, Facebook

Andrew mluvil o Production Engineeringu (PE) ve Facebooku. Je to obdoba SRE. Mají asi 700 lidí v šesti kancelářích po celém světě. Drží poměr 1:10 podobně jako LinkedIn. Hodně řeší, nakolik je v každém týmu potřeba PE a zda je produkt opravdu tak důležitý pro firmu, aby bylo nutné mít oncall (min. 12+ PE). Pokud ne, tak se oncall přesune na vývojáře a PE může působit jako poradce, jak věci zlepšit. Naopak na core produktech mají například pro cache pět paralelních rotací na oncallu.

How to Improve Your Service by Roasting It – Jake Welch, Microsoft

Jake mluvil o tom jak přenést znalosti o komplexních systémech od autorů k dalším lidem do firmy. Doporučil vytvořit skupinku a věnovat 45 min týdně po dobu 10 týdnů na předávání znalostí. Je důležité, aby to někdo řídil. Role Roast Master je pro úspěch klíčová. Musí hlídat jak tón řeči a vůbec vyjadřování, aby to nesklouzlo k osobním antipatiím a drželo se to v racionální rovině. Agendu je potřeba správně rozdělit po komponentách nebo subsystémech a držet se toho, na konci potom stanovit co se bude probírat příště a nepřekračovat čas 45 min.

What SRE Means in a Start-up – Brian Scanlon, Intercom

Brian mluvil o SRE ve startupu, kde je situace jednodušší, pokud se prostě nastaví politika od začátku, často se používá hostovaná infrastruktura, která celou věc usnadňuje. Celkem to kopírovalo to, jak to děláme my v Apiary.

Hodně je vidět, jaký velký rozdíl a kolik práce to dá, pokud chcete firmu předělat na SRE (brownfielding) nebo začnete hned.

The Many Ways Your Monitoring Is Lying to You – Sebastian Kirsch, Google

Skvělá přednáška o tom, jak nemůžete věřit každému grafu v monitoringu. Doporučuji shlédnout, až bude video, bylo tam hodně příkladů. Jde o to, že věci, které uváděl, nejsou pro mě například vůbec nové díky lekcím z numerické matematiky a statistiky na ČVUT, ale ne každý má statistický background a nebývá to až tak běžná součást Computer Science.

Next-generation Alerting and Fault Detection – Dieter Plaetinck, raintank

Dieter hodně zdůrazňoval použití machine learning na detekci anomálií a to, jak to prakticky moc nefunguje, a proto se uchylujeme k streamovanému zpracování dat pomocí nástrojů jako je Spark nebo Riemann.io. Ale nejzajímavější věc zmíněná v přednášce je Bosun, také IDE pro alerting, kde se dá dělat historický testing, ladění alertů, vyhodnocování na základě dalších dat. Pro podrobnosti doporučuji projít články na blogu.

DNS @ Shopify – Emil Stolarsky, Shopify

Krátký lighting talk o managementu DNS používající Git a CI. Čerstvé open source přímo před konferencí.

Availability Objectives of SoundCloud’s Microservices – Bora Tunca, SoundCloud

SoudCloud je autorem Prometheus.io monitoringu a měli dvě přednášky, co jsem viděl. Mají dnes microservice architekturu rozdělenou do několika vrstev a podle toho je daná požadovaná dostupnost. Také pracují s graceful degradation, pokud to jde. Jako příklad jsou třeba statistky k jednotlivým trackům. Modul stats má SLO 95% a tracks mají 99.995%, a tak je to zohledněno i na UI.

The Knowledge: Towards a Culture of Engineering Documentation – Riona MacNamara, Staff technical writer, Google

Riona mluvila o hrozném stavu dokumentace v Google. Přirovnala ji k testování v roce 2005. Jak to celkově zhoršuje produktivitu, spolehlivost a rychlost. Zkoušeli to několikrát vyřešit pomocí vytvoření komplexního dokumentačního systému, který vytvoří někdo pro celou firmu a zeshora se to prosadí.

Tento přístup nefungoval a proto v roce 2014 úplně změnili přístup, začali zdola nahoru od jednotlivých engineerů a vytvořili systém g3doc, který dnes používá 10k projektů v google a mají přes 17k autorů, kteří do dokumentace přispívají.

Klíčové bylo dát dokumentaci přímo do repositářů projektu, mít to v jednoduchém formátů čitelném přímo v IDE. Zvolili markdown, který si potom silně vylepšili. Mají potom na serverové straně systém, který vygeneruje HTML a publikuje dokumentaci na url, které se dá lehce podle jména projektu odhadnout.

Projekt bohužel není open source, ale snad jednou bude. Díky spoustě googlerů, kteří do projektu v rámci svých 20 % přispěli, je tam hodně funkcí, které my máme díky Sphinx.

Odkazy na zdroje

Shrnutí

Pokud se zajímáte o transformaci engineeringu a říká vám něco DevOps nebo SRE je to konference pro vás. Pokud vás to zajímá a chtěli byste si o tom promluvit, klidně mě kontaktujte. Bohužel jsem nenašel vhodnou konferenci v Česku, kde o tom mluvit, aby se to dostalo více do povědomí firem.

Další SREcon bude příští rok zase v USA (March 13–14, 2017, SF), Evropě (Dublin) a také poprvé v Asii (May 22–24, 2017, Singapur).

Komentáře

Subscribe
Upozornit na
guest
0 Komentářů
Inline Feedbacks
View all comments

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.